業界の急速な発展とビジネスの高速反復により、データ量も爆発的に増加しました。ビッグデータ クラウド ネイティブは、企業のデジタル変革にとって徐々に重要な進化の方向性となってきました。デジタル化により、企業は業務効率を向上させ、ビジネスチャンスに対する洞察を得ることができます。クラウド ネイティブは IT システムの効率を向上させ、ビジネスの俊敏性を促進します。ビッグデータ クラウド ネイティブは、企業のイノベーションに無限の可能性をもたらします。 一般的な傾向: クラウドネイティブのビッグデータ 従来のビッグデータ アーキテクチャには、リソースの利用、効率的な運用と保守、可観測性などの点で多くの欠点があり、現在の開発ニーズに適応できなくなっています。具体的には、従来のビッグデータ アーキテクチャには次のような問題があります。
クラウドネイティブ ビッグデータは、ビッグデータ プラットフォームの次世代アーキテクチャと運用形式です。クラウドネイティブなプラットフォーム展開、クラウドネイティブなコンピューティングスケジューリング、統合されたストレージ負荷を特徴とするビッグデータ処理および分析プラットフォームです。複数のコンピューティング負荷をサポートし、より柔軟なコンピューティング スケジューリングと高いストレージ効率を実現します。クラウドネイティブなビッグデータは、次の3つの観点から、ビッグデータの活用と運用に大きな変化をもたらしています。
「3+1」アーキテクチャモデル: 3つの主要プラットフォームと1つの主要サポートシステム クラウドネイティブ ビッグデータ プラットフォームの機能アーキテクチャは、「3 つの主要プラットフォームと 1 つの主要サポート システム」として要約できます。 3 つの主要なプラットフォームは、プラットフォーム サービス層、コア エンジン層、およびリソース スケジューリング層です。
プラットフォームサービス層 プラットフォーム サービス層は、オープンソース コンポーネントによってプラグイン方式で統合されており、柔軟に構成および選択することができ、これがプラットフォーム アーキテクチャ全体の重要な設計となっています。 既存のユーザー習慣を尊重するために、ユーザーが使い慣れているオープンソース コンポーネントがプラグインの形で統合されています。現在主流のビッグデータの作業シナリオには、主に情報ポータル、データエンジニアリング、データサイエンスが含まれます。それぞれのシナリオには、ユーザーがよく使用するオープンソース コンポーネントが多数あります。
上記の 3 つのシナリオは、ビッグ データの作業では非常に一般的です。クラウドネイティブ ビッグデータ プラットフォームは、これらのオープン ソース コンポーネントをプラグイン方式で統合しており、すぐに使用でき、利便性と柔軟性に優れています。 コアエンジン層 コアエンジン層は、ストレージとコンピューティングを分離する特性を持っています。 コンピューティング面では、Flink や Spark などの主流のビッグデータ コンピューティング エンジンに加え、クラウドネイティブ メッセージング ミドルウェア、リアルタイム サービス分析エンジン、クラウドネイティブ ログ検索サービスを統合しています。 ストレージ面では、HDFS セマンティクスと互換性があり、TOS 透過アクセラレーション、キャッシュアクセラレーション、データレイク管理をサポートする統合ストレージが採用されています。 1. 自動チューニング クラウドネイティブに向けたビッグデータの開発には、コンピューティングエンジンとクラウドネイティブの深い統合を促進し、自動チューニングに向けて進化することが必要です。私たちの経験から、このプロセスは次の 4 つの段階に分けられます。 • フェーズ 1 ○K8sクラスタの導入と管理 ○アプリケーションはコンテナとイメージを自ら管理する • フェーズ II ○リソースプーリング: 基盤となるK8sリソースを認識しない ○リソースコロケーション: オフラインジョブでのクラスタリソースの共有 ○ジョブリソースの割り当てと並列性のみに焦点を当てる ○スムーズな進化:YARNとKubernetesジョブの共存 • フェーズ3 ○仮想キュー:クラスターやコンピュータルーム間でのジョブの自動スケジュールをサポート ○アイドルリソースを活用する:過剰発行と排除メカニズムを通じてアイドルリソースを活用する ○半自動エンジンチューニング:インテリジェントチームを使用してタスク構成パラメータを推奨し、手動で確認して発行します。 • 第4段階(現在の最終目標でもある) ○グローバル自動災害復旧:コンピュータルーム全体にわたる自動スケジュールと災害復旧を実現 ○自動リソース最適化:負荷がない場合、リソース使用量を 0 に減らすことができます。ミリ秒レベルのコールドスタート遅延 ○エンジン自動チューニング: AI技術を使わず、コンピューティングネットワークやメモリなどのリソースの使用を最適化するハイブリッド 2. ストレージとコンピューティングの分離 クラウドネイティブの具体的な作業は、主に次の 3 つの部分で構成されます。 統合管理とスケジュール: • データ権限を統一し、セキュリティ リスクを軽減する: リソース プールにはデータが含まれており、セキュリティ リスクを軽減するために権限とセキュリティ管理を統一する必要があります。 • 統一されたリソースのスケジュールと再利用: リソース プールでは、統一されたリソースのスケジュールと再利用も必要です。例えば、ストレージを統合した後は、異なる業務で再利用する際にも統合スケジューリングを行うことができます。 ストレージ容量の共有: • データのコピーを統一し、データのアンロードを削減します。データ タスクは失敗することが多く、同期によってリソースが消費されます。タスク同期エラーが発生した場合、その原因の特定が困難で、非常に手間がかかるため、データのアンロードは可能な限り削減する必要があります。 • 高い信頼性要件を満たす統合データ災害復旧: 複数のストレージとコンピューティングの分離展開形式をサポートします。コンピューティングとストレージの 2 つのクラスターに完全に分割することも、コンピューティングとストレージを K8s クラスター上で混在させることもできますが、この場合はコンピューティングとストレージは別々に管理されます。 ストレージとコンピューティングの分離負荷: • スケールアップ、スケールダウン、データの再バランス調整にかかる時間を短縮: クラウドネイティブのデータレイク、データウェアハウス、メッセージキュー、検索エンジンがストレージとコンピューティングの分離の展開モードをサポートしている場合、ストレージを統合されたビッグデータ ファイル ストレージまたはオブジェクト ストレージに配置できるため、スケールアップ、スケールダウン、データの再バランス調整にかかる時間を短縮できます。 • 要求応答性の強化: 統合ビッグデータ ファイル ストレージまたはオブジェクト ストレージにストレージを配置すると、要求応答性も強化されます。 リソーススケジューリングレイヤー リソース スケジューリング レイヤーは、主にコンピューティング リソース スケジューリングとエンジン クラウド ネイティブ ライフサイクル管理を統合するために使用されます。次の 4 つのモジュールが含まれます。 •マルチクラウドの展開とスケジュール設定: クロスクラウドのクォータ管理 (統合クォータ) を提供し、高可用性を実現します。 • 統合リソース プール: 統合負荷の計算をサポートし、オフライン コロケーションをサポートします。 • クラウドネイティブ YARN: YARN リソース ロードと互換性があり、既存の Hadoop ロードをスムーズに移行します。 •クラウド ネイティブ オペレーター: Helm Chart を使用して、エンジン全体のクラウド ネイティブ ライフサイクルを管理します。 従来のリソース スケジューリング システムをクラウド ネイティブに進化させるには、2 つの並行した方法があります。次の 2 つのいずれかを選択できます。 •サーバーレス YARN: 上の図からわかるように、リソース マネージャー、ノード マネージャー、アプリケーション マスターは YARN の 3 つの主要コンポーネントです。このソリューションはリソース マネージャーで変更され、新しいコンポーネントが追加されます。この変換後、お客様にとって、新しいシステムは YARN クライアントを介してジョブを送信する使用方法を引き続き維持しますが、リソース マネージャー レイヤーでそれらをカプセル化してスケジュールし、ユーザーが API サーバー (実際には K8s API サーバー) に直接ジョブを送信できるようにします。つまり、YARN のリソース マネージャーを変革することで、もともと YARN を使用してリソース要求を送信していた企業は、K8s にビジネスをスムーズに送信できるようになります。 •クラウド ネイティブ オペレーター: このソリューションは、既存のビッグ データ コンポーネントをクラウド ネイティブに展開し、Flink や Spark などのコンピューティング エンジンをクラウド ネイティブ方式で K8s に展開するためのものです。このソリューションには 2 つの利点があります。 1 つ目は、オペレーターを使用してコンピューティング エンジンをそのライフ サイクル全体にわたって管理できるため、ユーザーはより優れたバッチ ジョブの再起動戦略を実装できるようになります。 2 つ目は、クラウド ネイティブと K8s がより適切に統合されていることです。 Pod 上のログをより細かく収集し、ビッグデータ エンジン全体とジョブの実行状態を追跡できます。 統合リソースプール(左)クラスター間、コンピュータ ルーム間、リージョン間をサポートするグローバル リソース レイク (右) スケジュール レベルでは、クラウド ネイティブを実現するために次の 2 つのことを行う必要があります。 1. 統合リソースプール 仮想リソース プールの概念には、次のような基本的な要件が必要であると考えています。 • キューのプロパティ: リソースプールの最小値と最大値のプロパティを設定する • より強力なスケジューリング戦略: タスク優先度スケジューリング、GANG スケジューリング、DRF スケジューリング (GANG スケジューリング戦略では、ジョブのすべてのコンテナが一緒にスケジュールされ、DRF アルゴリズムでは、リソース プール内の各ジョブにリソースが公平に割り当てられます) • より優れた分離制御: 各ポッドのCPUタイムスライスとメモリ使用量を制限 •より柔軟なリソース使用:アイドルリソースの利用とキューのプリエンプション 2. グローバルリソースレイク •ResLakeは、リソース、グローバルリソースプール、クォータ管理のグローバルビューを備えています。 • コンピュータルームやクラスタに制限はなく、最終的なスケジュール目標はリソースの利用を最適化することです。 たとえば、現在、クラスター A にリソース プールがあり、クラスター B にリソース プールがあります。災害復旧の要件を満たすために、これらの 2 つのリソース プールをプライマリ リソース プールとバックアップ リソース プールとして使用し、仮想キューの概念を抽象化することができます。このように、タスクを送信するときに、ユーザーはリソース プールに注意を払う必要はなく、仮想キューに送信するだけで済みます。クラスタA/コンピュータ室に割り当てるか、クラスタB/コンピュータ室に割り当てるかは、以下のクラスタ/コンピュータ室の稼働状況に応じて自動的に決定されます。 運用保守管理プラットフォーム オープンソース コンポーネント、サービス ライフサイクル、クラスタリング、ディザスタ リカバリ、および可観測性を統合したワンストップ管理プラットフォーム。 ビッグデータ プラットフォームには、可観測性、オープン ソース コンポーネント管理、サービス ライフサイクル管理、クラスター管理、災害復旧管理の機能とサービスが必要です。図中の青い部分は、クラウド ネイティブ コンピューティング向けに特別に強化されています。詳細な説明は次のとおりです。 •フルリンク監視:コールチェーン、コール関係などを含むリンク全体で各サービスの実行状態を監視できるため、障害が発生した場合に問題のある特定のコールリンクを特定できます。 •オープンソース コンポーネント管理: Helm Chart を通じてコンポーネントをデプロイし、起動、終了、クリーンアップなどの一連の操作を含む実行中のコンポーネントのライフサイクル全体を Operator を通じて管理します。したがって、オープンソース コンポーネント管理は、エンジンや特定のオープンソース コンポーネント、さらには K8s プラットフォーム上のタスクを管理するための特別なモードです。このモードの利点は、より高速で、よりきめ細かいことです。 •サービス ライフサイクル管理: 統合されたビジュアル管理インターフェイスを通じて、サービス コンポーネントのレンダリング、公開、およびステータス管理サービスを提供します。 •クラスター管理:クラスターの拡大・縮小やクラスター情報の統計に加え、ジョブ全体の実行状況やサービスの実行状況をより適切に監視するために、コンテナログをより細かく収集する必要がある場合が多いため、この部分を強化しました。また、コンテナの実行状況を把握するために、Web Shell 経由で Pod にログインし、コマンドライン形式で Linux の指示を入力し、ローカル端末上でリモートサーバーを操作するのと同様に、ブラウザ上でジョブ実行環境を直接操作できるサービスを提供しています。これは、ジョブの開発と問題の特定に非常に実用的なツールです。 コスト削減と効率改善:ユーザーシナリオと価値 ハイブリッド展開によりリソース利用率が向上 ハイブリッド ユーザー シナリオでは、クラウド ネイティブ ビッグ データ プラットフォームは、オンライン、ストリーミング、オフライン、クエリ分析、バッチ処理など、さまざまなビジネス シナリオをサポートします。 ビジネス シナリオが異なれば、基盤となるリソースの応答に関するコア指標も異なるため、基盤となるリソースの最適化要件も異なります。これらのさまざまなシナリオのビジネス指標の要件を満たすには、コロケーション中に対応する最適化に重点を置く必要があります。コロケーションの典型的なシナリオを 2 つ示します。 1. Flink と Spark の共存。つまり、Flink がリソースを使用しない場合や負荷が低い場合は、リソースを Spark に解放することができます。 Spark がバッチ コンピューティングを完了すると、アイドル リソースをストリーミング コンピューティング (Flink) に解放することもできます。 2. APP リアルタイム呼び出しとビッグデータ シナリオの混合展開。上の図に記載されている 5 つのシナリオのうち、右側の 4 つはビッグデータ シナリオです。ビッグ データ シナリオでは、APP リアルタイム呼び出しシナリオでリソースを再利用できます。つまり、APP のオンライン リソース使用量が少ない場合は、ビッグ データ シナリオに解放することができ、その逆も同様です。 ByteDance を例にとると、さまざまなコンピューティング リソースを組み合わせて展開およびスケジュール設定することで、顕著なメリットが得られました。
マルチクラウド展開により、マルチクラウドコストの最適な再利用が実現 マルチクラウド ユーザー シナリオでは、マルチクラウドの展開とスケジュール設定を提供して、マルチクラウドのコストを最適化した再利用とクロスクラウド キューの災害復旧を実現できます。
著者について: Chi Hui Volcano Engine Cloud Native Computing のプロダクト エキスパートとして、Volcano Engine Cloud Native Big Data Platform 関連のプロダクト業務を担当しており、ビッグデータ開発プラットフォームおよびビッグデータ ガバナンス プラットフォームにおける長年のプロダクト経験を持っています。 |
<<: IDC: コンピューティングおよびストレージクラウドインフラストラクチャの支出は、2022年第3四半期も引き続き大幅に増加
>>: Java クラウド ネイティブの実践におけるメモリの問題の解釈
Google は急速に増加するデータ処理に対処するための一連のアルゴリズムを開発しました。その後、誰...
今日、鄭州のあるインターネット企業とグループチャットをしていたところ、最適化の難易度が増し、コスト投...
マルチクラウドはエンドツーエンドでフラット化されます。次の 10 年に向けて、クラウド プラットフォ...
raksmart日本データセンターは、デフォルト帯域幅100Mbps、最大帯域幅1Gbpsの大帯域幅...
過去には、2012 年は世界の終わりだとよく言われていましたが、SEO の世界では、2012 年は多...
かつて電子商取引の伝説的存在だったヴァンクルは、マーケティングと口コミを利用して短期間でブランド認知...
2003 年 10 月、Taobao の取引ニーズにより Alipay が誕生しました。その後、Al...
115 会長兼CEO 頼 林鋒シナテクノロジーはわずか400語の発表文が、115 Cloud Dis...
NVMe トランスポートは、信頼性の高い NVMe コマンドとデータ転送を提供するために設計された抽...
2020年9月10日から11日にかけて、クラウドコンピューティング分野における毎年恒例の大規模技術イ...
2018年最もホットなプロジェクト:テレマーケティングロボットがあなたの参加を待っていますV6.0....
企業や組織が人工知能の開発から真の利益を得られるよう、マイクロソフトは今週、顧客が人工知能ツールを簡...
[[373788]]コンピューティングの今後とそれが組織の戦略にどのような影響を与えるでしょうか?専...
サイトの重みに大きな影響を与える比較的重要なサイトが 2 つあります。YAHOO と DMOZ です...
誰もがこれまでこのような考えを持っていました。コア周波数の高い CPU 製品を使用することは、特にサ...