クラウドネイティブのビッグデータ知識マップを1つの記事で学ぶ

1. 一般的な傾向: クラウドネイティブのビッグデータ

業界の急速な発展とビジネスの高速反復により、データ量も爆発的に増加しました。従来のビッグデータ アーキテクチャには、リソースの利用、効率的な運用と保守、可観測性などに多くの欠点があり、現在の開発ニーズに適応できなくなっています。具体的には、従来のビッグデータ アーキテクチャには次のような問題があります。

1. 従来のビッグデータには多数のコンポーネントがあり、インストールとメンテナンスが複雑で、実稼働での使用には多くの人的サポートが必要になります。
2. オンライン サービスやビッグ データ サービスでは独立したリソース プールが使用されるため、リソースの転送が困難になり、使用率が低下し、コストが上昇します。
3. 従来のビッグデータ アーキテクチャには CICD メカニズムがなく、テストおよび品質管理プロセスが欠けています。
4. 従来のビッグデータには、高可用性、マルチテナント、ログ記録、監視、アラーム、認識、承認、監査、課金などのすぐに使用できる機能が欠けています。

クラウドネイティブ ビッグデータは、ビッグデータ プラットフォームの次世代アーキテクチャと運用形式です。クラウドネイティブなプラットフォーム展開、クラウドネイティブなコンピューティングスケジューリング、統合されたストレージ負荷を特徴とするビッグデータ処理および分析プラットフォームです。複数のコンピューティング負荷をサポートし、より柔軟なコンピューティング スケジューリングと高いストレージ効率を実現します。クラウドネイティブビッグデータは、次の3つの観点から、ビッグデータの活用と運用に大きな変化をもたらしました。

• ビジネス レベル: 従来のモデルでは、ビジネスは独立してリソースを占有します。ビジネスのピーク時にはすべてのリソースが占有されますが、オフピーク時にはリソースの使用率は 20% ～ 30% にしかならない場合があります。クラウドネイティブ モデルでは、オンライン ビジネスやオフライン ビジネスなどのビジネスが同じ場所に配置され、タイムシェアリング多重化方式でリソースを呼び出すことができます。
• リソースのスケジューリング: 従来のモードでは、Flink クラスターに 100 台のマシンがある場合、これらの 100 台のマシンが排他的に使用されます。クラウドネイティブ モードは、リソース プールの概念を仮想化します。リソース プールは、Flink クラスターや Spark クラスターなど、さまざまな種類のビッグ データ クラスターを実行できます。さらに、これらのクラスターはオンデマンドでプルアップされ、すぐにリサイクルでき、不要になったら解放できます。
• 統合されたデプロイメントと運用保守インストール: 本来の運用保守方法では、各クラスターが各クラスターの状態を維持する必要があります。クラスター間で遅延や障害が発生すると、問題の場所がより複雑になります。クラウド ネイティブには、Helm Chart または Operator の形式で統一された方法でサービスを公開、運用、保守する統合サービス管理インターフェースがあります。これにより、問題が発生した場合、統一されたインターフェースを通じて問題を表示および管理できるようになります。監視アラームログもK8s Pod（プロセス）とNodeのコレクションと統合されます。監視アラームでは、K8s ノードとコンテナの両方、およびサービスの実行ステータスを確認できます。

2. 「3+1」アーキテクチャモデル: 3つのプラットフォームと1つのサポートシステム

クラウドネイティブ ビッグデータ プラットフォームの機能アーキテクチャは、「3 つの主要プラットフォームと 1 つの主要サポート システム」として要約できます。 3 つの主要なプラットフォームは、プラットフォーム サービス層、コア エンジン層、リソース スケジューリング層です。

• プラットフォーム サービス層はオープン ソース コンポーネント プラグインによって統合されており、柔軟な構成と選択をサポートします。
• コアエンジン層には、Flink、Spark、クラウドネイティブ メッセージング エンジン、リアルタイム サービス分析エンジン、クラウドネイティブ ログ検索、統合ストレージ HDFS などのコア コンポーネントが含まれており、ストレージとコンピューティングの分離と自動チューニングをサポートします。
• リソース スケジューリング レイヤーは、統合コンピューティング リソース スケジューリングと統合エンジン クラウド ネイティブ ライフサイクル管理をサポートします。

