クラウドネイティブのデータレイクを有効活用するにはどうすればよいでしょうか?

データ レイクは、企業がデータ シナリオの増加、データ構造の複雑化、データ処理要件の多様化といった現在の問題に対処するのに役立ちます。 Alibaba Cloud は 2018 年にデータ レイクの構築を開始し、クラウド ネイティブのデータ レイク分析 (DLA) を開始しました。これは、データ レイク管理 (顧客によるデータ レイクの効率的な管理と構築を支援)、サーバーレス Spark (コスト効率の高い大規模コンピューティングを提供)、サーバーレス SQL (コスト効率の高いオンライン インタラクティブ分析を提供) の 3 つの側面から、顧客がデータの価値を活用できるように支援します。この記事では、関連する技術的な課題と解決策を紹介します。

データレイクの機会と課題

データ レイクは、データ シナリオの増加、データ構造の複雑化、データ処理ニーズの多様化といった現在の問題に企業が対処するのに役立ちます。ガートナーが2020年に発表したレポートによると、現在39%のユーザーがデータレイクを使用しており、34%のユーザーが1年以内にデータレイクの使用を検討しているとのことです。

2018年以降、Alibaba Cloudはデータレイクの開発を開始し、クラウドネイティブのデータレイクアナリティクス（DLA）製品をリリースしました。オブジェクトストレージOSSと連携し、弾力的な拡張性、従量課金制、サービス指向の面で競争力のある製品を生み出しています。ストレージとコンピューティングを分離したモデルを採用することで、ストレージとコンピューティングは完全にオンデマンドで支払われ、ユーザーは実際に価値を生み出すコンピューティングに対してのみ支払うことになります。 DLA は、クラウド ネイティブの弾力性機能を詳細にカスタマイズしてジョブ レベルの弾力性を実現し、1 分間に 300 個のノードを起動できます。クラウドネイティブのデータレイク分析 DLA は、従来のデータ分析ソリューションと比較して、コスト、弾力性、配信機能の大幅な改善を実現しました。

​​

クラウド内の何千もの企業が、データ アプリケーションのニーズを満たすためにデータ レイク サービスを使用しています。例えば、Umeng+のU-DOPデータオープンプラットフォームは、Umeng+の長年のビッグデータ分野での経験に基づいて、APP、WEB、ミニプログラム、広告マーケティング、ソーシャルシェアリング、プッシュに基づくマルチターミナル主体データの収集と処理能力を形成し、顧客のために標準化されたマルチターミナルデータ資産を形成しています。特に、ダブルイレブンのピーク期間中の DAU の急増などのビジネスの変化に対応するために、データレイクの弾力性が活用されました。例えば、検索キーワードの変化を分析し、ホームページ上の推奨広告情報を変更したり、アクティブユーザーを分析して分類し、さまざまなチャネルに基づいてユーザーを順序付けたり、割引戦略をタイムリーに調整して、より多くの顧客を新規購入やリピート購入に誘導したりします。

データベースとビッグデータの統合の傾向が強まっています。従来のデータベース ユーザーと DBA も、ビッグ データ システムを使用および保守して、ビッグ データの問題を統合的に解決できます。具体的には、DLA が提供するワンクリック レイク ウェアハウス構築機能など、データベース データとビッグ データのシームレスな統合に DLA が反映されています。 DLA Serverless SQL は、MySQL プロトコルおよび一部の構文と互換性があります。

DLA Serverless 製品形式の場合、開発者は、DLA SQL の JDBC インターフェースを使用して SQL を送信したり、DLA Spark の OpenAPI を使用して Spark ジョブを送信したりするなど、プラットフォーム インターフェースのみを使用する必要があります。開発者はビジネス ロジック自体に集中するだけでよく、プラットフォームの複雑なロジックについて心配する必要はありません。オープンソース コンポーネントを使用する際に発生する問題点の多くは、簡単に解決できます。

参入障壁が高い

