DataFunSummit 2022 數(shù)據(jù)湖論壇 數(shù)據(jù)湖技術(shù)論壇 (xiaoe-tech.com)
1. 美團增量數(shù)倉的探索和實踐
美團離線增量數(shù)據(jù)的探索和實踐
Hadoop沒有主鍵概念
hive沒有主鍵概念
- upsert(replace),delete,MVCC(Multi Version concurrency Control)受限
- 有主鍵的數(shù)據(jù)在hive中,無法形成增量數(shù)據(jù)生產(chǎn)鏈路,必須全量數(shù)據(jù)參與
HDFS文件不支持修改
- Btree+覆蓋寫的方式行不通
- 只能增量+存量進行Merge產(chǎn)生最終數(shù)據(jù)集
架構(gòu)選型-數(shù)據(jù)模型
- MOR架構(gòu) -- 降低生產(chǎn)成本:讀數(shù)據(jù)時產(chǎn)生冗余IO + 離線compact
- 支持主鍵
- 支持復(fù)雜MVCC,不支持事物:同步任務(wù)模型:有調(diào)度的亂時間序?qū)懭?/li>
- sharding策略:1.差異化讀寫并發(fā) 2.彈性伸縮:hash主鍵前綴 + range打散
架構(gòu)選型-HIDI
hadoop incremental dataformat implemtation
HFile + Bulkload + SnapshotinputFormat + 離線compact

HIDI架構(gòu)
美團實時增量數(shù)據(jù)的探索和實踐
從增量數(shù)倉到批流融合
批計算和流計算

成本與時效性的權(quán)衡
批流一體的數(shù)倉模型
- 開發(fā)模型融合 -- Flink
- 調(diào)度融合 1. 批到流 mini batch by kafka 2. 流到批 mini batch by hudi logfile
- 存儲融合 1. 流join 2. 點 + 批 + 增量 + 全量 + 離線 + 實時
- 批流應(yīng)能靈活切換
問題
- level0 和 level1 區(qū)別
- 為什么選取hudi
2. 實時數(shù)倉場景與架構(gòu)搭建實戰(zhàn)
數(shù)倉設(shè)計架構(gòu)演進

數(shù)倉架構(gòu)演進
實時數(shù)倉架構(gòu)

實時數(shù)倉架構(gòu)
是否需要實時計算
- 當前的業(yè)務(wù)場景是否需要
- 業(yè)務(wù)價值是什么
是否需要更輕的服務(wù)
- 更輕的運維
- 更好的彈性伸縮能力
- 更好的系統(tǒng)穩(wěn)定性
- 成本節(jié)省
- 安全
- 減一點配置
Amazon Analytics Serverless
Amazon Analytics Serverless 服務(wù)
無服務(wù)器的實時數(shù)倉架構(gòu)
還需要什么
Amazon Redshift 更強勁的云原生實時數(shù)倉架構(gòu)
Redshift 架構(gòu)
Redshift 實時數(shù)據(jù)攝入能力

實時數(shù)據(jù)攝取能力
Redshift 實時數(shù)倉
Redshift實時數(shù)倉與實時計算
Redshift實時數(shù)倉 + ML
3. Delta技術(shù)原理及其在EBAY的應(yīng)用
Lakehouse架構(gòu)

Lakehouse架構(gòu)
Delta Lake技術(shù)原理

Delta Lake技術(shù)原理
4. Icebege在微視實時場景的應(yīng)用
為何用Icebege
背景-數(shù)倉架構(gòu)

微視數(shù)倉架構(gòu)
- 實時數(shù)倉成本高
- 兩套計算存儲的數(shù)據(jù)一致性和成本問題
原因分析

原因分析
Icebege與傳統(tǒng)存儲對比

Icebege與傳統(tǒng)存儲對比
如何用Icebege
落地結(jié)構(gòu)

Icebege落地結(jié)構(gòu)
使用Icebege支持實時需求

