Iceberg Definitive Guide輪読会 Chapter9

Transcript

1. Iceberg Definitive Guide輪読会 
 Chapter9
 Appache Flink

2. アジェンダ 
 Flinkの概要とIcebergと使う利点
 FlinkでのDDL
 Flinkでのデータ読み込み
 Flinkでのデータ書き込み
 まとめと所感
 
 

3. Apache Flinkとは 
 ストリーム処理、バッチ処理どちらも低レイテンシで実行できる 
 分散エンジン 
 他とストリーム処理できるサービスと比べてexactly-onceへの対応が早かったり 
 クラスタの設定が楽なのでストリームデータの処理ではよく使われているらしい 
 
 
 
 
 
 

4. Flinkアーキテクチャ 
 クラスタ全体を制御するJobManagerとJobManagerが割り振ったTaskを実際に遂行する 
 TaskManagerに役割を分離することで大規模なストリーム処理と分散処理を効率的に実行 
 
 
 
 
 
 

5. なぜFlinkとIcebergを一緒に使うのか 
 ストリーミングデータに対して様々な恩恵を得られるから 
 • トランザクションの一貫性を保証 
 • スキーマエボリューションが容易になる 
 • ログ生成からのレイテンシの向上 
 • 従来システムからの簡略化
 • インクリメンタルなデータ読み込みによる処理の高速化 
 参考:LINEがログパイプラインにFlink+Icebergを採用している事例 
 
 

6. 環境のセットアップ 
 Definitive Guideではローカルでセットアップする手順が記載されているが
 面倒なのでFlink+Hadoopカタログを触れるコンテナイメージを利用するのが
 おすすめ https://github.com/gordonmurray/apache_flink_and_iceberg 

7. FlinkでのIcebergテーブルの作成 
 Iceberg実行のランタイムがセットアップされていれば 
 簡単にIcebergのカタログを作れる 
 
 
 
 CREATE CATALOG <catalog_name> WITH ( 'type'='iceberg', 'catalog-type'=<values> <config_key>=<config_value> );
8. DBとテーブルの作成 
 テーブル作成時にWITHでコネクターの指定をしている以外は一般的なSQLで 書ける
 (WITH句内では他のIcebergのテーブルプロパティを指定できる) 
 
 
 CREATE DATABASE iceberg_db; USE iceberg_db; CREATE TABLE employee ( id BIGINT,role STRING,department STRING,salary FLOAT,region STRING ) WITH ( 'connector'='iceberg' );
9. Flinkでのパーティション作成 
 パーティションを作成したい時もWITHでコネクターの指定をしている
 以外は一般的なSQLで書ける
 ※ 隠れパーティション非対応 
 
 
 CREATE TABLE emp_partitioned_table ( id BIGINT, role STRING, ) PARTITIONED BY (role) WITH ( 'connector'='iceberg' );
10. ALTER TABLE 
 テーブルプロパティを変更したい時も特殊な操作は必要ない
 ALTER TABLE employee SET ('write.format.default'='avro'); ALTER TABLE employee RENAME TO emp_new; テーブル名の変更
 テーブルの書き込みフォーマットの変更 

11. バッチ読み込み 
 SELECT文の実行前にランタイムの実行方法をbatchに指定することでジョブ実 行時にバッチでデータを読み込むことができる
 
 
 
 SET execution.runtime-mode = batch; SELECT * FROM employee;
12. ストリーミング読み込み 
 ランタイムをstreamingに指定、更にOPTIONS以下の部分で
 SQLプランナーの実行計画に対して追加で情報を指定することで
 インクリメンタルなデータに対してのクエリも実現
 （※OPTIONSの部分をSQLヒントと呼ぶらしい） 
 
 
 
 SET execution.runtime-mode = streaming; SELECT * FROM employee /*+ OPTIONS('streaming'='true', 'monitor-interval'='1s')*/ ;
13. メタデータに対するアクセス 
 主要なメタデータに対するアクセスは以下の通り
 
 
 
 
 
 
 　　　　　　　　　　　　　　　　　　　　　※その他のメタデータに対するアクセスはリンクを参照inspecting-tables
 SELECT * FROM `catalog`.`database`.`table`$history; テーブル履歴へのアクセス 
 メタデータファイル履歴へのアクセス 
 スナップショットへのアクセス 
 SELECT * FROM `catalog`.`database`.`table`$metadata_log_entries; SELECT * FROM `catalog`.`database`.`table`$snapshots;
14. INSERT INTO 
 特別な処理は必要なく一般的なクエリでデータを挿入することができる
 バッチ処理、ストリーミング処理どちらでも実行可能
 INSERT INTO employee VALUES (1, 'Software Engineer', 'Engineering', 25000, 'NA'); 値を指定して挿入するケース 
 他テーブルから値を挿入するケース 
 INSERT INTO employee SELECT id, role from emp_new;
15. INSERT OVERWRITE 
 既にテーブルにあるデータを書き換えたいときに使用する
 IcebergのAtomicな操作のおかげでこのようなクエリを実行しても
 データの一貫性を保つことが可能
 (※バッチモードのみ対応)
 
 INSERT OVERWRITE employee VALUES (1, 'Software Tester', 'Engineering', 23000,'NA'); 指定された行を全て指定の値で上書きする 
 INSERT OVERWRITE employee PARTITION(department='Engineering') SELECT * FROM updated_emp_data WHERE department='Engineering'; 指定されたパーティション値のみを上書きする 

16. UPSERT 
 INSERTとUPDATEの組み合わせで以下のような挙動をする 
 （SparkやDremioのMERGE INTOと同じような操作） 
 • レコードがある場合→更新
 • レコードがない場合→新しいレコードを挿入 
 実行のためにはテーブルが以下の条件が満たされている必要がある 
 • テーブルスキーマでプライマリキーが指定されている 
 

17. UPSERT INTOの実例 
 UPSERTその1（テーブル作成時にオプション指定） 
 
 CREATE TABLE employee ( `id` INT UNIQUE, `role` STRING NOT NULL, `department` STRING NOT NULL, `salary` FLOAT, `region` STRING NOT NULL, PRIMARY KEY(`id`) NOT ENFORCED ) WITH ('format-version'='2', 'write.upsert.enabled'='true'); INSERT INTO employee VALUES (1, 'Director', 'Product', 33000, 'APAC'); UPSERTその2(INSERT操作の時にオプション指定) 
 INSERT INTO employee /*+ OPTIONS('upsert-enabled'='true') */ VALUES (3, 'Manager', 'Engineering', 26000, 'NA');
18. まとめと所感 
 まとめ
 ストリーミングデータを扱うような場合でもIcebergの恩恵を得られることがわかった 
 所感
 kafkaとか実際にストリーミングデータを処理してみないとここらへんの嬉しさわからないかも・・・