2022年1月9日，StarRocks亮相Flink Forward Asia 2021大會(huì)開源解決方案專場(chǎng)，StarRocks解決方案架構(gòu)師謝寅做了題為“雙劍合璧：Flink+StarRocks構(gòu)建實(shí)時(shí)數(shù)倉解決方案”的主題演講。本文以主講嘉賓從技術(shù)方案的角度，為社區(qū)的小伙伴帶來最全、最詳細(xì)的文字版實(shí)錄回顧!

本文從以下5個(gè)方面介紹：

第一部分，實(shí)時(shí)數(shù)倉技術(shù)的發(fā)展趨勢(shì)和技術(shù)挑戰(zhàn)，以及為什么Flink+StarRocks能夠提供端到端的極速實(shí)時(shí)數(shù)倉體驗(yàn)。

第二部分，介紹什么是StarRocks，它有哪些技術(shù)特點(diǎn)，擅長(zhǎng)的場(chǎng)景是什么，以及為什么作為OLAP層的極速分析引擎，它能夠很好與Flink技術(shù)進(jìn)行整合。

第三部分，重點(diǎn)介紹聯(lián)合Flink和StarRocks兩大技術(shù)棧構(gòu)建實(shí)時(shí)數(shù)倉的方法論。

第四部分，介紹一些利用Flink和StarRocks構(gòu)建實(shí)時(shí)數(shù)倉的最佳實(shí)踐案例。

第五部分，展望了StarRocks在實(shí)時(shí)數(shù)倉方向以及Flink社區(qū)貢獻(xiàn)等方面的后續(xù)規(guī)劃。

1.實(shí)時(shí)數(shù)倉概述

隨著各行各業(yè)對(duì)數(shù)據(jù)越來越重視，實(shí)時(shí)計(jì)算技術(shù)也在不斷的演進(jìn)。從時(shí)效性上來講，對(duì)于小時(shí)級(jí)或者分鐘級(jí)的計(jì)算已經(jīng)不能滿足客戶業(yè)務(wù)的需要，需求逐漸從時(shí)窗驅(qū)動(dòng)，升級(jí)到事件驅(qū)動(dòng)，甚至每產(chǎn)生一條數(shù)據(jù)，都想盡快看到數(shù)據(jù)。ETL過程也從離線或者微批的ETL，變?yōu)镕link擅長(zhǎng)的實(shí)時(shí)流式處理。

數(shù)據(jù)源上，早先只能支持單一的數(shù)據(jù)源，整體的數(shù)據(jù)表現(xiàn)力較差。而當(dāng)下，人們不僅希望能對(duì)單一數(shù)據(jù)流進(jìn)行分析計(jì)算，還希望能聯(lián)合多個(gè)數(shù)據(jù)源進(jìn)行多流計(jì)算，為此不惜想盡一切辦法，來讓數(shù)據(jù)的表現(xiàn)力更加豐富。

從工程效率的角度上看，技術(shù)團(tuán)隊(duì)也逐漸意識(shí)到，工程代碼開發(fā)的成本高企不下，更希望能構(gòu)建自己的平臺(tái)化IDE工具，讓業(yè)務(wù)人員能基于其上直接進(jìn)行FlinkSQL的開發(fā)。在這些演進(jìn)的過程也逐漸浮現(xiàn)出一些技術(shù)難點(diǎn)亟待解決，比如：

·亂序數(shù)據(jù)怎么更好的處理?

·通過Watermark之類的手段，是讓過去的數(shù)據(jù)隨即失效，還是希望所有的明細(xì)數(shù)據(jù)都能入庫?

·多流Join到底應(yīng)該怎么做合適?

·維表是一次性加載進(jìn)來，還是放到外存儲(chǔ)做熱查詢，除此之外還有沒有其他的技術(shù)選擇?

·數(shù)據(jù)處理作業(yè)一旦重啟，怎么保證在恢復(fù)之后還能做到不丟不重的續(xù)接消費(fèi)?

