ビッグデータクラウドネイティブの発展の道筋をどう見るか - 2023年雲奇カンファレンスの考察

2023年雲斉会議は予定通り杭州で開催されました。その前身は Alibaba Cloud Developer Conference でした。国内最大のパブリッククラウドコンピューティング企業であるアリババの本拠地として、今年のテーマは「計り知れない価値を生み出すコンピューティング」です。このカンファレンスの主なテーマは、ビッグモデルとクラウドコンピューティングの 2 つです。ビッグモデルの人気と、将来予測される応用シナリオは、皆の注目を集めています。午前のセッションでは、Alibaba Cloud における人工知能の開発に焦点が当てられ、クラウド コンピューティングが人工知能のコンピューティング能力を強力にサポートしていることも説明されました。午後のセッションでは、クラウド製品ラインの責任者がコンテナ、ストレージ、ネットワーク、データベース、サーバーレス、ビッグデータの観点から今年の開発と改善の成果を紹介しました。ビッグデータ実践者として、パブリッククラウドとコンテナ化開発の一般的な傾向の下で、私たちの焦点はもはやビッグモデルだけではありません。また、今後数年間のビッグデータの主要な発展方向は何か、ビッグデータの技術的進化の道筋はどうなるかにも注目する必要があります。

1. 主要技術フォーラムからのクラウド技術の主な進歩

雲奇カンファレンスの午前のセッションでは、アリババクラウドの創設者である王建氏が講演し、クラウドコンピューティングの第3波の到来について語った。同時に、彼はクラウドコンピューティングの第一波についての理解を詳しく説明し、NetflixとmiHoYoの事例を用いて、クラウドコンピューティングの波の到来によってもたらされたメリットを表現しました。第 2 の波は、銀行のクラウドへの移行など、伝送企業のクラウドへの移行によって表されます。第3波の画期的な出来事は、北京冬季オリンピックの基幹システムのクラウドへの移行です。将来、クラウド コンピューティングはほとんどの企業にとって第一の選択肢となるでしょう。その根本的な理由は、パブリック クラウドの規模とクラウド コンピューティングの才能にあります。これは、従来の分散型の手工芸工房が集中型の大規模工場へと進化したようなものです。午後のメイン技術フォーラムを詳しく見て、技術コンテンツやコア製品に関してどのような改善が行われたか、そしてそれがビッグデータの分野にどのような影響を与えるかを見てみましょう。以下に主な製品技術講演をまとめます。

エラスティック コンピューティング/コンテナーに関しては、クラウド ネイティブを採用することが中心であり、CIPU + FeiTian オペレーティング システムに基づくエラスティック コンピューティングの第 3 フェーズがリリースされました。 ECS コンピューティングは、Intel、自社開発の Yitian 710、AMD チップをサポートしており、各チップの主な焦点は異なります。同時に、異なる ECS インスタンスごとに価格が分割されます。エコノミーインスタンスは、主に学生、中小企業の開発者、テスト環境を対象としています。 HPC インスタンスと高性能かつ高安定性のインスタンスは、主に特殊な要件を持つ業界を対象としています。 ECI コンテナの機能が導入されました。たとえば、ある大手企業は、ECI コンテナの機能をベースに独自の弾力性のあるビッグデータ システムを構築しました。驚くべきことに、1 日あたり 200 万個の ECI インスタンスを作成できます。

ストレージ：クラウド化すればビッグデータ分野でも使われる基本サービスとなるAlibaba CloudのオブジェクトストレージOSSに注目が集まっています。標準、低頻度、アーカイブの 3 つの OSS ストレージ タイプと、アーカイブ直接読み取りを提供します。 OSS 帯域幅を 100 Gbps に増加します。例えば、270GBモデルであれば約20秒で読み取ることができます。 OSS プロトコル互換性サポート、OSS-Posix ローカル ファイル、Hadoop プロトコルと互換性のある OSS-HDFS。