Hadoop エコシステムでは、Yarn、HDFS、Spark、Hive、Kerberos、Zookeeper など、複数のコンポーネントを同時に使用することがよく必要になります。開発プロセスではコンポーネントに触れることが多いため、開発者はすべてのコンポーネントを理解する必要があります。

開発と維持が難しい

開発者は開発プロセス中にさまざまなコンポーネントによって引き起こされる使用上の問題に遭遇しますが、開発者はこれらの問題に対処するためにこれらすべてのコンポーネントを理解する必要があります。これらは開発者の負担を増大させます。

安定性を保証するのは難しい

オープンソース コンポーネント自体は、正常に動作させるためには慎重なパラメータ調整と適切なハードウェア リソース構成を行う必要があり、多くのバグを修正する必要があり、発生する問題に対するカバーはありません。

クラウドのパフォーマンス最適化の欠如

クラウド上の OSS や PolarDB などのコンポーネントはすべてクラウドネイティブ コンポーネントです。オープンソース コンポーネントはこの部分の変換に十分に適応しておらず、より高いパフォーマンスを十分に活用できていません。

DLA は、データ レイク管理 (データ レイクを効率的に管理および構築できるように支援)、サーバーレス Spark (コスト効率の高い大規模コンピューティングを提供)、サーバーレス SQL (コスト効率の高いオンライン インタラクティブ分析を提供) の 3 つの側面から、お客様がデータの価値を活用できるように支援します。全体的なアーキテクチャを以下に示します。次に、この記事では、これら 3 つの側面から関連する技術的な課題と解決策について説明します。

​​

2. データレイクを管理および構築するにはどうすればよいですか?

データ レイクでのデータ管理の難しさは、主に次の 2 つの側面に反映されます。

データ レイク OSS にすでに保存されているデータのメタデータを効率的に構築する方法。

非 OSS データをレイクに効率的に保存する方法。

データ レイク管理に関連する主な機能には、メタデータ管理、メタデータ検出、レイク内のデータベース ストレージ、レイク内のリアルタイム データ ストレージなどがあります。次に、「大量ファイルメタデータの自動構築技術」と「レイクエントリー・ウェアハウス構築のためのデータ管理技術」という2つのキーテクノロジーに焦点を当てて紹介します。

1. 大規模ファイルメタデータの自動構築技術

OSS をデータ レイク ストレージとして使用する場合、保存されるデータ ファイルには次の特性があります。

• 豊富なフォーマット: CSV、テキスト、JSON、Parquet、Orc、Avro、hudi、Delta Lake などのフォーマットが含まれます。 CSV とテキストにはさまざまなカスタム区切り文字が含まれています。
• ファイル数は数百万単位：OSS はスケーラビリティとコスト効率に優れており、ユーザーが OSS に保存するファイル数は数百万単位になります。
• 動的ファイルアップロード: OSS に保存されるデータ ファイルは、動的かつ継続的なアップロードの特性を備えています。新しいファイルのメタデータをすばやく段階的に変更するにはどうすればよいですか?

OSS上の膨大なデータのメタデータを効率的に構築するために、Alibaba Cloud DLAは「大量ファイルメタデータ自動構築技術」を提案し、実装しました。具体的な技術は下図の通りです。コアテクノロジーは、10,000 個のテーブルと 10,000 個のパーティションの識別、およびメタデータの増分認識と更新という 2 つの問題を解決します。

​​

マルチメーターのマルチゾーン識別

ユーザーの OSS 上のファイル数は数百万に達する可能性があります。これらのファイルは、JSON、CSV、テキストなどのさまざまな形式を持つだけでなく、ビジネス属性が異なるため、同じ形式でも特定のスキーマ フィールドが異なります。このテクノロジーは、ファイル スキーマ識別子とファイル分類子を通じて、10,000 個のテーブルと 10,000 個のパーティションの自動生成をサポートします。たとえば、ファイル スキーマ識別子は、単一の JSON ファイルを 0.15 秒で識別し、単一の CSV ファイルを 0.2 秒で識別できます。プラグ可能なインテリジェント サンプリングと分散戦略を組み合わせることで、数百万のファイルのスキーマ識別を数分で実行できます。ファイル分類子は、ツリー構造を通じてファイルを集約、整理、圧縮します。数百万のファイルを分類して識別するには約 290 ミリ秒かかります。

