2022年1月9日，StarRocks亮相Flink Forward Asia 2021大會開源解決方案專場，StarRocks解決方案架構(gòu)師謝寅做了題為“雙劍合璧：Flink+StarRocks構(gòu)建實時數(shù)倉解決方案”的主題演講。本文以主講嘉賓從技術(shù)方案的角度，為社區(qū)的小伙伴帶來最全、最詳細(xì)的文字版實錄回顧!
本文從以下5個方面介紹：
第一部分，實時數(shù)倉技術(shù)的發(fā)展趨勢和技術(shù)挑戰(zhàn)，以及為什么Flink+StarRocks能夠提供端到端的極速實時數(shù)倉體驗。
第二部分，介紹什么是StarRocks，它有哪些技術(shù)特點，擅長的場景是什么，以及為什么作為OLAP層的極速分析引擎，它能夠很好與Flink技術(shù)進(jìn)行整合。
第三部分，重點介紹聯(lián)合Flink和StarRocks兩大技術(shù)棧構(gòu)建實時數(shù)倉的方法論。
第四部分，介紹一些利用Flink和StarRocks構(gòu)建實時數(shù)倉的最佳實踐案例。
第五部分，展望了StarRocks在實時數(shù)倉方向以及Flink社區(qū)貢獻(xiàn)等方面的后續(xù)規(guī)劃。
1.實時數(shù)倉概述
隨著各行各業(yè)對數(shù)據(jù)越來越重視，實時計算技術(shù)也在不斷的演進(jìn)。從時效性上來講，對于小時級或者分鐘級的計算已經(jīng)不能滿足客戶業(yè)務(wù)的需要，需求逐漸從時窗驅(qū)動，升級到事件驅(qū)動，甚至每產(chǎn)生一條數(shù)據(jù)，都想盡快看到數(shù)據(jù)。ETL過程也從離線或者微批的ETL，變?yōu)镕link擅長的實時流式處理。
數(shù)據(jù)源上，早先只能支持單一的數(shù)據(jù)源，整體的數(shù)據(jù)表現(xiàn)力較差。而當(dāng)下，人們不僅希望能對單一數(shù)據(jù)流進(jìn)行分析計算，還希望能聯(lián)合多個數(shù)據(jù)源進(jìn)行多流計算，為此不惜想盡一切辦法，來讓數(shù)據(jù)的表現(xiàn)力更加豐富。
從工程效率的角度上看，技術(shù)團(tuán)隊也逐漸意識到，工程代碼開發(fā)的成本高企不下，更希望能構(gòu)建自己的平臺化IDE工具，讓業(yè)務(wù)人員能基于其上直接進(jìn)行FlinkSQL的開發(fā)。在這些演進(jìn)的過程也逐漸浮現(xiàn)出一些技術(shù)難點亟待解決，比如：
·亂序數(shù)據(jù)怎么更好的處理?
·通過Watermark之類的手段，是讓過去的數(shù)據(jù)隨即失效，還是希望所有的明細(xì)數(shù)據(jù)都能入庫?
·多流Join到底應(yīng)該怎么做合適?
·維表是一次性加載進(jìn)來，還是放到外存儲做熱查詢，除此之外還有沒有其他的技術(shù)選擇?
·數(shù)據(jù)處理作業(yè)一旦重啟，怎么保證在恢復(fù)之后還能做到不丟不重的續(xù)接消費(fèi)?
·怎么才能提高整體的業(yè)務(wù)開發(fā)效率，保證業(yè)務(wù)上線時沒有業(yè)務(wù)中斷，更優(yōu)雅快捷的進(jìn)行業(yè)務(wù)邏輯迭代?
在此之外，還有一件事也是業(yè)務(wù)人員或平臺架構(gòu)師最關(guān)注的，那就是通過Flink這么強(qiáng)大的實時計算引擎，費(fèi)勁千辛萬苦好不容易把計算層效率從小時級或者分鐘級的延遲提升到了秒級，結(jié)果現(xiàn)有的OLAP產(chǎn)品拖了后腿，查詢耗費(fèi)了好幾分鐘，辜負(fù)了計算團(tuán)隊的大量心血。
以上種種，充分證明了極速OLAP+實時計算的重要性，以此我們就可以打造一套端到端的極速實時數(shù)倉解決方案，即所謂“雙劍合璧”!
談到數(shù)倉，目前業(yè)界落地較多的還是Lambda架構(gòu)，也就是離線數(shù)倉和實時數(shù)倉分開構(gòu)建。邏輯分層的形式，也基本形成了業(yè)界的共識。業(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ù)據(jù)到達(dá)的先后情況以及業(yè)務(wù)需要，可能會有些層次的裁剪，不像離線數(shù)倉里那么豐富。中間的一些維度信息，可能會同時被離線數(shù)倉和實時數(shù)倉共享使用。最后將數(shù)據(jù)送入OLAP產(chǎn)品，供報表系統(tǒng)、接口或者Adhoc查詢所調(diào)用。
基于前面對數(shù)倉典型邏輯分層的探討，問題也隨之而來：
是否有一款OLAP產(chǎn)品能夠很好的和Flink結(jié)合，滿足持續(xù)的秒級的數(shù)據(jù)攝入和極速分析查詢能力?
答案是一定的，StarRocks的定位正是要提供極速分析查詢能力，來適應(yīng)各種各樣的OLAP場景。
2.StarRocks是什么
這是StarRocks的宏觀架構(gòu)圖。
從左邊我們可以看到常見的Kafka、分布式文件系統(tǒng)、傳統(tǒng)關(guān)系型數(shù)據(jù)庫，都可以作為StarRocks的數(shù)據(jù)源。
StarRocks提供了4種模型：
·如果業(yè)務(wù)場景只涉及數(shù)據(jù)的持續(xù)Append，可以選擇Duplicate明細(xì)模型，在其上可以實時構(gòu)建物化視圖加速DWS層查詢;
·如果業(yè)務(wù)場景不關(guān)注明細(xì)的下鉆，StarRocks還有Aggregate聚合模型表，相當(dāng)于數(shù)據(jù)直接秒級打入DWS層，滿足高并發(fā)的聚合指標(biāo)查詢;
·對于ODS層做業(yè)務(wù)庫數(shù)據(jù)還原時，若涉及到數(shù)據(jù)更新的場合，可以采用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回撤流語義，聚合計算不必非要開窗轉(zhuǎn)為Append流來Sink，進(jìn)一步增強(qiáng)了FlinkSQL的表現(xiàn)力。
StarRocks還提供了邏輯View和物化視圖，提供了更豐富的建模能力。
在上圖的右側(cè)是StarRocks的物理架構(gòu)，整體還是非常簡潔的，主要就是兩種角色：FE前端節(jié)點和BE后端節(jié)點。
·FE負(fù)責(zé)查詢規(guī)劃、元數(shù)據(jù)管理、集群高可用，并包含CBO優(yōu)化器，為分布式多表關(guān)聯(lián)和復(fù)雜Adhoc查詢提供最優(yōu)的執(zhí)行規(guī)劃。
·BE節(jié)點承載了列式存儲引擎和全面向量化的執(zhí)行引擎，保障在OLAP分析場景中提供極速查詢體驗。
·對上層應(yīng)用提供MySQL連接協(xié)議，可以用MySQL客戶端輕松連入進(jìn)行開發(fā)和查詢，和主流BI工具有很好的兼容性，也可以服務(wù)于OLAP報表和API封裝。
3.StarRocks擅長哪些場景
基于StarRocks的4種模型，可以提供明細(xì)查詢和聚合查詢，能夠應(yīng)對OLAP報表的上卷和下鉆，比如在廣告主報表場景應(yīng)對高并發(fā)點查詢。
StarRocks基于Roaring Bitmap提供了Bitmap數(shù)據(jù)結(jié)構(gòu)，并配套有集合計算函數(shù)，可以用于精確去重計算和用戶畫像的客群圈選業(yè)務(wù)。在實時方面，StarRocks可以用于支撐實時大屏看板、實時數(shù)倉，秒級延遲的呈現(xiàn)業(yè)務(wù)原貌和數(shù)倉指標(biāo)。
最后，基于CBO優(yōu)化器，StarRorcks在OLAP場景下有很好的多表關(guān)聯(lián)、子查詢嵌套等復(fù)雜查詢的性能，可以用于自助BI平臺、自助指標(biāo)平臺和即席數(shù)據(jù)探查等自助分析場景。
StarRocks能夠用于構(gòu)建實時數(shù)倉，得益于他的三種實時數(shù)據(jù)攝入能力：
·可以直接消費(fèi)Kafka的消息。
·可以借助Flink-connecor實現(xiàn)Exactly-once語義的流式數(shù)據(jù)攝入。
·另外，結(jié)合Flink-CDC和PrimaryKey模型，可以實現(xiàn)從TP庫Binlog實時同步Upsert和Delete等操作，更好的服務(wù)于ODS層業(yè)務(wù)庫還原。
利用Flink-Connector-StarRocks插件，可以實現(xiàn)從TP庫Binlog實時同步Upsert和Delete等操作，更好的服務(wù)于ODS層業(yè)務(wù)庫還原。配套的SMT(StarRocks Migration Tool)工具，可以自動映射Flink中的TP庫Source和StarRocks庫的Sink建表語句，使得基于FlinkSQL的開發(fā)工作變得簡單便捷。
另外，F(xiàn)link-Connector更重要的功能是提供了通用Sink能力，開發(fā)者把依賴加入后，無論是工程編碼還是FlinkSQL都可以輕松Add Sink，保障數(shù)據(jù)秒級導(dǎo)入時效性。
結(jié)合Flink的Checkpoint機(jī)制和StarRocks的導(dǎo)入事務(wù)標(biāo)簽，還可以保障不丟不重的精準(zhǔn)一次導(dǎo)入。
StarRocks的實時物化視圖構(gòu)建能力，結(jié)合Flink-Connector的持續(xù)增量數(shù)據(jù)導(dǎo)入，可以在流量類指標(biāo)計算的建模中，實現(xiàn)DWD明細(xì)數(shù)據(jù)導(dǎo)入完成的同時，DWS聚合指標(biāo)也同步增量構(gòu)建完成，極大提升聚合指標(biāo)產(chǎn)出效率，縮短分層ETL的旅程。
StarRocks提供的Replace_if_not_null能力比較有意思，正如語義所述，只要插入的數(shù)據(jù)不是null，那么就可以去替換數(shù)據(jù)。
如圖所示，右側(cè)是個建表示例，里面維度列為日期和Uid，其余3列中SRC表示數(shù)據(jù)源，另外帶了v1，v2兩個Metric;
通過2個Insert語句我們可以看到，來自2個Kafka主題的數(shù)據(jù)源的數(shù)據(jù)，輕松的實現(xiàn)了同時寫入一張表的不同列。因此，這個功能提供了兩種實時數(shù)倉能力：
1)Join on Load，也就是在導(dǎo)入的過程中，基于StarRocks來實現(xiàn)流式Join。
2)部分列更新能力。
StarRocks為了支持更好的Upsert/Delete，提供了PrimaryKey表模型。
如上圖所示，最左側(cè)是經(jīng)典的LSM模型，也就是Merge-on-Read的形式。這種模型寫入時不用去判斷既有鍵位，對寫友好，但讀取時需要Merge合并，所以對讀取數(shù)據(jù)不友好。
而最右側(cè)是Copy-on-Write的模型，典型的產(chǎn)品就是DeltaLake。這種模型和LSM正好相反，有比較好的讀效率，但是對于寫入不是很友好。
比較平衡讀取和寫入的，就是上圖中間的兩種Record級別沖突檢查的模型，Kudu的Write Delta和StarRocks的Delete+Insert模型。
由于維護(hù)了內(nèi)存表，PrimaryKey模型更適合冷熱特征明顯的場合，對熱數(shù)據(jù)頻繁的更新和刪除更友好;
另外非常適合PrimaryKey較少的表(如用戶畫像的寬表)，雖然列很多，但是主鍵其實只有UUID這種字段。
StarRocks早期的Unique模型就是采用了最左邊的LSM模型，因此查詢效率較差，并且對于Delete不友好，結(jié)合Flink開發(fā)應(yīng)用時，只能使用Append流進(jìn)行Sink。
StarRocks 2.0版本中新增加的PrimaryKey模型，提供了軟刪除字段，通過在內(nèi)存中維護(hù)最新數(shù)據(jù)，使得查詢時避免了Merge的過程，從而極大提升了查詢性能，并且既可以使用Append流也可以使用Retract流進(jìn)行Sink，豐富了與Flink結(jié)合時的應(yīng)用場景。
4.構(gòu)建實時數(shù)倉的具體方法
眾所周知，在按照邏輯分層自下而上的構(gòu)建實時數(shù)倉時，多流Join是有一定的技術(shù)門檻的。傳統(tǒng)的實時計算引擎如Storm、Spark Streaming在這方面做的都不是很好。而Flink其實提供了很多通用的解決方法，如：
·基于MapStat做狀態(tài)計算，或者BroadcastStat將維度緩存廣播出去;
·用Flink關(guān)聯(lián)外部熱存儲，如HBase/Redis等;
·一些相對穩(wěn)定、更新頻率低的維度數(shù)據(jù)或者碼表數(shù)據(jù)，可以利用RichFlatMapFunc的Open方法，在啟動時就全部加裝到內(nèi)存里;
不限于以上這些，其實Flink已經(jīng)在維度擴(kuò)展上，給了開發(fā)者很多可以落地的選擇。然而有了StarRocks，我們會有更多的想象空間。
比如利用前面介紹的Replace_if_not_null的能力，開發(fā)者可以實現(xiàn)多個數(shù)據(jù)源稀疏寫入寬表的不同列，來實現(xiàn)Join-on-Load的效果。
另外StarRocks強(qiáng)悍的CBO優(yōu)化器在多表關(guān)聯(lián)查詢能力方面也表現(xiàn)優(yōu)異，如果數(shù)據(jù)量不大或者在查詢并發(fā)不高的場景，甚至可以把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的時候沒有節(jié)點間Shuffle，在上層構(gòu)建邏輯View面向查詢。
雙劍方案1.微批調(diào)度
Flink清洗導(dǎo)入Kafka的日志或者用Flink-CDC-StarRocks讀取MySQL Binlog導(dǎo)入StarRocks，ETL過程中埋入批次處理時間，采用外圍調(diào)度系統(tǒng)，基于批次處理時間篩選數(shù)據(jù)，做分鐘級微批調(diào)度，向上構(gòu)建邏輯分層。
這種方案的主要特點是：StarRocks作為ETL的Source和Sink，計算邏輯在StarRocks側(cè)，適用于分鐘級延遲，數(shù)據(jù)體量不大的場景。
雙劍方案2.Flink增量構(gòu)建
實時消息流通過Kafka接?，采用Flink進(jìn)?流式ETL、多流Join、增量聚合等，在內(nèi)存中完成分層構(gòu)建，然后將相應(yīng)的數(shù)據(jù)，層對層的通過Flink-connector寫出到StarRocks對應(yīng)表內(nèi)。各層按需面向下游提供OLAP查詢能力。
該方案的主要特點是：計算邏輯在Flink側(cè)，適用于需要前導(dǎo)做較重ETL的場景，StarRocks不參與ETL，只承載OLAP查詢，應(yīng)對較高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，查詢時現(xiàn)場計算指標(biāo)結(jié)果，保證指標(biāo)上卷和下鉆高度同源一致。
該方案主要特點是：計算邏輯在StarRocks側(cè)(現(xiàn)場查詢)，適用于業(yè)務(wù)庫高頻數(shù)據(jù)更新的場景，實體數(shù)據(jù)只在ODS或DWD存儲(未來StarRocks提供多表Materialized Views，將會進(jìn)一步提升查詢性能)。
5.最佳實踐案例
前面我們介紹了一些聯(lián)合Flink和StarRocks構(gòu)建實時數(shù)倉的幾種方法論，下面我們來看4個實際的客戶案例。
汽車之家目前在智能推薦的效果分析、物料點擊、曝光、計算點擊率、流量寬表等場景，對實時分析的需求日益強(qiáng)烈。經(jīng)過多輪的探索，最終選定StarRocks作為實時OLAP分析引擎，實現(xiàn)了對數(shù)據(jù)的秒級實時分析。
在數(shù)據(jù)處理流程上，SQLServer、MySQL、TiDB等數(shù)據(jù)源，通過CDC打入多個Topic主題，用FlinkSQL進(jìn)行ETL清洗和聚合計算，然后通過Flink-Connector導(dǎo)入StarRocks。早期選擇的Unique表模型，由于業(yè)務(wù)有很多Delete操作，而Merge-on-Read的模型對Delete支持不好，如果只做Update而不做Delete，會造成結(jié)果數(shù)據(jù)比業(yè)務(wù)庫多的問題。
最新的PrimaryKey模型支持了OP字段(更新/刪除操作)，改為PrimaryKey模型后，數(shù)據(jù)結(jié)果與上游業(yè)務(wù)完全一致。
上圖右側(cè)是在硬件配置6x 48c 256G、數(shù)據(jù)量3500W+、有持續(xù)寫入情況下，22個SQL用例的測試情況，查詢性能也比Unique模型有大幅提升。
在合理的選型和建模之后，汽車之家在實時平臺IDE上也做了很多工作，開發(fā)運(yùn)維人員可以在頁面里進(jìn)行DDL建表，F(xiàn)linkSQL開發(fā)，作業(yè)的起停、上線管理等工作。結(jié)合Flink-Connecotor，可以直接通過FlinkSQL將加工后的數(shù)據(jù)導(dǎo)入StarRocks，完成端到端的實時平臺集成。
另外，利用StarRocks提供的200多個監(jiān)控Metric，汽車之家用Prometheus和Grafana等組件做了充分的可視化監(jiān)控，即時查看集群的統(tǒng)計指標(biāo)，把握集群的健康狀態(tài)。
第2個案例，順豐科技的運(yùn)單分析場景實踐。在2021年雙11大促活動中，運(yùn)單分析場景應(yīng)對了15w TPS消息體量的實時數(shù)據(jù)導(dǎo)入和更新。整體的處理流程如圖所示，多個業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)源打到幾個Source Kafka，用Flink來對數(shù)據(jù)進(jìn)行加工、字段補(bǔ)充、重新組織，然后整理后的數(shù)據(jù)打到若干個Sink Kafka主題，最后利用前面介紹的Join-on-Load的形式，將多個數(shù)據(jù)源的數(shù)據(jù)，稀疏的寫入寬表的不同列，以此來實現(xiàn)寬表拼齊的過程。
在具體使用上，順豐科技將運(yùn)單的數(shù)據(jù)根據(jù)更新的頻度，劃分為了2張寬表，按照相同的數(shù)據(jù)分布做成Colocation組，保證Join的時候沒有額外的節(jié)點Shuffle。一張表涉及的更新較少，命名為公表。另一張表涉及的更新較多，命名為私表。
每個子表都利用了Replace_if_not_null的部分列更新的能力，合理的設(shè)計了維度和聚合指標(biāo)，并引入了Bloom Filter索引加速篩選的效率，用日期做范圍分區(qū)，用訂單號做數(shù)據(jù)分布，配置了動態(tài)分區(qū)，自動淘汰冷數(shù)據(jù)。對外通過邏輯View的形式關(guān)聯(lián)成一張寬表，底層是以現(xiàn)場Join的形式，整體面向業(yè)務(wù)提供查詢服務(wù)。
第3個案例是來自多點DMALL的實時數(shù)倉實踐。實時更新場景主要對實時監(jiān)控經(jīng)營的各項指標(biāo)進(jìn)行分析，如當(dāng)前時間段內(nèi)的GMV、下單數(shù)量、妥投數(shù)量、指標(biāo)達(dá)成、對比、環(huán)比等指標(biāo)分析，為客戶的經(jīng)營決策提供更具時效性的參考依據(jù)。
早期，針對數(shù)據(jù)為實時(秒級)更新的場景，主要使用Impala on Kudu引擎，采用Lambda架構(gòu)，基于相同的主鍵，將流式的預(yù)計算的結(jié)果數(shù)據(jù)、批計算的結(jié)果數(shù)據(jù)，基于相同的主鍵進(jìn)行Merge。
這個Case早期的架構(gòu)如左圖所示，ODS、DWD、DWS等分層在Kafka里承載，ADS層在Kudu/MySQL里，維表放在HBase里，采用Flink查詢外表熱存儲的形式實現(xiàn)維度數(shù)據(jù)和事實消息的關(guān)聯(lián)。如右圖所示，經(jīng)過梳理和改造，順豐科技將DWD到DWS的聚合處理從Flink下沉到OLAP層，用StarRocks替換了Kudu，簡化了預(yù)聚合鏈路，提升了開發(fā)效率。
第4個案例是來自一個某車聯(lián)網(wǎng)企業(yè)的Fusion數(shù)倉建設(shè)。隨著新能源汽車的普及，車聯(lián)網(wǎng)IOT數(shù)據(jù)的實時接入分析的需求也越來越多。
業(yè)務(wù)邏輯如左圖所示，傳感器上報的儀表、空調(diào)、發(fā)動機(jī)、整車控制器、電池電壓、電池溫度等1000+傳感器Metric要通過Flink做實時ETL清洗，同時要完成功能主題實時分揀、數(shù)據(jù)質(zhì)量實時報告，最終滿足于時序數(shù)據(jù)綜合分析和可視化展示。技術(shù)上，大量采用Flink.Jar的工程代碼開發(fā)，對于某些碼值還涉及到Flink多流Join及狀態(tài)計算。流量類的主題，采用StarRocks的增量聚合模型出聚合指標(biāo)。也利用FlinkSQL對于運(yùn)營分析類業(yè)務(wù)進(jìn)行了實時數(shù)倉構(gòu)建，將ADS層結(jié)果導(dǎo)入StarRocks供統(tǒng)一接口查詢。
整體上也是按照Lambda模型設(shè)計的，F(xiàn)Link清洗整合后的合規(guī)數(shù)據(jù)，會通過落盤程序沉降到HDFS，用于持久存儲、離線數(shù)倉進(jìn)行跑批及更復(fù)雜的模型訓(xùn)練，最終Hive的結(jié)果數(shù)據(jù)也會送到StarRocks供接口查詢使用。
數(shù)據(jù)邏輯設(shè)計如右圖所示，上面為離線數(shù)倉，下面為實時數(shù)倉邏輯分層。
可以看到實時清洗后的DWD層數(shù)據(jù)會成為離線數(shù)倉的ODS層，而離線數(shù)倉構(gòu)建好的一些相對固定的維表數(shù)據(jù)，也會用于實時數(shù)倉的流式維度擴(kuò)展。實時數(shù)倉的邏輯分層相較于離線數(shù)倉更為簡約，DWD明細(xì)層會存在于獨(dú)立的Kafka或者在Flink內(nèi)存中，DWS層在FlinkSQL聚合完成后就直接下沉到StarRocks了。
這里其實是進(jìn)行了兩次聚合，在Flink里進(jìn)行了秒級的聚合，而StarRocks里的時間信息相關(guān)的維度列是到分鐘或者15分鐘的，利用StarRocks的聚合模型，將Flink匯聚的5-10s的聚合結(jié)果，再次匯聚到分鐘級鍵位。這樣設(shè)計有兩個好處，第一，能夠減少LSM模型的Version版本，提升查詢性能;第二，抽稀到分鐘級后，更便于可視化展示，降低了前端取數(shù)的壓力。
6.實時即未來，StarRocks后續(xù)規(guī)劃
關(guān)于PrimaryKey模型，后續(xù)版本即將支持部分列更新，進(jìn)一步豐富TP業(yè)務(wù)庫還原的能力;并在PrimaryKey模型上支持Bloom Filter、Bitmap等索引能力，進(jìn)一步提升數(shù)據(jù)查詢性能。
資源隔離方面，后續(xù)StarRocks會發(fā)布自適應(yīng)內(nèi)存、CPU分配能力，客戶不再需要手動調(diào)整配置參數(shù);未來也會支持多租戶資源隔離的Feature。
對于Apache Flink項目的貢獻(xiàn)方面，當(dāng)前Flink-Connector-StarRocks還只具備Sink能力，后續(xù)會在Source方面提供支撐，屆時用戶可以通過Flink分布式讀取StarRocks數(shù)據(jù)，用FlinkSQL做跑批任務(wù)。
另外，在CDC適配上，后續(xù)也會提供Oracle/PostgreSQL等更豐富的TP庫的DDL自動映射能力，適應(yīng)更多CDC應(yīng)用。
在云原生時代，StarRocks已經(jīng)開始了積極探索和實踐，很快就會提供存儲計算分離、異地容災(zāi)等能力，為客戶提供彈性、可靠的OLAP層查詢分析體驗。
以上就是本次分享的全部內(nèi)容。實時即未來，歡迎大家一起加入到Apache Flink和StarRocks社區(qū)建設(shè)，共同探索出更多實時數(shù)倉的最佳實踐。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
