本文发表于： &{ new Date(1651852800000).toLocaleDateString() }

本文发布于 2022年5月7日。作者 向羿燃360 大数据开发资深工程师，负责数据分析平台数仓架构、数据开发工作

定位于互联网和安全服务提供商的 360 公司，是互联网免费安全的倡导者和先行者。自 2005 年创立以来，先后推出 360 安全卫士、360 手机卫士、360 安全浏览器等安全产品。随着全社会、全行业数字化程度的深化，“大安全”时代加速到来，360 以“让世界更安全更美好”为使命，致力于不断创造黑科技、做全方位守护者。

在各业务线高速发展的同时，业务和用户行为所产生的数据的存储计算问题也日渐突出。360 公司的业务线多、业务复杂度高，对数据分析平台的要求也非常高，于是 360 数据平台部团队开始考虑升级原有分析架构，以更好的满足分析需要。

StarRocks 的极速多维分析能力在我们团队的调研中表现亮眼，并提供灵活模型构建，兼备高并发查询，吸引我们放弃原有分析架构，开始基于 StarRocks 构建“极速统一”的全新分析架构。目前已完成雷达分析平台和人群画像分析平台两个系统的迁移。

#01 业务背景

雷达分析平台是一款面向企业内部业务人员，进行数据集成、数据清洗、数据可视化分析的产品。该产品打通各类业务数据，为业务人员提供多种数据分析方法，协助业务线提升数据分析效率，进而促活留存、增加营收。

雷达分析平台主要为业务人员提供如下三大方面的功能：

1. 日常业务数据的监测和统计；
2. 多种业务分析方法（事件细分、留存分析、多维分析等），并生成多维自定义报表；
3. 数据分析结果的可视化展示。

客户端的数据主要用于事件细分、留存分析、自助宽表，也可用于多维分析和自助查询；服务端的源数据主要用于自助查询、多维分析。自助查询的结果也可通过中间表的形式用于多维分析。所有数据分析的结果会导入看板模块进行可视化展示。

人群画像分析平台帮助业务对目标群体进行人群画像和用户分析，提供具有高可行性，操作性的人群洞察。通过对用户的属性、行为偏好、兴趣爱好等信息进行标签化分析处理，我们将用户分成不同的类别，进行更深入的分析，不断为业务挖掘更相关、更具有价值的用户群体。

人群画像分析平台为业务人员提供如下三大方面的功能：

1. 标签集市/管理：自助定义标签，通过离线任务对人群批量进行标签处理；
2. 用户分群：业务人员可根据任意规则划分用户分群；
3. 用户画像：业务人员可在自定义的用户群进行画像分析。

#02 历史架构与痛点
 

SDK 打点数据通过 SCRIBE 服务采集后，分别进行实时和离线处理，根据不同业务要求，由 MySQL、Druid、Hive 对外提供数据服务。

雷达分析平台使用 Hive 存储事件明细数据，离线任务通过 MapReduce、Hive、Spark 处理，实时任务通过 Flink 处理，暂存到 Redis 中，最终离线和实时数据汇总后落盘到 MySQL，通过 MySQL 对外提供查询服务。

这种方案由于高基维的存在，各业务汇总数据达到数十亿，MySQL 无法直接承载，只能按照业务线、指标做分库分表处理，这导致在查询目标数据前要先查询业务线对应数据库的映射信息，平台维护成本过高；同时，对于部分高流量的业务线，即使做了分库分表处理，存量数据也达到了千万级， MySQL 难以支撑，响应时间无法达到预期。另外，海量数据压缩率过低，也增加了平台成本。

人群画像分析平台大部分基本标签的即席查询需求使用 Druid 来满足，但 Druid 无法处理数组类型标签，因此采用 Hive on Spark 查询作为补充共同完成人群画像的需求。这种方案将 Hive 数据导入到 Druid 需要繁复的中间处理流程，同时两套系统使得维护变得更为复杂，也导致了存储成本的提升。在特定条件下，平台需要快速地基于亿级数据量精确去重，获取符合条件的用户数量。Druid 虽然在大多数情况下性能还可以，但精确去重性能不佳且存在诸多限制，非精确去重有 3% 左右的误差值。

另外，由于需要多个组件相互配合共同支持平台的分析需求，数据链路复杂，不仅开发成本高，也给运维带来了挑战。某些场景性能也无法达到业务需要。

#03 StarRocks 让“极速统一”成为可能

为解决上述的痛点，从 2021 年开始，我们调研引入 StarRocks。通过逐步替换之前的 OLAP 引擎来构建“极速统一”的分析架构，解决了当前运维成本高、平台性能无法满足预期等痛点。