増分認識更新

ユーザーは継続的に OSS にファイルをアップロードし、メタデータの自動構築により、作成されたテーブルに属するファイル スキーマの変更が既存のテーブルに更新されるだけでなく、個別に追加されたファイル用の新しいテーブルも作成されます。一方、「ファイルスキーマ識別子」は、OSS 上のファイルの追加や削除の変更を取得することで、変更されたファイルを識別します。同時に、「ファイル分類子」は、新しく追加されたファイル スキーマと作成されたテーブルの変更戦略を生成します。現在、パーティションの追加、フィールドの追加、フィールドの変更なし、ファイルの削除を認識しないという 4 つの戦略がサポートされています。将来的には新しい戦略が追加される可能性があります。

2. 湖への入庫と倉庫構築のためのデータ整理技術

データベースとメッセージ ログ サービスのデータは、管理用のデータ レイク ストレージ OSS に統一的に保存され、コンピューティングの高速化、データ ウェアハウス アーカイブの構築、ホットとコールドの分離などのビジネス ニーズを満たすことができます。 DLA のデータ レイクへの入力とウェアハウスの構築のためのデータ編成テクノロジには、ミラー モード、パーティション モード、増分モードの 3 つのデータ編成および管理モードが含まれます。 3 つのモードを組み合わせることで、これらのビジネス シナリオをフレンドリーな方法でサポートできます。

​​

ミラーモード

毎回、ソース データベース内のデータベースの下にあるすべてのテーブルのデータが、データ レイク ストレージ OSS に完全に同期されます。同期期間中、ソース データベースの負荷の増加は 10% 以内に制御できます。ここでは主に、グローバル統合データ シャーディング スケジューリング アルゴリズムが使用されます。データ レイク内のデータをソース データベースと一貫性のある状態に保ちます。

パーティションモード

アーカイブ シナリオでは、ソース データベース データのデータ レイクへの毎日の完全同期と増分同期をサポートし、アーカイブ管理を容易にするために時間パーティション別に整理します。このモードでは、時間単位での遅延を実現できます。

増分モード

このモデルは、行と列の混合ストレージ テクノロジ、コミット ログ、およびインデックス管理テクノロジを使用して、レイクへの T+10 分のデータ エントリを実現します。小さなファイルの問題は、デルタ増分ファイルと非同期圧縮テクノロジを使用することで解決されます。デルタ増分ファイルとインデックス テクノロジは、データベース シナリオの更新と削除ログの増分リアルタイム書き込みをサポートできます。従来のカタログ管理モードで数百万のパーティションによってパフォーマンスが低下する問題を解決するために、パーティション ファイルのマッピングがコミットログによって記録されます。

3つのクラウドネイティブデータレイクプラットフォームはクラウドインフラストラクチャに接続する必要がある

DLA は、リージョンに展開されるマルチテナント アーキテクチャです。各地域のユーザーは、一連の制御ロジックを共有します。仮想クラスタ VC は論理的な分離ユニットです。このプラットフォームは、クラウドネイティブ サービスを作成するために、Serverless Spark や Serverless SQL などのエンジンをサポートしています。

​​

上の図に示すように、プラットフォームが直面する主な課題は、効率的なリソース供給、セキュリティ保護、およびデータ ソースにアクセスするための帯域幅の保証です。

1. 効率的な資源供給

クラウド ネイティブ プラットフォームは、Alibaba Cloud の ECS、ACK、ECI 基盤に基づいており、Alibaba Cloud の IAAS リソース プールに接続されています。このリージョンでは、リソースの供給を確実にするために、可用性ゾーン全体でリソースをスケジュールします。 1 分間に 300 個のノードを起動でき、大規模なリージョン内の単一の顧客に対して 50,000 個のコンピューティング ノード リソースを保証します。

