數據湖 iceberg 在小米的應用場景.pdf

《數據湖 iceberg 在小米的應用場景.pdf》由會員分享，可在線閱讀，更多相關《數據湖 iceberg 在小米的應用場景.pdf（28頁珍藏版）》請在三個皮匠報告上搜索。

1、演講人：李培殿小米數據湖研發負責人 2023 Iceberg 核心特性Iceberg 在小米的應用場景未來規劃Iceberg簡介Iceberg 是什么？Iceberg Is an open standard for tables with SQL behavior.-Ryan Blue事務性、Schema EvolutionAviod unpleasant suprisesAviod unpleasant suprisesFull Schema Evolution 字段類型提升 增加列 刪除列 重命名列 調整列順序字段類型提升：int-longfloat-doubledecimal(P,S)-

2、decimal(P,S),P P事務性事務性 原子性操作 多快照讀寫分離隱式分區-靈活的分區CREATE TABLE prod.db.sample(id bigint,data string,category string,ts timestamp)USING icebergPARTITIONED BY(bucket(16,id),days(ts),category)(bucket(16,id),days(ts),category)多種分區函數可供選擇隱式分區-與Hive分區的區別寫入寫入分區由 Iceberg 根據數據自動轉換生成，不需要用戶管理數據正確分區查詢查詢用戶查詢時不需要考慮分區的

3、物理結構目錄結構目錄結構分區的物理結構(目錄結構)和邏輯結構分離，便于 Partition Evolution行級更新(Format Version=2)Merge On Read 模式Iceberg 在小米的應用場景1.日志集成入湖特點：At Least Once 語義，數據可能重復按照上報時間分區，存在分區漂移問題Hive 的 Schema 和文件 Schema 不匹配Talos/KafkaSpark StreamingClientHive舊架構：舊架構：無無 SchemaSchema On Read1.日志集成入湖特點：Exactly Once 語義，數據不丟不重數據正確分區Schema

4、 On Write 保證數據正確性缺點：流程上的不規范（MQ 的 Schema 更新不及時）導致數據丟失Talos/KafkaFlink SQLClientIceberg新架構：新架構：Schema On ReadSchema On Write2.近實時數倉設備打點數據延遲上報問題數據延遲上報問題非常嚴重，延遲數據需要重新存儲和計算凌晨離線指標拆分，資源緊張，數據產出延遲風險大數據產出延遲風險大2.近實時數倉的優點隱式分區保證延遲數據正確分區延遲數據正確分區二級隱式分區，數據掃描量減少數據掃描量減少 10 倍倍，計算資源節約 25%近實時計算替換離線計算，降低產數延時風險（凌晨風險分攤至全天）

5、3.離線場景分區完備性校驗分區完備性校驗分區完備性校驗：校驗上游表分區何時完備，下游作業可以啟動離線寫入的表：離線寫入的表：無 SUCCESS 文件，無法使用校驗文件list partition 分區比較慢，無法校驗分區實時寫入的表：實時寫入的表：數據寫入即生成分區，無法校驗分區數據可能延遲到達 引入任務依賴，依賴上游任務 引入 iceberg watermark，校驗 watermark3.離線場景的優化:page column index+local sort ETL 鏈路中整個分區執行z-order 有較大的代價 local sort+page column index 進行有效的 da

6、ta skipping3.離線場景的優化:page column index+local sortbenchmark結果:查詢排序列，數據掃描量可大大減少查詢非排序列基本無優化3.隱式分區在離線場景的問題 dynamic overwrite+隱式分區帶來不確定性-期望覆蓋 date=20230101 分區，-但實際只覆蓋 date=20230101/hour=1 和-date=20230101/hour=2 分區，-不會覆蓋 date=20230101/hour=3 的分區insert overwrite catalog.db.table_testvalues(1,a,20230101,1),

7、(2,b,20230101,2)解決解決方案：使用方案：使用 static overwrite：set spark.sql.sources.partitionOverwriteMode=static;-覆蓋 date=20230101 下所有的分區的數據insert overwrite catalog.db.table_test partition(date=20230101)values(1,c,1),(2,d,2)字段名字段名類型類型是否是否分區分區idint否datastring否dateint是hourint是3.Spark timestamp 帶來的問題 IcebergSpark 3

8、.1Flink 1.14Trinotimestamptz 有時區timestamptimestamp_ltztimestamp with time zonetimestamp 無時區timestamptimestamptimestamp1.如何使用 Spark DDL 創建出 iceberg 的 timestamp 類型set spark.sql.iceberg.use-timestamp-without-timezone-in-new-tables=true;2.如何使用 Spark 讀取 iceberg timestamp 類型？set spark.sql.iceberg.handle-t

9、imestamp-without-timezone=true;4.Changelog 實時集成入湖Talos/Kafka特點：端到端的 Exactly Once 語義近實時，延遲3至5minIceberg 需要后臺定時執行 Compaction 任務 MySQLTiDBOracleFlink Streaming Flink Streaming format v24.Iceberg format v2 存在的問題1.主鍵唯一性約束主鍵唯一性約束沒有明確支持主鍵not enforced 解法：默認開啟 upsert,代價較高2.upsert 2.upsert 的支持的支持delete+insert

10、 來實現 upsert equality delete file 過多解法:增加 compaction 頻次 bloom filter 過濾無效的 delete 3.3.與與 compaction compaction 并發沖突并發沖突position delete file 寫入導致 compaction 頻繁失敗解法：忽略 flink 生成的 position delete file 校驗4.4.完整的完整的 changelog changelog 支持支持讀取 Iceberg changelog 有較大成本Changelog 存在不準確解法：依賴 flink 去重機制，但學習成本較高5.

11、列級數據加密數據加密依賴隱私集群（IDC 機房隔離），運維成本較高，存在數據孤島單層數據加密方案優點：列級數據加密性能影響極小對 KMS 壓力小Hive 升級 Iceberg方案1：使用 migrate 原地升級CALLcatalog_name.system.migrate(spark_catalog.db.sample,map(foo,bar)只支持 parquet、orc、avro 文件格式,不支持text、sequenceFile 等文件格式表下游消費離線作業必須是 Spark 2.4+，低版本 hive sql 和 spark 作業無法消費Hive 升級 Iceberg方案2：復用 Hive location優點：下游作業改動小遷移過程保留一份存儲缺點：Iceberg 特性受限、升級風險大失去事務性受限的 Schema Evolution Hive 升級 Iceberg方案3：創建新表Iceberg 使用 ZSTD 壓縮算法提高壓縮率，存儲成本降低 30%+歷史存量數據排序后轉儲至 IcebergIceberg 應用現狀表數量：14k+，日新增已超過，日新增已超過 Hive總數據量：30PB+未來規劃未來規劃物化視圖Changelog View數據上云演講人：李培殿小米數據湖研發負責人