中国邮政邮科院 X StarRocks：统一 OLAP 平台，大幅降低运维成本

邮政科学研究规划院有限公司（以下简称“邮科院”），作为中国邮政集团有限公司的科研智库单位，专注于战略规划、企业管理、工程设计、物流装备、智能终端、质量检测、标准化研究等领域，在助力中国邮政战略转型和经营发展中发挥着重要支撑作用。

邮科院数据组负责全院大数据体系架构的建设，支撑日常 BI 运营分析、科研数据产品、物流数据、网点画像等业务场景。邮科院数据组通过使用 StarRocks，统一了实时和离线的分析场景，替换了 ClickHouse、Presto、MySQL 等系统，解决了原有多套系统带来的运维和使用复杂性，简化了数据 ETL 流程，同时大幅提升 OLAP、Adhoc 等场景的查询效率。本文主要介绍邮科院数据组基于新一代极速全场景 MPP 数据库 StarRocks，在数据服务体系和数据应用场景中的实践和探索。

作者：谢翔

邮政科学研究规划院有限公司寄递研究所数据组负责人，专注于数仓建设、数据分析等领域研究

业务背景

随着科研数据积累越来越大，数据规模和体量也急剧膨胀。科研的原始数据通常来源于研报抽取、日志埋点文件、业务数据库、三方接口等。过去通常基于 CDH/Hadoop 等大数据分布式计算框架和数据集成工具，构建离线的数据仓库，并对数据进行适当的分层、建模、加工和管理，构建各类分析主题。邮科院数据体系中沉淀了诸多研报主题数据，例如：电商流量数据，物流企业财务数据，行业报告相关的数据等。

上层数据应用对查询的响应延迟和时效性要求高，会将数据通过数据同步工具同步到 MySQL、ElasticSearch、Presto、HBase、ClickHouse 等数据库系统中，来支撑上层数据应用的查询要求。

邮科院的大数据总体架构如下图所示，从下到上可以分为数据接入层、数据计算层、数据服务层和数据应用层。

数据计算层使用科研工作各分析场景下产生的模型/方案/业务的明细数据，进行离线数据计算，对 TB 级别的明细数据进行调度、聚合、计算，在数仓里沉淀出大量明细表、聚合表和最终的数据报表。

数据计算层生成的各类数据表，会同步到数据服务层，由数据服务层提供接口给数据应用层使用，满足不同的数据业务需求。

业务痛点

数据服务层的愿景是开放数仓能力，建立统一的数据服务出口，针对不同的数据业务分析场景（数据规模、QPS、UDF 支持、运维成本等），原有架构在底层使用了不同的查询引擎：

• 大数据量、低 QPS：使用 Hive、Presto、ClickHouse 等基于 Hadoop 生态的离线批任务计算框架和 MPP 数据库来解决。

• 小数据量、高 QPS：使用 MySQL、ElasticSearch、HBase、MongoDB 等关系型/非关系型数据库来解决。

使用多套查询引擎，我们遇到如下问题和挑战：

• 离线/实时 ETL 任务过多，处理逻辑大部分为简单聚合/去重，聚合表数量庞大，导致运营和运维上的成本增加；

• 针对中等数据量、中等 QPS 的查询场景，如何能兼顾数据规模的同时，有较友好的查询响应延迟；

• 大数据量下插入、更新的实时数据场景无法得到支持，例如：网点画像、实时数据导入、邮路路径、研报数据汇总等。

OLAP 引擎选型

针对如上的问题和挑战，我们的目标是寻求尽可能少的 OLAP 引擎，利用在明细表上现场计算来解决 ETL 任务、数仓表过多问题，同时需要兼顾在数据规模、查询 QPS、响应耗时、查询场景方面的权衡。

目前市面上 OLAP 引擎百花齐放，诸如 Impala、Druid、ClickHouse、StarRocks。经过一番调研，我们最终选择了 StarRocks。StarRocks 是基于 MPP 架构的分析型数据库，自带数据存储，整合了大数据框架的优势，支持主键更新、支持现代化物化视图、支持高并发和高吞吐的即席查询等诸多优点，天然能解决我们上述的问题。