2. セキュリティ保護

ユーザーは任意のコードを記述してプラットフォーム上で実行することができ、それが意図的な悪意のある攻撃となる可能性があります。保護がなければ、プラットフォームはセキュリティ上のリスクに直面することになります。セキュリティに関しては、セキュリティを確保するために以下のテクノロジーを使用しています。

• ワンタイム キー: 各ジョブ タスクは TokenServer にアクセスして一時トークンを申請します。トークンが無効な場合、ジョブは期限切れになります。攻撃があった場合、プラットフォームはトークンを直接失効させ、Meta などのサービスへのアクセスは拒否されます。
• DDOS およびインジェクション攻撃の防止: プラットフォーム サービスへのアクセス要求はすべて、セキュリティ保護センターに接続されます。セキュリティ保護センターは、あらゆる攻撃やインジェクション動作を検出し、ネットワーク ポートを直接閉じます。
• コンピューティング コンテナの分離: コンピューティング ノード間で Alibaba Cloud が独自に開発したセキュリティ コンテナが使用され、コンテナ自体は VM と同じセキュリティ分離レベルを実現できます。
• セキュリティ ホワイトリスト: ユーザーのネットワークは互いに完全に分離されています。
• ENI 仮想ネットワーク カード: VPC に接続するには、自分のアカウントでセキュリティ グループと仮想スイッチ (VSwitch) を構成する必要があります。設定後、決済ノード コンテナは、ユーザーの VPC に対応する VSwitch ネットワーク セグメントの IP アドレスを割り当て、ユーザーのセキュリティ グループをマウントします。

3 高スループットネットワーク帯域幅

OSS サービスへのアクセスは、高スループット帯域幅サービスを通じて行われます。

ENI テクノロジーを使用して自立型 VPC にアクセスすることは、自立型 VPC 内の ECS にコンピューティング エンジンをデプロイして自立型 VPC 内のデータにアクセスするのと同じです。帯域幅は VPC イントラネット帯域幅でもあります。

サーバーレス Spark サービスの 4 つの技術的課題

Apache Spark は、コミュニティで最も人気のあるオープンソース エンジンです。ストリーミング、SQL、機械学習、グラフなどのコンピューティング機能を備えているだけでなく、さまざまなデータ ソースに接続することもできます。しかし、データ レイクのシナリオでは、Spark ソリューションの従来のクラスター バージョンは、前述のデータ管理の難しさ、運用および保守コスト、コンピューティング リソースの弾力性の不足、エンタープライズ レベルの機能の弱さといった問題に直面するだけでなく、OSS へのアクセスのパフォーマンスが低い、複雑なジョブのデバッグが難しいなどの問題にも直面します。

第 2 章で説明したデータ レイク管理メカニズムの助けを借りて、データ管理の問題を適切に解決できます。 DLA Spark は、第 3 章で説明したマルチテナント セキュリティ プラットフォームの助けを借りて、弾力性、運用および保守コスト、エンタープライズ レベルのニーズの問題を効果的に解決する新しいクラウド ネイティブ サーバーレス製品形式を実現しました。このセクションでは、マルチテナント UI サービスを使用した OSS への Spark アクセスのパフォーマンス最適化についてさらに説明します。

1 OSS最適化へのSparkアクセス

コミュニティ版の問題

デフォルトでは、Spark のオープン ソース バージョンは Hadoop FileFormat インターフェイスを使用して OSS FileSystem に直接接続し、OSS データにアクセスします。実際には、この方法ではパフォーマンスが低い、一貫性を確保するのが難しいなどの問題があることが判明しています。

（１）SparkはOSSへのアクセス性能が低い