·怎么才能提高整體的業(yè)務(wù)開發(fā)效率，保證業(yè)務(wù)上線時(shí)沒有業(yè)務(wù)中斷，更優(yōu)雅快捷的進(jìn)行業(yè)務(wù)邏輯迭代?

在此之外，還有一件事也是業(yè)務(wù)人員或平臺(tái)架構(gòu)師最關(guān)注的，那就是通過Flink這么強(qiáng)大的實(shí)時(shí)計(jì)算引擎，費(fèi)勁千辛萬苦好不容易把計(jì)算層效率從小時(shí)級(jí)或者分鐘級(jí)的延遲提升到了秒級(jí)，結(jié)果現(xiàn)有的OLAP產(chǎn)品拖了后腿，查詢耗費(fèi)了好幾分鐘，辜負(fù)了計(jì)算團(tuán)隊(duì)的大量心血。

以上種種，充分證明了極速OLAP+實(shí)時(shí)計(jì)算的重要性，以此我們就可以打造一套端到端的極速實(shí)時(shí)數(shù)倉解決方案，即所謂“雙劍合璧”!

談到數(shù)倉，目前業(yè)界落地較多的還是Lambda架構(gòu)，也就是離線數(shù)倉和實(shí)時(shí)數(shù)倉分開構(gòu)建。邏輯分層的形式，也基本形成了業(yè)界的共識(shí)。業(yè)務(wù)數(shù)據(jù)有的是RDBMS采集上來的，有的是日志采集上來的，有的是批量抽取上來的，有的是CDC或者流式寫上來的。原始操作層(ODS)基本都是保持?jǐn)?shù)據(jù)原貌，然后經(jīng)過維度擴(kuò)展、清洗過濾、轉(zhuǎn)換，構(gòu)建成明細(xì)層(DWD)。再往上層走，數(shù)據(jù)開始做輕度聚合，并有原子指標(biāo)出現(xiàn)。最后按照主題或者應(yīng)用的需要產(chǎn)出ADS層里的派生指標(biāo)或者衍生指標(biāo)。

企業(yè)構(gòu)建實(shí)時(shí)數(shù)倉，為了讓整體的邏輯清晰，通常情況下也會(huì)沿用這種分層模式，只不過受限于實(shí)時(shí)數(shù)據(jù)到達(dá)的先后情況以及業(yè)務(wù)需要，可能會(huì)有些層次的裁剪，不像離線數(shù)倉里那么豐富。中間的一些維度信息，可能會(huì)同時(shí)被離線數(shù)倉和實(shí)時(shí)數(shù)倉共享使用。最后將數(shù)據(jù)送入OLAP產(chǎn)品，供報(bào)表系統(tǒng)、接口或者Adhoc查詢所調(diào)用。

基于前面對(duì)數(shù)倉典型邏輯分層的探討，問題也隨之而來：

是否有一款OLAP產(chǎn)品能夠很好的和Flink結(jié)合，滿足持續(xù)的秒級(jí)的數(shù)據(jù)攝入和極速分析查詢能力?

答案是一定的，StarRocks的定位正是要提供極速分析查詢能力，來適應(yīng)各種各樣的OLAP場(chǎng)景。

2.StarRocks是什么

這是StarRocks的宏觀架構(gòu)圖。

從左邊我們可以看到常見的Kafka、分布式文件系統(tǒng)、傳統(tǒng)關(guān)系型數(shù)據(jù)庫，都可以作為StarRocks的數(shù)據(jù)源。

StarRocks提供了4種模型：

·如果業(yè)務(wù)場(chǎng)景只涉及數(shù)據(jù)的持續(xù)Append，可以選擇Duplicate明細(xì)模型，在其上可以實(shí)時(shí)構(gòu)建物化視圖加速DWS層查詢;

·如果業(yè)務(wù)場(chǎng)景不關(guān)注明細(xì)的下鉆，StarRocks還有Aggregate聚合模型表，相當(dāng)于數(shù)據(jù)直接秒級(jí)打入DWS層，滿足高并發(fā)的聚合指標(biāo)查詢;

