共计 2370 个字符，预计需要花费 6 分钟才能阅读完成。
作者
徐昱 | 华米科技 / 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 数据。
数据流程
具体流程如下：
- 对原始数据进行数据转换解决，而后依据数据个性，别离以 Upsert 模式和 Append 模式接入 Hudi（对数据反复不敏感的业务数据间接以 Append 模式高效写入 Hudi）；
- 将产出的数据经由 Broker Load 写入带有 Bitmap 字段的聚合模型，生成业务 Bitmap 数据；
- 依据业务需要，自定义对 Bitmap 进行汇合操作（以后的利用场景为生成 PV、UV 等数据）；
- 用户依据查问剖析平台进行自助业务指标查问
性能指标
通过 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 落地并服务于智能可穿戴衰弱业务。