主な理由は、OSS KV モデルと HDFS ファイル ツリー モデルの違いにあります。 FileFormat アルゴリズムは、もともと HDFS ファイル システムに基づいて設計されました。ただし、OSS などのオブジェクト ストレージでは、スケーラビリティに対応するために基本的に KV モデルが採用されています。 KV モデルは HDFS ファイル システムとはまったく異なります。たとえば、RenameDirectory インターフェースは HDFS では単なるポインター操作ですが、KV ではすべてのサブファイルとディレクトリの KV の名前を変更する必要があり、パフォーマンスのオーバーヘッドが大きく、アトミック性を保証することができません。データを書き込むとき、Hadoop FileOutputFormat は最初にデータを一時ディレクトリに書き込み、次に最終ディレクトリに書き込みます。一時ディレクトリから最終ディレクトリまでのプロセスでは、ファイル ツリーをマージする必要があり、マージ プロセスには多数の名前変更操作が伴います。

（２）一貫性確保の難しさ

FileFormat v1 アルゴリズムでは、ファイル ツリーをマージするすべての操作が AppMaster の 1 つのポイントで実行されるため、特に動的パーティションのシナリオでは非常に非効率的です。 AppMaster の単一点問題を解決するために、コミュニティはアルゴリズム 2 を提供しています。中心となるアイデアは、タスク内でマージ プロセスを並列に実行することであり、これによりパフォーマンスがある程度向上します。ただし、ジョブの実行に失敗した場合、一部の成功したタスクはデータを最終データ ディレクトリに書き込み、ダーティ データの問題が発生します。

Spark OSS アクセス最適化

​​

(1) MultipartUploadに基づくFileOutputFormatの実装

Spark が OSS にアクセスする特性を考慮し、上図に示すように Hadoop FileOutputFormat インターフェースを新たに実装しました。アルゴリズムの改善の焦点は、マージ操作を最適化することです。マージの核心は、ファイルがいつ表示されるかという問題を解決することです。 OSS は、ブレークポイント再開機能である MultipartUpload インターフェイスを提供します。ファイルは分割してアップロードできます。アップロードが完了していない場合、パーツファイルは表示されません。この機能を使用すると、タスクが最終ディレクトリに直接データを書き込むことができます。ファイルはジョブが成功した場合にのみ表示されます。この方法では、最初に一時ディレクトリに書き込む必要がないため、メタデータ操作が大幅に削減されます。失敗したタスクによって書き込まれた一時シャードについては、ジョブの終了時に中止操作を実行することで削除でき、占有されるスペースが削減されます。

Spark の一般的な ETL ベンチマーク Terasort では、入力データが 1 TB の場合、DLA FileOutputFormat の実行時間が 62% 短縮され、パフォーマンスが 163% 向上しました。動的パーティショニングのシナリオでは、コミュニティ アルゴリズム 1 は実行に失敗しますが、アルゴリズム 2 は正常に実行できます。 DLA FileOutputFormat アルゴリズムのパフォーマンスは、アルゴリズム 2 と比較してさらに 124% 向上します。

(2)OSSメタデータキャッシュ

Spark が OSS を読み取るとき、ResolveRelation フェーズでは、Spark は OSS ディレクトリをトラバースし、テーブル構造とパーティション構造を解析し、スキーマを解析します。このプロセスでは、メタデータ操作も大量に発生し、同じ OSS オブジェクトのメタデータに複数回アクセスすることになります。この問題に対処するために、OSS メタデータのキャッシュを実装しました。初めてアクセスされた OSS オブジェクトのメタデータはローカルにキャッシュされ、その後のオブジェクトへのアクセスではローカル キャッシュが直接読み取られます。このアプローチにより、OSS メタデータへのアクセスを最小限に抑えることができます。キャッシュ メカニズムにより、ResolveRelation のパフォーマンスが約 1 倍向上します。一般的な Spark クエリ シナリオでは、このメカニズムにより全体的なパフォーマンスが 60% 向上します。

2 マルチテナントUIサービス