主要な支援システムは、オープンソースコンポーネント、サービスライフサイクル、クラスター、災害復旧、可観測性を統合したワンストップ管理プラットフォームである運用保守管理プラットフォームです。

1. プラットフォームサービス層

プラットフォーム サービス層は、オープンソース コンポーネントによってプラグイン方式で統合されており、柔軟に構成および選択することができ、これがプラットフォーム アーキテクチャ全体の重要な設計となっています。

既存のユーザー習慣を尊重するために、ユーザーが使い慣れているオープンソース コンポーネントがプラグインの形で統合されています。現在主流のビッグデータの作業シナリオには、主に情報ポータル、データエンジニアリング、データサイエンスが含まれます。それぞれのシナリオには、ユーザーがよく使用するオープンソース コンポーネントが多数あります。

• 情報ポータル:一般的には、Superset、Apache Ranger などの BI レポート タイプ。
• データ エンジニアリング:一般的には、ビッグ データ開発エンジニアやデータ ウェアハウス エンジニアであり、データ開発、データ ETL、データ処理、およびクリーニングに使用されるコンポーネントを担当します。たとえば、データ開発には Zeppelin Notebook を使用し、データ ガバナンス プラットフォームやスケジューリング プラットフォームに接続します。
• データ サイエンス: Jupyter、Ray などの AI シナリオに一般的に適用できます。

上記の 3 つのシナリオは、ビッグ データの作業では非常に一般的です。クラウドネイティブ ビッグデータ プラットフォームは、これらのオープン ソース コンポーネントをプラグイン方式で統合しており、すぐに使用でき、利便性と柔軟性に優れています。

2. コアエンジン層

コアエンジン層は、ストレージとコンピューティングを分離する特性を持っています。

コンピューティング面では、Flink や Spark などの主流のビッグデータ コンピューティング エンジンに加え、クラウドネイティブ メッセージング ミドルウェア、リアルタイム サービス分析エンジン、クラウドネイティブ ログ検索サービスを統合しています。

ストレージ面では、HDFS セマンティクスと互換性があり、TOS 透過アクセラレーション、キャッシュアクセラレーション、データレイク管理をサポートする統合ストレージが採用されています。

自動チューニング

クラウドネイティブに向けたビッグデータの開発には、コンピューティングエンジンとクラウドネイティブの深い統合を促進し、自動チューニングに向けて進化することが必要です。私たちの経験から、このプロセスは次の 4 つの段階に分けられます。

• フェーズ1

#K8s クラスターのデプロイと管理

#コンテナとイメージの管理に適用

• フェーズII

# リソースプーリング: 基盤となる K8s リソースを認識しない

#リソースコロケーション: オフラインジョブでのクラスターリソースの共有

#ジョブリソースの割り当てと並列性のみに焦点を当てる

#スムーズな進化: YARN と Kubernetes ジョブの共存

• フェーズ3

#仮想キュー: クラスターやコンピュータルーム間でのジョブの自動スケジュールをサポートします

#アイドルリソースを活用する: 過剰発行と排除のメカニズムを使用してアイドルリソースを活用する

#半自動エンジンチューニング:インテリジェントチームを使用してタスク構成パラメータを推奨し、手動で確認して発行します

• 第4段階（現在の最終目標でもある）

#グローバル自動災害復旧: データセンター全体の自動スケジュールと災害復旧

#自動リソース最適化: 負荷がない場合、リソース使用量を 0 に減らすことができます。ミリ秒レベルのコールドスタート遅延

#エンジン自動チューニング：AI技術を使わず、コンピューティングネットワークやメモリなどのリソースの使用を最適化するハイブリッド

ストレージとコンピューティングの分離

クラウドネイティブの具体的な作業は、主に次の 3 つの部分で構成されます。

統合管理とスケジュール:

