小米有品是小米旗下精品生活电商平台，也是小米“新零售”战略的重要一环。依托小米生态链体系，延续小米的“爆品”模式，致力于将“小米式的性价比”延伸到更广泛的家居生活领域。有品数据中心主要负责有品电商的数据资产，提供数据分析服务。数据分析帮助做出有效决策，有效决策促进业务增长，业务增长需要更多的数据分析，形成闭环。

作者：

汪细勖，小米高级研发工程师

陈亦奇，小米有品研发工程师

历史架构及业务痛点

受限于以往业务规模以及技术条件，曾经的小米数据中心的架构如下图：

业务数据和流量数据通过数据采集服务传送到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生态很有意义。