2022年1月9日，StarRocks亮相Flink Forward Asia 2021大會(huì)開源解決方案專場(chǎng)，StarRocks解決方案架構(gòu)師謝寅做了題為“雙劍合璧：Flink+StarRocks構(gòu)建實(shí)時(shí)數(shù)倉(cāng)解決方案”的主題演講。本文以主講嘉賓從技術(shù)方案的角度，為社區(qū)的小伙伴帶來(lái)最全、最詳細(xì)的文字版實(shí)錄回顧!
本文從以下5個(gè)方面介紹：
第一部分，實(shí)時(shí)數(shù)倉(cāng)技術(shù)的發(fā)展趨勢(shì)和技術(shù)挑戰(zhàn)，以及為什么Flink+StarRocks能夠提供端到端的極速實(shí)時(shí)數(shù)倉(cāng)體驗(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ù)倉(cāng)的方法論。
第四部分，介紹一些利用Flink和StarRocks構(gòu)建實(shí)時(shí)數(shù)倉(cāng)的最佳實(shí)踐案例。
第五部分，展望了StarRocks在實(shí)時(shí)數(shù)倉(cāng)方向以及Flink社區(qū)貢獻(xiàn)等方面的后續(xù)規(guī)劃。
1.實(shí)時(shí)數(shù)倉(cāng)概述
隨著各行各業(yè)對(duì)數(shù)據(jù)越來(lái)越重視，實(shí)時(shí)計(jì)算技術(shù)也在不斷的演進(jìn)。從時(shí)效性上來(lái)講，對(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ì)算，為此不惜想盡一切辦法，來(lái)讓數(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ù)都能入庫(kù)?
·多流Join到底應(yīng)該怎么做合適?
·維表是一次性加載進(jìn)來(lái)，還是放到外存儲(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)勁千辛萬(wàn)苦好不容易把計(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ù)倉(cāng)解決方案，即所謂“雙劍合璧”!
談到數(shù)倉(cāng)，目前業(yè)界落地較多的還是Lambda架構(gòu)，也就是離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)分開構(gòu)建。邏輯分層的形式，也基本形成了業(yè)界的共識(shí)。業(yè)務(wù)數(shù)據(jù)有的是RDBMS采集上來(lái)的，有的是日志采集上來(lái)的，有的是批量抽取上來(lái)的，有的是CDC或者流式寫上來(lái)的。原始操作層(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ù)倉(cāng)，為了讓整體的邏輯清晰，通常情況下也會(huì)沿用這種分層模式，只不過受限于實(shí)時(shí)數(shù)據(jù)到達(dá)的先后情況以及業(yè)務(wù)需要，可能會(huì)有些層次的裁剪，不像離線數(shù)倉(cāng)里那么豐富。中間的一些維度信息，可能會(huì)同時(shí)被離線數(shù)倉(cāng)和實(shí)時(shí)數(shù)倉(cāng)共享使用。最后將數(shù)據(jù)送入OLAP產(chǎn)品，供報(bào)表系統(tǒng)、接口或者Adhoc查詢所調(diào)用。
基于前面對(duì)數(shù)倉(cāng)典型邏輯分層的探討，問題也隨之而來(lái)：
是否有一款OLAP產(chǎn)品能夠很好的和Flink結(jié)合，滿足持續(xù)的秒級(jí)的數(shù)據(jù)攝入和極速分析查詢能力?
答案是一定的，StarRocks的定位正是要提供極速分析查詢能力，來(lái)適應(yīng)各種各樣的OLAP場(chǎng)景。
2.StarRocks是什么
這是StarRocks的宏觀架構(gòu)圖。
從左邊我們可以看到常見的Kafka、分布式文件系統(tǒng)、傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)，都可以作為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ù)庫(kù)數(shù)據(jù)還原時(shí)，若涉及到數(shù)據(jù)更新的場(chǎng)合，可以采用Unique模型，利用Flink的Append流Sink數(shù)據(jù)進(jìn)來(lái)，完成ODS數(shù)據(jù)去重和更新;
·另外，StarRocks最新2.0版本提供的PrimaryKey主鍵模型，比Unique模型查詢性能快3倍以上，內(nèi)置了OP字段來(lái)標(biāo)記Upsert/Delete操作，并且能夠很好的吻合Flink的Retract回撤流語(yǔ)義，聚合計(jì)算不必非要開窗轉(zhuǎn)為Append流來(lái)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ù)倉(cāng)，秒級(jí)延遲的呈現(xiàn)業(yè)務(wù)原貌和數(shù)倉(cāng)指標(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ù)倉(cāng)，得益于他的三種實(shí)時(shí)數(shù)據(jù)攝入能力：
·可以直接消費(fèi)Kafka的消息。
·可以借助Flink-connecor實(shí)現(xiàn)Exactly-once語(yǔ)義的流式數(shù)據(jù)攝入。
·另外，結(jié)合Flink-CDC和PrimaryKey模型，可以實(shí)現(xiàn)從TP庫(kù)Binlog實(shí)時(shí)同步Upsert和Delete等操作，更好的服務(wù)于ODS層業(yè)務(wù)庫(kù)還原。
利用Flink-Connector-StarRocks插件，可以實(shí)現(xiàn)從TP庫(kù)Binlog實(shí)時(shí)同步Upsert和Delete等操作，更好的服務(wù)于ODS層業(yè)務(wù)庫(kù)還原。配套的SMT(StarRocks Migration Tool)工具，可以自動(dòng)映射Flink中的TP庫(kù)Source和StarRocks庫(kù)的Sink建表語(yǔ)句，使得基于FlinkSQL的開發(fā)工作變得簡(jiǎn)單便捷。
另外，F(xiàn)link-Connector更重要的功能是提供了通用Sink能力，開發(fā)者把依賴加入后，無(wú)論是工程編碼還是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能力比較有意思，正如語(yǔ)義所述，只要插入的數(shù)據(jù)不是null，那么就可以去替換數(shù)據(jù)。
如圖所示，右側(cè)是個(gè)建表示例，里面維度列為日期和Uid，其余3列中SRC表示數(shù)據(jù)源，另外帶了v1，v2兩個(gè)Metric;
通過2個(gè)Insert語(yǔ)句我們可以看到，來(lái)自2個(gè)Kafka主題的數(shù)據(jù)源的數(shù)據(jù)，輕松的實(shí)現(xiàn)了同時(shí)寫入一張表的不同列。因此，這個(gè)功能提供了兩種實(shí)時(shí)數(shù)倉(cāng)能力：
1)Join on Load，也就是在導(dǎo)入的過程中，基于StarRocks來(lái)實(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ù)倉(cāng)的具體方法
眾所周知，在按照邏輯分層自下而上的構(gòu)建實(shí)時(shí)數(shù)倉(cāng)時(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ù)源稀疏寫入寬表的不同列，來(lái)實(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層來(lái)做，這樣可以釋放掉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ù)庫(kù)高頻數(shù)據(jù)更新的場(chǎng)景，實(shí)體數(shù)據(jù)只在ODS或DWD存儲(chǔ)(未來(lái)StarRocks提供多表Materialized Views，將會(huì)進(jìn)一步提升查詢性能)。
5.最佳實(shí)踐案例
前面我們介紹了一些聯(lián)合Flink和StarRocks構(gòu)建實(shí)時(shí)數(shù)倉(cāng)的幾種方法論，下面我們來(lái)看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ù)庫(kù)多的問題。
最新的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)維人員可以在頁(yè)面里進(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來(lái)對(duì)數(shù)據(jù)進(jìn)行加工、字段補(bǔ)充、重新組織，然后整理后的數(shù)據(jù)打到若干個(gè)Sink Kafka主題，最后利用前面介紹的Join-on-Load的形式，將多個(gè)數(shù)據(jù)源的數(shù)據(jù)，稀疏的寫入寬表的不同列，以此來(lái)實(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è)案例是來(lái)自多點(diǎn)DMALL的實(shí)時(shí)數(shù)倉(cāng)實(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è)案例是來(lái)自一個(gè)某車聯(lián)網(wǎng)企業(yè)的Fusion數(shù)倉(cāng)建設(shè)。隨著新能源汽車的普及，車聯(lián)網(wǎng)IOT數(shù)據(jù)的實(shí)時(shí)接入分析的需求也越來(lái)越多。
業(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ù)倉(cāng)構(gòu)建，將ADS層結(jié)果導(dǎo)入StarRocks供統(tǒng)一接口查詢。
整體上也是按照Lambda模型設(shè)計(jì)的，F(xiàn)Link清洗整合后的合規(guī)數(shù)據(jù)，會(huì)通過落盤程序沉降到HDFS，用于持久存儲(chǔ)、離線數(shù)倉(cāng)進(jìn)行跑批及更復(fù)雜的模型訓(xùn)練，最終Hive的結(jié)果數(shù)據(jù)也會(huì)送到StarRocks供接口查詢使用。
數(shù)據(jù)邏輯設(shè)計(jì)如右圖所示，上面為離線數(shù)倉(cāng)，下面為實(shí)時(shí)數(shù)倉(cāng)邏輯分層。
可以看到實(shí)時(shí)清洗后的DWD層數(shù)據(jù)會(huì)成為離線數(shù)倉(cāng)的ODS層，而離線數(shù)倉(cāng)構(gòu)建好的一些相對(duì)固定的維表數(shù)據(jù)，也會(huì)用于實(shí)時(shí)數(shù)倉(cāng)的流式維度擴(kuò)展。實(shí)時(shí)數(shù)倉(cāng)的邏輯分層相較于離線數(shù)倉(cāng)更為簡(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í)即未來(lái)，StarRocks后續(xù)規(guī)劃
關(guān)于PrimaryKey模型，后續(xù)版本即將支持部分列更新，進(jìn)一步豐富TP業(yè)務(wù)庫(kù)還原的能力;并在PrimaryKey模型上支持Bloom Filter、Bitmap等索引能力，進(jìn)一步提升數(shù)據(jù)查詢性能。
資源隔離方面，后續(xù)StarRocks會(huì)發(fā)布自適應(yīng)內(nèi)存、CPU分配能力，客戶不再需要手動(dòng)調(diào)整配置參數(shù);未來(lái)也會(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庫(kù)的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í)即未來(lái)，歡迎大家一起加入到Apache Flink和StarRocks社區(qū)建設(shè)，共同探索出更多實(shí)時(shí)數(shù)倉(cāng)的最佳實(shí)踐。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
