基于Flink+ClickHouse打造輕量級點(diǎn)擊流實(shí)時數(shù)倉

前言

今天事情又比較多境氢，寫得言簡意賅一些，看官勿怪身腻。

Flink和ClickHouse分別是實(shí)時計(jì)算和（近實(shí)時）OLAP領(lǐng)域的翹楚产还，也是近些年非常火爆的開源框架嘀趟，很多大廠都在將兩者結(jié)合使用來構(gòu)建各種用途的實(shí)時平臺，效果很好愈诚。關(guān)于兩者的優(yōu)點(diǎn)就不再贅述她按，本文來簡單介紹筆者團(tuán)隊(duì)在點(diǎn)擊流實(shí)時數(shù)倉方面的一點(diǎn)實(shí)踐經(jīng)驗(yàn)牛隅。

點(diǎn)擊流及其維度建模

所謂點(diǎn)擊流（click stream），就是指用戶訪問網(wǎng)站酌泰、App等Web前端時在后端留下的軌跡數(shù)據(jù)媒佣，也是流量分析（traffic analysis）和用戶行為分析（user behavior analysis）的基礎(chǔ)。點(diǎn)擊流數(shù)據(jù)一般以訪問日志和埋點(diǎn)日志的形式存儲陵刹，其特點(diǎn)是量大默伍、維度豐富。以我們一個中等體量的普通電商平臺為例衰琐，每天產(chǎn)生200+GB也糊、十億條左右的原始日志，埋點(diǎn)事件100+個羡宙，涉及50+個維度狸剃。

按照Kimball的維度建模理論，點(diǎn)擊流數(shù)倉遵循典型的星形模型狗热，簡圖如下钞馁。

點(diǎn)擊流數(shù)倉分層設(shè)計(jì)

點(diǎn)擊流實(shí)時數(shù)倉的分層設(shè)計(jì)仍然可以借鑒傳統(tǒng)數(shù)倉的方案，以扁平為上策匿刮，盡量減少數(shù)據(jù)傳輸中途的延遲僧凰。簡圖如下。

DIM層：維度層熟丸，MySQL鏡像庫允悦，存儲所有維度數(shù)據(jù)。
ODS層：貼源層虑啤，原始數(shù)據(jù)由Flume直接進(jìn)入Kafka的對應(yīng)topic隙弛。
DWD層：明細(xì)層，通過Flink將Kafka中數(shù)據(jù)進(jìn)行必要的ETL與實(shí)時維度join操作狞山，形成規(guī)范的明細(xì)數(shù)據(jù)全闷，并寫回Kafka以便下游與其他業(yè)務(wù)使用。再通過Flink將明細(xì)數(shù)據(jù)分別寫入ClickHouse和Hive打成大寬表萍启，前者作為查詢與分析的核心总珠，后者作為備份和數(shù)據(jù)質(zhì)量保證（對數(shù)、補(bǔ)數(shù)等）勘纯。
DWS層：服務(wù)層局服，部分指標(biāo)通過Flink實(shí)時匯總至Redis，供大屏類業(yè)務(wù)使用驳遵。更多的指標(biāo)則通過ClickHouse物化視圖等機(jī)制周期性匯總淫奔，形成報表與頁面熱力圖。特別地堤结，部分明細(xì)數(shù)據(jù)也在此層開放唆迁，方便高級BI人員進(jìn)行漏斗鸭丛、留存、用戶路徑等靈活的ad-hoc查詢唐责，這些也是ClickHouse遠(yuǎn)超過其他OLAP引擎的強(qiáng)大之處鳞溉。

要點(diǎn)與注意事項(xiàng)

Flink實(shí)時維度關(guān)聯(lián)

Flink框架的異步I/O機(jī)制為用戶在流式作業(yè)中訪問外部存儲提供了很大的便利。針對我們的情況鼠哥，有以下三點(diǎn)需要注意：

使用異步MySQL客戶端熟菲，如Vert.x MySQL Client。
AsyncFunction內(nèi)添加內(nèi)存緩存（如Guava Cache朴恳、Caffeine等）抄罕，并設(shè)定合理的緩存驅(qū)逐機(jī)制，避免頻繁請求MySQL庫菜皂。
實(shí)時維度關(guān)聯(lián)僅適用于緩慢變化維度贞绵，如地理位置信息、商品及分類信息等恍飘≌ケ溃快速變化維度（如用戶信息）則不太適合打進(jìn)寬表，我們采用MySQL表引擎將快變維度表直接映射到ClickHouse中章母，而ClickHouse支持異構(gòu)查詢母蛛，也能夠支撐規(guī)模較小的維表join場景。未來則考慮使用MaterializedMySQL引擎（當(dāng)前仍未正式發(fā)布）將部分維度表通過binlog鏡像到ClickHouse乳怎。