使用Icebege支持實時需求
- 使用Icebege基礎(chǔ)核心模型建設(shè),為更多業(yè)務(wù)落地打基礎(chǔ)
- 成本降低超99%
數(shù)據(jù)回溯
- 新增指標
- 修改計算口徑
- 數(shù)據(jù)修復(fù)

數(shù)據(jù)回溯功能的實現(xiàn)
流轉(zhuǎn)批場景
流體一體
維護Icebege
數(shù)據(jù)維護
- 清除過期數(shù)據(jù)
- 清除過期快照
- 小文件合并 1. binpack策略 2. sort策略:例如:使用用戶ID做分組排序
- 元數(shù)據(jù)合并
- 清除孤兒文件
小文件合并原理

原理
問題
- 每次維表更新率在萬分之一在Icebege如何更新
- flink中的數(shù)據(jù)回溯功能是如何實現(xiàn)的
- Icebege底層和hive的區(qū)別,存儲格式
- iceberg小文件合并占用多少資源
- upsert
5. Juice FS在數(shù)據(jù)湖存儲架構(gòu)上的探索
大數(shù)據(jù)存儲架構(gòu)概覽
大數(shù)據(jù)存儲架構(gòu)的變遷

大數(shù)據(jù)存儲架構(gòu)的變遷
為什么要有數(shù)據(jù)湖
- 數(shù)據(jù)孤島
- 多樣的數(shù)據(jù)格式(結(jié)構(gòu)化,半結(jié)構(gòu)化,非結(jié)構(gòu)化)
- 分散的數(shù)據(jù)管理
- 存儲計算耦合,缺乏彈性
- 機器學(xué)習(xí)和深度學(xué)習(xí)
什么是數(shù)據(jù)湖
- A data lake is a system or repository of data stored in its natural / raw format ,usually object blobs or files
- 一個足夠便宜,可靠且能支撐海量數(shù)據(jù)的底層存儲(對象存儲)
- everything in one place
- 后置ETL
- 存儲計算分離,更加云原生
為什么要有湖倉一體
- 數(shù)據(jù)倉庫依然存在,只是后置了
- 數(shù)據(jù)倉庫的數(shù)據(jù)滯后性
- 機器學(xué)習(xí)和深度學(xué)習(xí)的問題依然存在
- 數(shù)據(jù)重復(fù)拷貝和重復(fù)ETL
- ACID事務(wù),多版本數(shù)據(jù),索引,零拷貝克隆等
什么是湖倉一體
- 開放統(tǒng)一的底層文件格式
- 開發(fā)的存儲層
- 開發(fā)的計算引擎集成
- 與深度學(xué)習(xí)框架的結(jié)合
Juice FS與Lakehouse
Juice FS簡介
簡介

簡介
架構(gòu)
Juice FS與HDFS,對象存儲的比較

Juice FS與HDFS,對象存儲的比較
Juice FS與數(shù)據(jù)湖生態(tài)
6. Icebege在小紅書的探索和實踐
APM日志入湖
數(shù)據(jù)平臺概覽

小紅書數(shù)據(jù)平臺概覽
日志數(shù)據(jù)入湖

APM case
- 動態(tài)分區(qū)流量極不均勻,keyby數(shù)據(jù)傾斜,不keyby小文件多
- 小文件多 1.distcp延遲 2. 下游讀取效率差
Evenpartionshuffle
- 引入shuffle
- 流量動態(tài)變化
日志數(shù)據(jù)入湖
- 異步:下游ETL任務(wù)已觸發(fā)
- 跨云讀寫,OI&OOM風(fēng)險
Cloud Native Table

日志數(shù)據(jù)入湖 - Cloud Native Table
S3FileIO

S3FileIO
下游集成

下游集成
日志數(shù)據(jù)入湖
實時湖分析探索
實時分析鏈路
流批一體存儲
IcebegeMergeTree
CDC實時入湖
Mysql全量入倉

Mysql全量入倉
CDC增量入倉

CDC增量入倉
CDC實時入湖
Exactly once語義

Exactly once語義
MoR
Deduper
Hidden Partition

Hidden Partition