·對(duì)于ODS層做業(yè)務(wù)庫數(shù)據(jù)還原時(shí)，若涉及到數(shù)據(jù)更新的場(chǎng)合，可以采用Unique模型，利用Flink的Append流Sink數(shù)據(jù)進(jìn)來，完成ODS數(shù)據(jù)去重和更新;

·另外，StarRocks最新2.0版本提供的PrimaryKey主鍵模型，比Unique模型查詢性能快3倍以上，內(nèi)置了OP字段來標(biāo)記Upsert/Delete操作，并且能夠很好的吻合Flink的Retract回撤流語義，聚合計(jì)算不必非要開窗轉(zhuǎn)為Append流來Sink，進(jìn)一步增強(qiáng)了FlinkSQL的表現(xiàn)力。

StarRocks還提供了邏輯View和物化視圖，提供了更豐富的建模能力。

在上圖的右側(cè)是StarRocks的物理架構(gòu)，整體還是非常簡(jiǎn)潔的，主要就是兩種角色：FE前端節(jié)點(diǎn)和BE后端節(jié)點(diǎn)。

·FE負(fù)責(zé)查詢規(guī)劃、元數(shù)據(jù)管理、集群高可用，并包含CBO優(yōu)化器，為分布式多表關(guān)聯(lián)和復(fù)雜Adhoc查詢提供最優(yōu)的執(zhí)行規(guī)劃。

·BE節(jié)點(diǎn)承載了列式存儲(chǔ)引擎和全面向量化的執(zhí)行引擎，保障在OLAP分析場(chǎng)景中提供極速查詢體驗(yàn)。

·對(duì)上層應(yīng)用提供MySQL連接協(xié)議，可以用MySQL客戶端輕松連入進(jìn)行開發(fā)和查詢，和主流BI工具有很好的兼容性，也可以服務(wù)于OLAP報(bào)表和API封裝。

3.StarRocks擅長(zhǎng)哪些場(chǎng)景

基于StarRocks的4種模型，可以提供明細(xì)查詢和聚合查詢，能夠應(yīng)對(duì)OLAP報(bào)表的上卷和下鉆，比如在廣告主報(bào)表場(chǎng)景應(yīng)對(duì)高并發(fā)點(diǎn)查詢。

StarRocks基于Roaring Bitmap提供了Bitmap數(shù)據(jù)結(jié)構(gòu)，并配套有集合計(jì)算函數(shù)，可以用于精確去重計(jì)算和用戶畫像的客群圈選業(yè)務(wù)。在實(shí)時(shí)方面，StarRocks可以用于支撐實(shí)時(shí)大屏看板、實(shí)時(shí)數(shù)倉，秒級(jí)延遲的呈現(xiàn)業(yè)務(wù)原貌和數(shù)倉指標(biāo)。

最后，基于CBO優(yōu)化器，StarRorcks在OLAP場(chǎng)景下有很好的多表關(guān)聯(lián)、子查詢嵌套等復(fù)雜查詢的性能，可以用于自助BI平臺(tái)、自助指標(biāo)平臺(tái)和即席數(shù)據(jù)探查等自助分析場(chǎng)景。

StarRocks能夠用于構(gòu)建實(shí)時(shí)數(shù)倉，得益于他的三種實(shí)時(shí)數(shù)據(jù)攝入能力：

·可以直接消費(fèi)Kafka的消息。

·可以借助Flink-connecor實(shí)現(xiàn)Exactly-once語義的流式數(shù)據(jù)攝入。

·另外，結(jié)合Flink-CDC和PrimaryKey模型，可以實(shí)現(xiàn)從TP庫Binlog實(shí)時(shí)同步Upsert和Delete等操作，更好的服務(wù)于ODS層業(yè)務(wù)庫還原。

利用Flink-Connector-StarRocks插件，可以實(shí)現(xiàn)從TP庫Binlog實(shí)時(shí)同步Upsert和Delete等操作，更好的服務(wù)于ODS層業(yè)務(wù)庫還原。配套的SMT(StarRocks Migration Tool)工具，可以自動(dòng)映射Flink中的TP庫Source和StarRocks庫的Sink建表語句，使得基于FlinkSQL的開發(fā)工作變得簡(jiǎn)單便捷。