主要因为 StarRocks 具备以下特性：

• 极速多维分析性能：为充分评估 StarRocks 查询性能对业务的满足程度，我们结合实际业务场景分别进行了单表、多表关联的性能测试。测试环境：

单表测试：

两表 Shuffle Join 测试：

总体上看，StarRocks 查询性能可以很好满足业务需求。同时，StarRocks 可以通过 Bitmap 物化视图进一步提升性能，实现 Count (distinct) 高效精确去重，且对查询透明。
 

• 复合型数据结构：在人群画像场景中，某些特殊用户标签以数组形式存储，StarRocks 拥有复合型数据类型的存储、分析能力，并提供 array_contains、array_max、array_min、array_sum 等丰富的数组函数，方便使用。
• 多种数据导入方式：360 有 HDFS、Kafka、本地文件等多种数据来源，StarRocks 分别提供了对应的 Broker Load、Routine Load 、Stream Load 等导入方式，使用简单，并能方便地集成其他系统。
• 简化数据链路，方便开发运维：StarRocks 不仅可以高效支撑雷达分析平台对汇总数据的查询需求，也能很好地支撑人群画像平台数组类型分析和精准去重的需求。这大大精简了数据链路，不仅降低开发和运维成本，也节约存储成本。

#04 StarRocks 在 360 数据平台的应用

在 360 数据平台，雷达分析平台和人群画像分析平台共用一套 StarRocks。

雷达分析平台采用 StarRocks 作为汇总层，实现了更强大的即席查询。StarRocks 单节点每秒可处理多达 100 亿行数据，替代分库分表的 MySQL，大大降低了开发运维和平台运行的复杂度，简化了数据处理链路，解决了原有架构数据导入、查询、维护过于复杂的痛点。仅仅通过分区分桶就可保证响应时间在 2S 以内，提升了平台的响应速度。同时，较高的数据压缩也节约了不少平台存储成本。

人群画像分布平台将原来的 Druid 和 Spark-Hive 两套引擎统一替换为 StarRocks。针对用户标签表，采用明细模型，在将数据导入到 StarRocks时，通过 to_bitmap 将 user_id 转化为 Bitmap 类型，后续通过 Bitmap 运算支持人群圈选、留存分析等需求。

例如，求今天和昨天不同标签下的用户留存也变得非常简单：

select tag, bitmap_intersect(user_id)
from (
    select tag, date, bitmap_union(user_id) user_id
    from table
    where date in ('2020-05-18', '2020-05-19')
    group by tag, date) a
group by tag;

采用 StarRocks 主要带来了四方面的惊喜：

1. 大大简化了平台的数据处理链路，整体维护成本大大降低；
2. 性能表现良好，对亿级别的大宽表进行即席分析，响应时间可以保持在200ms-4s；
3. 支持数组类型的标签数据，并提供 array_contains 等多种函数实现对数组类型数据分析、处理；
4. 利用 Bitmap 集合计算、精准去重以及灵活的数据类型转换能力，实现快速的人群留存计算。
    

#05 总结

360 公司从 2021 年 9 月开始调研引入 StarRocks，当前已有三个 StarRocks 集群在稳定使用中，其中两个已经开始稳定提供线上服务，一个作为测试环境使用。

在引入 StarRocks 后，360 构建了“极速统一”的全新分析架构，实现了数据服务的统一，大大简化了数据处理链路，同时也提高了即席查询的性能。

StarRocks 的 Bitmap 数据结构的特性，是一个非常值得挖掘并应用的优化方向。架构简洁也是 StarRocks 独特的优势，大大减少了运维人员的工作量和学习成本。

后续 360 会在更多的业务场景中应用 StarRocks：

1. 将其他的画像场景迁移到 StarRocks 中，统一使用 StarRocks 提供画像服务；
2. 由于历史原因，雷达分析平台 Druid 中还有部分历史数据，后续将这部分数据也接入 StarRocks 中，替换 Druid；
3. 将 StarRocks 集成到数据治理平台，以方便更多业务部门采用 StarRocks 进行建模；
4. 目前 360 也在进行 StarRocks 数据湖分析能力的探索，测试性能比之前用的 Trino + Iceberg 要好数倍，后续会推进 StarRocks 在数据湖分析的应用。

在测试和使用 StarRocks 的过程中，360 团队得到了 StarRocks 的大力支持，后续 360 也会积极参与 StarRocks 的社区建设，共同打造 StarRocks 极速全场景的分析能力。