UI サービスは、ジョブのデバッグや本番ジョブのトラブルシューティングに頼る開発者にとって非常に重要です。優れた UI サービスは、R&D の効率を大幅に向上させることができます。

HistoryServer の問題点

Spark コミュニティは、Spark 履歴ジョブの UI とログ サービスを提供する HistoryServer を提供します。実際のアプリケーションでは多くの問題点が発生しますが、典型的なものは次のとおりです。

（１）イベントログのスペースオーバーヘッドが大きい

HistoryServer は、Spark エンジンを利用して実行中のすべてのイベント情報を FileSystem に記録し、それをバックグラウンドで再生して UI ページを描画します。複雑で長いジョブの場合、イベントログのボリュームは大きくなり、数百 GB または TB レベルに達することもあります。

（２）複雑で長い作業はサポートされていない

複雑なジョブや長いジョブの EventLog が非常に大きい場合、HistoryServer はそれを解析できないか、OOM を引き起こす可能性があります。さらに、スペースのオーバーヘッドが大きいため、通常、ユーザーは Eventlog を閉じるしかありません。

（３）再生効率が低く、遅延が大きい

HistoryServer は、バックグラウンドでイベントログを再生して Spark UI を復元します。これは、Spark エンジンのすべてのイベントを再生することと同じです。これには大きなオーバーヘッドがかかり、遅延が発生します。特にタスクの数が多かったり複雑だったりする場合は、遅延が数分、場合によっては 10 分にも達することがあります。

DLA マルチテナント SparkUI

​​

SparkUI サービスは、DLA プラットフォームによって開発されたマルチテナント UI サービスであり、コミュニティ ソリューション向けに最適化されています。

（1）イベントログへ移動

DLA Spark は Eventlog への依存関係を削除します。ジョブが終了すると、Spark ドライバーは UI メタを OSS にダンプし、ジョブが終了する前にページ メタ情報を保存します。この部分の情報は、イベントログと比較して大幅に削減されており、非常に複雑なジョブでも MB レベルのみです。 UiServer は OSS 上の UI Meta を読み取り、デシリアライズして SparkUI ページを表示します。

（２）UIServerの水平展開

UIServer は主に、履歴 UI メタの解析と、Stderr および Stdout ログ サービスの提供を担当します。軽量かつステートレスであり、水平方向に拡張して、オンラインで同時にサービスを提供する数万の顧客をサポートできます。 UIServer URL は暗号化されたトークンをパラメータとして使用します。トークンはユーザー ID とジョブ ID を表し、UIServer はこれに基づいてマルチテナント サービスを実装します。

（３）ローカルログの自動スクロール

長時間のジョブの場合、Stderr または Stdout の情報が時間の経過とともに蓄積され、ディスクが破損する可能性もあります。 DLA Spark セキュリティ コンテナーには、ログ ローリングを実装し、最新の期間の最も重要なログを保存するためのバックグラウンド プロセスが組み込まれています。

サーバーレス SQL サービスの 5 つの技術的課題

DLA Serverless SQL は、現在 Linux Foundation によってホストされている PrestoDB に基づいて構築されたクラウドネイティブのデータ レイク エンジンです。 Alibaba は Presto Foundation のメンバーでもあり、Presto の最適化に貢献しています。 PrestoDB エンジン自体には優れた機能があります。

• フルメモリコンピューティングがもたらす超高速性。
• 完全な SQL セマンティクスによってもたらされる強力な表現力をサポートします。
• 使いやすいプラグイン メカニズムにより、任意のデータ ソースに対して関連するクエリを実行できます。
• 強力なコミュニティのおかげで、使用後も安心です。

ただし、コミュニティ PrestoDB はシングルテナント エンジンです。企業内での使用を前提としているため、コンピューティングパワーの分離、高可用性などへの投資は多くありません。そのため、クラウドネイティブサービスのエンジンとして直接使用することは困難です。いくつかの問題があります:

• ユーザーが大量のクエリを送信すると、すべてのクラスター リソースが占有され、他のユーザーが使用できなくなる可能性があります。
• 単一のコーディネーターでは、サービス全体の可用性を保証することはできません。

すべてのユーザーにクラウドネイティブ形式でサービスを提供できるように、一連の最適化と変更を行いました。今日は、マルチテナント分離テクノロジーとマルチコーディネーターという 2 つの主な機能に焦点を当てます。

まず、DLA Serverless SQL の全体的なアーキテクチャを見てみましょう。

​​

ユーザーが安定して便利に使用できるように、コア PrestoDB クラスターの周囲にアクセス層や統合メタデータなどのサービスを構築しました。以下では、マルチテナント分離技術とマルチコーディネーター技術の紹介の中で詳細に分析します。

1 マルチテナント分離技術

PrestoDB はリソース グループによってネイティブにサポートされています。異なるリソース グループ間で、ある程度の CPU およびメモリの制限をサポートできます。ただし、これに基づいてコンピューティング パワー分離を実装することを妨げるいくつかの問題があります。

• グローバル スケジューリング レベル: テナントがコンピューティング リソースを過剰に使用した場合でも、時間的に罰せられることはなく、新しいクエリのみがブロックされます。
• ワーカーのスケジュール レベル: すべてのテナントの分割が同じキューにスケジュールされます。テナントの Split が多すぎると、他のテナントに影響します。

当社のコンピューティング パワー マルチテナント ソリューションは次のとおりです。

​​

すべてのコーディネーターからすべてのテナントのリソース使用状況情報を収集するために、クラスターに ResourceManager モジュールを導入しました。 ResourceManager は、収集されたリソース使用情報と事前に設定されたコンピューティング能力のしきい値を比較し、どのテナントを罰する必要があるかを計算し、すべてのワーカーにペナルティ情報を通知します。スケジュール設定時に、Worker は ResourceManager から通知されたペナルティ情報を参照して、どのテナントのクエリをスケジュール設定するか、どのテナントのクエリをスケジュール設定しないかを決定します。このようにして、異なるテナント間のコンピューティング能力が分離されます。テナントがリソースを過剰に使用した場合、最大 1.3 秒以内にペナルティが課せられ、他のテナントにリソースが解放されることをテストしました。コミュニティのデフォルト バージョンの「ペナルティ」は、テナントのすべてのクエリが実行されるまで発生しません。メタデータとコンピューティング能力が分離されている場合にのみ、1 つのクラスターを安全に使用してすべてのユーザーにサービスを提供できます。

2 マルチコーディネーター技術

Presto のコミュニティ バージョンでは、コーディネーターは単一のポイントであるため、次の 2 つの問題が発生します。

• 可用性リスク: コーディネーターがダウンすると、クラスター全体が 5 ～ 10 分間使用できなくなります。
• シームレスなアップグレードは実現できず、アップグレード プロセス中はすべてのユーザーのクエリ使用状況が影響を受けます。

私たちは次のアーキテクチャソリューションを採用しました。

​​

まず、Presto の Coordinator の上に新しい FrontNode モジュールを配置し、ユーザーが基盤となる Coordinator に直接接続するのではなく、このモジュールに接続できるようにしました。こうすることで、下部にいくつのコーディネーターがいて、どのコーディネーターが現在ユーザーにサービスを提供しているかがユーザーにとって完全に透明になります。これにより、アーキテクチャがより柔軟になり、下部のコーディネーターを拡張しやすくなります。

ユーザーのクエリを受信した後、FrontNode は、複数のコーディネータが負荷を共有できるように、ラウンドロビン方式で複数の基盤となるコーディネータにリクエストを送信します。ただし、Presto のワーカー ステータス監視、OOM Killer など、クラスター全体で単一のコーディネーターが実行する必要があるグローバルな処理がまだいくつかあります。そのため、コーディネーター リーダーを選出するために Zookeeper を導入しました。選挙後、メインコーディネーターの責任はコミュニティの Presto の責任と同様になります。つまり、グローバルワーカーステータスの監視、OOM Killer、それに割り当てられたクエリの実行などです。スレーブ コーディネータの役割は比較的軽く、割り当てられたクエリを実行することだけを担当します。

