【ビッグデータ】Apache Icebergの概要とソースコード構築

ビッグデータの計算に異なるエンジンを使用する場合、計算エンジンに応じてデータを適応させる必要があります。これはかなり扱いにくい問題ですが、新しい解決策が登場しました。それは、上位のコンピューティング エンジンとその下にあるストレージ フォーマットの間の中間層です。この中間層はデータ ストレージの手段ではなく、データのメタデータ構成を定義するだけであり、従来のデータベースの「テーブル」に似た統一されたセマンティクスをコンピューティング エンジンに提供します。その最下層は依然として Parquet や ORC などのストレージ形式です。

これに基づいて、Netflix は Iceberg を開発しました。これは、現在 Apache のトップレベル プロジェクトhttps://iceberg.apache.org/です。

1. データ レイク ソリューション - Iceberg

1.1 氷山とは

Apache Iceberg は、巨大な分析データセット用のオープン テーブル形式です。Iceberg は、SQL テーブルと同様に機能する高性能テーブル形式を使用して、Flink Trino Spark や Hive などのコンピューティング エンジンにテーブルを追加します。

Iceberg はオープン データ レイク テーブル形式です。これは、コンピューティング層 (Flink、Spark) とストレージ層 (ORC、Parquet、Avro) に基づく中間層として単純に理解できます。Flink または Spark を使用してデータを Iceberg に書き込み、その後、次のような他の方法でテーブルを読み取ります。スパーク、フリンク、プレストなど

ファイル形式 ( Parquet//Avroなど)ORCの上にテーブル セマンティクスを実装します。

• スキーマの定義と変更のサポート
• 隠しパーティションとパーティションの変更をサポート
• ACID セマンティクス
• 歴史的バージョンのバックトラッキング
• パーティションと列の統計を利用したパーティションのプルーニング
• ストレージ エンジンをバインドせず、HDFS//S3などOSSに拡張できます。
• 複数writerの同時書き込みが許可され、オプティミスティック ロック メカニズムにより競合が解決されます。

1.2 Iceberg のテーブル形式の概要

Iceberg は大量のデータを分析するために設計されており、コンピューティング層とストレージ層の間にあるテーブル形式として定義されています。

テーブル フォーマットは、ストレージ システム上のファイルを下位に管理し、コンピューティング レイヤに豊富なインターフェイスを提供します。ストレージ システム上のファイル ストレージは、特定の編成形式を採用します。たとえば、Hive テーブルを読み取るとき、HDFS ファイル システムは、パーティション、データ ストレージ形式、データ圧縮形式、データ ストレージ HDFS ディレクトリ情報などをすべて保持します。Metastoreでは、Metastore をファイル編成形式と呼ぶことができます。

Iceberg などの優れたファイル編成フォーマットは、ディスク上のファイルへのアクセス、操作list、rename検索を行うための上位コンピューティング層をより効率的にサポートできます。

テーブルとテーブル形式は 2 つの概念です。テーブルは具体的な概念であり、アプリケーション レベルの概念であり、私たちが毎日話題にするテーブルは、行と列の単純な組み合わせです。テーブル形式はデータベースシステム実装レベルの抽象概念であり、どのフィールドが含まれるか、テーブル配下のファイルの編成形式（パーティションモード）、メタデータ情報（テーブル関連の統計情報）などのテーブルのスキーム定義を定義します。 、テーブル インデックス情報)、

上図の右側はデータウェアハウスのエコシステムにおけるIcebergの位置づけを示しており、これとほぼ同等のコンポーネントがMetastoreです。ただし、Metastore はサービスであり、Iceberg はjarパッケージのセットです。表形式の場合、主に4 4が含まれると思います。$4\; つの$レベルテーブル スキーマ定義(複雑なデータ型がサポートされているかどうか)、テーブル内のファイルの編成形式、テーブル関連の統計情報、テーブル インデックス情報、テーブルの読み取りおよび書き込み API 情報です。

• intテーブル スキーマは、 、string、複合データ型などのフィールド タイプをサポートするテーブルを定義しますlong。
• テーブル内のファイル編成の最も一般的な形式は、レンジ パーティションまたはハッシュ パーティションであるパー​​ティション モードです。
• メタデータ データの統計。
• テーブルの読み取りおよび書き込み API。上位エンジンは、対応する API を通じてテーブル内のデータを読み書きします。

1.3 Iceberg の核となるアイデア

Iceberg の中心となるアイデアは、テーブルのすべての変更を時間軸上で追跡することです。