• セキュリティ リスクを軽減するためにデータ権限を統一する: リソース プールにはデータが含まれており、セキュリティ リスクを軽減するために権限とセキュリティ管理を統一する必要があります。
• 統合されたリソースのスケジュールと再利用: リソース プールでは、統合されたリソースのスケジュールと再利用も必要です。例えば、ストレージを統合した後は、異なる業務で再利用する際にも統合スケジューリングを行うことができます。

ストレージ容量の共有:

• データのコピーを統一し、データのアンロードを削減します。データ タスクは頻繁にエラーが発生し、同期によってリソースが消費されます。タスク同期エラーが発生した場合、その原因の特定が困難で、非常に手間がかかるため、データのアンロードは可能な限り削減する必要があります。
• 高い信頼性要件を保証する統合データ災害復旧: ストレージとコンピューティングの分離の複数の展開形式をサポートします。コンピューティングとストレージの 2 つのクラスターに完全に分割することも、コンピューティングとストレージを K8s クラスター上で混在させることもできますが、この場合はコンピューティングとストレージは別々に管理されます。

ストレージとコンピューティングの分離負荷:

• スケールアップ、スケールダウン、データの再バランス調整にかかる時間を短縮: クラウドネイティブのデータレイク、データ ウェアハウス、メッセージ キュー、検索エンジンがストレージとコンピューティングの分離の展開モードをサポートしている場合は、ストレージを統合されたビッグ データ ファイル ストレージまたはオブジェクト ストレージに配置できるため、スケールアップ、スケールダウン、データの再バランス調整にかかる時間を短縮できます。
• 要求応答性の向上: 統合されたビッグデータ ファイル ストレージまたはオブジェクト ストレージにストレージを配置すると、要求応答性も向上します。

3. リソーススケジューリングレイヤー

リソース スケジューリング レイヤーは、主にコンピューティング リソース スケジューリングとエンジン クラウド ネイティブ ライフサイクル管理を統合するために使用されます。次の 4 つのモジュールが含まれます。

• マルチクラウドの展開とスケジューリング: クロスクラウドのクォータ管理 (統合クォータ) を提供し、高可用性を実現します。
• 統合リソース プール: 統合負荷計算とオフライン コロケーションをサポートします。
• クラウドネイティブ YARN: YARN リソース ロードと互換性があり、既存の Hadoop ロードをスムーズに移行します。
• Cloud Native Operator: Helm Chart を使用して、エンジン全体のクラウド ネイティブ ライフサイクルを管理します。

従来のリソース スケジューリング システムをクラウド ネイティブに進化させるには、2 つの並行した方法があります。次の 2 つのいずれかを選択できます。

• サーバーレス YARN : 上の図からわかるように、リソース マネージャー、ノード マネージャー、アプリケーション マスターは、YARN の 3 つの主要コンポーネントです。このソリューションはリソース マネージャーで変更され、新しいコンポーネントが追加されます。この変換後、お客様にとって、新しいシステムは YARN クライアントを介してジョブを送信する使用方法を引き続き維持しますが、リソース マネージャー レイヤーでそれらをカプセル化してスケジュールし、ユーザーが API サーバー (実際には K8s API サーバー) に直接ジョブを送信できるようにします。つまり、YARN のリソース マネージャーを変革することで、もともと YARN を使用してリソース要求を送信していた企業は、K8s にビジネスをスムーズに送信できるようになります。
• Cloud Native Operator : このソリューションは、既存のビッグデータ コンポーネントをクラウドネイティブに展開し、Flink や Spark などのコンピューティング エンジンをクラウドネイティブな方法で K8s に展開するためのものです。このソリューションには 2 つの利点があります。 1 つ目は、オペレーターを使用してコンピューティング エンジンをそのライフ サイクル全体にわたって管理できるため、ユーザーはより優れたバッチ ジョブの再起動戦略を実装できるようになります。 2 つ目は、クラウド ネイティブと K8s がより適切に統合されていることです。 Pod 上のログをより細かく収集し、ビッグデータ エンジン全体とジョブの実行状態を追跡できます。

