オープンソースのストリーミングレイクリポジトリサービスである Arctic の詳細な説明: 単なるテーブル形式ではありません。

オープンソースの詳細については、以下をご覧ください。

51CTO オープンソース基本ソフトウェアコミュニティ

https://ost..com

まず初めに、Arcticオープンソースローンチイベントにご参加いただき、誠にありがとうございます。NetEase DataFanのリアルタイムコンピューティングおよびレイクウェアハウジングチームの責任者、Ma Jinです。2020年から新しいデータレイク技術に注力し、それらを用いてストリームバッチとレイクウェアハウジングを統合したアーキテクチャを構築しました。当初はFlink + Icebergを使用していましたが、実運用環境においてこのアーキテクチャは依然として大きなギャップがあることがわかったため、Arcticプロジェクト（github.com/NetEase/arctic）を立ち上げました。

データレイクのテーブル形式に関する議論

まず、主流のオープンソーステーブル形式である Apache Hudi、Apache Iceberg、Delta の選択について見てみましょう。

テーブル形式の概念はIcebergによって初めて提案され、現在業界では主に2つの側面に焦点が当てられています。まず、テーブル形式はどのファイルがテーブルを形成できるかを定義し、Apache Flink、Apache Spark、Trino、Apache Impalaなどのあらゆるエンジンが、この形式に基づいてデータを照会および取得できるようにします。次に、テーブル形式はデータとファイルの分散を標準化します。データを書き込むすべてのエンジンはこの標準に準拠する必要があり、この形式で定義された標準を使用することで、HiveではこれまでサポートされていなかったACIDとスキーマ進化機能をサポートします。Iceberg、Delta、Hudiは、実装が大きく異なるものの、これらの機能においては基本的に同等であることがわかります。しかし、共通点を抽象化することは、私見では非常に有意義です。

主流のデータレイクテーブル形式とHiveを比較すると、HiveはHDFS上のテーブルと静的ディレクトリ間のマッピング関係を単純に定義するだけです。ACID保証がないため、実際の本番環境では、単一の読み取りと単一の書き込み操作しか許可されません。現在、上位層データプラットフォーム、つまりDataOpsプラットフォームは、ワークフローを通じてHiveの適切な使用を保証できますが、これはオフラインシナリオにのみ適しています。

Iceberg、Delta、Hudi が主導する新しいテーブル形式機能は、スナップショットの概念を導入します。テーブルメタデータは、単純なテーブルとファイルの関係ではなく、テーブルとスナップショット、そしてスナップショットとファイルの関係性を表します。データの書き込みごとに新しいスナップショットが生成され、このスナップショットとファイルの間には動的なマッピング関係が確立されます。これにより、各書き込みの ACID 保護が保証され、スナップショットによる読み取りと書き込みの分離が可能になります。さらに、スナップショットは、増分書き込みに基づく増分読み取り（CDC 機能）や、タイムトラベルやデータロールバックなどのバックトラッキングのサポートなど、上位層にとって興味深い機能を提供します。

要約すると、テーブル形式には 4 つのコア機能があります。

まず、構造の自由度があります。単純な列追加操作しかサポートしていなかった以前のHive形式とは異なり、DeltaやIcebergなどのテーブル形式では、データの移行や変更に制限なく、列の追加、削除、変更など、テーブル構造を自由に変更できます。

2つ目は、読み書きの自由度です。スナップショットによってデータのACID特性が保証されるため、リアルタイム、オフライン、AI関連のあらゆるニーズにおいて、このテーブルへのデータの書き込みや読み取りを自由に行うことができます。

3つ目に、バッチ操作とストリーム操作は同じソースを共有します。テーブル形式の中核機能はストリーミングシナリオへの優れたサポートであるため、バッチ操作とストリーム操作の両方で新しいテーブル形式への書き込みと読み取りが可能です。

4つ目は、エンジンの均一性です。これは非常に重要です。単一のエンジンだけに縛られるべきではありません。例えば、DeltaはSpark 1.0時代のエコシステムの構成要素でしたが、1か月前にリリースされたDelta 2.0によって、複数のエンジンへの適応の重要性が改めて証明されました。