コーディネーターの 1 つが何らかの問題でダウンした場合、Zookeeper は数秒以内に問題を検出し、マスターを再選出します。ユーザーは影響を受けるクエリを再試行するだけで済みます。クエリを自動的に再試行することも試みています。システム上の理由により発生したと判断された障害については、自動的に再試行されます。この方法では、コーディネーターがユーザーに与える影響はほとんどありません。

マルチコーディネーターアーキテクチャにより、シームレスなアップグレードを簡単に実現できます。アップグレードする場合は、クラスターからコーディネーター/ワーカーを事前に削除し、アップグレードして、アップグレードが完了した後にクラスターに追加するだけです。アップグレード プロセス中は常に正常に動作するクラスターがユーザーにサービスを提供しているため、顧客はこれに気付かない場合があります。たとえば、スレーブ コーディネーターをアップグレードすると、クラスター全体は次のようになります。

​​

マルチテナント分離技術やマルチコーディネーターアーキテクチャなどの最適化を通じて、すべてのユーザーにサービスを提供できる PrestoDB ベースの Alibaba Cloud クラウドネイティブ データレイク サーバーレス SQL エンジンを構築しました。

クラウドネイティブ データレイクのエンドツーエンドのベストプラクティス 6 つ

​​

上の図に示すように、DLA はエンドツーエンドのソリューションを提供します。 OSS データのオープン性によって管理やデータ レイクへのアクセスが困難になる中、DLA データ レイク管理は、安全なデータ レイクをワンストップで構築するのに役立ちます。

• OSS データを管理し、ライブラリとテーブルの権限をサポートするための、統合されたオープンなメタ サービスを提供します。
• メタデータクロール機能を使用すると、ワンクリックでOSS上のメタデータ情報を作成し、CSV/JSON/Parquetなどの形式を簡単かつ自動的に識別し、後続のコンピューティングエンジンで使用するためのライブラリとテーブル情報を確立できます。
• RDS/PolarDB/MongoDB などのデータベースから OSS ストレージにデータをワンクリックで同期し、階層化されたホット データとコールド データを使用してビジネス アーキテクチャを構築し、複数のソースからの大量のデータに対してデータ分析を実行します。
• Hudi 形式のストリーミング構築をサポートし、T+10 分の遅延要件を満たし、分析のエンドツーエンドの遅延を大幅に改善します。
• サーバーレス SQL 分析により、データレイクをすぐに使用できるようになります。ユーザーは、リソースを購入することなく、標準の SQL 構文を実行してデータを照会できます。
• データ レイク ストレージ OSS キャッシュの高速化をサポートし、パフォーマンスが 10 倍向上します。
• RDS、PolarDB、ADB、MongoDB を含む 10 個のデータ ソースの分析をサポートします。
• 従来の Presto および Impala ソリューションと比較すると、コスト効率が 10 倍向上します。
• サーバーレス Spark コンピューティングは、データ レイクを独立して運用するのに役立ちます。ユーザーは、リソースを購入することなくクラウドネイティブの Spark サービスを使用でき、OSS PB データのクリーニング、機械学習、ユーザー プログラマビリティ、データ レイクの操作がサポートされます。
• 毎分 500 個のノードがポップアップして計算に参加できます。
• 従来の自社構築の Spark ソリューションと比較すると、コスト効率が 3 倍向上します。

DLA には多くの技術的なポイントが関係するため、この記事ではいくつかの技術的な詳細について説明します。詳細については、クラウドネイティブデータレイク分析 DLA をご覧ください: https://www.aliyun.com/product/datalakeanalytics

【この記事は51CTOコラムニスト「アリババオフィシャルテクノロジー」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください