この記事は、Alibaba Cloud のインテリジェント オープンソース テーブル ストレージの責任者であり、Paimon の創設者であり、Flink PMC のメンバーでもある Li Jinsong 氏が、コンピューティング カンファレンスのオープンソース ビッグ データ セッションで共有した内容を編集したものです。この記事の内容は主に次の 4 つの部分に分かれています。
- データ分析アーキテクチャの進化
- Apache Paimon の紹介
- フリンク + パイモン ストリーミング レイク ウェアハウス
- ストリーミングレイクウェアハウスのデモ
データ分析アーキテクチャの進化
現在、データ分析アーキテクチャは Hive から Lakehouse に進化しています。Hive や Hadoop などの従来のデータ ウェアハウスは、レイクおよびレイクハウス アーキテクチャに進化しており、レイクハウス アーキテクチャには、Presto、Spark、OSS、レイク フォーマット (Delta、Hudi、Iceberg) およびその他のアーキテクチャが含まれており、これは現在比較的大きなトレンドです。Lakehouse アーキテクチャには多くの新機能が含まれています。
まず、OSS は従来の HDFS よりも柔軟性が高く、コンピューティングとストレージを分離する機能を備えています。さらに、OSS にはホット ストレージとコールド ストレージを分離する機能もあり、データをコールド ストレージにアーカイブすることができ、そのコールド ストレージは非常に安価であり、ストレージの柔軟性が得られます。
さらに詳しく見てみると、これらのレイク形式にはいくつかの利点があることがわかります。具体的なメリットは何ですか?
まず操作が簡単であるという点ですが、Lake 形式には ACID、Time Travel、Schema Evolution があり、より優れた制御機能を実現できます。
2 番目の可能性は、クエリが高速になることです。たとえば、計画フェーズにかかる時間が短縮されます。大量のデータと多数のファイルがある場合、Hive ではクエリの問題が発生します。したがって、Lake フォーマットはこの点もより適切に解決します。
上記の 2 つのメリットは、必ずしも企業の意思決定者に好印象を与えるとは限りません。実際、すべての企業がアップグレードを行っているわけではない、またはすでにアップグレードしているわけではありません。大きな理由の 1 つは、Hive は古いと誰もが言っていますが、それでも戦うことができるということです。最初の 2 つの利点は、必ずしもすべての企業に厳密に必要というわけではありません。多くの企業が Hive を使用し続けており、基盤となるストレージが OSS (または OSS-HDFS) に置き換えられている可能性がありますが、依然として古い Hive のままです。
たとえば、安定して走行している列車がすでにあります。これをアップグレードし、食堂車を追加し、装飾し、さらに多くのセクションに分割してより柔軟にすることができます。ただし、新しいセットにアップグレードする必要があります。アップグレードのリスクを負いますか? ? しかし、それが高速鉄道にアップグレードできたらどうなるでしょうか?
それでは、左側の3番目のメリットを紹介します。Lakehouse はより適時性を実現できます。
適時性の向上は、必ずしもすべてのビジネスが日単位から分単位までの適時性の向上を必要とすることを意味するわけではありませんが、リアルタイムのアップグレード用にデータの一部を選択したり、リアルタイムの主流データをオフラインのまま使用するために特定の時間を選択したりすることもできます。
適時性の向上は、一部のビジネスに実質的な変化をもたらす可能性があり、アーキテクチャを大幅に簡素化し、データ ウェアハウス全体をより安定させることさえできます。
コンピューティング分野における適時性のリーダーは、Apache Flink です。先ほど、適時性の向上が Lakehouse の次の開発の焦点であると述べましたが、これからやるべきことは、Apache Flink というストリーミング コンピューティングの標準技術を Lakehouse アーキテクチャに導入することです。
そのため、私たちはここ数年、Iceberg と Hudi への投資を含む多くの関連調査を行い、Flink と Iceberg および Hudi の間の接続を磨き上げることに成功しました。ただし研磨効果はそこまで良くないので、Flink+IcebergやFlink+Hudiを使ったことがある方には不満もあるかもしれません。重要な問題は、Iceberg と Hudi がどちらも Spark 指向でオフライン指向のデータ レイク テクノロジであるため、リアルタイムや Flink とはうまく適合しないことです。
そこで私たちは、ストリーミング データ レイク フォーマットである新しいデータ レイク フォーマットである Apache Paimon を開発しました。データレイク四銃士の歴史と本来の目的を分析してみましょう。
Apache Iceberg と Delta Lake は、実際には従来の Hive 形式のアップグレードです。本質的には、依然として追加データの処理を指向しています。オフライン データ ウェアハウスの T+1 分析においては、Hive よりも多くの利点があり、使いやすくなっています。従来のオフライン処理により指向されています。
実際、Apache Hudi は、本来の目的である Hive に基づいて段階的に更新する機能を提供します。そのインフラストラクチャは依然として完全な増分マージを指向しています。Flink の統合は Spark ほど優れていません。一部の機能は Spark でのみ利用でき、Flink では利用できません。
Apache Paimon は、Flink コミュニティから誕生したデータ レイクであり、大規模な更新と真のストリーミング読み取りをサポートするように設計されています。
川と湖を組み合わせる難しさは、実は新しいものです。Flink に精通している場合は、Flink SQL が成功した理由の 1 つは、変更ログを真にネイティブに処理できることです。この変更ログ自体が更新です。
Iceberg、Hudi、Delta はすべて、バッチ処理と Spark のインクリメンタル + フル メソッドに基づいています。マージが必要になると、増分データと完全データを非常に大規模にマージすることになります。合計量は 10 TB にもなります。1 GB の増分でも、すべてのファイルのマージが必要になる場合があります。マージが完了する前に、10 TB のデータをすべて書き換える必要があります。マージのコストは非常に高くなります。
右側は更新されたテクノロジーである LSM (正式名は Log Structured Merge-Tree です。この形式は、RocksDB、Clickhouse、Doris、StarRocks など、リアルタイム分野の多数のさまざまなデータベースで使用されています)。
LSM によってもたらされた変更は、各マージが部分的になる可能性があることです。各マージでは、特定の戦略に従ってデータをマージするだけで済みます。この形式は、コスト、鮮度、クエリ遅延のトライアングルにおいて、より強力なトレードオフを実現でき、トライアングルでは、異なるパラメータに基づくことができます。選択肢を外します。
Apache Paimon の紹介
Flink Lakehouseを構築するためにFlink + lake storageが必要となる進化プロセスと、その難しさを紹介しました。後半では Apache Paimon を紹介します。
Apache Paimon とは何ですか? 基本的なアーキテクチャはレイク ストレージ + LSM の組み合わせであると単純に考えることができ、レイク ストレージの基本的な機能は書き込みと読み取りです。これに基づいて、Apache Paimon は Flink とより深く統合されており、Schema Evolution を通じてさまざまな CDC データを Paimon に同期でき、Flink CDC を通じてデータベース全体を同期できます。
また、Flink、Spark、Hive、ワイド テーブル マージ、またはバッチ書き込みカバレッジを介して Paimon に書き込むこともできます。これは Lakehouse の基本的な機能です。また、後で一括して読み取って、Flink、Spark、StrarRocks、Trino を通じて分析を行うこともできます。Flink を使用してデータを Paimon にストリーミングすることもできます。ストリーム読み取りによって生成される変更ログは後ほど紹介します。機能についても紹介します。ストリーム読み取りの。
これは、Paimon のアーキテクチャ図であり、主に、Paimon のストリーミング統合リアルタイム データ レイクの一般的な開発プロセスを示しています。2022 年の初めに、オープンソース コミュニティに不足しているテクノロジーが発見されたため、Flink コミュニティで Flink Table Store が提案されました。最初の安定バージョン 0.3 がリリースされたのは 2023 年 1 月になってからで、3 月に Apache インキュベータに入りました。今年 9 月にリリースされた Paimon バージョン 0.5 は、CDC Lake エントリと Append データ処理を含む完全に成熟したバージョンの Paimon です。
また、Alibaba Cloud 上の Apache Paimon と Hudi のパフォーマンスをテストし、Lake Storage の MergeOnRead の更新パフォーマンスもテストしました。左側のレイクには約 5 億個のデータが入力されていることがわかります。同じ指標で湖に入ります。5 億匹の魚を湖に入れるのにどれくらい時間がかかるかを見積もってみましょう。テストの結果、湖に入るプロセス中、Paimon のスループットまたは消費時間は Hudi の 4 倍に達する可能性があることが判明しましたが、同じデータをクエリする場合、Paimon のクエリ パフォーマンスは 10 倍、さらには 20 倍であることがわかりました。 Hudi のものです。Hudi もメモリが小さいため問題が発生し、読み取ることができません。
なぜ？Hudi MOR は純粋な追加であると分析しましたが、バックグラウンドでコンパクションが行われていますが、コンパクションをまったく待機しません。したがって、Hudi の Compaction はテストではほんの少ししか機能せず、読み取り時のパフォーマンスが特に悪かったです。
これを踏まえて、右のベンチマーク、1億件のデータのCopyOnWriteも作成し、CopyOnWriteの場合のマージ性能とコンパクション性能をテストしました。テストの結果、2分でも1分でも30秒でもパイモンのパフォーマンスが大きく上回り、12倍ものパフォーマンス差があった。30秒の時点で、フーディは走り出すことができませんでしたが、パイモンはまだ比較的普通に走り出すことができました。
振り返って、この3つのキーワードを通してパイモンに何ができるのかを説明できればと思います。
まず、低遅延、低コストのストリーミング データ レイクです。Hudi を使用していた場合は、Paimon に切り替えた後、1/3 のリソースで実行できることを願っています。
2つ目は、使いやすく、湖に入りやすく、開発効率が高いことです。CDC モードでデータベース データをデータ レイク Paimon に簡単に同期できます。
Flink と強力に統合され、データが流れます。
フリンク + パイモン ストリーミング レイク ウェアハウス
最初の部分では、Paimon を構築したい理由であるデータ アーキテクチャの進化について説明し、2 番目の部分では、Paimon で何ができるか、その統合、利点、パフォーマンスを紹介します。次の 3 番目のパートは、Flink と Paimon がストリーミング レイク ウェアハウスを構築する方法です。
まず、大まかなイメージを見てみましょう。実際、ストリーミング レイク ウェアハウスの本質は依然としてレイク ウェアハウスです。レイク ウェアハウスで何ができるでしょうか。最も基本的なものはバッチ書き込みとバッチ読み取りであり、従来の Hive データ ウェアハウスよりも優れた利点があります。これに基づいて、フルリンクのリアルタイムとストリーミング バッチの統合を実現するには、レイクへの強力なストリーミング データの更新と増分ストリーミング データのストリーミング読み取りを提供する必要があります。
ストリーミング レイク ウェアハウスが解決できる最も一般的なシナリオの 1 つは、Hive 上の CDC データ、つまり、MySQL、従来のデータベース データ、および CDC データからウェアハウスまたはレイクへのリンクです。これは比較的古いアーキテクチャ図ですが、企業でも広く使用されています。
最初の実行時に Hive の完全なパーティション テーブルに同期することも、必要に応じて完全同期を通じてパーティションになることもできます。次に、毎日増分同期を通じて Kafka に同期し、定期的なリフローを通じて増分 CDC データを Hive の増分テーブルに同期する必要があります。毎晩同期が完了した後、増分テーブルと完全テーブルのマージは約 0:10 で実行できます。マージ後に形成された新しいパーティションが、新しい日の MySQL のフル ボリュームになります。
このテクノロジを通じて、出力遅延が非常に長く、少なくとも T+1 を必要とし、増分データと完全データがマージされるまで待機する必要があることがわかります。さらに、増分の全量が断片化されており、ストレージも非常に無駄になります。Hive フル テーブルの各パーティションが全量のデータであることがわかります。100 日分のデータを保存する場合、ストレージは少なくとも 100 倍大きくなります。
3 つ目は、リンクが非常に長く複雑で、さまざまなテクノロジが関与していることです。実際のビジネス シナリオでは、この出力に遭遇することが非常によくあります。どのコンポーネントに問題があり、データを出力できず、その結果、次のような一連のオフラインが発生します。ジョブを実行できません。ここで説明するのは、高遅延、高コスト、高リンクの複雑さの 3 つの高さです。
Flink+Paimon のストリーミング CDC アップデートに目を向けると、アーキテクチャを非常にシンプルにしたいと考えています。Hive のパーティション テーブルは必要ありません。パーティショニングせずに Paimon の主キー テーブルを定義するだけで済みます。その定義は、MySQL テーブルの定義と非常に似ています。
Flink CDC および Flink ジョブを通じて完全な増分 CDC データを Paimon に統合するだけで十分であり、その後、このテーブルのステータスをリアルタイムで確認し、このテーブルをリアルタイムで確認できます。データはリアルタイムで同期されますが、オフライン データ ウェアハウスでは毎日のビューが必要であり、Paimon はタグ テクノロジーを提供する必要があります。今日タグを付けると、その日のステータスが記憶され、このタグを読み取るたびに同じデータになります。このステータスは不変です。したがって、タグ テクノロジは Hive の完全なテーブル パーティショニングを同等に置き換えることができ、Flink と Spark はタイム トラベル構文を通じてタグ データにアクセスできます。
従来の Hive テーブルはパーティション分割されたテーブルであり、Hive SQL にはタイム トラベル セマンティクスがありません。Paimon は、タグを Hive パーティション テーブルにマップする機能も提供し、Hive SQL のパーティション クエリを通じて複数日分のデータをクエリすることもできます。Hive SQL は、行を変更せずに Paimon のコンポーネント テーブルをクエリすることと完全に互換性があります。したがって、このようなアーキテクチャの変換後、分レベルでリアルタイムに表示されるデータ全体を確認できます。すべての完全な増分が統合され、ストレージが再利用されます。シンプルで安定したワンクリック同期により、ストレージとコンピューティングのコストを大幅に削減できます。
ストレージ コスト Paimon のファイル再利用メカニズムを使用すると、10 日間のタグ付けにかかるストレージ コストは 1 ～ 2 日分のストレージ コストにすぎないことがわかります。したがって、パーティションを 100 日間保持することで、最終的なストレージ コストは 50 ドル節約できます。回。
コンピューティング コストの点では、1 日 24 時間実行されるストリーミング ジョブを維持する必要がありますが、Paimon の非同期圧縮を使用して、同期リソースの消費を可能な限り削減できます。Paimon は、データベース全体を同期する同様の機能も提供します。 1 つのジョブを通じて数百のテーブルを同期できます。したがって、リンク全体で、低遅延、低コスト、低リンクの複雑さという 3 つの条件を達成できます。
次に、2 つのストリーミング読み取りが紹介されます。パイモンはリアルタイムでより良いフロー読み取りを行うために設計されていると思うかもしれませんが、実際には意味がありません。Hudi や Iceberg もストリーム読み取りが可能で、Paimon がデータ ストリーム読み取りに関して多くの作業を行っていることを示すために 2 つのメカニズムを使用しています。
消費者の仕組み。この機能がない場合、ストリームを読み取るときによく遭遇する最も厄介な問題は FileNotFoundException です。このメカニズムはどのようなものですか? データ作成プロセス中にスナップショットを継続的に生成する必要があるためです。スナップショットが多すぎると、ファイル数が多くなり、データ ストレージが非常に冗長になるため、スナップショット クリーンアップ メカニズムが必要になります。しかし、他のストリーミング ジョブはこれを知りません。ストリーミングしているスナップショットがスナップショットの有効期限によって削除されると、FileNotFoundException が発生します。さらに深刻なのは、ストリーミング読み取りジョブがフェールオーバーする可能性があることです。ジョブが 2 時間ハングすると、再開後にストリーミング読み取り中のスナップショットが削除され、再度復元できなくなります。
そこでパイモンはここで消費者メカニズムを提案した。Paimon では、ファイル システムの進行状況を記録するためにコンシューマ メカニズムが使用されています。このスナップショットを再度読み取ると、期限切れによってこのスナップショットは削除されません。このストリーム読み取りの安全性が確保され、kafka グループ ID と同様のことも実現できます。ストリーミング読み取り進行状況の保存。ジョブをステートレスに再起動すると、同じ進行状況が復元されます。したがって、コンシューマメカニズムはストリーム読み取りの基本的なメカニズムであると言えます。
2 番目は、変更ログの生成です。このようなパイモン PK テーブルがあり、キーは名前、値はカウントで、上流側は常に書き込み、下流側は常に読み取りを行っているとします。ストリーム書き込みでは、同じデータを同じコンポーネントに書き込む場合があります。たとえば、前に書き込まれたジェイソンは 1、次に書き込まれたジェイソンは 2 です。ストリーム読み取りジョブが正しいストリーム処理を実行する場合、たとえば合計を作成する場合、合計結果は 2 または 3 になるはずであることがわかります。この変更ログが生成されなければ、これが同じ主キーであることはわかりません。まず Jason -> Retract 1 を入力し、再度 Jason -> 2 を書き込む必要があります。したがって、ダウンストリーム ストリームの読み取り計算をより適切かつ正確に行うことができるように、レイク ストレージ自体がバイナリログを生成するデータベースのように動作する必要があります。
変更ログ生成のためのテクノロジーは何ですか? Flink リアルタイム ストリーム コンピューティングでは、宿題を書いたことがあるなら、重複を削除するための State の使用法もたくさん書いたことがあるでしょう。ただし、この方法による状態のコストは比較的高く、データは複数のコピーに保存されるため、一貫性を保証するのが困難です。または、完全マージを使用することもできます。たとえば、Delta、Hudi、および Paimon はすべて、完全マージ中に対応する変更ログを生成できるこのメソッドを提供しています。これは可能ですが、変更ログが生成されるたびに完全マージが必要になり、コストがかかりますとても大きくなります。
3番目に、Paimonのユニークな方法は、LSMであるためchagelog-Producer=lookupを持っていることです。LSM にはポイント チェックの機能があるため、このようなポイント チェック メソッドを構成して、書き込み時にバッチ効率的なポイント チェックを通じて対応する chanelog を生成し、ダウンストリーム ストリーム処理でストリームを正しく処理できるようにすることができます。
上記2部はパイモンの更新とストリーミング読み物です。ストリーミング レイク ウェアハウスは、Flink のストリーミング バッチ統合用に設計されています。以前はストリーム・バッチ統合計算でしたが、ストレージ付きではストリーム・バッチ統合計算＋ストリーム・バッチ統合ストレージになります。
しかし、Alibaba Cloud Serverless Flink を使用している一部の学生は、バッチ処理の基本的な機能 (スケジュールとワークフロー) が備わっていないことに気づきました。
ストリーミング レイク ウェアハウスはフロー機能を解決する必要があるだけでなく、バッチのオフライン処理機能も解決する必要があります。バッチはレイク ウェアハウスの基礎です。このストリーミング レイク ウェアハウスの実際のフローは 10% または 20% にすぎない可能性があります流れ全体ではなく、滄湖全体。したがって、Flink のストリームとバッチの統合は、Flink の実際のバッチ処理から切り離すことができません。
ストリーミング レイク ウェアハウスの写真からも、データの処理に 4 つのステップが必要であることがわかります。
最初のステップは、ワンクリックで湖に入り、Flink CTAS/CDAS を介してワンクリックで湖に入ります。
2 番目のステップでは、パイプラインの完全なリンクがリアルタイムでストリーミングされるため、ストレージへの読み取りと書き込みをストリーミングする機能が必要です。
3 番目のステップは、これらすべてのデータをオープン分析エンジンを通じて分析できるようにすることです。
4 番目のステップは Hucang の重要なもののバッチ読み取りとバッチ書き込みで、製品に必要なのは基本的にスケジュールとワークフローです。
Alibaba Cloud Serverless Flink は、製品のスケジュール機能とワークフロー機能を正式に歓迎し、サーバーレス Flink で真に完全なバッチ処理リンク機能を実現できるようになりました。
次に、準リアルタイム ストリーミング レイク ウェアハウス、つまり電子商取引データ分析の事例を取り上げたいと思います。Flink を通じて、リアルタイム データはレイクの ODS レイヤーの Paimon テーブルに転送され、その後 DWD、DWM、さらにストリーミングを通じて DWS に流れ、ストリーミング レイク ウェアハウスの完全なセットが形成されます。
ストリーミングレイクウェアハウスのデモ
デモ閲覧用アドレス:
https://yunqi.aliyun.com/2023/subforum/YQ-Club-0044
オープンソースビッグデータ特別リプレイビデオ 01:52:42 ～ 01:59:00 の時間帯
サーバーレス Flink には ETL をストリーミングする機能があるだけでなく、比較的完全なバッチ処理メソッドも備えています。これまでは、ストリームが 1 つの開発プラットフォーム上にあり、バッチが 1 つの開発プラットフォーム上にあり、非常に細分化されていました。開発プラットフォーム全体をサーバーレス Flink 上で実行でき、コンピューティング エンジン全体を Flink Unified で実行でき、基盤となるストレージはオフライン処理、リアルタイム処理、または準リアルタイム処理を完了できる Unified の Paimon ストレージのセットであることが実現されます。開発からコンピューティング、ストレージまでの完全な統合を実現できる計画です。バッチ処理版も近日公開予定ですので、必要な方は事前にお試しいただけますようお願いいたします。
OpenAI が ChatGPT Voice Vite 5 をすべてのユーザーに無料で公開、正式にリリース オペレーターの魔法の操作: バックグラウンドでネットワークを切断、ブロードバンド アカウントを非アクティブ化、ユーザーに光モデムの変更を強制 Microsoft オープン ソースの ターミナル チャット プログラマーが ETC 残高を改ざんし、年間 260 万元以上を横領 Redis の父が使用する Pure C 言語コードは、Telegram Bot フレームワークを実装しています あなたがオープンソース プロジェクトのメンテナである場合、この種の返答にどこまで耐えることができますか? Microsoft Copilot Web AI は 12 月 1 日に正式にリリースされ、中国の OpenAI をサポートします 元 CEO 兼社長の Sam Altman 氏と Greg Brockman 氏が Microsoft に加わりました Broadcom は VMware の買収に成功したと発表しました