企業が BI およびビジネス分析サービスをサポートするために独立したデータ ウェアハウス システムを構築する必要がある場合、「データ レイク + データ ウェアハウス」のハイブリッド アーキテクチャがあります。しかし、ハイブリッド アーキテクチャでは、建設コスト、管理コスト、ビジネス開発コストが高くなります。ビッグデータ テクノロジーの発展に伴い、分散トランザクション、メタデータ管理、極端な SQL パフォーマンス、SQL およびデータ API インターフェイス機能をデータ レイク レイヤーに追加することにより、企業は統合アーキテクチャに基づいてデータ レイクとデータ ウェアハウス ビジネスの両方をサポートできます。湖の倉庫統合アーキテクチャ。
— レイクとウェアハウスの統合アーキテクチャの紹介 —
従来のエンタープライズ データ レイクは、ほとんどが Hadoop またはクラウド ストレージに基づいて構築されており、データ サイエンスおよび機械学習タスクに半構造化および非構造化データ機能を提供します。エンタープライズ BI やビジネス分析では、データ処理プロセスでの厳密な整合性保証と分析プロセスでの優れた SQL パフォーマンスが必要ですが、オープン ソースの Hadoop やクラウド ストレージにはこれらの機能がないため、企業は独立したデータ ウェアハウス システムを構築してこのタイプをサポートする必要があります。ビジネスの「データレイク＋データウェアハウス」のハイブリッドアーキテクチャがあります。ハイブリッド アーキテクチャは、建設コスト、管理コスト、ビジネス開発コストが高くなります。ビッグ データ テクノロジーの発展に伴い、分散トランザクション、メタデータ管理、極端な SQL パフォーマンス、SQL およびデータ API インターフェイス機能をデータ レイク レイヤーに追加することで、企業は統合アーキテクチャに基づいてデータ レイクとデータ ウェアハウス ビジネスの両方をサポートできます。業界やオープンソースコミュニティで関連技術の探索が相次いでおり、Transwarpは2014年にHadoopをベースに関連技術の開発を開始し、2016年にはリレーショナル分析エンジンInceptorに分散トランザクションなどの機能を提供しました。2017 年に Uber のエンジニアが Apache Hudi プロジェクトの開発を開始し、2019 年に Netflix が Iceberg プロジェクトをオープンソース化し、2020 年に Databricks がクラウド サービスで Delta Lake を立ち上げ、コミュニティの広範な参加と活発なプロモーションが行われました。
CCID Consulting は、2022 年 7 月にリリースされた「統合された湖と倉庫の技術調査レポート」で、統合された湖と倉庫のアーキテクチャの主な主な機能は次のとおりであると指摘しました。
- 構造化データ、半構造化データ (JSON など)、および非構造化データを含む、マルチモデル データの分析と調査をサポートします。
- トランザクション サポートにより、同時データ操作での一貫性と正確性が保証されます。
- BI サポートにより、データ ウェアハウスのモデリングからデータ マートのドッキング ビジネス分析まで、複雑で長いデータ リンクを経由することなく、ソース データに対して BI ツールを直接使用でき、ビジネス対応の適時性が高くなります。
- データの 1 つのコピーが保存され、データ ガバナンスがデータ レイクで直接実行されるため、データ コピーと冗長なフローに起因するコンピューティング能力とストレージ コストが削減されます。
- ストレージとコンピューティングは分離されており、データ ストレージはグローバルに共有され、容量要件に応じてスケーリングされます。コンピューティング パワーはコンピューティング ニーズに応じて柔軟にスケーリングでき、コンピューティングとストレージはそれぞれのニーズに応じて個別に拡張できます。
- ビジネスの開放性、標準化された SQL と API をサポートし、さまざまな機械学習言語とフレームワークを柔軟にサポートできます。
また、「湖と倉庫の統合技術に関する研究報告」では、技術の実現経路に関して、湖と倉庫の統合を実装するには 3 つの方法があると指摘しています。
最初の方法は、Hadoop システムに基づくデータ レイクの容量をデータ ウェアハウスに拡張し、データ レイクに直接データ ウェアハウスを構築し、最終的にレイクとウェアハウスの統合に進化させることです。データ ウェアハウス システムは、比較的低コストのデータ レイクのストレージ上に構築できますが、より優れたトランザクション サポートと SQL パフォーマンスが必要です。Uber などのデジタル化に成功した一部の外国企業は、これらの技術的なルートを利用し、Hadoop 上の Hudi などの新しいストレージ形式を使用して、データ ウェアハウスのビジネス ニーズをサポートしています。国内のTranswarp Technologyは、このタイプの技術の主な推進者であり、Transwarp Technologyは、2015年にHDFSおよびORCファイル形式に基づいて、分散トランザクションのサポートとSQL機能を実現しました.したがって、Transwarp製品は数百の顧客を通過しました.生産の実践と研磨,比較してオープン ソース テクノロジ フレームワークであり、比較的成熟度が高く、多くの顧客が統合されたレイクおよびウェアハウス アーキテクチャを実装するのに役立っています。
2 番目の方法は、クラウド プラットフォーム ストレージまたはサード パーティのオブジェクト ストレージに基づいており、その上に Hadoop またはその他の自社開発テクノロジを構築して、レイク ウェアハウス統合アーキテクチャを構築するもので、一部のクラウド ベンダーはこのルートを推進しています。このルートは、ストレージ層でのクラウド サービスに基づくストレージとコンピューティングの分離を実現しますが、分散トランザクションやメタデータ管理などの機能は、自社開発の技術フレームワークまたはオープン ソースの Iceberg の統合に依存しています。
3 番目の方法は、データベース テクノロジに基づいて詳細な研究開発を行い、さらに複数のデータ モデルとストレージ コンピューティング分離テクノロジをサポートして、Snowflake と Databricks に代表されるデータ レイクのニーズをサポートすることです。以下、Apache Hudi、Iceberg、Delta Lake、Starlink Inceptor の実装原理と相違点を 2 つの記事で説明します。
— アパッチ・ハディ —
Hudi は、Hadoop Upserts Deletes and Incrementals の略で、その名前が示すように、Hadoop 上で更新、削除、および増分データ処理機能を提供することです。Hudi は、Uber のエンジニアが内部データ分析のニーズを満たすために設計したデータ レイク プロジェクトです. ビジネス シナリオは、オンラインで生成された旅行注文データを統合データ センターに同期し、上位の都市オペレーターに提供することです.分析および処理用。2014 年の Uber のデータ レイク アーキテクチャは比較的シンプルで、ビジネス ログは Kafka 経由で S3 に同期され、上位層はデータ分析に EMR を使用し、オンライン リレーショナル データベースと NoSQL は ETL タスクを介してクローズド ソースの Vertica に同期されていました。分析データベースの場合、都市部の学生は主に Vertica SQL を介してデータ集約を実装しますが、システム拡張のコストが高いため、ビジネス開発が制限されます。Uber チームはその後、スケーラビリティの問題などの問題を解決するために、オープンソースの Hadoop エコシステムに移行しました.しかし、ネイティブの Hadoop は、同時実行性の高い分散トランザクションとデータの変更および削除機能を提供しません.したがって、Uber の ETL タスクは定期的に増分を更新します更新されたデータが分析テーブルに同期され、既存の古いデータ ファイルがすべて書き換えられるため、データの遅延とリソースの消費が大きくなります。また、データ レイクの下流では、多数のストリーミング ジョブが新しく書き込まれたデータを段階的に消費します。データ レイクのストリーミング消費も、それらに必要な機能です。したがって、彼らは、Hudi プロジェクトが一般的なデータ レイクのニーズを解決するだけでなく、高速な更新/削除とストリーミングの増分消費を実現できることを望んでいます。このように、Uber のデータ リンクは下の図に示す形式に単純化できます。ここで、DeltaStreamer は独立したデータ インジェスト サービスであり、アップストリームからのデータの読み取りと Hudi への書き込みを担当します。
高速な更新と削除はコア要件であるため、Hudi プロジェクトはこの要件のために多くのシステム設計を行ってきました。データ ファイル内のデータを変更する必要がある場合、最も原始的な方法は、初期データ ファイルのデータをメモリに読み込み、それをメモリ内の変更対象のデータとマージしてから、そのデータをメモリに書き込むことです。データファイル。これにより、すべてのデータの読み取りと書き込みが再度行われ、ファイルが大きい場合、このパフォーマンスは非常に遅くなります。MVCC メカニズムは、この問題を解決できます. 各増分更新のデータは、初期データ ファイルを変更する代わりに、個別にデルタ ファイルに書き込まれます. データを読み取るとき、初期データとデルタ ファイル内のデータの両方がメモリに読み込まれます. 、そしてデータのバージョンと新旧の条件に従ってマージします。Hudi は MVCC の設計をさらに改良し、さまざまなシナリオのために、Copy on Write と Merge on Read の 2 つのデータ テーブル形式を設計します. Copy on Write 形式のテーブルは、各トランザクション操作の後に、新しいデータの全量のバージョンを生成します。これにより、データ テーブルの後続の読み取りは高速になりますが、トランザクション操作は遅くなります。コード テーブルなど、頻繁には変更されないが頻繁に読み取られる小規模および中規模のデータ テーブルに適しています。Merge on Read のデータ テーブル形式は、変更操作中に独立したデータ テーブルに書き込まれます. デルタ/削除ファイルでは、ベース ファイルとデルタ ファイルが一緒にメモリに読み込まれ、読み取り時にレコードに従ってマージされます. この方法は、高速な変更速度と読み取り速度が比較的遅く、大量のデータや頻繁に変更されるテーブルに適しています。開発者は、ビジネス ニーズに応じて各テーブルに適切なスキーマを選択できます。ほとんどのストレージ エンジンの実装では、デフォルトで Merge on Read 形式が採用されていることに注意してください。
カラムナ ストレージはデータ分析のパフォーマンスが比較的優れていますが、特定のレコード行を正確に特定できないため、クエリのパフォーマンスは一般的に低くなります。Hudi は、クエリのパフォーマンスを向上させるために主キーに似た HoodieKey を設計し、HoodieKey に BloomFilter などの機能を提供することで、ポイント チェックや正確なデータ削除など、修正が必要なデータ領域をより迅速に見つけることができるようになりました。トランザクション操作のパフォーマンスを向上させます。
さらに、インクリメンタル ストリーミング データの読み取りをサポートするために、Hudi は上位の分析エンジンに対して 3 つの異なる読み取りパースペクティブをサポートしています。インクリメンタル ファイルのみを読み取る (インクリメンタル ビュー)、初期データのみを読み取る (読み取り最適化ビュー)。全データ（リアルタイムビュー）、リアルタイムデータ分析の場合は増分ファイルのみ読み込み、機械学習など高いデータ精度を必要としない業務の場合は初期データ読み込み方式が利用可能. 高速化するため、およびデータの一貫性が必要なデータ ウェアハウス タスクの場合は、データをマージして全量を読み取る方法を使用する必要があります。
機械学習ビジネスにより良いサービスを提供するための Delta Lake とは異なり、Apache Hudi は主に構造化データの ETL と統計分析、およびより優れたリアルタイム コンピューティング効果を目的としています。これらはすべて SQL ビジネスを中心に展開しているため、その設計は機械学習プログラミング言語とフレームワークのニーズをあまり考慮していません。
— アパッチ・アイスバーグ —
Netflix のデータ レイクは、最初に Apache Hive を使用して構築されました. 基盤となるデータ ストレージは HDFS に基づいており、Hive はデータ テーブル スキーマの保証と限定的な ACID 機能のサポートを提供します. Hive は独立したメタストアに基づくデータ テーブル メタデータ クエリを提供する必要があるため、データ パーティションが特に大きい場合、メタストアのパフォーマンスが不十分であり、多くのパーティションを持つ一部のデータ テーブルでのクエリ分析のパフォーマンスがビジネスを満たせないという事実につながります。チームが直面している最大の問題。さらに、Hive の ACID 実装は完全ではありません. HDFS およびメタストアへのトランザクション書き込みの原子性が不十分です. いくつかの障害ケースでは、データに特定の矛盾が生じ、追加のデータ検証作業が導入されます. さらに、Netflix は、ストレージとコンピューティングの分離を実現するために、オブジェクト ストレージに拡張することを望んでいます。上記の理由に基づいて、Netflix はデータレイクの構築におけるさまざまな問題を解決するために Iceberg プロジェクトを構築しました。Iceberg はデータ レイク システム用に設計されたデータ テーブル ストレージ フォーマットであり、独立したプロセスやサービスではありません. これは、コンピューティング エンジンが Iceberg ライブラリをロードする必要がある Delta Lake や Hudi との最大の違いです.
Iceberg は、Netflix の多くのパーティションによって引き起こされるさまざまな問題を解決したいと考えているため、データ テーブルのメタデータ管理とパーティション関連の機能の設計に焦点を当てています。メタ サービスに依存する他のさまざまなエンジンとは異なり、Iceberg は上の図に示すように、メタデータをファイルに直接保存します。テーブルのすべての状態はメタデータ ファイルに保存され、テーブルに新しい変更を加えると、テーブル スキーマ、パーティション、スナップショット、およびその他のテーブル属性情報を格納する新しいメタデータ ファイルが生成されます。この設計では、Iceberg は他のエンジンを解決するために独立したメタ サービスに依存する必要があり、メタ サービスがパフォーマンスのボトルネックになる可能性があります。
Iceberg テーブルの物理的なデータ ストレージは、データ ファイルの形式で保存されます。これは、「ディレクトリ ファイル」の 2 層構造を採用する他のシステム (Hive、Hudi など) とは異なります。パーティションプルーナーを最適化する場合、ファイルシステムのリモート API を複数回呼び出して各ディレクトリの状態を判断し、実行計画に従ってパーティションとプルーニングを決定する必要があります。ファイルシステムの API 呼び出しはメモリ計算よりも遅いため、特にパーティション数が比較的大きい場合は時間がかかることが多いアイスバーグ氏の方法では、複数のマニフェスト ファイルを使用してデータ ファイルを直接管理するため、計算エンジンはマニフェスト ファイルをコンテンツに直接読み込むことができるため、最適化プロセス中にメモリ内の計算のみが必要になります. パーティションプルーナーは、複数のファイルシステムアクセスを必要としないため、アクセス速度が向上します. これは、マニフェスト ファイルによって記録され、対応するデータ ファイルを指します。マニフェスト ファイルは、パーティション情報といくつかのメトリック データを含む各データ ファイルの情報行を記録し、その後のパーティション最適化のためのデータ サポートを提供します。
このアーキテクチャ設計に基づいて、データ テーブルでトランザクション操作が実行されるたびに、新しいメタデータ ファイルが生成されます. 各コミットの後、Iceberg カタログは、アトミック操作を通じてメタデータ ポインタを新しいメタデータ ファイルにポイントします. したがって、トランザクション分離レベルでは、Iceberg は Serializable 分離レベルのみを提供でき、他のより高い分離レベルを提供することはできません。すべてのトランザクション操作は完全なテーブル レベルで行われますが、他のほとんどのストレージ エンジンはパーティション レベルで実行できます。この設計により、Iceberg は実際の運用業務での同時操作でロックの競合に遭遇する可能性が高くなります.たとえば、データ ウェアハウスの中間層にある幅の広いテーブルでは、複数のデータ ストリームが同時に処理されるため、ロックの競合が発生しやすくなります. Iceberg はオプティミスティック同時実行制御 (オプティミスティック コンカレンシー) 戦略を採用しており、競合が発生した後、現在のセッションの SQL トランザクション操作は、新しいトランザクション データに基づいて再試行されます。この方法の利点は、トランザクション プロトコルの実装が比較的簡素化されることですが、欠点は、同じテーブルで実行される同時トランザクション操作が増えるほど、トランザクションの中止率が急速に上昇し、SQL コンピューティング リソースが浪費されることです。したがって、トランザクションのサポートに関しては、アイスバーグは他のプロジェクトよりも弱いです。
MVCC の実装において、Iceberg は Merge on Read の実装も採用しました。トランザクション内のすべての変更操作は、個別に削除ファイルに保存されます. 設計に関しては、Iceberg はデータベースのバイナリ ログのアイデアを完全に利用しています. 削除ファイルに動作を記録するには 2 つの方法があります. 1 つは位置の削除です, どちらのどのデータファイルを詳細に記録します. 行を削除します, これは主に少量のデータを正確に削除するために使用されます. 別の方法として等価削除があります.式は、これらのデータ行を選択して削除を実行するために使用され、主にいくつかのバッチ削除操作に使用されます。データ ファイル内のデータを直接変更する必要がなく、ランダム アクセス ファイルも必要ないため、Iceberg は基盤となるファイル システムの要件が比較的低く、ファイル システム レベルのトランザクション、ランダム アクセス、および POSIX を必要としません。最も単純な S3 オブジェクト ストレージもサポートされるため、Netflix はオブジェクト ストレージに基づいてデータ レイクを構築できます。
要約すると、Iceberg は、Netflix が遭遇するいくつかの問題を解決するために、非常に異なるアーキテクチャ設計を採用しています。 ; ACID 機能はデータ操作で提供できますが、トランザクションの同時実行パフォーマンスは弱く、データ レイクの構築はオブジェクト ストレージに基づくことができます。また、Iceberg 自体はストレージ エンジンではないため、主キーなどの機能を提供できず、Spark や Presto などのコンピューティング エンジンと組み合わせて使用する必要があります。したがって、Iceberg が適している企業グループの特性も非常に特徴的であり、典型的なオンライン インターネット企業のマーケティングおよびリスク管理シナリオでは、大量のリアルタイム データまたはログ データがあり、これらはすべて洗練されたデータです。時間軸に沿った分析. 最近のデータの価値は高いが、中長期データの価値は大きくない. データパーティションの数は特に多く、コンピューティングエンジンを開発および最適化する能力を持っています. 設計上のトランザクション機能が比較的弱いため、高度な同時データ バッチ処理やデータ ウェアハウス モデリングには適していません。さらに、メタデータ ファイルが破損するとデータが失われる可能性があるため、データのセキュリティ管理には特に注意を払う必要があります。
- まとめ -
この記事では、Apache Hudi と Apache Iceberg の 2 つの統合レイクおよびウェアハウス アーキテクチャを紹介し、次回の記事では、Transwarp Inceptor と Delta Lake の 2 つのテクノロジを紹介します。