ネットワーク面では、アリババの飛天洛神クラウドネットワークは、主にソフトウェアとハ​​ードウェアの調整と補完を通じて、高性能ネットワークアクセスと転送を改善しました。クラウド ネイティブはネットワークに課題をもたらします。以前は、ネットワークは仮想マシン用に提供されていましたが、現在はコンテナ ポッド用に提供されており、両者の規模の違いにより課題が生じています。まず、コンテナではネットワーク カードの作成速度に対する要件が高く、その速度は数百から数千に増加しました。 2 番目に、K8s のシームレスな統合に基づいて、さまざまなネットワーク層テーブルの検索とメモリ管理が最適化されました。マルチリージョン ネットワークの突然の切断の問題と、モデル トレーニングのための大規模なネットワーク帯域幅の需要を解決するために、アクティブ リルーティング テクノロジが導入されています。

Hosted K8s: 主に使用状況データについて説明します。 64% のユーザーが本番環境で K8s を使用しており、クラウド上の K8s の成長率は 127% に達します。クラウドホスト型 K8s はローカル展開を上回り、73% を占めています。マネージド K8s クラスター製品の価格が再計画されました。

データベースに関しては、Yaochi Rds、Polardb、Adb が導入され、オープンソースのものには Selectdb、Mongodb、Clickhouse が含まれます。その中で、主力製品であるPolardbのパフォーマンス最適化について説明しました。製品面では、Rds+Redis、Polardb+Tair、組み込みキャッシュがあり、読み取りと書き込みの一貫性に手動で注意を払う必要はありません。同時に、Adb と Lindorm が導入され、Lindorm の Nosql データベースとしての機能とマルチモーダル性のサポートが導入されました。

ビッグデータに関しては、Pai プラットフォームが導入され、Maxcomputor が Python 処理をサポートし、Flink+Paimon が新世代のリアルタイム レイク ウェアハウス ソリューションとなり、Dataworks が自然言語のサポートなどのインテリジェント アップグレード、完全に管理されたベクトル検索サービス Dashvector、そして最後に、ES、Spark、StarRocks などの完全にサーバーレスになる製品が登場しました。

2. ビッグデータ技術の開発と応用の現状

ビッグデータの技術開発は、2003 年に Google が発表した 3 つの論文 (GFS、Bigtable、MapReduce) から始まり、私たちはこれをビッグデータ 1.0 段階と呼びたいと思います。彼らはそれぞれ、大規模データストレージ、高速クエリ、一般的なコンピューティングについて詳しく説明しました。その後、3 つの論文のプロトタイプに基づくオープンソースのビッグデータ コンポーネントである Hadoop テクノロジ システムには、HDFS、Hbase、Yarn、MapReduce が含まれ、それぞれ、分散ストレージの構築、高速ポイント クエリ、リソース スケジューリング、安価なマシンでの大量データ コンピューティングの問題を解決しました。

テクノロジーの発展に伴い、Hive、Spark、Storm に代表されるビッグデータ コンポーネントは継続的に更新されてきました。ビッグデータは2.0段階に入りました。同時に、特定のシナリオを解決する ELK のような軽量リンクにも開発の余地が見つかりました。このプロセスの中で、OLAP 分析の分野では、Clickhouse、Kylin、Druid などの OLAP エンジンなどの新しい開発が行われました。データを構築する主な方法は、SQL ベースに移行しました。

2.0 後期のリアルタイム コンピューティングの面では、Google は 2015 年に「Google-DataFlow」を公開し、ストリーミング コンピューティングの概念を導入しました。その後、オープンソースの Flink リアルタイム コンピューティングにより、ビッグ データ処理は 2.5 段階に入りました。近年、企業はクラウドコンピューティングの波を受け入れており、それが Alibaba Cloud の急速な発展をもたらしました。 K8s システムはビジネスシステムで徐々に普及しつつあります。 OLAP 分野では、StarRocks、Doris、その他の MPP データベース エンジンなど、新しいグループのメンバーが登場しました。同時に、データ レイクの急速な発展に伴い、Hudi、Iceberg、Delta、Paimon はストレージ層とテーブルの間にレイヤーを構築しました。クラウド上のオブジェクト ストレージのほぼ無制限の特性に基づいて、データ ウェアハウスの概念がデータ レイクの概念に入りました。

