• 數(shù)據(jù)快速膨脹，查詢性能成為瓶頸

•  維護(hù)多套系統(tǒng)，運(yùn)維成本，機(jī)器成本高

•  Druid 去重效果差，不支持明細(xì)數(shù)據(jù)

當(dāng)前架構(gòu)

采用 StarRocks 作為小米有品數(shù)據(jù)中心的 OLAP 引擎之后，我們當(dāng)前的架構(gòu)是這樣的：

業(yè)務(wù)數(shù)據(jù)和流量數(shù)據(jù)通過數(shù)據(jù)采集服務(wù)，寫入 Talos 中，實(shí)時數(shù)據(jù)通過 Flink 進(jìn)行 ETL，實(shí)時寫入 StarRocks 中；離線數(shù)據(jù)通過 Spark 進(jìn)行 ETL，寫入 Hive 中，然后導(dǎo)入到 StarRocks 中。由 StarRocks 作為統(tǒng)一的查詢引擎，架構(gòu)簡單明了。

數(shù)據(jù)寫入

數(shù)據(jù)首先寫入 STG 層，STG 層是數(shù)據(jù)緩沖層，包含了訂單 Binlog 數(shù)據(jù)，優(yōu)惠數(shù)據(jù) Binlog，退款數(shù)據(jù) Binlog，流量日志等；ODS 層進(jìn)行數(shù)據(jù)的解析，DWD 層對數(shù)據(jù)清洗、過濾及相關(guān)業(yè)務(wù)邏輯處理；DWS 層按照主題或者維度進(jìn)行輕度聚合，最后數(shù)據(jù)寫入 StarRocks 中。

目前在 StarRocks 之中主要包含了 SKU 聚合模型、頁面聚合模型、優(yōu)惠聚合模型、明細(xì)模型以及維度模型，那么聚合數(shù)據(jù)采用Aggregate模型；明細(xì)數(shù)據(jù)采用 Duplicate 模型，然后在此基礎(chǔ)上再采用物化視圖來加速；離線數(shù)據(jù)通過 Broker Load 方式導(dǎo)入；實(shí)時數(shù)據(jù)通過 Stream Load 方式導(dǎo)入。

經(jīng)過半年的努力，我們目前已經(jīng)實(shí)現(xiàn)了小米內(nèi)部的各大平臺與 StarRocks 的互聯(lián)互通，一鍵操作， 從 Flink、Hive、Hadoop、Kafka、Spark、MySQL 等平臺上，將數(shù)據(jù)一鍵操作寫入 StarRocks 中，也可以一鍵操作將 StarRocks 數(shù)據(jù)遷移到 Flink、Hive、Hadoop、Spark、Presto 中，實(shí)現(xiàn)了StarRocks 與各大平臺的互聯(lián)互通，一鍵操作，讓數(shù)據(jù)在各大平臺自由流動，方便用戶操作和使用。

數(shù)據(jù)建模

過去我們在進(jìn)行建模的時候，廣泛的采用的是大寬表，也就是將指標(biāo)列和維度列都放在同一張表上。這會帶來一個很嚴(yán)重的問題，就是當(dāng)維度修改的時候，我們需要對數(shù)據(jù)進(jìn)行重新的回溯，然后重新聚合計(jì)算，這樣的話非常消耗時間。由于 StarRocks 良好的多表 Join 性能，我們改變了過去大寬表的形式，采用星型關(guān)聯(lián)表來建模，可以支持維度動態(tài)修改，降低回溯成本。

數(shù)據(jù)查詢

對于去重，過去主要是采用 Druid 來進(jìn)行數(shù)據(jù)的去重，計(jì)算 PV/UV 等，由于 Druid 采用 HLL 近似算法，精度只能達(dá)到 97%到99%，對于 AB 實(shí)驗(yàn)以及搜索推薦算法進(jìn)行優(yōu)化效果的評估已經(jīng)不能滿足用戶的需求了。StarRocks 支持 Bitmap 精確去重算法，精度提升到了100%。