另外，F(xiàn)link-Connector更重要的功能是提供了通用Sink能力，開發(fā)者把依賴加入后，無論是工程編碼還是FlinkSQL都可以輕松Add Sink，保障數(shù)據(jù)秒級(jí)導(dǎo)入時(shí)效性。

結(jié)合Flink的Checkpoint機(jī)制和StarRocks的導(dǎo)入事務(wù)標(biāo)簽，還可以保障不丟不重的精準(zhǔn)一次導(dǎo)入。

StarRocks的實(shí)時(shí)物化視圖構(gòu)建能力，結(jié)合Flink-Connector的持續(xù)增量數(shù)據(jù)導(dǎo)入，可以在流量類指標(biāo)計(jì)算的建模中，實(shí)現(xiàn)DWD明細(xì)數(shù)據(jù)導(dǎo)入完成的同時(shí)，DWS聚合指標(biāo)也同步增量構(gòu)建完成，極大提升聚合指標(biāo)產(chǎn)出效率，縮短分層ETL的旅程。

StarRocks提供的Replace_if_not_null能力比較有意思，正如語義所述，只要插入的數(shù)據(jù)不是null，那么就可以去替換數(shù)據(jù)。

如圖所示，右側(cè)是個(gè)建表示例，里面維度列為日期和Uid，其余3列中SRC表示數(shù)據(jù)源，另外帶了v1，v2兩個(gè)Metric;

通過2個(gè)Insert語句我們可以看到，來自2個(gè)Kafka主題的數(shù)據(jù)源的數(shù)據(jù)，輕松的實(shí)現(xiàn)了同時(shí)寫入一張表的不同列。因此，這個(gè)功能提供了兩種實(shí)時(shí)數(shù)倉能力：

1)Join on Load，也就是在導(dǎo)入的過程中，基于StarRocks來實(shí)現(xiàn)流式Join。

2)部分列更新能力。

StarRocks為了支持更好的Upsert/Delete，提供了PrimaryKey表模型。

如上圖所示，最左側(cè)是經(jīng)典的LSM模型，也就是Merge-on-Read的形式。這種模型寫入時(shí)不用去判斷既有鍵位，對(duì)寫友好，但讀取時(shí)需要Merge合并，所以對(duì)讀取數(shù)據(jù)不友好。

而最右側(cè)是Copy-on-Write的模型，典型的產(chǎn)品就是DeltaLake。這種模型和LSM正好相反，有比較好的讀效率，但是對(duì)于寫入不是很友好。

比較平衡讀取和寫入的，就是上圖中間的兩種Record級(jí)別沖突檢查的模型，Kudu的Write Delta和StarRocks的Delete+Insert模型。

由于維護(hù)了內(nèi)存表，PrimaryKey模型更適合冷熱特征明顯的場(chǎng)合，對(duì)熱數(shù)據(jù)頻繁的更新和刪除更友好;

另外非常適合PrimaryKey較少的表(如用戶畫像的寬表)，雖然列很多，但是主鍵其實(shí)只有UUID這種字段。

StarRocks早期的Unique模型就是采用了最左邊的LSM模型，因此查詢效率較差，并且對(duì)于Delete不友好，結(jié)合Flink開發(fā)應(yīng)用時(shí)，只能使用Append流進(jìn)行Sink。

StarRocks 2.0版本中新增加的PrimaryKey模型，提供了軟刪除字段，通過在內(nèi)存中維護(hù)最新數(shù)據(jù)，使得查詢時(shí)避免了Merge的過程，從而極大提升了查詢性能，并且既可以使用Append流也可以使用Retract流進(jìn)行Sink，豐富了與Flink結(jié)合時(shí)的應(yīng)用場(chǎng)景。

4.構(gòu)建實(shí)時(shí)數(shù)倉的具體方法