では、私たちはビッグデータ 3.0 の段階に入ったと言えるのでしょうか?まだ埋める必要のある部分が残っていると思います。ビッグデータは、それが所在する企業とともにクラウドに移行され、クラウド上の基本的な設定が適用されていますが、ビッグデータ技術の構築は本質的には依然として従来の ECS に基づいています。パブリッククラウドの開発の観点から見ると、K8s によって自然に提供されるリソース スケジューリングおよびオーケストレーション システムは、Yarn リソース スケジューリングを置き換えることができます。 HDFS ストレージをベースに、OSS を使用してデータ レイク システムを構築できます。ネットワークの面では、パブリッククラウドはビッグデータクラウドネイティブのトレンドを捉え、ネットワークのアップグレードや変更を行ってきました。 K8s の弾力性と自然なコスト上の利点により、多くの企業にとって第一の選択肢となっています。次に解決する必要がある問題は、コンピューティング コンポーネントを K8s システムに適合させてクラウド ネイティブを形成する方法です。

Spark、Flink、Clickhouse、StarRocksなどの主要なビッグデータコンポーネントの開発動向を見ると、K8sをベースにアプリケーションを構築する能力が急速に発達していることがわかります。このプロセスでは、いくつかの問題に遭遇することは避けられません。詳しく見てみましょう。

3. ビッグデータクラウドネイティブの難しさと課題

ビッグデータ クラウド移行とビッグデータ クラウド ネイティブは、2 つの異なる概念です。クラウド上のビッグデータは、一般的に、企業が独自のコンピュータ ルームを構築する必要がなくなり、パブリック クラウドを IDC として使用することとして理解できます。ビッグデータは、パブリッククラウドのインフラストラクチャ（仮想マシン、ストレージ、ネットワーク）に基づいてビッグデータテクノロジーシステムを構築します。ビッグデータのクラウドネイティブ化とは、コンテナ化、柔軟なスケーリング、ストレージとコンピューティングの分離など、クラウドネイティブの利点を活用して、ビッグデータテクノロジとアプリケーションをクラウドネイティブ環境に展開し、より効率的で柔軟性と信頼性の高いビッグデータ処理と分析を実現することを指します。

クラウドネイティブ ビッグデータの実現には、互換性、リソース管理、コンピューティング パフォーマンス、エコシステムの統合など、いくつかの技術的およびエコロジカルな問題を解決する必要があることに留意する必要があります。したがって、ビッグデータ クラウド ネイティブを実装する場合、最終的なソリューションが実際のニーズを満たすことができるように、包括的なアーキテクチャ設計と実装方法の選択が必要です。ビッグデータ コンポーネントをアップグレードしてクラウド ネイティブに変換するには、ストレージ、コンピューティング、スケジューリングという 3 つの基本的な次元から始める必要があります。

ストレージの変換や交換は比較的簡単です。企業は市場にあるさまざまなクラウド ストレージから選択できます。このタイプのクラウド ストレージには、高い耐障害性と信頼性に加えて、ホット データとコールド データの階層管理、および近年 Alibaba Cloud が開始した OSS-HDFS クラウド ストレージなどの Hive、Spark、Trino などの主流のビッグ データ コンピューティング エンジンとのシームレスな互換性も必要です。前述のクラウド ストレージに加えて、ビッグ データをクラウド ネイティブ データに変換する際の重要かつ困難な問題は、コンピューティングとスケジューリングという 2 つの側面にあります。

