作者：董偉柯——騰訊云大數(shù)據(jù)產(chǎn)品中心高級工程師
概述
Apache Flink 是流式計(jì)算處理領(lǐng)域的領(lǐng)跑者。它憑借易用璃吧、高吞吐漓骚、低延遲饮怯、豐富的算子和原生狀態(tài)支持等優(yōu)勢闰歪，多方位領(lǐng)先同領(lǐng)域的開源競品。同樣地蓖墅，ClickHouse 是 OLAP 在線分析領(lǐng)域的一顆冉冉新星库倘，它擁有極其出眾的查詢性能，以及豐富的分析函數(shù)论矾，可以助力分析師靈活而迅速地挖掘海量數(shù)據(jù)的價(jià)值教翩。然而金無足赤，人無完人贪壳，每個(gè)組件都有自己擅長和不擅長的方面饱亿。為了實(shí)現(xiàn)構(gòu)造高性能實(shí)時(shí)數(shù)倉的目標(biāo)，接下來的文章會介紹如何將它們巧妙地結(jié)合起來闰靴，取長補(bǔ)短彪笼，最終實(shí)現(xiàn) “效率翻倍，快樂加倍” 的夢想蚂且。
影響海量數(shù)據(jù)查詢效率的因素
面對海量的業(yè)務(wù)數(shù)據(jù)配猫，有很多因素會顯著降低我們的端對端查詢效率（即數(shù)據(jù)從產(chǎn)生到最終消費(fèi)的全流程效率）。第一個(gè)因素是業(yè)務(wù)需求多樣膘掰，分析的鏈路繁雜章姓。例如我們有一個(gè)電商相關(guān)的數(shù)據(jù)庫，做增長分析的同學(xué)需要用它的數(shù)據(jù)來進(jìn)行用戶畫像识埋，以便實(shí)施精準(zhǔn)營銷，例如對新用戶零渐、流失用戶制定不同的營銷策略窒舟；而做風(fēng)控的同學(xué)則需要把數(shù)據(jù)接入機(jī)器學(xué)習(xí)模型，打擊 “羊毛黨” 和黑產(chǎn)用戶诵盼。
場景多 開發(fā)慢如果不加約束惠豺，大家都從原始數(shù)據(jù)源來讀取數(shù)據(jù)并分析银还，一方面對原始數(shù)據(jù)源的壓力非常大（同時(shí)承擔(dān)著各類業(yè)務(wù)的寫請求、讀請求）洁墙，另一方面分析鏈路難以復(fù)用蛹疯，最終會形成重復(fù)開發(fā)、各自為政的 “煙囪模式”热监，開發(fā)慢捺弦，運(yùn)維難。第二個(gè)因素是數(shù)據(jù)量龐大且多樣化孝扛，傳統(tǒng)的分析工具難以應(yīng)對：
海量數(shù)據(jù) 分析慢例如我們通常用 MySQL列吼、PostgreSQL、Oracle 等 OLTP（Online Transation Processing）數(shù)據(jù)庫來存放各類的交易流水等數(shù)據(jù)苦始，它們的優(yōu)點(diǎn)是支持高并發(fā)寞钥、低延遲讀寫，且對事務(wù)提供了完整的支持陌选。但是缺點(diǎn)是復(fù)雜查詢（聚合理郑、窗口、分組等）性能差咨油，且缺少數(shù)據(jù)分析常用的各類函數(shù)您炉，用作數(shù)據(jù)分析場景既低效，又不方便臼勉，還可能影響線上業(yè)務(wù)的穩(wěn)定性邻吭。因此，我們需要 OLAP（Online Analytical Processing）引擎構(gòu)造的數(shù)據(jù)倉庫（例如我們的 ClickHouse 就可以被用作 OLAP 引擎）宴霸，來滿足海量數(shù)據(jù)的復(fù)雜查詢能力囱晴。但它們通常并發(fā)讀寫的能力差，且事務(wù)支持不完備瓢谢，因此也不建議直接用作線上的唯一數(shù)據(jù)存取系統(tǒng)畸写。通常我們會使用 CDC（Change Data Capture，變更數(shù)據(jù)捕獲）工具氓扛，例如 Debezium枯芬、Canal 等，將 OLTP 數(shù)據(jù)庫的流水實(shí)時(shí)同步到 OLAP 系統(tǒng)以供分析采郎，這樣可以充分發(fā)揮兩套系統(tǒng)各自的優(yōu)勢千所。有些系統(tǒng)宣稱自己同時(shí)滿足 OLAP 和 OLTP 的特性，通常被稱為 HTAP（Hybrid Transactional/Analytical Processing）蒜埋。但實(shí)際上對于很多 HTAP 系統(tǒng)而言淫痰，往往只是在內(nèi)部將兩套系統(tǒng)的 CDC 數(shù)據(jù)同步的過程對用戶隱藏了，本質(zhì)上還是異構(gòu)的整份。此外待错，我們還會有一些流式數(shù)據(jù)籽孙，例如日志采集流、用戶點(diǎn)擊流等火俄，它們以流的形式源源不斷輸入犯建，且有很強(qiáng)的時(shí)效性，且順序在傳輸過程中很容易錯(cuò)亂瓜客，導(dǎo)致分析起來異常困難适瓦。第三個(gè)因素是數(shù)據(jù)源繁雜，組件和格式眾多忆家，接入起來耗時(shí)長：
數(shù)據(jù)源多樣 接入慢例如一個(gè)業(yè)務(wù)可能用 Kafka 來承接從 SDK 中上報(bào)的各類點(diǎn)擊流數(shù)據(jù)犹菇，又使用 HBase 等 KV 系統(tǒng)來存儲維表信息，還使用傳統(tǒng)的 MySQL芽卿、PostgreSQL 數(shù)據(jù)庫來保存精確的廣告點(diǎn)擊記錄和付費(fèi)訂單記錄等等揭芍。這些數(shù)據(jù)來自不同數(shù)據(jù)源，如何將它們規(guī)范化卸例，并合理地關(guān)聯(lián)在一起称杨，最終寫入到數(shù)倉中，也是一個(gè)難點(diǎn)和重點(diǎn)筷转。上述痛點(diǎn)和難點(diǎn)如果不加解決姑原，會嚴(yán)重拖慢分析師的效率：輕則影響拓客和營銷的效果，巨額的投入得不到轉(zhuǎn)化呜舒；重則會因?yàn)轱L(fēng)控系統(tǒng)失靈锭汛，對業(yè)務(wù)造成毀滅性打擊。因此我們必須通過系統(tǒng)化的體系構(gòu)建袭蝗，選擇合適的工具組件唤殴，逐一解決上述提到的效率困境。
實(shí)時(shí)數(shù)倉如何解決困境 提升效率
我們知道到腥，數(shù)據(jù)倉庫（Data Warehouse）是面向主題的朵逝、集成的一套系統(tǒng)。它遵循一系列的建模規(guī)范乡范，每層致力于解決不同的問題配名。下圖是一個(gè)典型的實(shí)時(shí)數(shù)倉架構(gòu)，它分為外部應(yīng)用晋辆、應(yīng)用層（ADS 或 APP）渠脉、匯總層（DWS）、明細(xì)層（DWD）和維度層（DIM）瓶佳，以及原始數(shù)據(jù)層（ODS）连舍。我們以電商行業(yè)的互聯(lián)網(wǎng)精準(zhǔn)營銷為例子，講解一下典型的實(shí)時(shí)數(shù)倉結(jié)構(gòu)涩哟。
分層的電商實(shí)時(shí)數(shù)倉實(shí)時(shí)數(shù)倉可以對接很多外部應(yīng)用索赏，例如用戶畫像、精準(zhǔn)推薦系統(tǒng)可以針對性地推送營銷活動贴彼，做到 “千人千面”潜腻，如下圖；BI 實(shí)時(shí)大屏可以將雙 11 大促的總體交易數(shù)據(jù)圖表化器仗；實(shí)時(shí)監(jiān)控則能讓運(yùn)維及時(shí)感知服務(wù)和主機(jī)運(yùn)行的風(fēng)險(xiǎn)融涣；風(fēng)控反欺詐則可以對業(yè)務(wù)運(yùn)行數(shù)據(jù)做展示，配合告警閾值系統(tǒng)精钮，可以實(shí)時(shí)監(jiān)控用戶行為和訂單量異常等風(fēng)險(xiǎn)因子等威鹿；即席查詢可以應(yīng)對分析師靈光一現(xiàn)的突發(fā)查詢需求。
用戶畫像的作用應(yīng)用層承擔(dān)了各類數(shù)據(jù)應(yīng)用的基礎(chǔ)設(shè)施轨香，例如 KV 存儲（HBase 等）忽你、數(shù)據(jù)庫服務(wù)（PostgreSQL 等）、OLAP 服務(wù)（ClickHouse 等）臂容、搜索服務(wù)（Elasticsearch 等）科雳，為上層的外部應(yīng)用提供支持。實(shí)時(shí)數(shù)倉的應(yīng)用層的數(shù)據(jù)來源于匯總層的各類多維主題寬表和匯總表脓杉，例如營銷匯總表糟秘、活動匯總表、商品匯總表等等球散。這樣尿赚，業(yè)務(wù)方只需要從不同的主題匯總表中讀取數(shù)據(jù)，無需再單獨(dú)對各類數(shù)據(jù)源做一整套分析鏈路蕉堰。如果寬表字段設(shè)計(jì)合理凌净，內(nèi)容足夠豐富的話，可以大大緩解開發(fā)慢的問題嘁灯。此外泻蚊，還可以導(dǎo)出數(shù)據(jù)接口，以供其他業(yè)務(wù)部門對接丑婿。匯總層的數(shù)據(jù)是從明細(xì)層和維度層關(guān)聯(lián)而來的性雄。由于 ClickHouse 等 OLAP 工具對關(guān)聯(lián)（JOIN）的性能較弱，因此我們可以采用 Flink 來實(shí)現(xiàn)流式數(shù)據(jù)的高效動態(tài) JOIN羹奉，并將實(shí)時(shí)的關(guān)聯(lián)數(shù)據(jù)定義為寬表并寫入 ClickHouse 以供應(yīng)用層后續(xù)分析查詢秒旋。由于 ClickHouse 等 OLAP 引擎的強(qiáng)勁性能，海量數(shù)據(jù)的分析慢等問題也可以得到一定程度的解決诀拭。明細(xì)層通常是經(jīng)過清洗過濾等規(guī)范化操作后的各類主題的事實(shí)表迁筛，例如訂單交易數(shù)據(jù)、瀏覽數(shù)據(jù)等耕挨，而 維度表 則保存了數(shù)據(jù)中 ID 與實(shí)際字段的映射關(guān)系细卧，以及其他變化緩慢但可以用來補(bǔ)充寬表的數(shù)據(jù)尉桩。原始層是對各類數(shù)據(jù)源的接入映射，例如業(yè)務(wù)方寫入 Kafka 的各類 Topics贪庙，以及 MySQL 等數(shù)據(jù)庫的 Binlog 等原始數(shù)據(jù)等等蜘犁。主要側(cè)重于數(shù)據(jù)攝取和簡單存儲，是上面各層的數(shù)據(jù)來源止邮。由于 Flink 等流計(jì)算平臺具有豐富的 Connector 以對接各種外部系統(tǒng)这橙，且提供了豐富的自定義接口，我們接入各類異構(gòu)的數(shù)據(jù)源也不成問題了导披。
Flink 是 ClickHouse 的最佳搭檔
ClickHouse 是一個(gè)用于聯(lián)機(jī)分析 (OLAP) 的列式數(shù)據(jù)庫管理系統(tǒng)（DBMS）屈扎，它采用了列式存儲、數(shù)據(jù)壓縮撩匕、多核并行鹰晨、向量引擎、分布式處理等技術(shù)滑沧，性能遙遙領(lǐng)先競品并村。例如我們給定一條數(shù)據(jù)分析時(shí)常見的分組和排序查詢語句：
<pre style="margin: 0.5em 0px; padding: 1em; box-sizing: border-box; list-style: inherit; color: rgb(204, 204, 204); background: rgb(80, 85, 107); border-radius: 3px; overflow: auto; font-family: Consolas, Monaco, "Andale Mono", "Ubuntu Mono", monospace; overflow-wrap: normal; text-align: left; word-break: normal; line-height: 1.5; tab-size: 4; hyphens: none; font-size: 14px;">SELECT Phone, Model, uniq(UID) AS u
FROM hits
WHERE Model != ''
GROUP BY Phone, Model
ORDER BY u DESC
LIMIT 10;</pre>
下圖是 1 億條數(shù)據(jù)量級下，ClickHouse 與多種常見數(shù)據(jù)處理系統(tǒng)的查詢速度對比圖（數(shù)字越小代表耗時(shí)越短滓技，性能越好）哩牍，可以看到 ClickHouse 的性能數(shù)據(jù)遙遙領(lǐng)先：
ClickHouse 與其他產(chǎn)品的性能對比盡管 ClickHouse 的數(shù)據(jù)分析能力如此高效，它還是有自己不擅長的地方：
不適合大量單條數(shù)據(jù)的寫請求令漂，因?yàn)閷懭脒^快時(shí)后臺合并不過來膝昆，會報(bào)
Too many parts等錯(cuò)誤不適合頻繁的數(shù)據(jù)更新和刪除操作，因?yàn)樽兏鼣?shù)據(jù)的聚合處理需要時(shí)間叠必，短期內(nèi)可能出現(xiàn)數(shù)據(jù)不準(zhǔn)的現(xiàn)象
不擅長做多張表的關(guān)聯(lián)（尤其是不同數(shù)據(jù)庫引擎的源表之間 JOIN）
生態(tài)支持弱荚孵，不適合多種不同數(shù)據(jù)源（特別是流式數(shù)據(jù)源）的接入
而這些 ClickHouse 不擅長做的事情，剛好是 Flink 最適合的領(lǐng)域：
Flink 流處理模型纬朝，天然適合處理大量單條的流數(shù)據(jù)收叶，吞吐量高，延遲低共苛。
Flink 的流 - 動態(tài)表映射模型（如下圖判没，來自 Flink 官網(wǎng)文檔），可以很好地應(yīng)對頻繁更新和刪除等記錄隅茎。還可以通過 Mini-Batch澄峰、Window 等優(yōu)化手段，極大地降低下游 ClickHouse 的處理壓力辟犀。
Flink 支持多種流和流的 JOIN俏竞，還支持流和維度表的 JOIN 操作。借助強(qiáng)大的狀態(tài)管理能力，可以做到精確的關(guān)聯(lián)語義魂毁。
Flink 的生態(tài)支持很豐富玻佩，常見的各類系統(tǒng)基本都有 Connector；而且通過標(biāo)準(zhǔn)化 Source 和 Sink API漱牵，也可以輕松實(shí)現(xiàn)自己的 Connector夺蛇。
Flink 的流表映射由于開源版 Flink 的應(yīng)用開發(fā)、調(diào)優(yōu)酣胀、監(jiān)控、運(yùn)維較為繁瑣娶聘，騰訊云為了解決這些痛點(diǎn)闻镶，推出了 流計(jì)算 Oceanus 產(chǎn)品。它是基于 Apache Flink 的實(shí)時(shí)化分析利器丸升，具備一站開發(fā)铆农、無縫連接、亞秒延時(shí)狡耻、低廉成本墩剖、安全穩(wěn)定等特點(diǎn)，致力于打造企業(yè)級實(shí)時(shí)大數(shù)據(jù)分析平臺夷狰。它提供了豐富的運(yùn)維開發(fā)岭皂、監(jiān)控告警、異常檢測能力沼头，融合了技術(shù)團(tuán)隊(duì)多年的 Flink 開發(fā)和運(yùn)維經(jīng)驗(yàn)爷绘，并持續(xù)為 Flink 內(nèi)核與生態(tài)貢獻(xiàn)力量。
騰訊云 Oceanus
打造穩(wěn)定可靠的實(shí)時(shí)數(shù)倉 v1.0
對于實(shí)時(shí)數(shù)倉的構(gòu)造方法狂芋，業(yè)界和學(xué)界有很多的探索和實(shí)踐薇宠。Lambda 架構(gòu)是一個(gè)成熟且廣為采用的方案谈飒。它分為離線批處理和實(shí)時(shí)流處理兩個(gè)子系統(tǒng)。
Lambda 架構(gòu)Lambda 架構(gòu)的優(yōu)點(diǎn)是離線和在線的數(shù)據(jù)源統(tǒng)一的前提下陶因，準(zhǔn)確性和容錯(cuò)性相對較好。例如實(shí)時(shí)流處理遇到了故障導(dǎo)致輸出的結(jié)果不夠精確時(shí)垂蜗，離線批處理系統(tǒng)可以把數(shù)據(jù)重跑一次楷扬，用更精確的數(shù)據(jù)來覆蓋它。但 Lambda 的缺點(diǎn)也很明顯：離線和實(shí)時(shí)采用獨(dú)立的平臺么抗，每個(gè)分析語句都需要重復(fù)寫兩套毅否，而且運(yùn)維人員也需要維護(hù)兩套以上的系統(tǒng)，成本高昂蝇刀。而且如果兩套系統(tǒng)的數(shù)據(jù)口徑不一致螟加，那么離線重算的結(jié)果，很可能和實(shí)時(shí)部分產(chǎn)生較大偏差，造成數(shù)據(jù)的 “跳變” 等異常捆探，反而失去了準(zhǔn)確性的優(yōu)勢然爆。
問題解決
當(dāng)我們推動這套實(shí)時(shí)數(shù)倉系統(tǒng)落地時(shí)，會遇到一些實(shí)踐的問題：
1. 如何將大量的流數(shù)據(jù)黍图，從 Flink 高效地寫入到 ClickHouse
我們知道曾雕，寫入 ClickHouse 時(shí)，既可以寫分布式表助被，也可以直接寫本地表剖张。寫分布式表的優(yōu)點(diǎn)在于不需要關(guān)注太多底層節(jié)點(diǎn)的細(xì)節(jié)，但是缺點(diǎn)也很明顯：由于數(shù)據(jù)需要被集中緩存和轉(zhuǎn)發(fā)揩环，會增加一定的延時(shí)搔弄，且會加重短期的數(shù)據(jù)不一致現(xiàn)象；此外丰滑，網(wǎng)絡(luò)方面壓力也較大顾犹，連接數(shù)和網(wǎng)絡(luò)流量都會有較大的上升。因此褒墨，如果我們要寫入的數(shù)據(jù)量很大的話炫刷，可以事先獲取各節(jié)點(diǎn)的連接地址，通過寫本地表的方式直接寫入各個(gè)節(jié)點(diǎn)郁妈。寫入本地表的方式可以有很多浑玛，例如為了防止節(jié)點(diǎn)之間出現(xiàn)較為嚴(yán)重的數(shù)據(jù)傾斜，可在每次寫入式隨機(jī)選擇一個(gè)節(jié)點(diǎn)圃庭；也可以采用輪詢的方式锄奢，每次寫入下一個(gè)不同節(jié)點(diǎn)。如果數(shù)據(jù)后續(xù)要按 Key 進(jìn)行聚合剧腻，那么還可以使用散列的方式拘央，將相同 Key 的數(shù)據(jù)寫到同一個(gè)節(jié)點(diǎn)，如下圖所示：
ClickHouse 寫本地表另外我們注意到书在，流式數(shù)據(jù)通常會包含大量的更新和刪除操作灰伟。為了支持頻繁變更的數(shù)據(jù)，可以將 Flink 的 Retract Stream（回撤流）儒旬、Upsert Stream（更新-插入流）等含有狀態(tài)標(biāo)記的數(shù)據(jù)流栏账，寫入到 ClickHouse 的 CollapsingMergeTree 引擎表中。例如下圖（來自 Flink 官方文檔[https://nightlies.apache.org/flink/flink-docs-master/docs/dev/table/concepts/dynamic_tables/]）中的 GROUP BY 查詢會隨著新數(shù)據(jù)的寫入栈源，對 user 這個(gè) Key 的統(tǒng)計(jì)值 cnt 進(jìn)行持續(xù)的更新挡爵。當(dāng) Mary 第二次出現(xiàn)時(shí)，cnt 統(tǒng)計(jì)值由 1 變成了 2甚垦，那么可以對舊記錄發(fā)一條 sign 為 -1 的消息茶鹃，和之前那條 sign 為 1 的記錄相互抵消涣雕。然后再寫入新的 cnt 為 2 的記錄。后續(xù) Mary 第三次出現(xiàn)時(shí)闭翩，執(zhí)行同樣的操作挣郭，即可保證寫入 ClickHouse 的最終統(tǒng)計(jì)數(shù)據(jù)是準(zhǔn)確的。
Flink 回撤流與 CollapsingMergeTree 的映射考慮到 ClickHouse 擅長大批量寫入的特點(diǎn)疗韵，還需要對 Flink ClickHouse Sink 增加攢批寫入的支持兑障，避免頻繁寫入造成的性能下降問題；此外還有故障重試策略蕉汪、Flink 與 ClickHouse 之間的 SQL 類型映射等需要關(guān)注的點(diǎn)流译。做好了這些，我們才可以得到一個(gè)性能肤无、穩(wěn)定性俱佳的 Flink ClickHouse Connector先蒋。
2. 如何評價(jià)數(shù)倉的質(zhì)量
當(dāng)我們完成了對數(shù)倉的初步建模和構(gòu)建后，數(shù)據(jù)質(zhì)量驗(yàn)證是決定數(shù)倉是否真正可用的關(guān)鍵環(huán)節(jié)宛渐，需要關(guān)注的有：一致性、準(zhǔn)確性眯搭、容錯(cuò)能力窥翩、鏈路延遲等。對于業(yè)務(wù)方和平臺方而言鳞仙，各自需要關(guān)注和保證不同的方面寇蚊，如下圖所示：
數(shù)據(jù)質(zhì)量保證業(yè)務(wù)方需要盡早制定并嚴(yán)格遵守?cái)?shù)據(jù)格式（Schema）的規(guī)范，因?yàn)?Flink SQL 和很多 Connector 是不支持運(yùn)行時(shí)動態(tài)修改表結(jié)構(gòu)的棍好。如果需要修改仗岸，則作業(yè)的狀態(tài)準(zhǔn)確度可能受到影響，甚至需要重新跑一遍所有數(shù)據(jù)借笙，代價(jià)很大扒怖。此外，對于離線和實(shí)時(shí)鏈路业稼，一定要保證數(shù)據(jù)源的口徑是一致的盗痒，不然會出現(xiàn)數(shù)據(jù) “跳變” 的問題。對于多分區(qū)的數(shù)據(jù)源（例如 Kafka 等）低散，還要保證應(yīng)當(dāng)將數(shù)據(jù)有序?qū)懭雴蝹€(gè)分區(qū)俯邓，否則亂序的數(shù)據(jù)會影響流處理的精度，造成結(jié)果錯(cuò)亂熔号。對于平臺提供方稽鞭，例如我們騰訊云流計(jì)算 Oceanus 而言，需要提供元數(shù)據(jù)管理等基本能力引镊，避免實(shí)際需要修改表結(jié)構(gòu)時(shí)朦蕴，難以追蹤多個(gè)不同作業(yè)之間的依賴關(guān)系篮条，造成錯(cuò)漏。同時(shí)平臺方需要集成 Flink 自帶的狀態(tài)快照功能梦重，精確保存作業(yè)的運(yùn)行時(shí)狀態(tài)兑燥，并在作業(yè)發(fā)生異常時(shí)使用最近的狀態(tài)來恢復(fù)作業(yè)，以最大程度地保證計(jì)算精度琴拧，減少誤差的存在降瞳。Flink 提供的 Watermark 機(jī)制也可以做到一定程度的亂序數(shù)據(jù)重整，對避免結(jié)果錯(cuò)亂也很有幫助蚓胸。如果從離線數(shù)倉或其他版本的數(shù)倉系統(tǒng)遷移到實(shí)時(shí)數(shù)倉時(shí)挣饥，一定要做雙寫驗(yàn)證，確保新系統(tǒng)的計(jì)算結(jié)果與原系統(tǒng)保持一致沛膳。另外可以使用例如 Apache Griffin（https://griffin.apache.org/） 等數(shù)據(jù)質(zhì)量監(jiān)控工具扔枫，實(shí)現(xiàn)數(shù)據(jù)異常的發(fā)現(xiàn)和告警。對于重點(diǎn)任務(wù)锹安，還可以通過熱備等方式短荐，避免單個(gè)任務(wù)由于外部不可控原因而發(fā)生崩潰時(shí)，引發(fā)輸出中斷等事故叹哭。實(shí)時(shí)數(shù)倉相比離線數(shù)倉平臺忍宋，對質(zhì)量的評價(jià)標(biāo)準(zhǔn)還多了一項(xiàng)：鏈路延遲。如果不能及時(shí)得到數(shù)據(jù)輸出的話风罩，這個(gè)數(shù)倉也是不合格的糠排。而影響鏈路時(shí)延有很多不同因素，例如：
影響時(shí)延的因素流計(jì)算 Oceanus 平臺為了確保及時(shí)發(fā)現(xiàn)上述問題超升，也做了很多優(yōu)化工作入宦。例如，我們支持 70+ 項(xiàng) Flink 核心指標(biāo)的訂閱室琢，用戶可在界面上查看數(shù)據(jù)源（Source）的實(shí)時(shí)數(shù)據(jù)攝入量乾闰、鏈路處理時(shí)延、JobManager 和 TaskManager 內(nèi)存各分區(qū)的用量研乒、GC 次數(shù)等指標(biāo)汹忠；也可以通過自定義 Reporter，將 Flink 監(jiān)控?cái)?shù)據(jù)導(dǎo)出到自己的 Prometheus 等外部系統(tǒng)來自助分析雹熬。在異常感知方面宽菜，流計(jì)算 Oceanus 平臺還可以自動診斷作業(yè)運(yùn)行期間的常見異常事件，例如 TaskManager CPU 占用率過高竿报、Full GC 事件過久铅乡、嚴(yán)重背壓、Pod 異常退出等烈菌，事件可以秒級送達(dá)阵幸，幫助用戶及時(shí)獲知并處理作業(yè)的異常情況花履。
持續(xù)演進(jìn)批流融合數(shù)倉 v2.0
在實(shí)時(shí)數(shù)倉領(lǐng)域，除了上述介紹的 Lambda 架構(gòu)外挚赊，還有一個(gè)比較流行的 Kappa 架構(gòu)诡壁，如圖所示：
Kappa 架構(gòu)相比 Lambda 架構(gòu)而言，Kappa 架構(gòu)將流和批融為一體荠割，不再分為兩條數(shù)據(jù)處理鏈路妹卿，數(shù)據(jù)統(tǒng)一經(jīng)過流式數(shù)據(jù)管道傳遞，清晰簡明蔑鹦，可以大幅降低開發(fā)和運(yùn)維成本夺克。但是它的缺點(diǎn)也很明顯：由于數(shù)據(jù)傳輸都需要經(jīng)過消息隊(duì)列等數(shù)據(jù)管道，為了保證作業(yè)崩潰或邏輯修改后可以隨時(shí)追溯歷史數(shù)據(jù)嚎朽，消息需要有很長的保存期铺纽。此外，由于各層之間沒有可落盤的文件存儲哟忍，難以直接分析中間層的數(shù)據(jù)狡门，通常需要啟動一個(gè)單獨(dú)的作業(yè)來導(dǎo)出數(shù)據(jù)才能分析，靈活度欠佳锅很。為了解決 Kappa 架構(gòu)的缺點(diǎn)融撞，我們引入新一代的表結(jié)構(gòu)：Apache Iceberg（https://iceberg.apache.org/），它的優(yōu)點(diǎn)如下：
Iceberg 優(yōu)點(diǎn)Iceberg 同時(shí)支持流式讀寫和批量讀寫粗蔚。對于實(shí)時(shí)鏈路而言，它可以在一定程度上代替 Kafka 等傳統(tǒng)流式數(shù)據(jù)管道饶火；對于需要讀取中間層的數(shù)據(jù)等特殊需求鹏控，又可以使用常見的批處理分析工具來直接分析 Iceberg 數(shù)據(jù)文件，非常便捷肤寝。如果流作業(yè)發(fā)生了崩潰等情形当辐，還可以借助它高效的歷史數(shù)據(jù)回溯能力，快速從特定的時(shí)間點(diǎn)開始重新消費(fèi)數(shù)據(jù)鲤看，如下圖：
使用 Flink 和 Iceberg 構(gòu)造實(shí)時(shí)數(shù)倉此外缘揪，它還支持超長的數(shù)據(jù)保存期，不必?fù)?dān)心數(shù)據(jù)保存期過短义桂，歷史數(shù)據(jù)被清理而難以回溯等傳統(tǒng)數(shù)據(jù)管道會遇到的難題找筝，因此 Iceberg 的引入，彌補(bǔ)了傳統(tǒng) Kappa 架構(gòu)的各類缺點(diǎn)慷吊。雖然 Iceberg 等組件的成熟度相對而言沒有那么高袖裕，但是已經(jīng)有不少大客戶在使用了。相信在不久的未來溉瓶，我們可以看到更多的類似的組件在生產(chǎn)環(huán)境的持續(xù)落地急鳄。
總結(jié)與展望
當(dāng)數(shù)據(jù)量總體較小時(shí)谤民，傳統(tǒng)的 OLTP 數(shù)據(jù)庫已經(jīng)可以初步滿足分析需求。但是隨著數(shù)據(jù)量的劇增疾宏，以及分析邏輯的復(fù)雜化张足，OLTP 數(shù)據(jù)庫已經(jīng)無法滿足需求時(shí)，業(yè)界逐步發(fā)展出了離線 OLAP 引擎和離線數(shù)倉等應(yīng)用技術(shù)坎藐。后來隨著大家對實(shí)時(shí)性的關(guān)注为牍，在離線數(shù)倉的基礎(chǔ)上又演進(jìn)出了 Lambda 實(shí)時(shí)數(shù)倉。為了解決 Lambda 數(shù)倉重復(fù)開發(fā)和運(yùn)維的繁雜等缺陷顺饮，Kappa 數(shù)倉也漸漸得到了采納吵聪。為了彌補(bǔ) Kappa 數(shù)倉的缺點(diǎn)，很多公司又設(shè)計(jì)了批流融合的數(shù)據(jù)格式兼雄，打造了融合的一體化數(shù)倉結(jié)構(gòu)吟逝。例如 Iceberg（https://iceberg.apache.org/）、Hudi（https://hudi.apache.org/） 為批處理的文件格式增加了流式讀寫支持赦肋；而 Pulsar（https://pulsar.apache.org/）块攒、Pravega（http://pravega.io/） 則為數(shù)據(jù)流增加了批處理所需的長期持久化存儲特性。
數(shù)倉的演進(jìn)流計(jì)算 Oceanus 產(chǎn)品在實(shí)時(shí)數(shù)倉領(lǐng)域長期深耕佃乘，也將批流融合數(shù)倉也作為重點(diǎn)發(fā)展方向囱井。在不久的將來趣避，我們會提供一整套的全面數(shù)倉構(gòu)造的解決方案庞呕，助力企業(yè)數(shù)據(jù)價(jià)值最大化，加速企業(yè)實(shí)時(shí)化數(shù)字化的建設(shè)進(jìn)程程帕，實(shí)現(xiàn)效率騰飛的夢想住练。