Flink-ClickHouse Sink設(shè)計(jì)

可以通過JDBC（flink-connector-jdbc）方式來直接寫入ClickHouse彩郊，但靈活性欠佳。好在clickhouse-jdbc項(xiàng)目提供了適配ClickHouse集群的BalancedClickhouseDataSource組件蚪缀，我們基于它設(shè)計(jì)了Flink-ClickHouse Sink秫逝，要點(diǎn)有三：

寫入本地表，而非分布式表询枚，老生常談了违帆。
按數(shù)據(jù)批次大小以及批次間隔兩個條件控制寫入頻率，在part merge壓力和數(shù)據(jù)實(shí)時性兩方面取得平衡金蜀。目前我們采用10000條的批次大小與15秒的間隔刷后，只要滿足其一則觸發(fā)寫入。
BalancedClickhouseDataSource通過隨機(jī)路由保證了各ClickHouse實(shí)例的負(fù)載均衡渊抄，但是只是通過周期性ping來探活尝胆，并屏蔽掉當(dāng)前不能訪問的實(shí)例，而沒有故障轉(zhuǎn)移——亦即一旦試圖寫入已經(jīng)失敗的節(jié)點(diǎn)护桦，就會丟失數(shù)據(jù)含衔。為此我們設(shè)計(jì)了重試機(jī)制，重試次數(shù)和間隔均可配置，如果當(dāng)重試機(jī)會耗盡后仍然無法成功寫入抱慌，就將該批次數(shù)據(jù)轉(zhuǎn)存至配置好的路徑下逊桦，并報警要求及時檢查與回填眨猎。

當(dāng)前我們僅實(shí)現(xiàn)了DataStream API風(fēng)格的Flink-ClickHouse Sink抑进，隨著Flink作業(yè)SQL化的大潮，在未來還計(jì)劃實(shí)現(xiàn)SQL風(fēng)格的ClickHouse Sink睡陪，打磨健壯后會適時回饋給社區(qū)寺渗。另外，除了隨機(jī)路由兰迫，我們也計(jì)劃加入輪詢和sharding key hash等更靈活的路由方式信殊。

還有一點(diǎn)就是，ClickHouse并不支持事務(wù)汁果，所以也不必費(fèi)心考慮2PC Sink等保證exactly once語義的操作涡拘。如果Flink到ClickHouse的鏈路出現(xiàn)問題導(dǎo)致作業(yè)重啟，作業(yè)會直接從最新的位點(diǎn)（即Kafka的latest offset）開始消費(fèi)据德，丟失的數(shù)據(jù)再經(jīng)由Hive進(jìn)行回填即可鳄乏。

ClickHouse數(shù)據(jù)重平衡

ClickHouse集群擴(kuò)容之后，數(shù)據(jù)的重平衡（reshard）是一件麻煩事棘利，因?yàn)椴淮嬖陬愃艸DFS Balancer這種開箱即用的工具橱野。一種比較簡單粗暴的思路是修改ClickHouse配置文件中的shard weight，使新加入的shard多寫入數(shù)據(jù)善玫，直到所有節(jié)點(diǎn)近似平衡之后再調(diào)整回來水援。但是這會造成明顯的熱點(diǎn)問題，并且僅對直接寫入分布式表才有效茅郎，并不可取蜗元。

因此，我們采用了一種比較曲折的方法：將原表重命名系冗，在所有節(jié)點(diǎn)上建立與原表schema相同的新表奕扣，將實(shí)時數(shù)據(jù)寫入新表，同時用clickhouse-copier工具將歷史數(shù)據(jù)整體遷移到新表上來毕谴，再刪除原表成畦。當(dāng)然在遷移期間，被重平衡的表是無法提供服務(wù)的涝开，仍然不那么優(yōu)雅循帐。如果大佬們有更好的方案，歡迎交流舀武。

The End

關(guān)于Flink和ClickHouse等組件的配置拄养、調(diào)優(yōu)、延遲監(jiān)控、權(quán)限管理等知識瘪匿，筆者在之前的博客中多少講到過（傳送門：Flink文集跛梗、ClickHouse文集），不再廢話了棋弥。

民那晚安晚安核偿。