ビッグデータ システムにおける K8s には、比較的顕著な問題がいくつかあります。1 つ目は、ビッグデータのオフライン コンピューティングで瞬時にコンテナが要求されるという突然の需要です。 Spark タスクを例にとると、大規模な Spark タスクでは、短期間で数千から数万のコンテナが必要になる場合があります。 K8s Pod はすぐにポップアップできますか?超大規模なイメージを短時間で取得する際にボトルネックが発生するでしょうか? 2つ目は、Pod上でのネットワークの作成と解放が満たされるか、コンテナ間のネットワーク帯域幅のパフォーマンスが満たされるかなど、コンテナの基本的なネットワークの問題に起因します。 3 つ目は、コンテナのマウント ディスクが一般的に小さく、Spark と Flink の両方でシャッフル データがディスクに落ちるという問題があることです。ビッグデータクラウドネイティブのコンピューティングとスケジューリングの2つの側面では、上記の3つの問題を解決する必要があります。

4. ビッグデータクラウドネイティブの実現可能性

メインフォーラムの技術的な観点から見ると、ビッグデータに関連するコアインフラストラクチャでは、サーバーレスエラスティックコンテナと基盤ネットワークのパフォーマンス向上、OSS帯域幅の向上、OSS-HDFSプロトコルのサポートなど、コンテナに大きな改善が行われました。同時に、Celeborn など、ビッグデータ中間結果用のさまざまなリモート シャッフル コンポーネントがオープン ソース コミュニティに登場しました。ビッグデータ向けのクラウドネイティブは実現可能だと私は思っており、多くの企業のビッグデータ開発の方向性はクラウドネイティブ路線へと進化していくと考えています。雲奇カンファレンスの参加者の中に、偶然、ある企業のビッグデータ クラウド ネイティブに関するケース スタディ「miHoYo ビッグデータ クラウド ネイティブ プラクティス」を目にしました。これは、同社のビッグデータ技術専門家である Du Anming 氏が共有したものです。彼らの実践は私の考えと一致しています。彼らがどのようにそれをやったか見てみましょう。

主に、miHoYo のビッグデータ アーキテクチャをクラウド ネイティブにアップグレードする目標、調査、実践、および Alibaba Cloud Container Service ACK に基づく Spark クラウド ネイティブ アーキテクチャを通じて、エラスティック コンピューティング、コスト削減、ストレージとコンピューティングの分離の価値を獲得する方法について共有しました。

1 つ目は、エラスティック コンピューティングです。ゲームビジネスでは、定期的なバージョンアップ、ローンチ活動、新しいゲームのリリースが行われるため、オフラインコンピューティングリソースの需要と消費量が大きく変動し、通常のレベルの数十倍から数百倍になることもあります。 K8s クラスターの自然な弾力性を活用し、Spark コンピューティング タスクを K8s 上で実行するようにスケジュールすることで、このようなシナリオでのリソース消費ピークの問題を簡単に解決できます。

2つ目はコスト削減です。 Alibaba Cloud Container Service for Kubernetes ACK クラスターの強力な弾力性を利用して、すべてのコンピューティング リソースが大量に適用され、使用後に解放されます。さらに、Spark コンポーネントをカスタマイズおよび変換し、ECI スポットインスタンスを最大限に活用しました。同じコンピューティング タスクとリソース消費では、コストが 50% 削減されます。

3 つ目は、ストレージとコンピューティングの分離です。 Spark は K8s 上で実行され、K8s クラスターのコンピューティング リソースを最大限に活用します。アクセスされるデータは、HDFS および OSS から OSS-HDFS に徐々に切り替えられます。 Celeborn は中間シャッフル データの読み取りと書き込みに使用されます。アーキテクチャ全体でコンピューティングとストレージの分離が実現され、保守と拡張が容易になります。

全体の共有から、miHoYo ビッグデータは多くの困難で重要な問題を克服し、ビッグデータ コンピューティングのクラウド ネイティブ性を実現し、非常に優れた利益を達成したことがわかります。

付録：

2023 Yunqi カンファレンス技術基調講演セッション: https://yunqi.aliyun.com/2023/techkeynotesession。

オープンソース ビッグデータ プラットフォーム 3.0 の技術的解釈: https://mp.weixin.qq.com/s/iEAl4qk2pkabCi-vfOBRyA。

MiHoYo のビッグデータ クラウド ネイティブ実践: https://mp.weixin.qq.com/s/VTV9J6J1J-KZlYO79M_J4g。