眾所周知，在按照邏輯分層自下而上的構(gòu)建實(shí)時(shí)數(shù)倉時(shí)，多流Join是有一定的技術(shù)門檻的。傳統(tǒng)的實(shí)時(shí)計(jì)算引擎如Storm、Spark Streaming在這方面做的都不是很好。而Flink其實(shí)提供了很多通用的解決方法，如：

·基于MapStat做狀態(tài)計(jì)算，或者BroadcastStat將維度緩存廣播出去;

·用Flink關(guān)聯(lián)外部熱存儲(chǔ)，如HBase/Redis等;

·一些相對(duì)穩(wěn)定、更新頻率低的維度數(shù)據(jù)或者碼表數(shù)據(jù)，可以利用RichFlatMapFunc的Open方法，在啟動(dòng)時(shí)就全部加裝到內(nèi)存里;

不限于以上這些，其實(shí)Flink已經(jīng)在維度擴(kuò)展上，給了開發(fā)者很多可以落地的選擇。然而有了StarRocks，我們會(huì)有更多的想象空間。

比如利用前面介紹的Replace_if_not_null的能力，開發(fā)者可以實(shí)現(xiàn)多個(gè)數(shù)據(jù)源稀疏寫入寬表的不同列，來實(shí)現(xiàn)Join-on-Load的效果。

另外StarRocks強(qiáng)悍的CBO優(yōu)化器在多表關(guān)聯(lián)查詢能力方面也表現(xiàn)優(yōu)異，如果數(shù)據(jù)量不大或者在查詢并發(fā)不高的場(chǎng)景，甚至可以把Join的邏輯下推到OLAP層來做，這樣可以釋放掉Flink上的一些構(gòu)建負(fù)荷，讓Flink專注于清洗和穩(wěn)定的數(shù)據(jù)導(dǎo)入，而多表關(guān)聯(lián)和復(fù)雜查詢等業(yè)務(wù)邏輯在StarRocks上進(jìn)行。

不僅如此，還可以結(jié)合Join-on-Load和Join on StarRocks的兩種形式，也就是稀疏寫入有限張表，通過表之間做Colocation join策略，保證有限的表之間數(shù)據(jù)分布一致，做Join的時(shí)候沒有節(jié)點(diǎn)間Shuffle，在上層構(gòu)建邏輯View面向查詢。

雙劍方案1.微批調(diào)度

Flink清洗導(dǎo)入Kafka的日志或者用Flink-CDC-StarRocks讀取MySQL Binlog導(dǎo)入StarRocks，ETL過程中埋入批次處理時(shí)間，采用外圍調(diào)度系統(tǒng)，基于批次處理時(shí)間篩選數(shù)據(jù)，做分鐘級(jí)微批調(diào)度，向上構(gòu)建邏輯分層。

這種方案的主要特點(diǎn)是：StarRocks作為ETL的Source和Sink，計(jì)算邏輯在StarRocks側(cè)，適用于分鐘級(jí)延遲，數(shù)據(jù)體量不大的場(chǎng)景。

雙劍方案2.Flink增量構(gòu)建

實(shí)時(shí)消息流通過Kafka接?，采用Flink進(jìn)?流式ETL、多流Join、增量聚合等，在內(nèi)存中完成分層構(gòu)建，然后將相應(yīng)的數(shù)據(jù)，層對(duì)層的通過Flink-connector寫出到StarRocks對(duì)應(yīng)表內(nèi)。各層按需面向下游提供OLAP查詢能力。

該方案的主要特點(diǎn)是：計(jì)算邏輯在Flink側(cè)，適用于需要前導(dǎo)做較重ETL的場(chǎng)景，StarRocks不參與ETL，只承載OLAP查詢，應(yīng)對(duì)較高QPS查詢負(fù)荷。

雙劍方案3.StarRocksView視圖

Flink清洗導(dǎo)入Kafka的日志或者用Flink-CDC-StarRocks工具讀取MySQL Binlog導(dǎo)入StarRocks;根據(jù)需要選用明細(xì)、聚合、更新、主鍵各種模型，只物理落地ODS和DIM層，向上采用View視圖;利用StarRocks向量化極速查詢和CBO優(yōu)化器滿足多表關(guān)聯(lián)、嵌套子查詢等復(fù)雜SQL，查詢時(shí)現(xiàn)場(chǎng)計(jì)算指標(biāo)結(jié)果，保證指標(biāo)上卷和下鉆高度同源一致。