Table Format などのプロジェクトの公式 Web サイトでは、CDC、SQL 拡張、データロールバック、タイムトラベル、スキーマの進化、ストリーミング更新 (Upsert)、よく話題になる merge-on-read 機能などの機能が強調表示されます。

CDCは、ある程度、メッセージキューを置き換えることができます。例えば、実稼働シナリオでは、リアルタイムコンピューティングでは主にKafkaまたはPulsarを使用してストリーミングテーブルを選択します。テーブル形式を使用することで、データレイクをベースにメッセージキューのような機能を実装でき、データレイテンシを数ミリ秒または数秒から数分に短縮できます。多くの企業がデータレイクを推進する主なシナリオは、リアルタイム更新と読み取り時マージを使用してApache Kudu、Doris、Greenplumなどのリアルタイムデータウェアハウスシステムを置き換えることです。

企業にはどのようなデータレイクが必要ですか?

まず、データレイクテーブル形式の個々の機能だけに焦点を当てると、広範な導入は非常に困難になります。例えば、データレイクのCDC（コンテンツ配信制御）機能は確かにある程度メッセージキューを代替できますが、同時に他の問題も生じます。まず、レイテンシーの問題があります。次に、データレイクをメッセージキューとして使用すると、多数の小さなファイルが生成される可能性がありますが、これらの小さなファイルは誰が管理するのでしょうか？さらに、より暗黙的な問題として、メッセージキューのコストはかつてビジネスチームが負担していました。共有データレイクプラットフォームを使用する場合、このコストはどのように分配すべきでしょうか？

過去2年間、私たちは業界の多くの企業と話をしてきましたが、彼らは皆、あるジレンマに悩まされています。既存のソリューションを置き換えるために新しいデータレイクテクノロジーを導入したいと考えているものの、自社のビジネスにとってその魅力が限られているのです。では、私たちのデータレイク、あるいはレイクハウステクノロジーは、企業に実際にどのような価値をもたらすのでしょうか？

2020年に本番環境においてデータプラットフォームシステム全体が遭遇した最も重大な問題は、ストリーミングプラットフォームとバッチ処理プラットフォーム間の連携不全でした。ご存知のとおり、私たちはオフラインデータウェアハウスであるHiveを中心に、データモデル、データアセット、データ品質など、あらゆる側面を網羅する豊富な手法を開発してきました。また、データレイクのオープンアーキテクチャに基づき、優れた仕様、標準、ガバナンスシステムも構築してきました。

しかし、リアルタイムシナリオに重点を移すと、現在、リアルタイムコンピューティングには主にFlinkを使用し、ストリームテーブルにはKafkaを使用しています。ストリームテーブルの結合を実行する際には、データベースから別途リアルタイム同期タスクを実行する必要がある場合があります。後からデータ分析を行い、高いデータ鮮度が求められる場合は、KuduやDorisなど、準リアルタイムまたはリアルタイムで更新できるデータウェアハウスシステムを導入する必要があります。

このアプローチは、オフラインのテクノロジの選択やツールとは大きく異なり、適切な標準が欠如しており、主にポイントツーポイントの開発に重点を置いています。

例えば、リアルタイム処理とオフライン処理の両方を実行する必要がある場合、2つの別々のパイプラインを設定する必要があります。オフラインパイプラインは、私たちの方法論とオフラインプロセス全体のワークフローに基づいて、比較的容易かつ体系的に定義できます。しかし、リアルタイムシナリオでは、開発者とユーザーはFlinkの使い方、Kafkaからの読み取り方法、シリアライズとデシリアライズの実行方法、Kuduへのテーブル作成方法などを習得する必要があります。こうした仕様は、ユーザーにとって大きな負担となります。

特にAI関連ビジネスでは、データを生成する必要があるため、データのトレーニングやサンプル作成といったAI関連のプロセスに注力しています。HBaseやキーバリューペアの知識がないため、要件を別のチームに委ねてしまい、そのチームは1対1でしか対応できません。

従来の Lambda アーキテクチャの欠点をまとめてみましょう。

最初の問題は、データサイロの問題です。Kuduなどのデータレイクとは別のデータウェアハウスソリューションを使用すると、別途調達・導入コストが発生し、容易な保存によってそのコストが無駄になります。データの再利用や相互運用が難しいため、同じビジネスシナリオでリアルタイムのデータウェアハウスが必要な場合、ソースからデータのコピーを取得する必要があり、コストと人的資源の無駄が生じます。

