NI
Uploaded byNTT DATA Technology & Innovation
1,438 views
ポスト・ラムダアーキテクチャの切り札? Apache Hudi（NTTデータ テクノロジーカンファレンス 2020 発表資料）
ポスト・ラムダアーキテクチャの切り札? Apache Hudi（NTTデータ テクノロジーカンファレンス 2020 発表資料）2020年10月16日（金）NTT ソフトウェアイノベーションセンタZhai Hongjie講演動画は、YouTubeチャンネル「NTT DATA Tech」にて公開中！https://www.youtube.com/watch?v=qMmJUjpff-8
Recommended
More Related Content
What's hot
Similar to ポスト・ラムダアーキテクチャの切り札? Apache Hudi（NTTデータ テクノロジーカンファレンス 2020 発表資料）
![[db tech showcase Tokyo 2014] L34: そのデータベース 5年後大丈夫ですか by 日本ヒューレット・パッカード株式会社 後藤宏](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fdbtstokyo2014l34hp5-141120233511-conversion-gate02-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[Japanese Content] Lance Riedel_The App Server, The Hive in Tokyo_Aug29](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2flanceriedelappserver-thehiveaug29-130920154018-phpapp01-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More from NTT DATA Technology & Innovation
ポスト・ラムダアーキテクチャの切り札? Apache Hudi（NTTデータ テクノロジーカンファレンス 2020 発表資料）
- 1.ポスト・ラムダアーキテクチャの切り札?ー Apache HudiNTTソフトウェアイノベーションセンタ2020年10月16日ZhaiHongjie, 研究員大村 圭, 主任研究員
- 2.
- 3.
- 4.
- 5.Apache Hudiの「Hudi」の由来はどれでしょう？A： 初期の名前Hoodieと同じ発音の単語B：Hadoop Upsert Delete and Incrementalの略C： Hive, Uber DEveloped略「HuDE」と同じ発音の単語D： 開発者の名前5【問題】Hudiは2016年からUberによって開発され、多様なワークロード（Read重視・Write重視）に対応できることが特徴です。https://github.com/apache/hudi
- 6.Apache Hudiの「Hudi」の由来はどれでしょう？A： 初期の名前Hoodieと同じ発音の単語B：Hadoop Upsert Delete and Incrementalの略C： Hive, Uber DEveloped略「HuDE」と同じ発音の単語D： 開発者の名前6【解答】名前の通り、Apache HudiはHDFS・S3などにデータのUpsert(Update& Insert)、Delete、Incremental Read機能を実現するソフトウェア
- 7.7Apache Hudiの概要Copy-On-Write(CoW) Table:Read-intensiveなワークロード向き(書き込みが重い)・新規データは既存の小さいParquetに統合するMerge-On-Read(MoR) Table: Write-intensiveなワークロード向き(読み出しが重い)・新規データはAvroで一時保存してからParquetに統合(Compaction)するApache Hudiストレージ（HDFS,S3, etc.）Data(Parquet,Avro)Spark APIHudiWriteClient APIHudiReadClient APISpark APIMetadata IndexDBCopy-On-Write TableMerge-On-Read Table・バッチReadバッチ分析向け・Incremental Readリアルタイム分析向け・Compaction・Rollbackデータを指定の時間まで巻き戻す・バッチUpsert・バッチDelete・ストリーミングWrite
- 8.8Apache Hudiの概要Copy-On-Write(CoW) Table:Read-intensiveなワークロード向き(書き込みが重い)・新規データは既存の小さいParquetに統合するMerge-On-Read(MoR) Table: Write-intensiveなワークロード向き(読み出しが重い)・新規データはAvroで一時保存してからParquetに統合(Compaction)するApache Hudiストレージ（HDFS,S3, etc.）Data(Parquet,Avro)Spark APIHudiWriteClient APIHudiReadClient APISpark APIMetadata IndexDBCopy-On-Write TableMerge-On-Read Table・バッチReadバッチ分析向け・Incremental Readリアルタイム分析向け・Compaction・Rollbackデータを指定の時間まで巻き戻す・バッチUpsert・バッチDelete・ストリーミングWrite
- 9.9Apache Hudiの概要Copy-On-Write(CoW) Table:Read-intensiveなワークロード向き(書き込みが重い)・新規データは既存の小さいParquetに統合するMerge-On-Read(MoR) Table: Write-intensiveなワークロード向き(読み出しが重い)・新規データはAvroで一時保存してからParquetに統合(Compaction)するApache Hudiストレージ（HDFS,S3, etc.）Data(Parquet,Avro)Spark APIHudiWriteClient APIHudiReadClient APISpark APIMetadata IndexDBCopy-On-Write TableMerge-On-Read Table・バッチReadバッチ分析向け・Incremental Readリアルタイム分析向け・Compaction・Rollbackデータを指定の時間まで巻き戻す・バッチUpsert・バッチDelete・ストリーミングWrite
- 10.10Apache Hudiの概要Apache Hudiストレージ（HDFS,S3,etc.）Data(Parquet,Avro)Spark APIHudiWriteClient APIHudiReadClient APISpark APIMatadata IndexDBCopy-On-Write TableMerge-On-Read Table・バッチReadバッチ分析向け・Incremental Readリアルタイム分析向け・Compaction・Rollbackデータを指定の時間まで巻き戻す・バッチUpsert・バッチDelete・ストリーミングWrite今回はApache Hudiのベンチマークからわかる得意分野・落し穴をピックアップして紹介※ベンチマークは0.5.2のものです。最新版では仕様が変更されている可能性があります
- 11.11１：テーブルタイプーMoR vs CoW01000020000300004000050000600007000080000CreateAppend Delete時間（ｍｓ）Upsert性能比較 (Partitionなし)COW MORAppendではMoRはCoWより19.4%速くなった遅い速い設計通りUpsert(Update & Insert)に関してはMoRのほうが速いただし例外も・・・Benchmark Environment:・Master: AWS m5.2xlarge * 1・Worker: AWS m5.2xlarge * 3・Hadoop 3.2.1 & Spark 2.4.5・Apache Hudi 0.5.2・Data: TPC-DS / store_sales
- 12.Upsert系の性能は１ファイルのサイズに左右される• ベンチマークのように初期データを細かく分割して書き込んだ直後、MoRとCoWは変わらない• 長期運用だと設計上MoRが速くなる12MoRは常に速いわけではない0200000400000600000800000100000012000001400000110 20 30 40 50 60 70 80 90 100時間（ｍｓ）Scale FactorInsert性能(Partitionあり) Insert(COW) with PartitionInsert(MOR) wth Partition7000007500008000008500009000009500001000000105000070 80データをPartitionで細かく分割すると、MoRは逆に1.5%遅くなった遅い速い
- 13.Upsert系の性能は１ファイルのサイズに左右される• ベンチマークのように初期データを細かく分割して書き込んだ直後、MoRとCoWは変わらない• 長期運用だと設計上MoRが速くなる13MoRは常に速いわけではないCopy-On-WriteTableMerge-On-Read TablePartitionありのテーブルA, B CA, B CE,FDPartitionありの場合、１ファイルサイズは小さいため、CoWのファイルコピーは速い。場合によってMoRのファイル内容書き換えより速くなる。DE,FUpdate: E→E'E',FCopy&UpdateE',FUpdate1KB 1KB 1KB 1KB1KB 1KB 1KB 1KB
- 14.Upsert系の性能は１ファイルのサイズに左右される• ベンチマークのように初期データを細かく分割して書き込んだ直後、MoRとCoWは変わらない• 長期運用だと設計上MoRが速くなる14MoRは常に速いわけではないCopy-On-WriteTableMerge-On-Read Table書き込みし続けるとA, B,G,H,I ..C,M,N,U,V,...A, B CE,F,K,L,X...D長期運用（書き込みし続ける）と、CoWのファイルは大きくなり、コピーも遅くなる。MoRは差分毎ファイル作っているため(*)、操作が速いD,O,Q,R,S,T ...E,FUpdate: E→E'E',FCopy&UpdateE',FUpdate120MB 120MB 120MB 120MBX Y Z 1KB ＊ Compactionされる前のデータに限る
- 15.ベンチマーク中予想外のことが発生していた・元データに対して、Hudiの書き込み量は２倍ぐらい・CoWに対するWriteで大量のSmall File(i.e. <120MB)が作られたー 小さいファイルが埋める前に新しいファイル作らないはず色々と調査した結果・・・15２：Hudiの隠し前提条件HudiはRecordサイズを1KBと仮定しているapproxRecordSize(Default = 1024)Recordサイズの平均値。データを既に書き込んだ場合データから計算することもできるが、それ以外はこの仮定値を使う。この設定はあらゆるところに影響が出る。
- 16.Hudiは１レコード1KB前提で設計されているー Incremental Readなどの機能を実現するために必要ーe.g. メタデータの設計、レコード書き込みアルゴリズム16書き込み量問題とHudiメタデータ生のデータ HudiメタデータIndexデータHudiのParquet・生のParquetに相当・Hudiはこの部分を1KBと仮定・今回のデータは約130bytes・Record毎に付与する・約130 bytes、サイズ調整不可・ファイル毎付与する・BloomFilterを使う場合のみ存在・データ量と関係なく422KB・サイズは調整可能- bloomFilterNumEntries- bloomFilterFPP1ファイル約100Kレコードの場合、最大メタデータ量：130𝑏𝑦𝑡𝑒𝑠 × 100,000 + 422𝐾𝐵 = 13.42𝑀𝐵Hudiの仮定通りRecordサイズ1KBなら、1ファイル約＋13.4%今回の場合は、＋100%の書き込み量となった
- 17.17ファイルサイズへの影響204060801001201400 500 10001500 2000 2500 3000 3500ファイルサイズ（MB）レコードサイズ(Byte)ファイルサイズとレコードサイズの関係Averge File Size(Copy On…ファイル最大サイズ(PARQUET_FILE_MAX_SIZE)4090140900 950 1000 1050 1100 11501024bytesレコードサイズが小さすぎると、出来上がったファイルもSmall File(i.e. <120MB)になる。小さいレコードは特に苦手レコードサイズ仮定値の手前でのファイルサイズが一番大きい
- 18.• 実はIncrement Queryの実装は全然速くない–MoRだと速いはずだが、まだ対応してない• スケーラビリティー重視のBulk Insertはパラメータによって遅くなることもある• ファイルDelete/Updateしても、ファイルにあるレコードの順番は変わらない• レコードサイズが時間によって大きく変動する場合、Small Fileができたり、巨大ファイルできたりするかもしれない18その他気づいたところ興味ある方はぜひAsk the Speakerで質問していただければ
- 19.19本講演のまとめ• データレイクへの期待が多様化しており、それを受けてApache Hudiが開発された•バッチ・ストリーミングを同じレイヤで処理するポスト・ラムダアーキテクチャ• 多様なワークロードに対応するテーブルタイプ（CoW・MoR）• まだ1.0に向けて開発中のため、対応しきれてないところもある• 現在はUber自身のユースケース(レコードサイズの仮定など)を優先している• 予想通りにならない時、隠し仕様あるかを一回調べましょう
- 20.
- 21.Hudiは１レコード1KB前提で設計されているー Incremental Readなどの機能を実現するために必要ーe.g. メタデータの設計、レコード書き込みアルゴリズム21Small File問題private void assignInserts(WorkloadProfile profile) {...long averageRecordSize =averageBytesPerRecord(metaClient.getActiveTimeline().getCommitTimeline().filterCompletedInstants(),config.getCopyOnWriteRecordSizeEstimate());List<SmallFile> smallFiles = getSmallFiles(partitionPath);...for (SmallFile smallFile : smallFiles) {long recordsToAppend =Math.min((config.getParquetMaxFileSize() -smallFile.sizeBytes) / averageRecordSize,totalUnassignedInserts);src/main/java/org/apache/hudi/table/HoodieCopyOnWriteTable.java,ファイルに書き込むレコード数はRecordサイズで算出される。実際のレコードは1KBより小さい場合、Small Fileになる初回書き込みなどレコードサイズ計算できない場合、Hudiの仮定値を使うファイルに書き込むべきレコード数を計算する関数
- 22.Insert： 一般的な書き込みBulk_insert：スケーラアップしやすいInsert22２：書き込みーInsert vsBulk_Insert00.0050.010.0150.020.0250.030.0350.040.0450.050 20 40 60 80 100 120bulk_insert vs insert性能比較Bulk Insert(COW)Bulk Insert(MOR)Insert(COW)Insert(MOR)ScaleFactor=50（約10GB）からInsertの効率が落ち始め、Bulk_Insertの効率は上がり続けるTime(ms)/RecordScale Factor遅い速い0.0040.00450.0050.00550.00640 60 80 100 120ただし、どんなサイズのデータでも速いわけではない小さいデータでは、Insertは圧倒的に速い
- 23.23Bulk InsertのターゲットデータサイズBulk Insertが速いのは一定のサイズまで–このサイズは、以下２つのパラメータに影響されるBulkInsertParallelism(Default =1500)ParquetFileMaxSize(Default =120MB)参考ページ：https://hudi.apache.org/docs/configurations.html予め用意するファイルの数。このファイルをすべて使い切る前に新しいファイル作る必要はない。１つのファイルの最大サイズ。このサイズを越えたファイルには新しいデータを書き込めない。初期状態のターゲットサイズは1500 × 120𝑀𝐵 = 175𝐺𝐵このサイズ越えたら、普通のInsertと変わらなくなる違うサイズを想定しているならば、BulkInsertParallelismを優先的に調整する（ParquetFileMaxSizeは副作用出るかもしれないので、調整は慎重に）