• スナップショットは、テーブル データ ファイルの完全なコレクションを表します。
• 更新操作ごとに新しいスナップショットが生成されます。

1.4 氷山のメタデータ管理

図からわかるように、Iceberg はデータを階層的に管理しており、主にメタデータ管理層とデータ ストレージ層に分かれています。メタデータ管理レイヤーは、次の 3 つのレイヤーに分割できます。

• メタデータ ファイル
• スナップショット
• マニフェスト

メタデータ ファイルには現在のバージョンのメタデータ情報 (すべてのスナップショット情報) が格納されます。スナップショットは現在の操作のスナップショットを表し、commitスナップショットは毎回生成され、スナップショットには複数のマニフェストが含まれます。各マニフェストには、現在の操作によって生成されたデータに対応するファイルのアドレス、つまりデータ ファイルのアドレスが記録されます。Iceberg は、スナップショット管理方式に基づいてtime travel(履歴バージョンの読み取りと増分読み取り) を実行でき、 を提供しますserializable isolation。

データ ストレージ レイヤーはさまざまなファイル形式をサポートしており、現在は Parquet、ORC、および AVRO をサポートしています。

1.5 Iceberg の重要な機能

Apache Iceberg はもともと、Hive のオフライン データ ウェアハウスにおけるコンピューティングの遅さの問題を解決するために設計されましたが、長年の反復を経て、データ レイク サービスを構築するための表形式の標準に発展しました。Apache Iceberg の詳細については、Apache Iceberg の公式 Web サイトを参照してください。

現在、Iceberg は次のコア機能を提供しています。

1.5.1 リッチコンピューティングエンジン

• 優れたカーネル抽象化により、特定のエンジンに束縛されず、現在、Spark、Flink、Presto、Hive がサポートされています。
• Iceberg は、特定のエンジンなしで Iceberg テーブルにアクセスできる Java ネイティブ API を提供します。

1.5.2 柔軟なファイル構成

• ストリームベースの増分コンピューティング モデルとバッチベースのフルスケール テーブル コンピューティング モデルを提供します。バッチ タスクとストリーム タスクは同じストレージ モデル (HDFS、OZONE) を使用でき、データは分離されなくなり、低コストの軽量データを構築します。レイクストレージサービス。
• Iceberg は、隠しパーティション ( Hidden Partitioning) とパーティション レイアウトの変更 ( Partition Evolution) をサポートしているため、企業はデータ パーティション戦略を簡単に更新できます。
• Parquet、ORC、Avro、その他のストレージ形式をサポートします。

1.5.3 レイクに入るデータのプロセスの最適化

• Iceberg は ACID トランザクション機能を提供し、現在のデータ処理タスクに影響を与えることなく、書き込み直後にアップストリーム データを確認できるため、ETL が大幅に簡素化されます。
• IcebergUpsertは行Merge Intoレベルのデータ変更を提供し、データ ストレージの遅延を大幅に削減できます。

1.5.4 インクリメンタル読み取り処理機能

• Iceberg は、ストリーミング方式での増分データの読み取りをサポートし、レイクに参入する主流のオープンソース コンピューティング エンジンと分析シナリオの間の完璧な接続を実現します。
• Spark 構造化ストリーミングをサポートします。
• Flink テーブル ソースをサポートします。
• 過去のバージョンのバックトラッキングがサポートされています。

1.6 データファイルの構造

まず、ファイル システム内の Iceberg のレイアウトを理解しましょう。一般的に、Iceberg はデータの 2 つの部分に分割されます。

• 最初の部分は、次の図のようなデータ ファイル.parquetです。
• 2 番目の部分は、スナップショット ファイル ( )、マニフェスト ファイル ( )、TableMetadata ファイル ( ) などを含むテーブル メタデータ ファイル(メタデータ ファイル)です。snap-*.avro.avro*.json

1.6.1 メタデータ ファイル

このうち、メタデータ ディレクトリにはメタデータ管理レイヤーのデータが保存されます。テーブルのメタデータは変更できず、常に前方に反復され、現在のスナップショットはロールバックできます。

1.6.1.1 テーブルのメタデータ

version[number].metadata.json：バージョンごとのデータ変更項目を格納します。

1.6.1.2 スナップショット（スナップショット）

snap-[snapshotID]-[attemptID]-[commitUUID].avro: スナップショット スナップショット ファイルを保存します。

スナップショットは、特定の時点での Iceberg テーブルの状態を表し、マニフェスト リスト( Manifest List) とも呼ばれます。これにはマニフェスト ファイルのリストが格納され、各マニフェスト ファイルは 1 行のデータを占めます。マニフェスト リスト ファイルはサフィックスsnapで始まりサフィックスで終わりavro、更新ごとにマニフェスト リスト ファイルが生成されます。各行にはマニフェスト ファイルへのパスが格納されます。