第二に、研究開発効率の低さ、断片化された研究開発システム、そして普遍的な研究開発基準の欠如が挙げられます。これは特にAI機能やレコメンデーションといったシナリオにおいて顕著であり、ユーザーはリアルタイムデータとオフラインデータの適切な活用方法を判断する必要があり、ビジネスレイヤー全体にわたって大きな複雑さを招いています。

最後に、メトリクスとセマンティクスの曖昧さという問題があります。例えば、ここ数年、私たちはリアルタイムデータウェアハウスソリューションとして主にKuduを使用していました。ユーザーはKudu内にデータウェアハウステーブルを作成する必要があり、これにはKuduスキーマが必要でした。Hiveにもデータモデルを使用して作成された別のスキーマがあり、ユーザーは両方のシステムを自らメンテナンスする必要がありました。ビジネスロジックが変更されると、ユーザーはHiveを変更してもKuduは変更しない可能性があり、時間の経過とともにメトリクスとセマンティクスの曖昧さが生じました。さらに、メンテナンスコストは時間の経過とともに大幅に増加していました。

では、ビジネス側は何を期待しているのでしょうか？基本的には、プラットフォームレベル、データミドルウェア層全体、あるいはデータメソドロジー全体において、一連の標準とプロセスを用いて、リアルタイムプロセスとオフラインプロセス、そしてAIをはじめとする様々なシナリオを統合できるということです。Lakehouseコンセプトの意義を振り返ると、製品の境界を拡張し、データレイクがストリーミングやAIといったシナリオにより適切に対応できるようにすることが重要になります。

私たちの本番環境において、Lakehouseは単一の機能ではなく、最終的にはビジネス全体にわたるメリットをもたらすべきです。例えば、CDCや分析のシナリオでLakehouseを使用するとしても、Kudu、Hudi、Icebergの違いを単純に比較するだけでは、具体的なメリットを明確に伝えるのは難しいかもしれません。しかし、プラットフォーム全体でオフラインとリアルタイムの運用をシームレスに統合できることをユーザーに伝えれば、そのメリットは計り知れません。この目標に基づき、ストリーミングレイクハウスサービスArcticを開発しました。

Arctic Streaming Lakeware サービスについて

Arcticとは？簡単に言うと、ArcticはNetEase DataSailが開発したオープンソースのストリーミングレイクハウスサービスです。IcebergとHiveをベースに、より多くのリアルタイム機能を追加しています。Arcticは主にリアルタイム機能を重視し、DataOps向けにすぐに使えるメタデータサービスを提供することで、データレイクをより使いやすく実用的にします。一文でまとめるのは少々抽象的になってしまうので、Arcticをより深く理解していただくために、後ほど機能の具体例と実用的な洞察をいくつかご紹介します。

ニッチの違い

まず、この図は生態学的地位の違いを強調するために用います。北極圏は表形式よりも生態学的に優れているため、厳密に言えば、北極圏を別の氷山や別の表形式と見なすべきではありません。

もう1つのポイントは、テーブル形式に加えて、オープンソースのテーブル形式との互換性を重視していることです。そのため、Arcticの中心的な目標の一つは、企業がデータレイクのテーブル形式を最大限に活用できるように支援し、テーブル形式とユーザーや製品の実際のニーズとのギャップを解消、あるいは埋めることです。

Arctic自体は2つのコアコンポーネントで構成されています。1つ目はメタデータサービスAMSで、これは当社のシステムにおける次世代HMSとして位置付けられています。2つ目は、バックエンドデータの最適化を実現するための包括的なオプティマイザーコンポーネントとメカニズムを含む、継続的な自己最適化機能です。

テーブルストアのデザインと利点

Arcticについてこれまで多くのユーザーとお話してきましたが、最初に寄せられる質問の多くは、オープンソースのIcebergとの関係についてです。この図で説明したいと思います。まず、Arcticにはテーブルストアという概念があります。テーブルストアはストレージユニットであり、従来のデータベースにおけるクラスター化インデックスに似ています。ストリーミング書き込み時には、CDC（Cyclic Detection and Control：巡回検出と制御）に書き込まれたデータを変更テーブルストアに保存します。このデータは、データベースにおけるbinlogやrelogに似ています。この変更テーブルは、CDCの再生に使用したり、別のテーブルとしてアクセスしたりできます。

