Amoro は、Apache Iceberg などのオープン データ レイク テーブルに基づいて構築されたレイク ウェアハウス管理システムであり、プラグイン可能なデータの自己最適化メカニズムと管理サービスのセットを提供し、ユーザーがすぐに使用できるレイク ウェアハウスの使用を実現することを目指しています。 。
01 著者について
Zhejiang Telecom のビッグ データ センター プラットフォーム グループの責任者であるYu Zhiqiang 氏は、通信業界におけるデータ ウェアハウスとビッグデータの。商用 MPP データベース Vertica およびオープンソース MPP データベース StarRocks-DBA の経験があります。現在は主に、Apache Iceberg とオープンソース MPP 製品データ アプリケーション市場に基づく統合レイクウェアハウス アーキテクチャの構築と実装に携わっています。
02 浙江電信のApache Iceberg
アイスバーグを選ぶ理由
Zhejiang Telecom のビッグ データ センターは、主に通信のビジネス データの集約とデータ ウェアハウスの作成、および一部のデータ アプリケーションを担当しています。ビッグ データ アーキテクチャの革新は、これまでに一般的に 3 つの段階を経てきました。
フェーズ 1: データ ウェアハウスの変革 Hive の探索
ビッグデータ システムの反復に伴い、Hive をベースとしたリアルタイム分析ビッグデータ システムの構築を開始し、同時にデータ ウェアハウスの Hive への変換の実現可能性を検討しましたが、Hive への切り替え後、次のような問題が発生しました。 :
-
MR 実行を使用する場合、オフライン バッチ処理は非効率であり、商用 MPP データベースと比較して生産完了時間が 4 ～ 5 時間遅れます。
-
リレーショナル データベースの制約、フィールド タイプの厳格な制限、ACID セマンティクス、サードパーティのツールとプラットフォームの支援の欠如により、その後のデータ品質維持コストが増加し、データ品質が標準以下になってしまいました。
上記の要因に基づいて、Data Warehouse は Hive の変革プロセスを一時停止し、より手頃な価格の商用 MPP 製品の探索に戻りました (主に元の MPP 行ストレージのボトルネックから出発し、x86 アーキテクチャに基づくカラムナ ストレージ MPP データベースを導入しました)。完了したビッグ データ クラスターの同期は、高い適時性を必要としないいくつかのデータ アプリケーション タスクを実行するための Hive 探索に基づいています。Hive にデータを書き込むプロセスは次のとおりです。
ここでの派生ツールは主にローカル収集チームがJavaを介して開発しており、Oracleにアクセスしてライブラリから定型テキストファイルを定期的に抽出・生成し、Hiveに書き込みます。これで、ビジネス データとデータ ウェアハウス データの同期が完了します。この方法の主な基盤は、Oracle によるデータベースからの読み取りパフォーマンスが保証されており、ビジネス システム ライブラリの使用に影響を与えないことですが、定期的なトリガー方法では、Hive でのデータの適時性が比較的劣るという運命もありました。
フェーズ 2: ビジネス システムをクラウドに移行すると、バックエンドのデータ ウェアハウスとアプリケーション システムのアーキテクチャが調整されます。
その後、浙江電信がシステムのクラウド移行作業を開始するに伴い、業務システムライブラリはOracleからTeleDB（MySQLをベースとしたテレコム自社開発リレーショナルデータベース）へと徐々に移行し、ビジネスライブラリデータを直接読み込む従来のデータフローリンクから、 TeleDB ビジネス ライブラリを使用してデータ ウェアハウス システムに書き込むと、大きな負荷がかかります。これらの問題により、データリンクも変化しました。
ここでの派生ツールは主に 2 つの製品を使用します。1 つはオープンソースの Canal テクノロジを通じてパッケージ化された外部製品からのものです。その後、この製品は TeleDB のみを適応させたため、実際のニーズを満たしていませんでした (TelePG は後から本番環境で導入されました) Telecom は自社開発した postgresql データベースに基づいており、その後、Telecom が自社開発したクロス IDC 同期ツールを導入し、オフライン データ収集からリアルタイム データ収集までのデータ ウェアハウス ODS 層の革新を可能にしました。ビジネス分析用の Hive データ システムのデータの適時性は依然として比較的悪いです。
フェーズ 3: ビッグデータの方向性を再考し、統合されたレイクとウェアハウスのクラスターを構築する
本番システムのクラウド移行が安定した後、データウェアハウスとアプリケーションマートもクラウド移行のプロセスを開始し、ビッグデータの位置付けと方向性を再考し、徐々に疎外されつつあるビッグデータクラスターを再構築して浙江電信を支援することを検討しました。すべてのビジネス システム データのデータ ウェアハウスをリアルタイムで集約、統合、再構築します。オリジナルの CDH クラスターは、チャイナ テレコムによって開発されたビッグ データベース バージョンにアップグレードされました。同期には、リアルタイムのデータの書き込みと読み取りをサポートできるレイク ウェアハウスのベースの形式を選択する必要があります。データ レイク テクノロジが徐々に成熟し、ビッグ データ チームがオープン ソースを採用するようグループが奨励していることを背景に、私たちの調査では、データ レイク製品がリアルタイム データの書き込みと読み取りの問題を十分に解決できることが判明しました。
Hudi、Delta Lake、Iceberg を比較した結果、Iceberg は CDC データ書き込みを適切にサポートしているだけでなく、ストリーミング バッチ エンジンと MPP データベースのサポートも充実していると考えられます。パフォーマンス ニーズを満たすために、さまざまなビジネス分析シナリオに応じてさまざまなエンジンを選択できます。 、NetEase データ開発および管理プラットフォーム EasyData (以下 NetEase EasyData) と Wushu BI も Iceberg を適切にサポートしています。最終的に、新しいテーブル形式として Iceberg を選択しました。
ここでもデータ リンクは 2 つの段階を経ています。
-
ステージ 1:
Kafka は、主に NetEase EasyData による FlinkSQL モジュールのリアルタイム開発を通じて Iceberg に書き込まれます。しかし、独自の同期ツールでは保証が不十分であったこととデータセンターの導入により、データリンクの最適化・調整が行われました。
-
ステージ 2:
初期の頃、TeleDB は NetEase EasyData リアルタイム データ送信 (FlinkCDC ベース) を通じて Iceberg にリアルタイムで書き込まれていましたが、オンライン タスクの量がますます増大するにつれて、Telecom の自社開発データベース TeleDB とTelePG が発見されました。その後、プロジェクトの立ち上げに時間が迫っていたため、私たちのチームは、FlinkCDC 機能に基づいて、レイクへのビジネス データのリアルタイム入力を実現するために、自己開発したデータをレイク コレクション プラットフォームに投入しました。全体的な運用は現在安定していますが、リソースの最適化と使いやすさについてはさらなる研究開発が必要です。
ビジネス慣行
私たちのチームのデータ ソースは、Zhejiang Telecom の BMO ドメインやその他のシステムからのビジネス データを含む幅広いソースから取得しています。データは ODS 層に分類された後、DWD と DWS によって処理され、さまざまなビジネス分析シナリオの要件に従って Youshu プラットフォーム上でさまざまなレポート (リアルタイム レポートとオフライン レポート) が生成されます。これらのレポートの内容は次のとおりです。ビジネスと分析に組み込まれています。担当者が日常的に使用するアプリケーションは、各オペレーティング ノードで利用できます。
レポートのさまざまな使用シナリオによってデータの応答速度が決まり、さまざまな計算エンジンを使用する必要があることも決まります。日常的なセルフサービス分析では、Spark と Trino を使用して Iceberg レポートのクエリをサポートします。データ ウェアハウスの本番レイヤーのバッチ処理は主にオフラインであり、主に Spark に依存します。アプリケーション レイヤーで高い応答速度が要求されるシナリオの場合、 Doris データベース (カタログ Iceberg テーブルへの直接アクセス) を使用して、さまざまなシナリオのニーズをサポートします。
使用法
データ ウェアハウス システムのテーブル形式として Iceberg を決定してから、ほとんどの ODS を Iceberg に変換しており、今後は DWD と DWS を段階的に Iceberg に変換する予定です。
現在の Iceberg テーブルの合計ストレージ容量は 1.1PB ですが、すべてのデータ ウェアハウスの変革が完了した後は 10 ～ 15PB になることが予想されます。このうち、10,000 近くの Iceberg CDC テーブルがリアルタイムで書き込まれ、最初の変換完了後には合計 30,000 ～ 40,000 の Iceberg テーブルが書き込まれると推定されています。
03 浙江電信のアモロ
アモロを選ぶ理由
Iceberg テーブルへのリアルタイム書き込みでは、多数の小さなファイルが生成されます。特にデータの一貫性を確保するために、多くのシナリオで更新/挿入モードをオンにしました (このモードでは、データが書き込まれるたびに、大量の等価削除ファイルを生成すると、小さいファイルの問題がさらに悪化し、クエリのパフォーマンスに大きな影響を与え、エンジン側で OOM が発生することもあります。したがって、小さいファイルのタイムリーな監視とマージ、および等価削除ファイルの削減は、Iceberg テーブルの可用性を確保するために非常に重要です。
Iceberg ファイルをマージするときに、主に次の問題に遭遇しました。
- 等価削除ファイルのマージ効果は理想的ではありません。Iceberg コミュニティが提供するマージ方法を使用し、定期的に Flink Spark タスクをスケジュールしてファイルをマージします。書き換えによるファイルのマージのこの方法は、数百 G のデータを必要とし、比較的高価ですマージには毎回数時間またはそれ以上かかる場合があり、マージの完了後すぐに等価削除ファイルが削除されないという問題が依然として発生する可能性があります。
- 等価削除ファイルのバックログが大きいとマージが失敗する:テーブルのファイル ステータスが時間内に検出されない場合、またはマージ失敗によって等価削除バックログが発生すると、ファイルのマージ プラン、メモリ消費量、読み取りおよび書き込みのオーバーヘッドが発生します。多くの場合、 OOM 、実行時間が長すぎるなどの問題が原因で非常に大きくなり、最終的にはマージを完了できなくなり、テーブルを復元するためにのみテーブルを復元できるため、メンテナンスコストが大幅に増加します。
上記の問題に基づいて、多くの断片化されたファイルを含むテーブルを適時に検出し、これらのテーブルをタイムリーに最適化できる成熟したシステムを実現したいと考えています。調査を通じて、Amoro がこのシナリオを非常にうまく解決できることがわかりました。Amoroは、テーブルの最適化をより適切に管理するのに役立つさまざまな機能を提供します。
-
Web UIにはテーブルや最適化に関するインジケーターが表示され、テーブルのファイル状態や書き込み頻度、最適化の内容や動作状況をより直感的に把握できます。
-
永続的なタスクにより継続的にテーブルを最適化します。
-
オプティマイザーリソースの柔軟な拡張と縮小
-
オプティマイザーグループによる分離テーブルのリソースの最適化
使用法
Amoro のデプロイ後、すべての Iceberg テーブルを迅速に接続しました。初期のデプロイとデバッグ段階で多くのテストと検証を行い、同時に Iceberg テーブルの作成方法 (パーティションの使用など) を最適化しました。コミュニティのサポートに感謝します。素晴らしいサポートです。現在、テーブルのサイズとビジネスに基づいて合計 2 つのオプティマイザー グループに分けており、合計リソースでは 78 コアと 776GB のメモリ (比較的多くのメモリ リソースを消費します) を使用し、小さなファイルを安定かつ効率的に管理およびマージできます。
効果
Amoro は効率的で安定したマージを提供します
Amoro は、小さなファイルをマージして大きなファイルの書き換えを回避する軽量のマイナー最適化メソッドを提供し、クエリ パフォーマンスが高い等価削除ファイルを pos-delete ファイルに変換します。Iceberg コミュニティのファイル マージ方法と比較して、このマージ方法はオーバーヘッドが少ないため、より頻繁に実行でき、実行サイクルは分レベルであるため、小さなファイルのバックログを効果的に回避できます。
Amoro を使用する前は、CDC によって頻繁に書き込まれる Iceberg テーブル内の等価削除ファイルの数は 1,000 を超えることが多く、単一のデータファイルに関連付けられた等価削除ファイルのサイズは 5 GB を超えていました。
Amoro を使用した後、Iceberg テーブルの等価削除と小さなファイルの数は 50 未満のままです。
Amoro は等価削除ファイルのバックログを処理します
すべての Iceberg テーブルに対して upsert構成を有効にした 後の問題は、 Icebergテーブルに多数の等価削除ファイルがあることです。等価削除のバックログが発生すると、マージ タスクの OOM が容易に発生する可能性があります。これは、Iceberg プランのタスクメカニズムでは、データファイルが、それ自体よりシーケンス番号が大きいすべての等価削除ファイルに関連付けられるためです(ファイルのシーケンス番号は、デフォルトではスナップショットのシーケンス番号と等しく、ファイルのシーケンス番号はスナップショットのシーケンス番号と等しくなります)。スナップショットは自動的に増加します) 。したがって、履歴スナップショット用に送信されたファイルは、大量の等価削除ファイルを参照します。これらの等価削除ファイルは、関連するデータファイル内のデータを削除するために、 Iceberg MORおよびファイルのマージ中にメモリに読み込まれる必要があります。これにより、大量のメモリが消費されます。
上記の問題に対応して、Amoro コミュニティは の最適化を行いました。UPSERT シナリオでは、データファイルに関連付けられた等価削除ファイル内のデータの多くは現在のデータファイルに関連していないため、実際にはメモリ内に読み取られた等価削除ファイルには無効なコンテンツが大量にありますが、それらはメモリを占有します。たくさんの記憶。さらに、Amoro は、自己最適化タスクを計画するときに self-optimizing.max-task-size-bytes 構成を構成することで、各タスクのデータファイルのサイズを制限できます。そのため、各タスクのデータファイルのサイズは予期されていますが、等価削除は可能です。ファイル サイズは予測不可能です。次に、タスク内のデータファイルの内容を使用して、メモリにキャッシュする必要のない等価削除レコードを除外できます。
具体的な実装方法は、タスク内のデータファイルの等価フィールドのレコードを使用してブルームフィルターを構築し、このブルームフィルターを通じて、関連する多数の等価削除ファイル内の等価フィールドのデータとデータファイルの間に交差があるデータをフィルターで除外します。 MOR に参加するためにメモリが使用されるため、メモリ使用量が大幅に削減され、多数のファイルがある場合にオプティマイザ OOM を引き起こす UPSERT シナリオの等価削除ファイルが回避されます。
04 今後の計画
-
将来的には、現在の Iceberg バージョンをテレコム自社開発の Iceberg バージョンにアップグレードする予定であり、まず、Flink によるリアルタイム書き込み中に生成されるファイルの数を最適化し、自己最適化における Amoro へのプレッシャーを軽減します。 Iceberg オープンソース コミュニティ
-
DWD レイヤーと DWS レイヤーを商用 MPP データベースからアイスバーグベースのレイクウェアハウス統合クラスターに段階的に移行します。
-
将来的にデータレイクをリアルタイムで読み取る必要があるかもしれないことを考慮すると、Iceberg はまだ V2 テーブルのリアルタイム読み取りをサポートしていないため、実際のシナリオを解決するために Amoro Mixed Iceberg を使用することも調査し、試みています。 -データレイクの読み取り時間。
最後に、アモロ コミュニティの強力なサポートに改めて感謝し、アモロ コミュニティがますます良くなることを願っています。
終わり〜
データレイク、レイクとウェアハウスの統合、テーブル形式、または Amoro コミュニティにご興味がある場合は、詳細なディスカッションのためにお問い合わせください。
アモロの詳細については、次のサイトを参照してください。
- 公式サイト： amoro.netease.com/
- ソースコード: github.com/NetEase/amo…
コミュニティコミュニケーション: kllnn999 を検索し、芦田愛菜アシスタント WeChat を追加してコミュニティに参加します
著者: ゆう志強
編集者: ビリジアン