（原標題：小米基于StarRocks極致性能打造小米式性價比數據平臺）

　　 小米有品是小米旗下精品生活電商平臺，也是小米“新零售”戰略的重要一環。依托小米生態鏈體系，延續小米的“爆品”模式，致力于將“小米式的性價比”延伸到更廣泛的家居生活領域。有品數據中心主要負責有品電商的數據資產，提供數據分析服務。數據分析幫助做出有效決策，有效決策促進業務增長，業務增長需要更多的數據分析，形成閉環。

　　 作者：

　　 汪細勖，小米高級研發工程師

　　 陳亦奇，小米有品研發工程師

　　 歷史架構及業務痛點

　　 受限于以往業務規模以及技術條件，曾經的小米數據中心的架構如下圖：

　　 業務數據和流量數據通過數據采集服務傳送到Talos，實時數據通過Spark Streaming進行ETL處理，商品數據聚合之后寫入MySQL中，其他數據寫入Druid中做預聚合；離線數據直接寫入Hive中，通過Spark SQL提供查詢服務。這套架構隨著業務的快速發展，已經越來越不滿足用戶需求，主要表現為以下幾點：

　　 ·數據快速膨脹，查詢性能成為瓶頸

　　 ·維護多套系統，運維成本，機器成本高

　　 ·Druid去重效果差，不支持明細數據

　　 StarRocks在小米有品的應用實踐

　　 OLAP引擎調研

　　 為了解決這些問題，我們調研了多款OLAP引擎，沒有一款引擎能從數據規模，查詢性能，靈活性三個方面滿足我們的需求。結合實際，綜合考慮，我們選擇了StarRocks作為小米有品數據中心的新一代OLAP引擎。主要考慮到StarRocks有以下幾點優勢：

　　 ·極致查詢性能：單表查詢性能已經超過ClickHouse，多表Join經過CBO優化，性能遠超ClickHouse

　　 ·同時支持明細和聚合模型：支持Duplicate/Aggregate/Unique三種數據模型，同時支持物化視圖

　　 ·高效數據導入：高效支持流式導入和批量導入

　　 ·運維簡單，高可用：多副本，一致性協議支持高可用，自動化運維，操作簡單

　　 當前架構

　　 采用StarRocks作為小米有品數據中心的OLAP引擎之后，我們當前的架構是這樣的：

　　 業務數據和流量數據通過數據采集服務，寫入Talos中，實時數據通過Flink進行ETL，實時寫入StarRocks中；離線數據通過Spark進行ETL，寫入Hive中，然后導入到StarRocks中。由StarRocks作為統一的查詢引擎，架構簡單明了。

　　 數據寫入

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

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

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

　　 數據建模

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

　　 數據查詢

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

　　 除此之外，相比于傳統的Broadcast/Partition Shuffle Join算法，StarRocks提供了Colocate Join和Bucket Shuffle Join算法。Colocate Join在數據寫入時，保證多個表的數據按照分桶鍵分布，保持一致，這樣多張表Join時可以在本地進行，減少網絡傳輸，提升查詢性能。在生產實踐中我們發現能夠帶來3-4倍以上的產品性能的提升，非常強悍。

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

　　 綜合比較，相比于之前的架構，現在的架構查詢性能方面提升明顯。聚合上卷查詢，關聯查詢相較于此前基于MySQL的架構，基于StarRocks的架構性能可以提升20-30倍以上。StarRocks在明細聚合查詢方面，相比于Spark SQL，提升4倍以上。存儲成本相比于MySQL+Druid，降低2倍以上。

　　 平臺展示

　　 下圖是我們基于StarRocks實現的小米有品數據中心的一個平臺，主要是提供業務分析以及看板、報表等等這些服務。

　　 未來規劃

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

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

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

　　 總結

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