HudiとIcebergにもupsert機能がありますが、2020年に開発を開始したIcebergにはこの機能がありませんでした。コミュニティがマニフェストレイヤーの設計を厳密に検討した結果、実装にはいくつかの妥協点がありました。そのため、最終的には、私たちの強みを活かせる上位レイヤーでこの機能を実現することにしました。

Changeテーブルは主にCDCの変更データを保存し、別のBasestoreは既存のデータを保存します。これら2つのTablestoreは、本質的に2つの独立したIcebergテーブルです。あるいは、Kafkaのログストアを統合することもできます。つまり、データをKafkaとデータレイクの両方に書き込むことができ、フローテーブルとバッチテーブルを統合できます。

この設計の利点は何でしょうか? まず、変更テーブル内の CDC データを順番に再生できるため、Iceberg のネイティブ V2 CDC の再生が容易ではないという問題が解決されます。

第二に、「変更」テーブルはパブリックアクセス可能です。多くのeコマースや物流のシナリオでは、「変更」データはテーブル内の組み込みデータとしてだけでなく、注文テーブルや物流テーブルからの変更データが独立したデータウェアハウステーブルとして使用されることも少なくありません。この設計により、「変更」テーブルを書き込み保護を追加することで、独立して使用できます。将来、「変更」テーブルにフィールドを追加したり、カスタムUDF計算ロジックを実装したりするなど、ビジネスニーズに合わせてカスタマイズする必要が生じた場合も、この設計により対応可能です。

第三に、私たちの設計理念は、変更データとベースデータ間の変換、つまり最適化と呼ばれるプロセスに重点を置いています。この概念はDelta、Iceberg、Hudiに導入されており、その中核となるのは小さなファイルのマージです。変更データからベースデータへの変換も最適化のスコープに含めており、これらのプロセスはユーザーにとって透過的です。ユーザーがIcebergまたはDeltaを直接使用すると、すべての最適化操作は基盤レベルでスナップショットを取得することになり、ユーザーフレンドリーではありません。私たちはこれをより高レベルでカプセル化しています。ユーザーが分析のために非常に新鮮なデータを読み取る際、私たちのエンジンは変更データとベースデータの間で読み取り時にマージ操作を実行します。

北極の建築と構成要素

Tablestore の概念を理解すると、Arctic のアーキテクチャとコンポーネントの理解がはるかに容易になります。データレイク層には、それぞれ変更ストアとベースストアに対応する変更ファイルとベースファイルがあります。Tablestore の概念は CDC シナリオに限定されません。将来的なソート機能や特定の ZOrder 要件にも対応できるよう、上位層に別の Tablestore をセットアップします。

上位層には、先ほどご紹介したAMS（Arctic Meta Service）があります。AMSは、Arctic Streaming Lake Warehouseサービスの「サービス」層における重要なコンポーネントであり、トリプルのメタデータセンターとして機能します。

トリプルとは何でしょうか？それはcatalog.table.dbのようなトリプルです。ご存知の通り、Spark 3.0とFlink 1.2は主にマルチカタログ機能を推進し、異なるデータソースに適応できるようにしました。現在、主流のビッグデータ実務では、メタデータセンターとしてHMSが主に使用されています。HMSはバイナリ構造であり、より多くのデータソースに対応するように拡張するには、多くのカスタマイズが必要です。例えば、NetEase DataSailのデータプラットフォームには、トリプルとデータソースの関係を管理するための、HMSとは別のメタデータセンターがあります。AMS自体はトリプル向けに設計されたメタデータサービスです。

第二に、AMSはHMSと同期できるため、スキーマをHMSに保存できます。Hiveが保存できるフィールド情報に加えて、追加のコンポーネント情報とプロパティもAMSに保存されます。このように、AMSとHMSは連携してサービスを提供できるため、Arcticを使用する際に代替手段を用意する必要がありません。これは実際には非常に段階的なプロセスです。

3 つ目は、AMS がトランザクションと競合解決のための API を提供していることです。

