精品国产亚洲一区二区三区|亚洲国产精彩中文乱码AV|久久久久亚洲AV综合波多野结衣|漂亮少妇各种调教玩弄在线

<blockquote id="ixlwe"><option id="ixlwe"></option></blockquote>
  • <span id="ixlwe"></span>

  • <abbr id="ixlwe"></abbr>

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

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

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

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

    第二部分,介紹什么是StarRocks,它有哪些技術(shù)特點(diǎn),擅長的場景是什么,以及為什么作為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è)對數(shù)據(jù)越來越重視,實(shí)時(shí)計(jì)算技術(shù)也在不斷的演進(jìn)。從時(shí)效性上來講,對于小時(shí)級或者分鐘級的計(jì)算已經(jīng)不能滿足客戶業(yè)務(wù)的需要,需求逐漸從時(shí)窗驅(qū)動,升級到事件驅(qū)動,甚至每產(chǎn)生一條數(shù)據(jù),都想盡快看到數(shù)據(jù)。ETL過程也從離線或者微批的ETL,變?yōu)镕link擅長的實(shí)時(shí)流式處理。

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

    從工程效率的角度上看,技術(shù)團(tuán)隊(duì)也逐漸意識到,工程代碼開發(fā)的成本高企不下,更希望能構(gòu)建自己的平臺化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)來,還是放到外存儲做熱查詢,除此之外還有沒有其他的技術(shù)選擇?

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

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

    在此之外,還有一件事也是業(yè)務(wù)人員或平臺架構(gòu)師最關(guān)注的,那就是通過Flink這么強(qiáng)大的實(shí)時(shí)計(jì)算引擎,費(fèi)勁千辛萬苦好不容易把計(jì)算層效率從小時(shí)級或者分鐘級的延遲提升到了秒級,結(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è)界的共識。業(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ù)倉,為了讓整體的邏輯清晰,通常情況下也會沿用這種分層模式,只不過受限于實(shí)時(shí)數(shù)據(jù)到達(dá)的先后情況以及業(yè)務(wù)需要,可能會有些層次的裁剪,不像離線數(shù)倉里那么豐富。中間的一些維度信息,可能會同時(shí)被離線數(shù)倉和實(shí)時(shí)數(shù)倉共享使用。最后將數(shù)據(jù)送入OLAP產(chǎn)品,供報(bào)表系統(tǒng)、接口或者Adhoc查詢所調(diào)用。

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

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

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

    2.StarRocks是什么

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

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

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

    StarRocks提供了4種模型:

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

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

    ·對于ODS層做業(yè)務(wù)庫數(shù)據(jù)還原時(shí),若涉及到數(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回撤流語義,聚合計(jì)算不必非要開窗轉(zhuǎn)為Append流來Sink,進(jìn)一步增強(qiáng)了FlinkSQL的表現(xiàn)力。

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

    在上圖的右側(cè)是StarRocks的物理架構(gòu),整體還是非常簡潔的,主要就是兩種角色: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)承載了列式存儲引擎和全面向量化的執(zhí)行引擎,保障在OLAP分析場景中提供極速查詢體驗(yàn)。

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

    3.StarRocks擅長哪些場景

    基于StarRocks的4種模型,可以提供明細(xì)查詢和聚合查詢,能夠應(yīng)對OLAP報(bào)表的上卷和下鉆,比如在廣告主報(bào)表場景應(yīng)對高并發(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ù)倉,秒級延遲的呈現(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í)數(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)工具,可以自動映射Flink中的TP庫Source和StarRocks庫的Sink建表語句,使得基于FlinkSQL的開發(fā)工作變得簡單便捷。

    另外,F(xiàn)link-Connector更重要的功能是提供了通用Sink能力,開發(fā)者把依賴加入后,無論是工程編碼還是FlinkSQL都可以輕松Add Sink,保障數(shù)據(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;

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

    通過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表模型。

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

    如上圖所示,最左側(cè)是經(jīng)典的LSM模型,也就是Merge-on-Read的形式。這種模型寫入時(shí)不用去判斷既有鍵位,對寫友好,但讀取時(shí)需要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較少的表(如用戶畫像的寬表),雖然列很多,但是主鍵其實(shí)只有UUID這種字段。

    StarRocks早期的Unique模型就是采用了最左邊的LSM模型,因此查詢效率較差,并且對于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)用場景。

    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)外部熱存儲,如HBase/Redis等;

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

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

    比如利用前面介紹的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ā)不高的場景,甚至可以把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)度

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

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

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

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

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

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

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

    雙劍方案3.StarRocksView視圖

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

    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)場計(jì)算指標(biāo)結(jié)果,保證指標(biāo)上卷和下鉆高度同源一致。

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

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

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

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

    汽車之家目前在智能推薦的效果分析、物料點(diǎn)擊、曝光、計(jì)算點(diǎn)擊率、流量寬表等場景,對實(shí)時(shí)分析的需求日益強(qiáng)烈。經(jīng)過多輪的探索,最終選定StarRocks作為實(shí)時(shí)OLAP分析引擎,實(shí)現(xiàn)了對數(shù)據(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的模型對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個(gè)SQL用例的測試情況,查詢性能也比Unique模型有大幅提升。

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

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

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

    第2個(gè)案例,順豐科技的運(yùn)單分析場景實(shí)踐。在2021年雙11大促活動中,運(yùn)單分析場景應(yīng)對了15w TPS消息體量的實(shí)時(shí)數(shù)據(jù)導(dǎo)入和更新。整體的處理流程如圖所示,多個(gè)業(yè)務(wù)系統(tǒng)中的數(shù)據(jù)源打到幾個(gè)Source Kafka,用Flink來對數(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ū),用訂單號做數(shù)據(jù)分布,配置了動態(tài)分區(qū),自動淘汰冷數(shù)據(jù)。對外通過邏輯View的形式關(guān)聯(lián)成一張寬表,底層是以現(xiàn)場Join的形式,整體面向業(yè)務(wù)提供查詢服務(wù)。

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

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

    早期,針對數(shù)據(jù)為實(shí)時(shí)(秒級)更新的場景,主要使用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查詢外表熱存儲的形式實(shí)現(xiàn)維度數(shù)據(jù)和事實(shí)消息的關(guān)聯(lián)。如右圖所示,經(jīng)過梳理和改造,順豐科技將DWD到DWS的聚合處理從Flink下沉到OLAP層,用StarRocks替換了Kudu,簡化了預(yù)聚合鏈路,提升了開發(fā)效率。

    實(shí)時(shí)數(shù)倉不用愁,StarRocks+Flink來解憂!

    第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ā)動機(jī)、整車控制器、電池電壓、電池溫度等1000+傳感器Metric要通過Flink做實(shí)時(shí)ETL清洗,同時(shí)要完成功能主題實(shí)時(shí)分揀、數(shù)據(jù)質(zhì)量實(shí)時(shí)報(bào)告,最終滿足于時(shí)序數(shù)據(jù)綜合分析和可視化展示。技術(shù)上,大量采用Flink.Jar的工程代碼開發(fā),對于某些碼值還涉及到Flink多流Join及狀態(tài)計(jì)算。流量類的主題,采用StarRocks的增量聚合模型出聚合指標(biāo)。也利用FlinkSQL對于運(yùn)營分析類業(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ù),會通過落盤程序沉降到HDFS,用于持久存儲、離線數(shù)倉進(jìn)行跑批及更復(fù)雜的模型訓(xùn)練,最終Hive的結(jié)果數(shù)據(jù)也會送到StarRocks供接口查詢使用。

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

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

    這里其實(shí)是進(jìn)行了兩次聚合,在Flink里進(jìn)行了秒級的聚合,而StarRocks里的時(shí)間信息相關(guān)的維度列是到分鐘或者15分鐘的,利用StarRocks的聚合模型,將Flink匯聚的5-10s的聚合結(jié)果,再次匯聚到分鐘級鍵位。這樣設(shè)計(jì)有兩個(gè)好處,第一,能夠減少LSM模型的Version版本,提升查詢性能;第二,抽稀到分鐘級后,更便于可視化展示,降低了前端取數(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會發(fā)布自適應(yīng)內(nèi)存、CPU分配能力,客戶不再需要手動調(diào)整配置參數(shù);未來也會支持多租戶資源隔離的Feature。

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

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

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

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

    (免責(zé)聲明:本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性,但不保證有關(guān)資料的準(zhǔn)確性及可靠性,讀者在使用前請進(jìn)一步核實(shí),并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏,概不負(fù)任何法律責(zé)任。
    任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí),應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明,并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后,將會依法盡快聯(lián)系相關(guān)文章源頭核實(shí),溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 )