該方案主要特點(diǎn)是：計(jì)算邏輯在StarRocks側(cè)(現(xiàn)場(chǎng)查詢)，適用于業(yè)務(wù)庫高頻數(shù)據(jù)更新的場(chǎng)景，實(shí)體數(shù)據(jù)只在ODS或DWD存儲(chǔ)(未來StarRocks提供多表Materialized Views，將會(huì)進(jìn)一步提升查詢性能)。

5.最佳實(shí)踐案例

前面我們介紹了一些聯(lián)合Flink和StarRocks構(gòu)建實(shí)時(shí)數(shù)倉的幾種方法論，下面我們來看4個(gè)實(shí)際的客戶案例。

汽車之家目前在智能推薦的效果分析、物料點(diǎn)擊、曝光、計(jì)算點(diǎn)擊率、流量寬表等場(chǎng)景，對(duì)實(shí)時(shí)分析的需求日益強(qiáng)烈。經(jīng)過多輪的探索，最終選定StarRocks作為實(shí)時(shí)OLAP分析引擎，實(shí)現(xiàn)了對(duì)數(shù)據(jù)的秒級(jí)實(shí)時(shí)分析。

在數(shù)據(jù)處理流程上，SQLServer、MySQL、TiDB等數(shù)據(jù)源，通過CDC打入多個(gè)Topic主題，用FlinkSQL進(jìn)行ETL清洗和聚合計(jì)算，然后通過Flink-Connector導(dǎo)入StarRocks。早期選擇的Unique表模型，由于業(yè)務(wù)有很多Delete操作，而Merge-on-Read的模型對(duì)Delete支持不好，如果只做Update而不做Delete，會(huì)造成結(jié)果數(shù)據(jù)比業(yè)務(wù)庫多的問題。

最新的PrimaryKey模型支持了OP字段(更新/刪除操作)，改為PrimaryKey模型后，數(shù)據(jù)結(jié)果與上游業(yè)務(wù)完全一致。

上圖右側(cè)是在硬件配置6x 48c 256G、數(shù)據(jù)量3500W+、有持續(xù)寫入情況下，22個(gè)SQL用例的測(cè)試情況，查詢性能也比Unique模型有大幅提升。

在合理的選型和建模之后，汽車之家在實(shí)時(shí)平臺(tái)IDE上也做了很多工作，開發(fā)運(yùn)維人員可以在頁面里進(jìn)行DDL建表，F(xiàn)linkSQL開發(fā)，作業(yè)的起停、上線管理等工作。結(jié)合Flink-Connecotor，可以直接通過FlinkSQL將加工后的數(shù)據(jù)導(dǎo)入StarRocks，完成端到端的實(shí)時(shí)平臺(tái)集成。

另外，利用StarRocks提供的200多個(gè)監(jiān)控Metric，汽車之家用Prometheus和Grafana等組件做了充分的可視化監(jiān)控，即時(shí)查看集群的統(tǒng)計(jì)指標(biāo)，把握集群的健康狀態(tài)。

第2個(gè)案例，順豐科技的運(yùn)單分析場(chǎng)景實(shí)踐。在2021年雙11大促活動(dòng)中，運(yùn)單分析場(chǎng)景應(yīng)對(duì)了15w TPS消息體量的實(shí)時(shí)數(shù)據(jù)導(dǎo)入和更新。整體的處理流程如圖所示，多個(gè)業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)源打到幾個(gè)Source Kafka，用Flink來對(duì)數(shù)據(jù)進(jìn)行加工、字段補(bǔ)充、重新組織，然后整理后的數(shù)據(jù)打到若干個(gè)Sink Kafka主題，最后利用前面介紹的Join-on-Load的形式，將多個(gè)數(shù)據(jù)源的數(shù)據(jù)，稀疏的寫入寬表的不同列，以此來實(shí)現(xiàn)寬表拼齊的過程。

