企業が BI および分析サービスをサポートするために独立したデータ ウェアハウス システムを構築する必要がある場合、「データ レイク + データ ウェアハウス」のハイブリッド アーキテクチャがあります。しかし、ハイブリッド アーキテクチャでは、建設コスト、管理コスト、ビジネス開発コストが高くなります。ビッグデータ テクノロジーの発展に伴い、分散トランザクション、メタデータ管理、極端な SQL パフォーマンス、SQL およびデータ API インターフェイス機能をデータ レイク レイヤーに追加することにより、企業は統合アーキテクチャに基づいてデータ レイクとデータ ウェアハウス ビジネスの両方をサポートできます。湖の倉庫統合アーキテクチャ。この記事では引き続き、Transwarp Inceptor と Apache Delta Lake を紹介します。
— Transwarp Inceptor — Transwarp Inceptor は、2013 年に開発された分散リレーショナル分析エンジンで、主に ODS、データ レイク、およびその他の構造化データの分析ビジネス シナリオで使用されます。Inceptor は、ANSI 92、99、および 2003 SQL 標準のほとんどをサポートし、Oracle、IBM DB2、Teradata などの従来のリレーショナル データベースの方言と互換性があり、ストアド プロシージャをサポートします。2014 年以降、一部の国内銀行の顧客は、DB2 では本来パフォーマンスが不十分だった一部のデータ処理サービスを Inceptor に移行しようとし始めており、これらのリレーショナル データベース上に構築されたデータ タスクには多数の同時更新および削除要件があり、結果テーブルを処理する複数のデータ リンクがあるため、同時トランザクション パフォーマンスに対する強い要件があります。また、リレーショナル データベースから Hadoop プラットフォームへのデータ一括処理ビジネスの完全な移行をユーザーが期待するだけでなく、パフォーマンスが桁違いに向上することも期待されているため、Transwarp Technology は 2014 年に HDFS に基づく分散トランザクション メカニズムの開発を開始しました。データ ウェアハウスのビジネス シナリオでは、関連するテクノロジが 2016 年に Inceptor 4.3 バージョンで正式にリリースされ、その後数年間で数百の金融業界のユーザーで運用され、技術的な成熟度は金融業界に達しました。レベル要件。
Inceptor の全体的なアーキテクチャは上に示されています.ORC は列型ストレージであり、統計分析のパフォーマンスが非常に優れているため、ORC ファイル形式に基づいて分散システムを再開発することにしました。HDFS はファイルへのランダム アクセスとファイル内のトランザクション操作をサポートしていないため、MVCC メカニズムを使用して、データの同時更新と削除を行います. データが更新されるたびに、データ ファイルは直接書き換えられませんが、データに対応する新しいバージョンがファイルに追加され、トランザクション内のすべてのデータ操作がデルタ ファイルに書き込まれます。データを読み取るときは、すべてのファイル データをメモリに読み取り、トランザクションの順序と可視性に従って、メモリ内の複数のファイルにある同じデータをマージします。これが、Merge on Read メカニズムです。データ ウェアハウスはすべてデータ バッチ処理に関するものであり、バッチ データ ビジネスの各 SQL は大量のデータを操作する可能性があり、1 つの SQL 操作に必要な遅延は数十秒またはそれ以上になる可能性があることを強調する必要があります。分散トランザクションのパフォーマンス要件は、トランザクション ビジネスの分散データベースに必要な数万またはそれ以上の TPS ではなく、数十から数百の TPS です。ロックの競合は、バッチ処理における同時実行パフォーマンスの主要なボトルネックです。複数の ETL タスクがデータ テーブルを同時に処理している場合、このテーブルでロックの競合が発生する可能性があり、その結果、データ タスク間でロック待機が発生し、最終的な処理リズムが遅くなります。パフォーマンスの問題を解決するために、分散トランザクションの生成と可視性の判断を管理する独立したロック マネージャーを開発しました.同時に、ロックの粒度にはデータベース、テーブル、パーティションの 3 つの粒度が含まれ、不要なロックの多くを削減します。コンフリクトの質問。
さらに、データ ウェアハウスの処理プロセスでは、多くのテーブルが前の処理タスクの結果テーブルであるだけでなく、他のデータ タスクのデータ ソースでもあるため、読み取りと書き込みの競合も発生し、同時実行が発生します。場合によっては制限。この問題を解決するために、Serializable Snapshot のスナップショット メカニズムと分離レベルを導入します. データ テーブルの読み取り操作はスナップショットを直接読み取ることができるため、書き込み操作とのトランザクションの競合を生成する必要はありません. In our design, Snapshots do not need to be persisted, and do don't need to add a large amount of physical storage. 代わりに、スナップショットは軽量でグローバルに一貫した論理概念であり、特定のバージョンのデータを含める必要があるかどうかをすばやく判断できます。トランザクション処理中に除外されます。
トランザクションの分離に関して、Inceptor は 5 つの分離レベルをサポートしています。コミットされていない読み取り、コミットされた読み取り、反復可能な読み取り、シリアライズ可能、およびシリアライズ可能なスナップショットです。同時実行制御テクノロジに関して、Inceptor は悲観的および楽観的の 2 種類のシリアライズ可能な分離レベルを提供します。厳密な 2 フェーズ ロック ベースのシリアライゼーション分離レベルとスナップショット ベースのシリアライゼーション分離レベルです。ユーザーは、ビジネス シナリオに応じて適切な分離レベル タイプを選択できます。Strict two-stage lock serialization isolation (S2PL Based Serializable Isolation) は、悲観的な同時実行制御技術です. その主な機能は、最初にロックを取得し、次に読み取りと書き込みを処理し、トランザクションがコミットされるまですべてのロックを解放しないことです. その実装は比較的便利ですが、主な問題はデッドロックの問題 (リング検出によって解決される) に対処することです。このテクノロジの読み取りと書き込みは同時に実行できないため、トランザクション処理の同時実行パフォーマンスは低くなります。シリアル化可能なスナップショット分離 (Serializable Snapshot Isolation) は、トランザクション処理の同時実行パフォーマンスを向上させることができます. 楽観的ロックに基づくシリアル化可能なスナップショット分離を採用しています. この技術の利点は、2 段階で読み取り操作と書き込み操作の相互ブロックが発生しないことです.ロック技術 この状況により、読み取りと書き込みが非ブロックになり、並行性が向上します。スナップショット分離では、ダーティ リード、繰り返し不可能な読み取り、ファントム リードは発生しませんが、シリアライゼーションを保証することはできません. 同時トランザクションを処理する場合、書き込み部分順序問題 (ライト スキュー) と呼ばれる制約 (制約) により例外が発生する場合があります。 . 書き込みの半順序の問題を解決するために、Inceptor はシリアル化可能なスナップショットの競合の検査を導入し、スナップショット分離レベルの下でトランザクション間の読み取り/書き込み依存関係のループの検出を追加して、関連する競合の問題を見つけ、異常なトランザクションを中止します。
前述のように、Inceptor は、分散トランザクションの同時実行性、トランザクションの分離、および SQL パフォーマンスの点で比較的完全な技術蓄積を有しており、2016 年以降、金融業界で広く採用されています。 . Inceptor は機械学習シナリオ用に設計されていないため、機械学習フレームワークによって直接使用されるデータ API レイヤーは提供されません。さらに、Inceptor はリアルタイム データ書き込み用の個別のアーキテクチャを設計しておらず、ストリーム バッチ統合アーキテクチャを効果的にサポートすることもできませんが、Transwarp Technology は、分散データベース ArgoDB におけるストリーム バッチ統合要求の問題を解決しました。
— アパッチデルタ湖 —
Databricks Cloud で多数のユーザーが機械学習タスクを実行しているため、Databricks の主な設計目標は次のとおりです。
- 優れたSQL性能
データ分析の性能は、BIや分析ソフトウェアのコア要件であるため、列形式のファイル形式（Parquetなど）やその他の統計分析に適した形式、およびベクトル計算エンジンを採用する必要があります。データ レイクでの SQL 統計分析のパフォーマンスを向上させ、データ ウェアハウスの技術要件を満たすための、データ アクセス キャッシュ、階層型データ ストレージ (コールドおよびホット データ分離ストレージ テクノロジなど) およびその他のテクノロジ - 分散トランザクションとスキーマのサポートを提供する
データ レイクはほとんどがファイルの形式で格納され、スキーマレスであるため、データ分析の柔軟性が提供されますが、データベースの ACID 管理機能を実現することはできません。Delta Lake はファイル ストレージを改善し、厳密なデータベース スキーマ メカニズムを提供した後、MVCC に基づくマルチバージョン トランザクション メカニズムを開発しました。これにより、データベースの ACID セマンティクスがさらに提供され、高度な同時更新および SQL 操作の削除がサポートされます。さらに、Delta Lake はオープン データ フォーマット (Parquet) に基づいており、HDFS を直接操作できるだけでなく、他のコンピューティング エンジンが関連データにアクセスできるため、生態系の互換性が向上します。
- 機械学習タスクと探索的分析を柔軟にドッキングするためのデータ API
機械学習と AI トレーニング タスクは、Databricks のコア ビジネス シナリオであるため、Delta Lake は、この種のビジネスを設計で確実にサポートすることに大きな注意を払っており、DataFrame API を提供するだけでなく、Python や R などのプログラミング言語インターフェイスもサポートしています。 、および Spark のサポートを強化します MLlib、SparkR、および Pandas などの機械学習フレームワークの統合。
上記の機能に基づいて、Spark のコンピューティング能力と Delta Lake のストレージ容量を組み合わせることで、完全に Databricks のストレージとコンピューティング テクノロジに基づくデータ アーキテクチャを実現でき、BI 統計分析、リアルタイム分析、機械学習をサポートできます。さらに、Delta Lake はオープン データ ストレージ形式に基づいており、インタラクティブな分析のために Presto などの他のコンピューティング エンジンに接続することもできます。プロジェクトの初期の設計目標に関して、Hudi は高同時更新/削除パフォーマンスに焦点を当て、Iceberg は大量のデータの場合のクエリ パフォーマンスに焦点を当て、Delta Lake 設計のコアはリアルタイムをより適切にサポートすることです。コンピューティングとコンピューティング オフライン。Spark Structured Streaming との緊密な統合により、デルタ テーブルはストリーミングのデータ ソースとして使用できるだけでなく、ストリーミングのターゲット テーブルとして直接使用することもでき、Exactly-Once セマンティクスも保証できます。Delta コミュニティは、マルチホップ データ アーキテクチャを組み合わせて、一連のストリーム バッチ統合参照アーキテクチャ デザインを設計しました。これにより、Kappa アーキテクチャと同様のデータ ストレージを実現して、両方のストリーム バッチ シナリオのニーズに対応できます。
Databricks の Delta Lake のオープン ソースは比較的限られているため、一部の機能は Databricks File System と Engine に依存する必要があるため、コミュニティでの注目は Huid と Iceberg ほどではありません。さらに、Delta Lake は設計上主キーを提供しないため、高度な同時更新/削除は Hudi ほど良くなく、Iceberg と同様のメタデータ レベルのクエリ最適化も提供しないため、クエリ パフォーマンスは Iceberg ほど良くない可能性があります。しかし、Delta Lake は Spark の組み合わせを強調しています. 形成されたストリームバッチ統合データ アーキテクチャと、機械学習アプリケーションのネイティブ API レベル サポートは、適用可能なビジネス シナリオにおいて優れた普遍性を備えています.
- まとめ -
時間の観点から見ると、Transwarp Inceptor は、データ レイク上にデータ ウェアハウスを提供する機能を調査した最初の製品であり、2016 年に製品の大規模な生産を完了したため、特に分散トランザクションにおいて、製品の成熟度は比較的高いです。実現の完全性における明らかな利点です。
Hudi は、同時実行性の高い更新/削除のビジネス シナリオに適しているように設計されています. Transwarp Inceptor と同様に、これら 2 つのテクノロジも、更新と削除を提供する Hadoop の機能に基づいています. 比較的言えば、分散トランザクションでの Hudi のパフォーマンス 実装の詳細はまだ必要です.改善するための時間と生産の研磨。
Iceberg プロジェクトの設計は, パーティション数が多いがトランザクション操作が少ない大規模なデータの分析シナリオに適しています. インターネット企業により適しています. さらに, Iceberg はソフトウェア設計において非常に優れた抽象化を行っており, 比較的さまざまなコンピューティング エンジンの完全なサポート、パーティションの最適化などは非常に細心の注意を払っており、トランザクション要件が低いいくつかのシナリオでは依然として非常に魅力的です。
Delta Lake の Databricks のオープン ソースは比較的限定的であり、一部の機能は Databricks File System と Engine に依存して改善する必要があるため、コミュニティでの注目は Hudi や Iceberg ほどではありません。Delta Lake はパフォーマンスの点で優れた設計がなく、分散トランザクションの実装は比較的簡単です. トランザクションの同時実行と分離の実装はまだ初期段階にあります. 現在、プロジェクトはストリームとバッチのデータアーキテクチャを組み合わせることを重視しています.機械学習アプリケーションのネイティブ API レベルのサポート。
各プロジェクトが初期の設計目標を徐々に完了するにつれて, 彼らはすべて適用可能なシナリオをさらに拡大したいと考えています, そして彼らはすべてそれぞれの分野に参入しています. 各プロジェクトの急速な開発はまた、統合された湖の倉庫アーキテクチャの迅速な反復を促進します.