小米有品是小米旗下精品生活電商平臺，也是小米“新零售”戰略的重要一環。依託小米生態鏈體系，延續小米的“爆品”模式，致力於將“小米式的價效比”延伸到更廣泛的家居生活領域。有品資料中心主要負責有品電商的資料資產，提供資料分析服務。資料分析幫助做出有效決策，有效決策促進業務增長，業務增長需要更多的資料分析，形成閉環。
作者：汪細勖，小米高階研發工程師
陳亦奇，小米有品研發工程師
歷史架構及業務痛點
受限於以往業務規模以及技術條件，曾經的小米資料中心的架構如下圖：
業務資料和流量資料透過資料採集服務傳送到 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-Order Indexing 來提升多維分析的查詢效能。目前 StarRocks 在資料寫入的時候，會在記憶體中將多個列按照字典的方式來進行排序，然後寫入到磁碟中。這種字典排序的方式在實際的查詢過程中，只有利於第一列的過濾，但是其他列的過濾效果都比較差。為了支援多維分析的場景，未來我們打算開發 Z-Order Indexing 來提升多維分析的查詢效能。
三、我們準備攜手 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 生態很有意義。