統合リソースプール（左）クラスター間、コンピュータ ルーム間、リージョン間をサポートするグローバル リソース レイク (右)

スケジュール レベルでは、クラウド ネイティブを実現するために次の 2 つのことを行う必要があります。

統合リソースプール

仮想リソース プールの概念には、次のような基本的な要件が必要であると考えています。

• キューのプロパティ: リソース プールの最小値と最大値のプロパティを設定する
• より強力なスケジューリング戦略: タスク優先度スケジューリング、GANG スケジューリング、DRF スケジューリング (GANG スケジューリング戦略では、ジョブのすべてのコンテナが一緒にスケジュールされ、DRF アルゴリズムでは、リソース プール内の各ジョブにリソースが公平に割り当てられます)
• より優れた分離制御: 各ポッドのCPUタイムスライスとメモリ使用量を制限します
• より柔軟なリソース使用: アイドルリソースの利用とキューのプリエンプション

グローバルリソースレイク

• ResLakeは、リソース、グローバルリソースプール、クォータ管理のグローバルビューを備えています。
• コンピュータルームやクラスタに制限はなく、最終的なスケジュール目標はリソースの利用を最適化することです。

たとえば、現在、クラスター A にリソース プールがあり、クラスター B にリソース プールがあります。災害復旧の要件を満たすために、これらの 2 つのリソース プールをプライマリ リソース プールとバックアップ リソース プールとして使用し、仮想キューの概念を抽象化することができます。このように、タスクを送信するときに、ユーザーはリソース プールに注意を払う必要はなく、仮想キューに送信するだけで済みます。クラスタA/コンピュータ室に割り当てるか、クラスタB/コンピュータ室に割り当てるかは、以下のクラスタ/コンピュータ室の稼働状況に応じて自動的に決定されます。

4. 運用保守管理プラットフォーム

オープンソース コンポーネント、サービス ライフサイクル、クラスタリング、ディザスタ リカバリ、および可観測性を統合したワンストップ管理プラットフォーム。

ビッグデータ プラットフォームには、可観測性、オープン ソース コンポーネント管理、サービス ライフサイクル管理、クラスター管理、災害復旧管理の機能とサービスが必要です。図中の青い部分は、クラウド ネイティブ コンピューティング向けに特別に強化されています。詳細な説明は次のとおりです。

• フルリンク監視：コールチェーン、コール関係などを含むリンク全体で各サービスの実行状態を監視できるため、障害が発生した場合に問題のある特定のコールリンクを特定できます。
• オープンソース コンポーネント管理: Helm Chart を通じてコン​​ポーネントをデプロイし、開始、停止、クリーンアップなどの一連の操作を含む実行中のコンポーネントのライフサイクル全体を Operator を通じて管理します。したがって、オープンソース コンポーネント管理は、エンジンや特定のオープンソース コンポーネント、さらには K8s プラットフォーム上のタスクを管理するための特別なモードです。このモードの利点は、より高速で、よりきめ細かいことです。
• サービス ライフサイクル管理: 統合されたビジュアル管理インターフェイスを通じて、サービス コンポーネントのレンダリング、公開、およびステータス管理サービスを提供します。
• クラスター管理：クラスターの拡張と縮小、クラスター情報の統計に加え、ジョブ全体の実行状況やサービスの実行状況をより適切に監視するために、コンテナのログをより細かく収集する必要がある場合が多いため、この部分を強化しました。また、コンテナの実行状況を把握するために、Web Shell 経由で Pod にログインし、コマンドライン形式で Linux の指示を入力し、ローカル端末上でリモートサーバーを操作するのと同様に、ブラウザ上でジョブ実行環境を直接操作できるサービスを提供しています。これは、ジョブの開発と問題の特定に非常に実用的なツールです。

3. コスト削減と効率化：ユーザーシナリオと価値

1. ハイブリッド展開によりリソースの利用率が向上する

ハイブリッド ユーザー シナリオでは、クラウド ネイティブ ビッグ データ プラットフォームは、オンライン、ストリーミング、オフライン、クエリ分析、バッチ処理など、さまざまなビジネス シナリオをサポートします。

