要約: この記事は、Alibaba Cloud のオープンソース ビッグ データ テーブル ストレージ チームの責任者、Alibaba のシニア テクニカル エキスパート、Apache Flink PMC、および Paimon PPMC の Li Jinsong (Zhixin) による Apache Paimon Meetup での共有内容を編集したものです。この記事の内容は主に次の 4 つの部分に分かれています。
- 湖沼貯留の困難
- Apache Paimon 0.4 の詳細
- 社会的慣習
- その後の計画
Paimon 0.4 は今年 6 月にリリースされたばかりで、非常に競争力の高いバージョンであり、Apache インキュベーターに入った後の最初のバージョンでもあります。
1. 湖沼貯留の難しさ
データ レイクには主に 3 つの新しいシナリオがあります。
- 最初のシナリオでは、リアルタイム データがレイクに入力されます。データはデータベースから CDC データをリアルタイムで更新し、リアルタイムでデータ レイクに入力できるため、さまざまなエンジンでデータをできるだけ早く分析できます。
- 2 番目のシーンでは、リアルタイムのフィールドが広がります。ディメンション テーブルのフィールドをリアルタイムで拡張し、ダウンストリームのクエリとストリームの読み取りに提供します。
- 3 番目のシナリオは、リアルタイムのデータ ストリーム読み取りです。メッセージ キュー エクスペリエンスのストリーミング読み取りを提供し、主キーに従って変更ログを生成できます。
湖に入る際の問題点は次のとおりです。
-
リソース消費とリアルタイム パフォーマンス: 更新スループットが低く、リソース消費が膨大です。COW 更新が貧弱で、MOR クエリが貧弱で、バック プレッシャー、バック プレッシャー、またはバック プレッシャーを選択するのが困難です。
-
データ レイクでは、圧縮の管理、小さな履歴ファイルのクリーンアップ、期限切れのパーティションのクリーンアップなど、管理すべきことがたくさんあります。
-
スキーマの進化: アップストリームとレイク ストレージに列を追加する場合はどうなりますか? 同期ジョブを再開しますか? 多数の小さなテーブルはリソースとエネルギーを消費します。
幅の広いテーブルには次の 3 つの問題点があります。
-
リソース消費とリアルタイム: スループットとリソースは同様に重要です。
-
入力ダイバーシティ: CDC 入力; 入力が故障している可能性があります。
-
読書: 十分に効率的で、プロジェクトのプッシュダウンがあり、ストリームで読めることを願っています。
ストリーム読み取りの問題点は次のとおりです。
-
全増分 1 ストリーム読み取り: 最初に全量を読み取り、次に増分に続き、読み取り専用の増分ではなく完全なストリームを読み取ります。
-
変更ログの生成: 一部のシナリオでは低コストが必要ですが、一部のシナリオでは低遅延が必要です。
-
FileNotFound: データ レイク ファイルのクリーニングとストリーミング読み取りの間の矛盾。
-
ルックアップ結合: Flink のルックアップ結合をサポートします。
Apache Paimon は、CDC 処理とストリーム コンピューティング用に特別に設計されたデータ レイクです。快適な自動湖ハンドリング体験をお届けしたいと考えています。
公式ウェブサイトからも、Apache Paimon が高速なデータ書き込み、Changelog 生成、効率的なリアルタイムクエリをサポートしていることがわかります。
2. Apache Paimon 0.4 の詳細
Paimon の全体的なアーキテクチャは、データ レイク (HDFS/OSS/S3) 上に構築されたデータ レイクであり、すべてのメタとデータはこれらのデータ レイク (データ レイク形式) に保存されます。このデータ レイクのメタは、Hive Metastore および Alibaba Cloud の Data Lake Formation に同期して、統合されたデータベースの表形式の管理を行うこともできます。次に、データ レイクは変更ログをレイクに同期し、次に Kafka を同期します。
現在、Paimon 0.4 では Flink CDC の Schema Evolution 同期が提供され、MySQL のデータベース全体の同期も提供されており、後続の Paimon 0.5 では Kafka の CDC データ同期がサポートされます。さらに、Append ログ データを Flink によるバッチ書き込みによって Paimon に書き込むことも、ワイド テーブル マージによって Paimon に書き込むこともできます。
読み取り側では、Paimon は、Spark、Trino、StarRocks などのさまざまなエンジンからのバッチ読み取りとアドホック クエリをサポートできます。また、Flink を介して完全に増分かつ統合された方法で変更ログを読み取ることもでき、ストリーミング読み取りも可能です。データを提供する 順序が保証されている場合は、Flink を使用して結合を検索することもできます。
Paimon はデータ レイク + LSM アーキテクチャですが、Paimon に LSM が必要な理由を説明しましょう。
LSM は書き込みに適した形式です。書き込み時にプロセス全体を確認できますが、特定のプロセスを理解する必要はありません。一般的な考え方は、書き込みは Flink Sink で行われるということです。チェックポイントが到着すると、データが並べ替えられます。メモリに保存し、レコードを Level0 ファイルにフラッシュします。
LSM のネイティブな非同期マイナー コンパクションのおかげで、LSM は非同期コンパクションを通じて最下位層に落ちたり、一部のマイナー コンパクションとマイナー マージが上位層で発生したりするため、レベルが高くなりすぎずに LSM を維持できます。マージ読み取りのパフォーマンスは、書き込みの大幅な増幅を引き起こすことなく保証されます。
さらに、Flink Sink は期限切れのスナップショットとファイルを自動的にクリーンアップし、パーティションのクリーンアップ戦略を構成することもできます。したがって、Paimon 全体は、高スループットの追加書き込み、低消費電力のローカル圧縮、完全自動クリーニング、および秩序あるマージを提供します。したがって、書き込みスループットは非常に高く、マージ読み取りも遅くなりません。
パイモンのデザインに基づいて、同じ旅行での製造実践を見て、オリジナルの Hudi ウォッチがもたらすメリットを比較してみましょう。
-
湖に流入する資源は 30% ～ 40% 節約されます。
-
書き込みパフォーマンスが 3 倍向上しました。
-
一部のクエリのパフォーマンスは約 7 倍向上しました。
スループットの観点からレイク内の Paimon CDC データの機能をいくつか共有しましたが、Paimon がレイクの CDC でユーザーに提供する便利なツールをいくつか紹介しましょう。
たとえば、Paimon 0.4 では、Flink CDC へのアクセスが提供されました。ネイティブに統合された Flink CDC は DataStream ジョブを提供し、変更ログ データは Flink CDC を介した Schema Evolution を通じて Paimon に書き込まれます。
テーブルの同期。テーブル構造の変更、列の追加、列の削除、タイプの変更、列名の変更などを自動的に管理できます。また、テーブル同期の定義を通じて、計算列の追加、パーティション列の定義、主キーの定義、サブデータベースとサブテーブルの同期を実行することもできます。
さらに、Paimon CDC はデータベース全体の同期も提供します。これにより、データベース全体のすべてのテーブルを Paimon に同期できるため、OOM や簡単なハングアップを心配する必要はありません。ジョブを同期する場合、同期のためのリソースを可能な限り削減できます。また、INCLUDING、EXCLUDING、およびテーブル名のプレフィックスとサフィックスもサポートし、失敗したテーブルを自動的にスキップし、テーブルを動的に追加します。
Paimon 0.5 では、Kafka 同期が提供されます。Flink CDC を介して同期できるだけでなく、Kafka の CDC データも同期できます。データベース、TIDB、MySQL、Oracle を Kafka に書き込み、それを Schema Evolution 同期を使用して Paimon に同期できます。
レイクへの同期は非常に簡単で、同期ジョブ全体は Paimon の Flink アクションを使用して開始できることがわかります。Paimon も CDC の DataStream API を提供しており、統合ジョブを直接呼び出してデータを同期したり、CDC の DataStream API を介して独自の Flink フロー スキーマ進化パイプラインを作成したりできます。
Paimon は部分更新の定義をサポートしており、部分更新エンジンを定義できます。このようにして、異なるフィールドに異なるフィールドを書き込むことができ、後でバッチ読み取りを実行できます。Paimon でもストリーム読み取りも提供しています。変更ログプロデューサーが宣言されている限り、マージされたデータはストリーム読み取り可能です。そのクエリもサポートしています列プルーニングの効率的なクエリ。
さらに、部分更新の入力は順序が狂っている可能性があるため、部分更新テーブルでは、順序が狂っている状況を処理するためにシーケンス フィールドを定義することもできます。シーケンス グループの概念は、各ストリームの異なる乱れを解決するために、Paimon 0.5 で導入されました。同じバージョン フィールドを共有する場合、1 つのストリームが更新された後、別のストリームの最新バージョンが更新されない可能性があります。
たとえば、更新する上流テーブルが 2 つあるため、2 つのシーケンス グループを定義する必要があり、このシーケンス グループのフィールドは異なるバージョン フィールドにすることができます。このようにして、異なるストリームはそれぞれのバージョンを更新するだけで済み、両側がどれほどずれていても、最終データは正しく更新されます。
Paimon では、ストリーム読み取りがコアの 1 つであり、他のデータレイクと区別する重要なポイントでもあります。Paimon は生データをストリーミングでき、Changelog-Producer=input を設定できます。データが完全な CDC の場合は、最も効率的でリソースの消費が最も少ないこのモードを使用できます。
ストリームが完全な CDC ではない場合 (部分更新入力など)。したがって、変更ログを生成するにはダウンストリーム ストリームの読み取りが必要です。Paimon は変更ログの生成をサポートするだけでなく、ルックアップ モードとフルコンパクション モードという 2 つの非常に柔軟なモードも備えています。
Lookup モードでは、書き込み時に高レベルのファイルを動的に検索し、最新のデータを検索し、最新の変更ログをマージしてダウンストリームに出力できます。これは最速であり、1 ～ 3 分の遅延に対して推奨される方法ですが、料金は高くなります。
一部のジョブで必要なコストが非常に低く、遅延が大きくても許容できる場合は、フルコンパクション モードを使用できます。非同期フルコンパクションの場合、対応する変更ログが生成され、フルコンパクション期間のスケジュール時間を 10 分など、より長く設定できます。その利点は、コストが低いことですが、遅延が大きいことです。
先ほど、レイク ストレージとストリーミング読み取りの間に矛盾がある、つまり FileNotFound があると述べました。ストリーミング ストレージではスナップショットを常にクリーンアップする必要があるため、ストレージ内の小さなファイルは少なくなります。ただし、ストリーミング読み取りが初期のスナップショットに依存している場合、ストリーミング ジョブがハングアップすると、読み取られたスナップショットはクリーンアップされ、まったく復元できなくなります。
この問題に対して、Paimon は Kafka の Group-ID に似た Consumer-ID を提案しました。これにより、ジョブがハングして再起動された後、読み取られたスナップショットがクリーンアップされないようにすることができます。
パイモン0.4は上図のようにエコロジー面でも大きな進歩を遂げています。
当初、Paimon は Flink のみをサポートしていましたが、Flink の完全なエコロジーと使用法をサポートする Flink Table Store として機能しました。
Paimon 0.4 ではさらに多くの機能がサポートされています。たとえば、Spark はバッチ読み取り、バッチ書き込みをサポートし、Spark でテーブルの作成やテーブルの変更もできます。Hive ではバッチ リーダー、バッチ書き込み、テーブルの作成などをサポートし、Trino などではテーブルの作成、テーブルの変更などをサポートします。機能。
適切に統合された 2 つのエンジンがあり、1 つは Flink で、もう 1 つは Spark です。私たちは、バッチ読み取り、バッチ書き込み、テーブルの作成、Meta やその他のコマンドの変更など、そのすべての機能が Flink と Spark でより適切にサポートされることを望んでいます。次に、他のエンジンがパイモンの読み取りや、テーブルの作成、テーブルの書き込みなどのさらに多くの操作をサポートできることを期待しています。
これらの従来の処理エンジンに加えて、StarRocks、Doris、Seatunnel にも Paimon が統合されており、コード全体は基本的に準備が整い、間もなくリリースされます。Alibaba Cloud 上の MaxCompute と Hologres、NetEase 上の Arctic も研究開発中です。
3. ソーシャルアプリケーションの実践
現在、オープンソース コミュニティの主なユーザーと参加者には、Alibaba Cloud、ByteDance、Tongcheng Travel、Bilibili、中原銀行、Mihayou、Autohome などの企業が含まれます。
みんなのパイモンの使い方を見てみましょう。
Alibaba Cloud Computing Platform では、Paimon はデータレイクでナンバー 1 の位置にあり、Alibaba Cloud Computing Platform のすべての計算が Paimon に統合され、Paimon が統合され、Paimon が読み取られることが期待されています。最良の統合は、Flink とオープンソースのビッグデータ プラットフォーム E-MapReduce に含まれるリアルタイム コンピューティング Flink バージョン プラットフォームであり、リアルタイム レイク アクセスの最初の選択肢として Hudi に代わることを期待しています。
上の写真は Apache Paimon を示しており、Alibaba Cloud の Flink リアルタイム コンピューティング、湖への CTAS、および Alibaba Cloud を介したリアルタイム Flink ストリーミングを通じて湖にアクセスできることがわかります。また、Paimon のデータが MaxCompute と Hologres によってクエリできるようになり、オープンソースのビッグ データ プラットフォーム E-MapReduce にうまく統合できるようになることも期待しています。
ByteDance では、エンジニアはリネージ管理と一貫したクエリのためのストリーミング ウェアハウス運用システムとして Paimon+Flink を使用しています。上の図に示すように、ビジネス データはストリーミング ETL を通じてストリーミング ウェアハウスに分類されます。これは、ストリーミング マテリアライズ ビューの概念に似ています。このようにして、一貫したクエリを通じてすべての Paimon テーブルをクエリできます。
同じ過程で、Paimon の導入により、主にオリジナルの Hudi のほぼリアルタイムのデータ ウェアハウスが最適化されました。
-
ODS レイヤーへのリアルタイム書き込みのシナリオでは、Paimon には約 114 以上のジョブがあり、Upsert の 1 日あたりの最大増分は 2,000 万以上、最大合計テーブル サイズは 90 億以上です。
-
部分更新シナリオでは、Paimon には 10 以上のジョブがあり、真の部分更新 (シーケンス グループ) の概念が適用されます。
-
ストリーミング/増分読み取りシナリオでは、Paimon には 20 以上のストリーミング増分読み取りジョブ、10 以上のバッチ時間ごとの増分読み取りジョブがあります。
中原銀行はストリーミング データ ウェアハウスを検討しており、Mihayou はストリーミングとバッチ技術の統合も検討しており、Bilibili は部分更新のシナリオを考慮して AI の方向に取り組んでおり、Chenfeng Information は TB レベルのデータを湖に入れることを検討しています。また、Flink ストリーミングとバッチの統合 + Paimon のストリームとバッチの統合データ ウェアハウスなどを構築しました。
4. その後の計画
私たちはそんなStreaming LakeHouseを実現したいと考えています。データは、レイクに入る非常に便利な方法で Paimon に入力でき、Paimon のストリーム読み取りとバッチ読み取りを通じてストリーミング パイプラインを確立することもできます。同時に、パイモンはさまざまなエンジンでクエリできる非常に優れた生態系も備えているはずです。これが今後のパイモン+フリンクの全体的な方向性です。
使いやすくシンプルなStreaming LakeHouseを作るには、大きく分けて以下の3つの方向性があります。
最初の方向:
-
CDC の処理中に湖に流入する CDC がさらに増加します。たとえば、先ほど述べたカフカの湖への侵入は、よりシンプルで、より自然で、より自動的であるべきです。
-
現時点では、パイモンはまだバケットの数を設定する必要があります。バケットが小さすぎるとパフォーマンスが相対的に低下し、データ量が多くなるとスループットが低下します。また、大きすぎるバケットには小さなファイルが多数含まれます。バケット内に 1 つの LSM があり、すでに比較的良好なスループットを備えていますが、まだ調整する必要があります。したがって、Paimon 0.5 では動的なバケットが提供され、望ましい状態が完全に自動化されます。
-
タグを作成します。パイモンがリアルタイムで湖に入った後、オフライン生産用にタグを毎日印刷できることを願っています。
2 番目の方向: 追加専用処理の強化。Paimon の前の Append-Only では、Bucket を定義する必要がありますが、これは定義するのが非常に難しい概念です。したがって、Paimon は将来的には実際のオフライン テーブルをサポートする必要があり、バケットはなく、オフライン テーブルの書き込みには小さなファイルのマージも含まれる必要があり、これは Paimon の完全自動コンセプトとも一致しています。
3 番目の方向: StarRocks のエコロジー ドッキングに加えて、Paimon のような 2 番目のよく統合されたエンジンに Spark を構築したいと考えています。Spark の読み書き能力は非常に優れている必要があります。完全なデータ レイクです。
次に、Paimon の開発プロセスを振り返ります。2021 年に Flink コミュニティで議論される予定です。Flink Table Store の最初のバージョンは 2022 年 5 月にリリースされます。0.3 は 2023 年 1 月にリリースされ、Paimon の実稼働バージョンになります。3 月にインキュベータに入る予定です。そして、Apache Paimon という名前に変更されます。2023 年 6 月に、Paimon 0.4 がリリースされました。
将来的には、CDC リアルタイム データ レイクが完全に成熟し、Append のオフライン テーブルの作成が利用可能になり、エコロジーが完全に接続され、Spark が成熟した状態になることを期待しています。
Q&A
Q: CDC は Paimon テーブルを書き込みます。ビンログ トラフィックが 1 秒あたり 3000 レコード + 完全な初期化の場合、それを最適化する方法はありますか。現在のテストでチェックポイントが頻繁に失敗しますか?
回答: 重要なのは、パフォーマンスのボトルネックがどこにあるのか、メモリの問題があるかどうかを確認し、最後に Jstack を確認することです。
Q: テーブル構造は動的に変更できますか?
回答: はい、Spark または Flink 1.17 は両方とも利用可能です。
Q: 0.5 はいつリリースされますか?
A：8月くらいです。
Q: ストリーム読み取りの遅延についてはどうですか?
回答: チェックポイント遅延の最小値は 1 分です。
Q: Hudi から Paimon に簡単に移行するにはどうすればよいですか?
回答: はい、現在リリースされている SparkGenericCatalog も、Hudi テーブルと Paimon テーブルの共存用です。
Q: 変更ログのルックアップ モードについて詳しく説明してもらえますか?
答え: 公式サイトで確認できます
Q: Bucket は重要なパラメータですか? また、それを調整するにはどうすればよいですか?
回答: はい、データ量に応じて実際に実行して確認することができますが、現在最新バージョンではダイナミックバケットもサポートしています。
Q: 一定期間保管した後、バケットを手動で調整できますか? 調整前のデータは再採点されるのでしょうか？
A: 詳細については、公式 Web サイトの Rescale Bucket を参照してください。
Q: リアルタイム データの順序が狂っている場合、Paimon の部分更新は古いデータが新しいデータを上書きするのをどのように防ぎますか? シーケンス列と同様の実装はありますか?
回答: はい、詳細については公式 Web サイトのシーケンスフィールドを参照してください。
Q: 圧縮すると、読み取りと書き込みのパフォーマンスに大きな影響がありますか?
回答: 読み取りと書き込みのトレードオフである書き込みに影響します。
パイモンをフォローする
ストリーミング データ レイクの開発には皆様のサポートが必要です。
-
WeChat パブリック アカウント: Apache Paimon に注目して、業界の慣行と最新の開発について学んでください。
-
Paimon コミュニケーション DingTalk グループに参加してください: 10880001919 を検索し、テクノロジーについて話し合い、リアルタイムのサポートを受けてください。
-
Github GitHub - apache/incubator-paimon: Apache Paimon(incubating) は 、高速データ インジェスト、変更データ追跡、効率的なリアルタイム分析をサポートするストリーミング データ レイク プラットフォームです。