StarRocks 应用实践

StarRocks 已经投入生产环境，主要作为离线/实时数据的 OLAP 数据库使用。离线数据主要存储于 HDFS 中，通过 DataX 任务批量同步数据到 StarRocks；另一部分实时数据主要存储于 Kafka 中，使用 StarRocks 的 routine load 功能实时将数据从 kafka 写入到 StarRocks。

在没有引入 StarRocks 之前，我们使用的底层引擎是 MySQL、Presto on HDFS 和 ClickHouse 等系统，对明细表/聚合表进行查询。这几种方式都存在着不少问题：

• MySQL 处理上亿规模的数据，无论使用分库分表、分区表、集群化部署的 PolarDB 方案，都会存在慢查询、数据库扛不住、运维困难的窘境；

• Presto on HDFS 的方案更偏向于分析型数据业务，虽然能存储海量的数据，计算能力不错，唯一致命的在于无法满足在线业务的高吞吐 QPS，查询比较难做到毫秒级。

• ClickHouse 对 Join 支持较弱，只能使用大宽表建模，不够灵活，另外运维也比较复杂。

在引入 StarRocks 替换 MySQL、Presto 和 ClickHouse 后，StarRocks 带来的业务效果如下：

• 支撑了在线报表查询+数据分析业务，服务于对内运营+对外行业分析的数据产品，报表业务查询大部分耗时在毫秒级别，分析型业务查询大部分耗时在秒级别；

• 支持 10 亿规模的明细表查询，月、季、年等维度统计数据现场算聚合统计、精准去重等，查询耗时都能控制在 500ms 以内；

• 千万级别的多表的 Join 和 union 查询，经过 Colocate Join 特性优化，查询响应在秒级。

另外，我们还将 StarRocks 应用到实时数据分析场景， StarRocks 在实时数据分析主要有如下优势：

• 实时写入性能：目前 StarRocks 支持 HTTP 方式的 Stream Load，可以自定义的分钟级别微批写入，以及 Routine Load 功能，可以将 Kafka 的数据实时同步到 StarRocks 中，满足当前实时数据分析业务；

• 统一离线和实时分析：实时数据和离线数据更好的在 StarRocks 中进行融合，灵活支撑应用，数据存储策略通过 StarRocks 动态分区的功能进行自动管理；

• SQL Online Serving：高效的 SQL 即席查询能力，能够兼容业界标准的 SQL 规范，支撑业务灵活复杂的访问，提高取数开发的效率。

总结和规划

邮科院数据组引入 StarRocks 生产集群，解决了数据服务层单表亿级别规模、高 QPS 数据场景下引擎的空白，直接开放明细表准实时查询的能力，给各项目组上层数据业务和 BI 系统提供了更多的选择和自由度，同时将大大减少数仓中大量 ETL 任务、聚合表、报表，降低了数仓 ETL 的运维压力和维护成本，StarRocks 综合性价比较原有的 MySQL、Presto、ClickHouse 等同类产品提升数倍以上。

未来，邮科院在 StarRocks 的应用和实践上还有不少规划：

• 除了 unique 和 duplicate 数据模型，未来会将符合的数据场景迁移至 aggregation 模型，并使用物化视图，进一步降低数仓开发维护成本，降低查询延迟；

• StarRocks on ES 的功能也值得我们深挖和探索，解决原生 ES 集群无法支持跨索引 Join 的能力；

• 更多数据应用层的场景接入 StarRocks，例如网点画像服务、邮路路径分析等，将进一步拓展 StarRocks 在实时数据写入、批量数据更新场景中的应用；

• 与科研数据分析平台、数仓平台深度打通，完善数据整体架构，作为数据团队的基础设施去保障稳定性和服务；

• 考虑使用多云架构，自主可控的数仓架构可以灵活的在多云间切换迁移，降低单一云厂商的依赖，控制成本提高可用性。

• ......

最后的最后，感谢 StarRocks 技术团队给予的热情、靠谱的答疑解惑和技术支持！！！