オプティマイザーには、包括的な拡張および管理メカニズムが備わっています。まず、オプティマイザーコンテナという概念があります。これは基本的にプラットフォームのタスクスケジューリングのためのコンポーネントです。バックエンドの最適化プロセス全体はビジネスに対して透過的です。バックエンドには、最適化プロセスをプラットフォーム（YARNやKubernetesなど）にスケジュールできるスケジューリングサービスが必要です。この異なるモードがオプティマイザーコンテナの概念です。将来的には、ユーザーはコンテナインターフェースを介してスケジューリングフレームワークを拡張することもできます。

オプティマイザグループはコンテナ内のリソース分離を実行します。例えば、特定のテーブルの最適化を優先的に実行する必要があるとユーザーが判断した場合、それらのテーブルの最適化タスクを実行するための独立したオプティマイザグループを設定できます。

第三に、私たちのアーキテクチャには独立したダッシュボードが含まれており、これは管理インターフェースでもあります。私たちは、レイクウェアハウス自体の管理エクスペリエンスを重視しています。

最後に、そして非常に重要な点として、前述の通り、テーブル形式の完全な互換性を実現しています。現在、IcebergとChangestoreの2つの形式を提供しています。当社のシステムはIcebergをベースとしているため、ベースストアとチェンジストアは独立したIcebergテーブルです。さらに、Icebergのイテレーションを通じて互換性は継続的に向上しており、現在はIceberg V2との互換性を備えています。

さらに、Hive互換モードも用意されており、企業はコードを変更することなくArcticの主要機能の一部を直接利用できます。ユーザーがHive形式互換を使用している場合、変更データは引き続きIcebergに保存されます。

管理機能

前述の通り、Arcticは管理エクスペリエンス、特にバックエンドの継続的な最適化を重視しています。一連の機能と、それに対応するメトリクスおよびキャリブレーション機能を提供しています。下の画像は、現在リソースの最適化を行っているテーブル、その最適化の期間、そして将来的にリソースをより適切にスケジュールする方法を示しています。これらはすべて、Arcticの管理機能を通じて提供されます。

当社のテーブルサービスは、各テーブルへの動的な変更、履歴 DDL 情報、トランザクション情報など、テーブルに関する多くのメタデータ情報を提供しており、それらはすべてテーブルサービスに反映されます。

同時実行競合解決

ストリーミングとバッチ処理の両方で同一オリジンシナリオに対応するためにテーブル形式を使用する場合、例えば下図の上部では、データのCDC同期を行っています。通常、Flinkタスクは継続的な同期を実行します。しかし、バッチ処理で初期化が必要なデフォルト値を持つ列を追加するなど、データのロールバックやデータ修正を実行したい場合は、SparkタスクとFlinkタスクが同期して起動されます。この場合、SparkタスクとFlinkタスクが同じ主キーを持つ同じ行のデータを操作すると、データの競合が発生します。

現在、テーブルフォーマット層は一般的に楽観的同時実行制御セマンティクスを提供しています。競合が発生した場合、まず特定のコミットを失敗させることが検討されます。言い換えれば、楽観的同時実行制御の中核となるセマンティクスは、同時実行を禁止することです。今回のシナリオでは、Sparkタスクがすべてのデータを書き換えると予想されるため、コミットがまったく行われない可能性があります。これは必然的にリアルタイムデータスコープと競合することになります。しかし、ビジネスロジックはデータのコミットが成功することを望んでいます。そこで、データが正常にコミットされると同時に、トランザクションの一貫性セマンティクスが維持されることを保証するために、同時実行競合解決メカニズムを提供しています。

2番目の部分も同様です。データウェアハウステーブルとレイクウェアハウステーブルに対して、c1とc2というアドホック同時更新を実行しました。c1はc2の後にコミットされましたが、c1はc2より前に開始されました。これらが競合した場合、c1はc2を上書きするのでしょうか、それともc2がc1を上書きするのでしょうか？現在、データレイクソリューションでは一般的にコミットが遅い方が優先されますが、より実稼働のシナリオでは、コミットの開始順序を優先する必要があります。時間の制約があるため、この部分については詳しく説明しません。ご質問がありましたら、ユーザーグループでお気軽に議論してください。

北極の自動バケット