リストファイル（Manifest Files）には、データファイルのパーティション範囲、データファイルの追加数、データファイルの削除数などの情報が格納される。データ ファイル (データ ファイル) は異なるマニフェスト ファイルに保存され、マニフェスト ファイルはマニフェスト リスト ファイルに保存され、マニフェスト リスト ファイルはスナップショットを表します。

1.6.1.3 マニフェストファイル

[commitUUID]-[attemptID]-[manifestCount].avro: マニフェスト ファイル。

マニフェスト ファイルは、サフィックスで終わるavro形式で保存され、更新操作ごとに複数のマニフェスト ファイルが生成されます。avroスナップショット(Snapshot)を構成するデータファイルの一覧を表示します。各行は、データ ファイルのステータス、ファイル パス、パーティション情報、列レベルの統計情報(各列の最大値と最小値、NULL 値の数、など）、ファイルのサイズ、データの行数およびその他の情報。列レベルの統計情報は、オペレーターがスキャン中にプッシュダウンするデータを提供するため、不要なファイルをフィルターで除外できます。

1.6.2 データファイル

dataディレクトリ編成形式は Hive に似ており、ディレクトリ編成はパーティション (dt図のパーティション列) に基づいています。

dataIceberg のデータ ファイルは通常、このディレクトリに保存されます。3 つのストレージ形式 (Avro、ORC 、および Parquet) があり、主に選択したストレージ形式に応じて、サフィックスはavroまたはに対応します。通常、ディレクトリには複数のデータ ファイルが存在します。orcparquet

2. Apache Icebergの実装詳細

2.1 スナップショットの設計方法

2.1.1 スナップショットの分離

• 読み取り操作は、現在生成されているスナップショットにのみ適用されます。
• 書き込み操作では、新しい分離されたスナップショットが生成され、書き込みの完了後にアトミックにコミットされます。

次の図に示すように、点線のボックス (スナップショット-1) は、書き込み操作が進行中であることを示していますが、操作はまだ行われていません。この時点では、スナップショット-1 は読み取り不能であり、ユーザーは読み取り専用commitですcommit。過ぎたスナップショット。同様に、スナップショット 2 とスナップショット 3 は、すでに読み取り可能であることを示しています。

同時読み取りをサポートできます。たとえば、S1、S2、および S3 のスナップショット データを同時に読み取ることができ、同時に、スナップショット 2 またはスナップショット 3 まで遡ることができます。Snapshot-4commitが完了すると、この時点で Snapshot-4 が実線になり、データが読み取れるようになります。

たとえば、現在のCurrent Snapshotポインタが S3 に移動された場合、テーブルに対するユーザーの読み取り操作はすべて、Current Snapshot読み取りポインタが指すスナップショットに対するものになりますが、前のスナップショットの読み取り操作には影響しません。

すべての準備が完了すると、メタデータ ファイルがアトミックに操作されcommit、1 つの Iceberg データ書き込みが完了します。書き込みのたびに、Iceberg は以下に示すようなファイル編成パターンを生成します。

2.1.2 インクリメンタルリードデータ

Iceberg の各スナップショットには、前のスナップショットのすべてのデータが含まれており、毎回全量のデータを読み取るのと同等であり、リンク全体では、データの読み取りコストが非常に高くなります。

現時点での増分データのみを読み取りたい場合は、Iceberg のスナップショット バックトラッキング メカニズムに従って実装し、スナップショット 1 からスナップショット 2 までの増分データのみを読み取ります。これは、図の紫色のデータ部分です。下の図。

同様に、S3も赤色部分のインクリメンタルデータのみを読み出すことも、S1～S3のインクリメンタルデータを読み出すこともできます。

Iceberg は読み取りと書き込みの分離をサポートしています。つまり、同時読み取りと増分読み取りをサポートできます。

2.1.3 アトミック操作

ファイル リストへのすべての変更はアトミック操作です。

• パーティションにデータを追加します。
• パーティションをマージまたは書き換えます。

• Iceberg はファイルの粒度でトランザクションを送信するため、トランザクションを数秒で送信する方法はありません。そうしないと、ファイルのデータ量が増大します。
• たとえば、Flink は書き込みユニットとしてチェックポイントを使用します。物理データが Iceberg に書き込まれた後は、直接クエリすることはできません。チェックポイントがトリガーされた場合にのみ、メタデータが書き込まれます。このとき、データは非表示から表示に変わります。また、CheckPoint の各実行にも一定の時間がかかります。

2.2 トランザクションコミット

2.2.1 書き込み操作の要件

アトミック置換により、直線的な履歴が保証されます。アトミック置換は、次の操作によって保証されます。

• 現在のメタデータのバージョンを記録しますbase version。
• 新しいメタデータとマニフェスト ファイルを作成します。
• base version新しいバージョンに自動的に置き換えられます。

2.2.2 競合の解決 - 楽観的ロック

• 現在進行中の他の書き込み操作がないと仮定します。
• 競合が発生した場合は、最新のメタデータに基づいて再試行します。
• メタデータ マネージャーによって提供される機能。
• renameHDFS またはローカル ファイル システムによって提供されるアトミック機能。

3. Iceberg と Flink シーン共有を組み合わせた

3.1 ほぼリアルタイムのデータ パイプラインの構築

Iceberg は、分レベルで準リアルタイム データを取得できます。

まず、Flink Iceberg の最も古典的なシナリオの 1 つは、リアルタイム データ パイプラインを構築することです。業務側で生成された大量のログデータは、Kafkaなどのメッセージキューにインポートされます。Flink ストリーム コンピューティング エンジンを使用して ETL を実行した後、それを Apache Iceberg の元のテーブルにインポートします。一部のビジネス シナリオでは、分析ジョブを直接実行して元のテーブルのデータを分析する必要がありますが、他のビジネス シナリオでは、データをさらに純化する必要があります。次に、新しい Flink ジョブを開始して、Apache Iceberg テーブルから増分データを消費し、処理後に精製された Iceberg テーブルにそれを書き込むことができます。現時点では、データをさらに集計するビジネス ニーズがある可能性があるため、引き続き Iceberg テーブルで増分 Flink ジョブを開始し、集計されたデータの結果を集計テーブルに書き込みます。

このシナリオは Flink Hive でも実現できるのではないかと考える人もいるかもしれません。Flink Hive は確かに実装できますが、Hive に書き込まれるデータは、増分プル用ではなく、データ ウェアハウスのデータ分析用です。一般的に、Hive の増分書き込みはパーティション単位となり、時間は$15分$以上、Flink の長期にわたる高頻度書き込みにより、パーティションが拡張されます。そして Iceberg は$1分$、あるいは$30\; 秒の$増分書き込みにより、エンドツーエンド データのリアルタイム パフォーマンスが大幅に向上します。上位レベルの分析ジョブは更新されたデータを確認でき、下流の増分ジョブは更新されたデータを読み取ることができます。

3.2 CDC データのリアルタイムの取り込みと出力

Flink CDC ( Change Data Capture) は増分データを Iceberg に書き込みます。

• 湖への準リアルタイムのデータ入力とデータ分析をサポートします。
• コンピューティング エンジンは、コンポーネントを追加せずに CDC をネイティブにサポートします。
• 統合されたデータ レイク ストレージ ソリューションを採用し、複数のデータ分析エンジンをサポートします。
• インクリメンタルデータ読み取りをサポートします。

Flink Iceberg を使用すると、MySQL などのリレーショナル データベースのデータを分析できますbinlog。一方で、Apache Flink はすでに CDC データ分析をネイティブにサポートしており、binlogデータの一部が によってプルされた後、 ververica flink-cdc-connectorFlink ランタイムによって認識できる4 つのメッセージINSERT、DELETE、UPDATE_BEFORE、に自動的に変換されUPDATE_AFTER、ユーザーはさらにリアルタイムで分析を行うことができます。計算。

さらに、CDC データが氷山湖に正常に入力された後、Presto、Spark、Hive などの一般的なコンピューティング エンジンも開き、氷山テーブルの最新データをリアルタイムで読み取ることができます。

MySQL Binlog はバイナリ形式のログ ファイルですが、binlogこのファイルは OS システムの特定のディレクトリにある特定のファイルと同一視することはできません。このファイルは狭いためです。Binlog は、MySQL 内のデータベースへの変更を記録するために使用され (データへの変更操作のみを記録します)、主にマスター/スレーブ レプリケーションとデータベースの増分リカバリに使用されます。

3.3 Iceberg の履歴データから Flink タスクを開始する

上記のアーキテクチャでは、Iceberg の完全データと Kafka の増分データを使用して、新しい Flink ジョブを駆動します。過去の長期間 (1 年など) のデータが必要な場合は、一般的な Lambda アーキテクチャを使用でき、オフライン リンクはKafka → Flink → Icebergデータ レイクに同期的に書き込まれます。Kafka はコストが高いため、最新の$7$日間のデータで十分です。Iceberg はストレージ コストが低く、履歴データを完全に保存できます。新しい Flink ジョブを開始するときは、Iceberg からデータを取得するだけで済み、実行後はスムーズに Kafka データに接続できます。

3.4 Iceberg データを使用したリアルタイム集計結果の修正

また、Lambda アーキテクチャでは、イベントの損失やリアルタイム リンクの到着順序により、ストリーミング コンピューティング エンドの結果が完全に正確ではない可能性があります。現時点では、通常、全量の履歴データが必要です。リアルタイム計算結果を修正します。そして、当社の Iceberg はコスト効率よく履歴データを管理できるため、この役割を非常にうまく果たすことができます。

4. Iceberg 0.11.1 ソースコードのコンパイル

4.1 Icebergのコンパイル

氷山を構築するにはグレード$5.6$および Java$8つの$環境。

4.1.1 Iceberg 0.11.1 パッケージをダウンロードする

ダウンロードリンク:

• https://github.com/apache/iceberg/releases/tag/apache-iceberg-0.11.1
• https://www.apache.org/dyn/closer.cgi/iceberg/apache-iceberg-0.11.0/apache-iceberg-0.11.0.tar.gz

4.1.2 Iceberg 0.11.1 パッケージを解凍する

[bigdata@bigdata185 software]$ tar -zxvf iceberg-apache-iceberg-0.11.1.tar.gz -C /opt/module/ 
[bigdata@bigdata185 software]$ cd /opt/module/iceberg-apache-iceberg-0.11.1/

4.1.3 対応バージョンの変更

コンパイルするには最も安定したバージョンである Hadoop $\mathrm{2.7.7}$、ハイブ$\mathrm{2.3.9}$、フィンク$\mathrm{1.11.6}$、スパーク$\mathrm{3.0.3}$。

org.apache.flink:* = 1.11.6 
org.apache.hadoop:* = 2.7.7
org.apache.hive:hive-metastore = 2.3.9 
org.apache.hive:hive-serde = 2.3.9 
org.apache.spark:spark-hive_2.12 = 3.0.3

4.1.4 build.gradle ファイルを編集し、国内ソースを追加する

(1)buildscriptのを追加しますrepositories:

maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }

追加後は次のようになります。

buildscript {
  repositories {
    jcenter()
    gradlePluginPortal()
    maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }
  }
  dependencies {
    classpath 'com.github.jengelman.gradle.plugins:shadow:5.0.0'
    classpath 'com.palantir.baseline:gradle-baseline-java:3.36.2'
    classpath 'com.palantir.gradle.gitversion:gradle-git-version:0.12.3'
    classpath 'com.diffplug.spotless:spotless-plugin-gradle:3.14.0'
    classpath 'gradle.plugin.org.inferred:gradle-processors:2.1.0'
    classpath 'me.champeau.gradle:jmh-gradle-plugin:0.4.8'
  }
}

(2)allprojectsを追加します。

maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }

追加後はこんな感じ

allprojects {
  group = "org.apache.iceberg"
  version = getProjectVersion()
  repositories {
    maven { url 'https://mirrors.huaweicloud.com/repository/maven/' }
    mavenCentral()
    mavenLocal()
  }
}

4.1.5 依存関係のダウンロード (オプション)

プロジェクトのルート ディレクトリを入力し、スクリプトを実行します。

[bigdata@bigdata185 iceberg-apache-iceberg-0.11.1]$ ./gradlew dependencies

4.1.6 公式編集

(1) プロジェクトのルートディレクトリに入り、以下を実行します。

[bigdata@bigdata185 iceberg-apache-iceberg-0.11.1]$ ./gradlew build

(2) 上記のコマンドはコード内の単体テストを実行します。そうでない場合は、次のコマンドを実行します。

[bigdata@bigdata185 iceberg-apache-iceberg-0.11.1]$ ./gradlew build -x test -x scalaStyle

4.1.7 生成されたディレクトリ

4.2 Iceberg環境の展開

次の章では、Iceberg 0.11.1とFlink 1.11.6、をそれぞれ統合する方法を紹介します。Spark 3.0.3Hive 2.3.9

5. まとめ

• データ レイク ソリューションである Iceberg の紹介。
• Apache Iceberg の技術実装の詳細。
• Iceberg は Flink シーン共有を組み合わせています。
• 氷山$\mathrm{0.11.1}$ソースコードのコンパイル。