ビジネス シナリオが異なれば、基盤となるリソースの応答に関するコア指標も異なるため、基盤となるリソースの最適化要件も異なります。これらのさまざまなシナリオのビジネス指標の要件を満たすには、コロケーション中に対応する最適化に重点を置く必要があります。コロケーションの典型的なシナリオを 2 つ示します。

1. FlinkとSparkの共存 。つまり、Flink がリソースを使用しない場合や負荷が低い場合は、リソースを Spark に解放することができます。 Spark がバッチ コンピューティングを完了すると、アイドル リソースをストリーミング コンピューティング (Flink) に解放することもできます。
2. APP リアルタイム呼び出しとビッグデータ シナリオのハイブリッド展開 。上の図に記載されている 5 つのシナリオのうち、右側の 4 つはビッグデータ シナリオです。ビッグ データ シナリオでは、APP リアルタイム呼び出しシナリオでリソースを再利用できます。つまり、APP のオンライン リソース使用量が少ない場合は、ビッグ データ シナリオに解放することができ、その逆も同様です。

ByteDance を例にとると、さまざまなコンピューティング リソースを組み合わせて展開およびスケジュール設定することで、顕著なメリットが得られました。

• 1 つ目は効率的なリソース切り替えで、数分以内に数万のオフライン リソースを解放できます。例えば、2022年の春節期間中、Douyinのオンラインリソースの需要は非常に高く、数分以内に数十万コアのオフラインリソースをオンラインリソースに割り当てました。突然のソーシャル ホットスポットによって極端に弾力性のあるシナリオが発生した場合、効率的なリソースの切り替えは、ビジネスにとって「命を救う武器」となることさえあります。
• 2つ目は利用率の向上です。コロケーションにより、全体的なパブリックオーバーヘッドを削減でき、ByteDance 内での利用率が 2% 向上しました。
• 最後に、オフライン リソースの統合管理とすべてのオフライン リソースの共有により、割り当て制御、スケジュール、操作、および機械の操作とメンテナンスを統合できます。

2. マルチクラウド展開により、マルチクラウドコストの最適な再利用が実現

マルチクラウド ユーザー シナリオでは、マルチクラウドの展開とスケジュール設定を提供して、マルチクラウドのコストを最適化した再利用とクロスクラウド キューの災害復旧を実現できます。

• グローバル仮想キューの提供: ユーザーが複数のクラウドを使用する場合、まずグローバル仮想キューの概念を提供する必要があります。上の図に示すように、仮想キューは 2 つの異なる物理リソース プールに対応するリソース プールです。送信時に、ユーザーは実際の対応するクラスターに注意を払う必要はなく、代わりに仮想キューに送信します。下位層はそれに応じてジョブをスケジュールし、適切なクラスター/コンピューター ルーム/キューに自動的に配布するため、災害復旧機能が効果的に向上します。
• アプリケーションは複数の要素に基づいてトラフィック分散を選択します。マルチクラウド展開のもう 1 つの利点は、複数の要素を総合的に考慮してトラフィック分散を選択できることです。たとえば、マルチクラウドのシナリオでは、AZ1 はメーカー 1、AZ2 はメーカー 2 であると理解されます。ここで、同じ数の CU を使用すると、メーカー 2 の方がメーカー 1 よりも 50% コストが高くなることがわかります。この場合、マルチクラウド スケジューリングを使用して、トラフィックを可能な限りメーカー 1 に分散できます。これはコストの観点から考慮された状況です。もちろん、コストは削減されるものの、ダウンタイムが頻繁に発生したり、応答時間が長くなったり、タスクステータスのエラー率が高くなったりする状況も考えられます。この場合、重要なアプリケーションをあらゆる面でより優れた指標を備えたコンピュータ ルームに配置する必要があります。一般的に、トラフィックの配分は複数の要素を総合的に考慮して行われます。マルチクラウド展開シナリオでは、ユーザーがマルチクラウドコストを最適に再利用できるように支援します。