Arcticはパフォーマンスにも多大な努力を払ってきました。現在、非常に柔軟でオープンなテーブル形式であるIcebergを使用しています。しかし、この形式は私のデータとパーティション内の関連する更新を考慮していません。パフォーマンスを向上させるために、どのようにマッピングを改善できるでしょうか？

Iceberg 上に、Hudi のファイルグループの概念に似た自動バケット化を実装しました。ただし、ファイルグループやファイルインデックスはユーザーに公開していません。代わりに、ファイル上にグループ化機能を提供しました。これは、バイナリツリー拡張手法を用いて各ノードのデータサイズをユーザーが設定したサイズに可能な限り近づけるスケーラブルなアプローチです。例えば、Iceberg のデフォルト設定は 128 MB ですが、バックエンドの最適化メカニズムを通じて、各ノードのサイズを可能な限り 128 MB に近づけるよう努めています。

ノードのデータがこの範囲を超える場合、分割を試みます。前述の通り、変更ストアとベースストアに分割し、同じ方法で管理しています。これにより、各ノードを変更データとベースデータにマッピングできるようになり、よりきめ細かなデータマッピングが可能になり、データ分析のパフォーマンスが大幅に向上します。

ご覧のとおり、このメカニズム全体は「merge-on-read」プロセスにも使用できます。2000年頃、バークレー大学はこのアプローチを具体的に説明した論文を発表しました。興味のある学生は自分で調べてみてください。

北極圏の性能試験

現在、ストリーミングレイク・ウェアハウスのパフォーマンス、あるいはデータレイク上にリアルタイム・ストリーミング・データウェアハウスを実装する実践全体を定義できる優れたベンチマークツールは存在しません。私たちもこの問題について多くの検討と調査を重ねてきました。現在のソリューションは、HTAPベンチマークのアプローチと一致しています。TiDBの導入に基づき、長年業界で利用されてきたCHbenchmarkのコンセプトを採用しました。

CHbenchmarkは、TPC-CとTPC-Hの両方でデータベースを実行できます。下の画像の左側からわかるように、TPC-CとTPC-Hの両方で実行される重複テーブルが6つ、TPC-Cで参照されるテーブルが3つ、TPC-Hでのみ参照されるテーブルが3つあります。

このソリューションをベースに、変更を加えました。まず、TPC-Cを使用してデータベースを実行しました。次に、Flink CDCタスクを実行して、データベースをArcticデータレイクにリアルタイムでストリーミングおよび同期しました。さらに、Arcticデータレイクを使用して、分単位のデータ鮮度を備えたストリーミングレイクウェアハウスを構築しました。さらに、CHbenchmarkのTPC-H部分を実行し、ストリーミングレイクウェアハウスでのデータ分析におけるより標準的なパフォーマンスを実現しました。

Arctic、Iceberg、Hudi（Trinoでテスト）の最適化前後のパフォーマンスを、0～30分、30～60分、60～90分、90～120分の4つのグループに分けて簡易比較しました。下のグラフの青い部分は、最適化なしのデータ分析のパフォーマンスを表しています。0～30分から最後の90～120分にかけて、レイテンシは20秒から40秒以上に短縮され、半分以上削減されました。黄色の部分は、連続マージを行ったArcticを表し、約20秒の安定したパフォーマンスを維持しています。

灰色の領域はネイティブのIceberg upsertソリューションを示しています。0～30分までは30秒ほどかかりますが、30～60分になるとパフォーマンスが急激に低下します。なぜIcebergではこれほどパフォーマンスが低下するのでしょうか？ネイティブのIcebergソリューションでは、挿入データと削除データ間のきめ細かなマッピングが欠如しているためです。そのため、ストリーミングファイルに継続的に書き込むと、各挿入ファイルは削除ファイルとの関連付けを多数生成し、Trinoのmerge-on-readパフォーマンスが急激に低下します。その後、60～90分と90～120分のテストではOutOfMemoryError（OOM）が発生し、プログラムの実行に失敗しました。

黄色の部分はHudiを表しています。現在、ArcticはHudiと同様に、バックエンドの最適化により比較的安定したデータ分析性能を維持しています。しかし、トップレベルの最適化はHudiよりもわずかに優れているようです。テストプロセス全体と関連設定については、後日公式ウェブサイトで公開する予定です。

