目录
前言
华米科技是一家基于云的健康服务提供商，每天都会有海量的埋点数据，以往基于HBase建设的埋点计算分析项目往往效率上会相对比较低，查询方式不够灵活 。
在埋点分析中，用户往往是基于单维度或者多维度组合去观测某个指标，这里的维度可以是时间，事件名称，城市或者设备属性等，指标可以是用户量、某个埋点的次数等。在此海量埋点数据背景下，如何比较灵活，高效的完成维度+指标的计算，满足用户快速查询分析的需求，是一个值得探索的问题。基于高效的OLAP引擎建设埋点分析平台就成为了业务发展中的重要一环。
一、原有方案及其痛点
在之前的架构中，华米科技的埋点数据统计相关信息，需要根据统计的指标，优先将需要计算的指标（例如PV、UV）通过Spark /Hive进行预计算操作，然后写入到HBase中，对下游相关用户提供点查的能力。
对于该方案，以下三点是较为不便的：
- 在HBase中，数据以KV形式存储，只能提供点查能力，不具备复杂的统计分析能力；
- 无法使用Bitmap 相关技术，将需要的指标事先计算出来，方式不够灵活，不能做集合操作；
- 流程链路较长，维护复杂度高，不具备模型抽象能力，业务升级有所不便。
二、引入StarRocks
针对数据存储层的问题，着力于寻找一款高性能、简单易维护的数据库产品来替换已有的 Spark + HBase 架构，同时也希望在业务层上能突破HBase点查的限制，通过实时多表关联的方式拓展业务层的需求。
目前市面上的 OLAP 数据库产品很多，诸如 Impala、Druid、ClickHouse 及 StarRocks。在经过一系列的对比之后，选择了 StarRocks 来作为 华米的 OLAP 引擎，替换原有的HBase成为存储层的新选择。
从上面的对比可以看出，StarRocks是一款极速全场景 MPP企业级数据库产品，具备水平在线扩缩容，兼容Mysql协议和Mysql生态，提供全面向量化引擎与多种数据源联邦查询等重要特性，在全场景OLAP业务上提供统一的解决方案，适用于对性能，实时性，并发能力和灵活性有较高要求的各类应用场景。
三、方案改造
3.1 架构设计
当前埋点数据经由网关转入kafka，采用Hudi on Flink 的模式进行数据清洗，过滤，转换，基于流式数据湖构建OLAP的预处理层。根据数据特性和写入的性能要求以及成本的权衡，分别基于Hudi 的 Upsert 和 Append 模式构建 DWD 层（借助 Hudi 的去重、追加能力）,定时离线处理数据转入DWS，考虑数仓的整体架构以及成本优化，将DWS数据定时离线导入到StarRocks中，最后经由统一的查询分析平台查询StarRocks数据。
3.2 数据流程
详细流程如下：
（1）对原始数据进行数据转换处理，然后根据数据特性，分别以Upsert 模式和Append模式接入Hudi（对数据重复不敏感的业务数据直接以Append 模式高效写入Hudi）
（2）将产出的数据经由 Broker Load 写入带有Btimap字段的聚合模型，生成业务Btimap数据；
（3）根据业务需求，自定义对Btimap进行集合操作（当前的应用场景为生成PV，UV等数据）；
（4）用户根据查询分析平台进行自助业务指标查询；
3.3 性能指标
通过StarRocks的监控平台可以看到查询的平均耗时在100ms左右，P99延迟大概在250ms 左右，能够很好地满足埋点数据分析平台业务上的需求。
3.4 改造收益
- 高效：能够快速响应用户的查询分析需求，很多大查询效率从分钟级别降低至秒级。
- 灵活：满足多维度、多时间段自由组合的指标统计分析，不需要提前计算冗余统计指标。
- 节约空间：StarRocks 自身的高效存储结构，同等业务量的数据存储成本较以往下降20%；
- 简单：相较于 ClickHouse，维护管理所需的人力成本有所降低。
- 便捷：用户自助查询便捷，取数体验有所提升，部分指标点查速度从之前的分钟级降低到秒级，部分指标可以达到毫秒级。
参考文章：