在具體使用上，順豐科技將運(yùn)單的數(shù)據(jù)根據(jù)更新的頻度，劃分為了2張寬表，按照相同的數(shù)據(jù)分布做成Colocation組，保證Join的時(shí)候沒有額外的節(jié)點(diǎn)Shuffle。一張表涉及的更新較少，命名為公表。另一張表涉及的更新較多，命名為私表。

每個(gè)子表都利用了Replace_if_not_null的部分列更新的能力，合理的設(shè)計(jì)了維度和聚合指標(biāo)，并引入了Bloom Filter索引加速篩選的效率，用日期做范圍分區(qū)，用訂單號(hào)做數(shù)據(jù)分布，配置了動(dòng)態(tài)分區(qū)，自動(dòng)淘汰冷數(shù)據(jù)。對(duì)外通過邏輯View的形式關(guān)聯(lián)成一張寬表，底層是以現(xiàn)場(chǎng)Join的形式，整體面向業(yè)務(wù)提供查詢服務(wù)。

第3個(gè)案例是來自多點(diǎn)DMALL的實(shí)時(shí)數(shù)倉實(shí)踐。實(shí)時(shí)更新場(chǎng)景主要對(duì)實(shí)時(shí)監(jiān)控經(jīng)營(yíng)的各項(xiàng)指標(biāo)進(jìn)行分析，如當(dāng)前時(shí)間段內(nèi)的GMV、下單數(shù)量、妥投數(shù)量、指標(biāo)達(dá)成、對(duì)比、環(huán)比等指標(biāo)分析，為客戶的經(jīng)營(yíng)決策提供更具時(shí)效性的參考依據(jù)。

早期，針對(duì)數(shù)據(jù)為實(shí)時(shí)(秒級(jí))更新的場(chǎng)景，主要使用Impala on Kudu引擎，采用Lambda架構(gòu)，基于相同的主鍵，將流式的預(yù)計(jì)算的結(jié)果數(shù)據(jù)、批計(jì)算的結(jié)果數(shù)據(jù)，基于相同的主鍵進(jìn)行Merge。

這個(gè)Case早期的架構(gòu)如左圖所示，ODS、DWD、DWS等分層在Kafka里承載，ADS層在Kudu/MySQL里，維表放在HBase里，采用Flink查詢外表熱存儲(chǔ)的形式實(shí)現(xiàn)維度數(shù)據(jù)和事實(shí)消息的關(guān)聯(lián)。如右圖所示，經(jīng)過梳理和改造，順豐科技將DWD到DWS的聚合處理從Flink下沉到OLAP層，用StarRocks替換了Kudu，簡(jiǎn)化了預(yù)聚合鏈路，提升了開發(fā)效率。

第4個(gè)案例是來自一個(gè)某車聯(lián)網(wǎng)企業(yè)的Fusion數(shù)倉建設(shè)。隨著新能源汽車的普及，車聯(lián)網(wǎng)IOT數(shù)據(jù)的實(shí)時(shí)接入分析的需求也越來越多。

業(yè)務(wù)邏輯如左圖所示，傳感器上報(bào)的儀表、空調(diào)、發(fā)動(dòng)機(jī)、整車控制器、電池電壓、電池溫度等1000+傳感器Metric要通過Flink做實(shí)時(shí)ETL清洗，同時(shí)要完成功能主題實(shí)時(shí)分揀、數(shù)據(jù)質(zhì)量實(shí)時(shí)報(bào)告，最終滿足于時(shí)序數(shù)據(jù)綜合分析和可視化展示。技術(shù)上，大量采用Flink.Jar的工程代碼開發(fā)，對(duì)于某些碼值還涉及到Flink多流Join及狀態(tài)計(jì)算。流量類的主題，采用StarRocks的增量聚合模型出聚合指標(biāo)。也利用FlinkSQL對(duì)于運(yùn)營(yíng)分析類業(yè)務(wù)進(jìn)行了實(shí)時(shí)數(shù)倉構(gòu)建，將ADS層結(jié)果導(dǎo)入StarRocks供統(tǒng)一接口查詢。

