作者

徐昱 | 华米科技/ Zepp Health

华米科技是一家基于云的健康服务提供商，拥有全球领先的智能可穿戴技术。在华米科技，每天都会有海量的埋点数据，以往基于 HBase 建设的埋点计算分析项目往往效率上会相对较低，查询方式不够灵活。

在埋点分析中，用户往往是基于单维度或者多维度组合去查看某个指标，这里的维度可以是时间、事件名称、城市或者设备属性等，指标可以是用户量、某个埋点的次数等。在此海量埋点数据背景下，如何比较灵活、高效地完成维度 + 指标的计算，满足用户快速查询分析的需求，是一个值得探索的问题。基于高效的 OLAP 引擎建设埋点分析平台就成为了业务发展中的重要一环。

原有方案及其痛点

在之前的架构中，华米科技的埋点数据统计相关信息，需要根据统计的指标，优先将需要计算的指标（例如 PV、UV）通过 Spark/Hive 进行预计算操作，然后写入到 HBase 中，对下游相关用户提供点查的能力。

对于该方案，以下三点是较为不便的：

• 在 HBase 中，数据以 KV 形式存储，只能提供点查能力，不具备复杂的统计分析能力；

• 无法使用 Bitmap 相关技术，需要将需要的指标事先计算出来，方式不够灵活，不能做集合操作；

• 流程链路较长，维护复杂度高，不具备模型抽象能力，业务升级有所不便。

引入 StarRocks

针对数据存储层的问题与挑战，我们着力于寻找一款高性能、简单易维护的数据库产品来替换已有的 Spark + HBase 架构，同时也希望在业务层上能突破 Hbase 点查的限制，通过实时多表关联的方式拓展业务层的需求。

目前市面上的 OLAP 数据库产品百花齐放，诸如 Impala、Druid、ClickHouse 及 StarRocks。在经过一系列的对比之后，StarRocks 高效的读写性能在众多产品中脱颖而出。同时，高度活跃的社区生态给开发者与用户带来了良好的开发与使用体验，所以我们选择了 StarRocks 来作为 华米的 OLAP 引擎，替换原有的 HBase 成为存储层的新选择。

从上面的对比可以看出，StarRocks 是一款极速全场景 MPP 企业级数据库产品，具备水平在线扩缩容、金融级高可用，兼容 MySQL 协议和 MySQL 生态，提供全面向量化引擎与多种数据源联邦查询等重要特性，在全场景 OLAP 业务上提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。

方案改造

架构设计

当前埋点数据经由网关转入 Kafka，采用 Hudi on Flink 的模式进行数据清洗、过滤、转换，基于流式数据湖构建 OLAP 的预处理层。根据数据特性和写入的性能要求及成本的权衡，分别基于 Hudi 的 Upsert 和 Append 模式构建 DWD 层（借助 Hudi 的去重、追加能力），定时离线处理数据转入 DWS，考虑数仓的整体架构以及成本优化，将 DWS 数据定时离线导入到 StarRocks 中。最后经由 统一的查询分析平台查询 StarRocks 数据。

数据流程

详细流程如下：

1. 对原始数据进行数据转换处理，然后根据数据特性，分别以 Upsert 模式和 Append 模式接入 Hudi（对数据重复不敏感的业务数据直接以 Append 模式高效写入 Hudi）；

2. 将产出的数据经由 Broker Load 写入带有 Bitmap 字段的聚合模型，生成业务 Bitmap 数据；

3. 根据业务需求，自定义对 Bitmap 进行集合操作（当前的应用场景为生成 PV、UV 等数据）；

4. 用户根据查询分析平台进行自助业务指标查询

性能指标

通过 StarRocks 的监控平台，我们可以看到，查询的平均耗时 在 100ms 左右，P99 延迟大概在 250ms 左右，能够很好地满足我们埋点数据分析平台业务上的需求。

改造收益

高效：能够快速响应用户的查询分析需求，很多大查询效率从分钟级别降低到秒级。

灵活：满足多维度、多时间段自由组合的指标统计分析，不需要提前计算冗余统计指标。

节约空间：StarRocks 自身的高效存储结构，同等业务量的数据存储成本较以往下降 20%。

简单：相较于 ClickHouse，维护管理所需的人力成本有所降低。

便捷：用户自助查询便捷，取数体验有所提升，部分指标点查速度从之前的分钟级降低到秒级，部分指标可以达到毫秒级。

社区贡献

开放活跃的社区环境也是我们产品选型的一个重要的指标，作为用户，开放的社区可以更快捷高效的帮助我们了解产品的特性，处理产品使用中的问题。同时，我们华米科技也愿意参与到社区的共建之中，希望通过我们的努力回馈社区，共同进步。华米大数据在使用过程中对 StarRocks 做出以下改进，并合入社区主分支：

• 修复发现的 StarRocks 建立物化视图过程中的 Bug

• 支持更多 StarRocks 数据导入的对象存储类型

• 丰富特定数据导入场景下的参数配置

总结与展望

整个华米科技大数据 OLAP 平台建设过程中，就业务落地、问题追踪解决等方面，我们与 StarRocks 社区保持着高度密切的沟通，感谢 StarRocks 社区的大力支持。

正是在这种 Open & Collaborate 社区精神的影响下，不仅使 StarRocks 用户的棘手问题得以高效解决，还使得社区参与者自身在技术层面获得较大的提升，再次向 StarRocks 社区表示感谢。

StarRocks 是一款优秀的 OLAP 产品，华米愿意使用并陪伴它一同成长，在未来也会继续投身于 StarRocks 社区的共建之中。目前我们做了两点规划：

• 当前生成 Bitmap 需要将明细数据增量导入到聚合模型中，尚不能直接导入 Bitmap 字段的 Parquet 文件，在异构存储的场景下方式不够高效。华米大数据也正与 StarRocks 社区协同，关注及解决该问题，详见：https://github.com/StarRocks/starrocks/issues/3279
  

• 进一步将更多业务接入 OLAP 平台，推动 StarRocks 落地并服务于智能可穿戴健康业务。