除此之外，相比于傳統(tǒng)的 Broadcast/Partition Shuffle Join 算法，StarRocks 提供了 Colocate Join 和  Bucket Shuffle Join 算法。Colocate Join 在數(shù)據(jù)寫入時，保證多個表的數(shù)據(jù)按照分桶鍵分布，保持一致，這樣多張表 Join 時可以在本地進(jìn)行，減少網(wǎng)絡(luò)傳輸，提升查詢性能。在生產(chǎn)實(shí)踐中我們發(fā)現(xiàn)能夠帶來3-4倍以上的產(chǎn)品性能的提升，非常強(qiáng)悍。

另外我們也廣泛的使用了 Bucket Shuffle Join，相比于過去的 Broadcast/Partition Shuffle Join 需要傳輸多份數(shù)據(jù)，Bucket Shuffle Join 只用傳輸一份右表的數(shù)據(jù)。當(dāng) Join Key 包含左表分桶鍵，可以實(shí)現(xiàn) Join 時，只用傳輸一份右表數(shù)據(jù)，減少數(shù)據(jù)網(wǎng)絡(luò)傳輸，提高查詢性能。通過測試發(fā)現(xiàn) Bucket Shuffle Join 能帶來提升2-3倍以上的查詢性能。

綜合比較，相比于之前的架構(gòu)，現(xiàn)在的架構(gòu)查詢性能方面提升明顯。聚合上卷查詢，關(guān)聯(lián)查詢相較于此前基于 MySQL 的架構(gòu)，基于 StarRocks 的架構(gòu)性能可以提升20-30倍以上。StarRocks在明細(xì)聚合查詢方面，相比于 Spark SQL，提升4倍以上。存儲成本相比于 MySQL+Druid，降低2倍以上。

平臺展示

下圖是我們基于 StarRocks 實(shí)現(xiàn)的小米有品數(shù)據(jù)中心的一個平臺，主要是提供業(yè)務(wù)分析以及看板、報表等等這些服務(wù)。

一、我們打算在小米集團(tuán)內(nèi)部廣泛的推廣 StarRocks，與商業(yè)平臺，小米賬號、MIUI、小愛等等這些業(yè)務(wù)部門進(jìn)行一個深度的合作，發(fā)掘 StarRocks 潛力，探索 StarRocks 能力邊界，滿足業(yè)務(wù)部門豐富的需求。

二、我們準(zhǔn)備攜手 StarRocks 開發(fā) Z-Order Indexing 來提升多維分析的查詢性能。目前 StarRocks 在數(shù)據(jù)寫入的時候，會在內(nèi)存中將多個列按照字典的方式來進(jìn)行排序，然后寫入到磁盤中。這種字典排序的方式在實(shí)際的查詢過程中，只有利于第一列的過濾，但是其他列的過濾效果都比較差。為了支持多維分析的場景，未來我們打算開發(fā) Z-Order Indexing 來提升多維分析的查詢性能。

三、我們準(zhǔn)備攜手 StarRocks 開發(fā)單副本 Compaction，減少對查詢的影響。目前 StarRocks 在數(shù)據(jù)寫入的時候會同時寫多個副本，多副本 Compaction 占用資源多，影響查詢性能，開發(fā)單副本 Compaction，分發(fā) Compaction 結(jié)果，減輕對查詢性能的影響。

總結(jié)

總的來說，首先我們覺得 StarRocks 運(yùn)維簡單，成本低。由于StarRocks同時支持明細(xì)和聚合模型，可以滿足大多數(shù)場景，之前采用的多種引擎構(gòu)建數(shù)據(jù)中心的架構(gòu)，現(xiàn)在可以采用 StarRocks 作為唯一引擎，架構(gòu)簡單明了，運(yùn)維高效便捷。StarRocks 相比于 Spark 引擎，機(jī)器成本降低50%以上。第二 StarRocks 查詢性能優(yōu)越，StarRocks 近乎實(shí)時的查詢性能，針對很多典型場景進(jìn)行優(yōu)化的各種特性（Colocate Shuffle Join，Bucket Shuffle Join，CBO等），給用戶帶來了良好的使用體驗(yàn)。第三 StarRocks 既可存算一體，也可存算分離。目前 StarRocks 是存算一體的系統(tǒng)，但它同時支持 ES/MySQL/Hive 等外表功能，可以實(shí)現(xiàn)對 Hadoop 生態(tài)的查詢，可以做到存算分離，對于節(jié)省成本，打通 Hadoop 生態(tài)很有意義。