整體上也是按照Lambda模型設(shè)計(jì)的，F(xiàn)Link清洗整合后的合規(guī)數(shù)據(jù)，會(huì)通過落盤程序沉降到HDFS，用于持久存儲(chǔ)、離線數(shù)倉進(jìn)行跑批及更復(fù)雜的模型訓(xùn)練，最終Hive的結(jié)果數(shù)據(jù)也會(huì)送到StarRocks供接口查詢使用。

數(shù)據(jù)邏輯設(shè)計(jì)如右圖所示，上面為離線數(shù)倉，下面為實(shí)時(shí)數(shù)倉邏輯分層。

可以看到實(shí)時(shí)清洗后的DWD層數(shù)據(jù)會(huì)成為離線數(shù)倉的ODS層，而離線數(shù)倉構(gòu)建好的一些相對(duì)固定的維表數(shù)據(jù)，也會(huì)用于實(shí)時(shí)數(shù)倉的流式維度擴(kuò)展。實(shí)時(shí)數(shù)倉的邏輯分層相較于離線數(shù)倉更為簡(jiǎn)約，DWD明細(xì)層會(huì)存在于獨(dú)立的Kafka或者在Flink內(nèi)存中，DWS層在FlinkSQL聚合完成后就直接下沉到StarRocks了。

這里其實(shí)是進(jìn)行了兩次聚合，在Flink里進(jìn)行了秒級(jí)的聚合，而StarRocks里的時(shí)間信息相關(guān)的維度列是到分鐘或者15分鐘的，利用StarRocks的聚合模型，將Flink匯聚的5-10s的聚合結(jié)果，再次匯聚到分鐘級(jí)鍵位。這樣設(shè)計(jì)有兩個(gè)好處，第一，能夠減少LSM模型的Version版本，提升查詢性能;第二，抽稀到分鐘級(jí)后，更便于可視化展示，降低了前端取數(shù)的壓力。

6.實(shí)時(shí)即未來，StarRocks后續(xù)規(guī)劃

關(guān)于PrimaryKey模型，后續(xù)版本即將支持部分列更新，進(jìn)一步豐富TP業(yè)務(wù)庫還原的能力;并在PrimaryKey模型上支持Bloom Filter、Bitmap等索引能力，進(jìn)一步提升數(shù)據(jù)查詢性能。

資源隔離方面，后續(xù)StarRocks會(huì)發(fā)布自適應(yīng)內(nèi)存、CPU分配能力，客戶不再需要手動(dòng)調(diào)整配置參數(shù);未來也會(huì)支持多租戶資源隔離的Feature。

對(duì)于Apache Flink項(xiàng)目的貢獻(xiàn)方面，當(dāng)前Flink-Connector-StarRocks還只具備Sink能力，后續(xù)會(huì)在Source方面提供支撐，屆時(shí)用戶可以通過Flink分布式讀取StarRocks數(shù)據(jù)，用FlinkSQL做跑批任務(wù)。

另外，在CDC適配上，后續(xù)也會(huì)提供Oracle/PostgreSQL等更豐富的TP庫的DDL自動(dòng)映射能力，適應(yīng)更多CDC應(yīng)用。

在云原生時(shí)代，StarRocks已經(jīng)開始了積極探索和實(shí)踐，很快就會(huì)提供存儲(chǔ)計(jì)算分離、異地容災(zāi)等能力，為客戶提供彈性、可靠的OLAP層查詢分析體驗(yàn)。

以上就是本次分享的全部?jī)?nèi)容。實(shí)時(shí)即未來，歡迎大家一起加入到Apache Flink和StarRocks社區(qū)建設(shè)，共同探索出更多實(shí)時(shí)數(shù)倉的最佳實(shí)踐。

特別提醒：本網(wǎng)信息來自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對(duì)本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請(qǐng)自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系我們，本站將會(huì)在24小時(shí)內(nèi)處理完畢。