現時点では、Arctic のパフォーマンスは Hudi に対して一定の優位性があるように見えます。Arctic のパフォーマンスについてはここでは強調しませんが、Hudi についても調査しました。Hudi には RO（読み取り専用）モードと RT（読み取り専用）モードの 2 つのモードがあります。前者は読み取り専用のマージモードであり、後者は読み取り時にマージするモードです。RO モードと RT モードのパフォーマンス差は大きく、将来の最適化の余地が大きいことを示唆しています。

北極圏のロードマップと概要

最後に、Arcticのロードマップとシステム全体について簡単に説明します。Arcticはストリーミングレイクハウスサービスであり、ストリーミング、レイクハウス、サービスに対応するコア機能を提供します。

ストリーミングレベルでは、主キーの効率的なストリーミング更新、データの自己バケット化と構造の柔軟性機能、Spark と Trino の読み取り時マージ機能、分単位の鮮度によるデータ分析を提供します。

Lakehouseレベルではフォーマットの互換性を確保しており、IcebergおよびHiveのテーブルフォーマット構文との100%の互換性を実現しています。Arcticでは利用できないがIcebergでは利用できる機能がある場合、ユーザーはIcebergカタログに切り替えるだけで、ArcticテーブルをIcebergテーブルとして利用できます。さらに、ベーステーブルと変更テーブルの両方にアクセスメソッドを提供しています。

このエンジンは、SparkとFlinkによるデータの読み書き、およびTrinoとImpalaによるデータクエリをサポートしています。現在、Impalaは主にHiveの互換性機能を使用しており、ArcticテーブルをHiveとしてクエリできるため、Impalaをサポートしています。

サービス部門では主に管理機能を重視しています。

1つ目は、データレイクとメッセージキューを統合テーブルにカプセル化し、ストリーミングテーブルとバッチテーブルの統合を実現することです。これにより、Arcticテーブルを使用するユーザーは、レイテンシを数秒または数ミリ秒から数分に短縮する必要がなくなり、データレイクのミリ秒または秒レベルのデータレイテンシ機能を継続して利用できます。

2 番目のポイントは、フローレイクウェアハウス、ダッシュボード、および関連する管理ツールの標準化されたメトリックを提供します。

3 番目のポイントは、同時書き込みの競合を解決し、トランザクションの一貫性セマンティクスを実現することです。

経営レベルでは、以下の質問に答えることに重点を置いていますが、この作業にはまだ長い道のりが残っています。

最初の疑問は、テーブルのリアルタイムパフォーマンスをどのように定量化するかということです。例えば、ストリーミングレイクウェアハウステーブルを構築した後、現在の鮮度レベル（1分、2分、あるいはそれ以上）をどのように判断し、それがユーザーの期待を満たしているかどうかをどのように判断するのでしょうか？

2 番目の質問は、適時性、コスト、パフォーマンスのバランスが取れたトレードオフソリューションをユーザーにどのように提供するかということです。

3 番目の質問は、クエリのパフォーマンス最適化の余地はどれくらいあるか、そしてそれを行うにはどれくらいのリソースが必要かということです。

4つ目に、データ最適化のためのリソースをどのように定量化し、その活用を最大化すべきかという問題があります。Arcticを深く理解していれば、私たちの最適化が他のHudiの最適化とは大きく異なることに気付くでしょう。まず、私たちの最適化は個々の書き込みタスク内ではなく、プラットフォームレベルでスケジュールされます。これにより、これらのデータ最適化リソースを一元管理し、最速のイテレーションが可能になります。例えば、特定の最適化によってマージ効率が大幅に向上することがわかった場合、非常に迅速にイテレーションを実行できます。

最後のポイントは、リソースを柔軟に割り当て、優先度の高いリソースをスケジュールする方法です。

今後のコア機能開発では、外部キーと値のペアに依存しないFlinkのルックアップ結合機能を実装することに重点的に取り組んでいます。以前検討したアーキテクチャでは、リアルタイムシナリオでディメンションテーブルの結合を実行するには、同期のために外部キーと値のペアが必要になる場合がありました。現在のソリューションでは、この外部同期が不要になり、Arcticテーブルに基づいてディメンションテーブルの結合を直接実行できます。

2つ目はストリーミング・アップサートです。現在、ストリーミング・アップサートには主にCDCを使用しています。機能や大規模なテーブルなど、多くのシナリオでは、一部の列のみを更新する必要がある場合もあります。

今後のサポートには、Kubernetesなどのオプティマイザーコンテナや、「merge into」などのSQL構文が含まれます。現在、Arcticレベルではこの構文はサポートされていませんが、ユーザーはArcticテーブルをIcebergテーブルのように扱うことで、「merge into」をサポートできます。将来的にArcticレベルで「merge into」がサポートされた場合、変更されたデータがまず変更領域に入るため、Icebergとは異なります。

最後に、当社のエコシステムはデータレイクテーブル形式に基づいて構築されているため、将来的にはアーキテクチャを分離して、Delta や Hudi などのより多くのテーブル形式に拡張する予定です。

最後に、オープンソースへの当初の動機についてお話しします。これまで、私たちはオープンソースに対してあまり統一されたアプローチをとっていませんでした。昨年、私たちのリーダーシップは、オープンソースをより重点的に推進することを決定しました。Arcticプロジェクトを例に挙げると、私たちは商業的な側面を一切隠すことはありません。さらに、組織構造の面でも、私たちのチームのオープンソース推進は非常に独立したプロセスです。商業化が必要な場合は、他のチームが担当します。

私たちは、開発者、ユーザー、そしてメンバーがデータレイク技術を交換できる、オープンで自由なコミュニティの構築に取り組んでいます。現在、主に中国のユーザーを対象としており、公式ウェブサイトも主に中国語で提供されています。より多くの開発者がこのプロジェクトに参加してくれることを願っています。

本日のシェアは以上です。皆様ありがとうございました！

質疑応答

ホスト: Flink Tablestore の機能に注目しましたか? また、Arctic との違いは何ですか?

Ma Jin:そうです。まず、皆さんがやっていることは非常に似ています。昨年、Flinkコミュニティで同様の提案がありました。Flinkも間違いなく同じようなことをするだろうと理解しています。彼らはまた、DeltaがSparkで行ったように、独自の完全なエコシステムを構築したいと考えています。

似ている部分もありますが、目指すところは全く異なります。Flinkのアプローチはストリーミングのシナリオに忠実ですが、Sparkや他のエンジンとの統合方法や、より高レベルでの管理機能の提供方法については、私たちのように考慮されていません。そのため、機能面での重複はさておき、それぞれの当初の意図や最終的に解決したい問題は異なるだろうと理解しています。

主持人：虽然在表现形式上是相似的，但是Flink tablestore的这种方式更贴近原生Flink的场景，但是我们除了兼容Flink的场景之外还会有更多偏向于Spark的场景做兼容和支持。

马进：不光是Spark，我们还提供了Hive兼容。如果是Hive用户，怎么能让一些Hive表比较顺滑地升级到我们湖仓一体新的架构上，这是我们系统去考量的一些东西，在这个过程中怎样提供一些便利的管理功能，提供度量指标，这些可能和Flink Tablestore考虑的点是不一样的。

主持人： Arctic底层刚才讲到是基于Iceberg实现的，在代码上有强绑定的关系吗？以后会不会考虑基于其他的Table format做这种转换？

马进：我们也经历过一些变化。现在我们自己定的标准首先不会侵入到format内部的实现，也不会魔改开源的代码。但早期我们并没有这样明确的目标，会有一些在Iceberg上的更改。现在我们代码和Iceberg相对来说是可以做一个比较干净的解耦，但是目前我们没有做这个事，比如说Schema这些定义用的还是Iceberg包里的东西，但是这个东西要解耦是很容易的。这里面有个设计上的初衷，产品要去考虑怎么把数据湖用起来，会有一些考虑，比如Iceberg和Delta谁更可能成为未来的主流？我们希望用户能免除这样的烦恼，未来我们希望能在上层给用户提供一个统一的他需要的Lakehouse方案，下层我们再做这样的选型。

主持人：说白了我们不帮用户做出最终的决定，而是提供更多的可能性，无论未来是Iceberg还是Delta，我们都能用一种比较开放的方式兼容。

马进：这个是长远的，现在我们还会和Iceberg结合得紧密一些。