顺丰科技 x StarRocks ：双十一实时运单分析实践

顺丰科技有限公司隶属于顺丰速运集团，成立于 2009 年，致力于构建智慧大脑，建设智慧物流服务。顺丰科技经过多年的自主研发，已经建成大数据整体生态系统，完成数据采集与同步、数据存储与整合、数据分析与挖掘、机器学习、数据可视化等平台的构建。在建设底盘平台的基础上，结合大数据、区块链、物联网与人工智能技术，广泛应用于速运、仓储、冷运、医药、商业、金融、国际等业务领域。

作者：严向东

顺丰科技大数据平台架构师

顺丰大数据平台简介

早期顺丰在 OLAP 层主要使用了 Elasticsearch、ClickHouse、Presto、Kylin 这四个组件。

• Elasticsearch 在顺丰场景使用的最多，倒排索引的机制下，检索效率高，整体运维也比较方便。目前在日志类、条件检索类的场景用的比较多。目前版本以 Elasticsearch 5.4 为主，新接入的业务使用了 7.6 版本，基于标准版本进行了一些定制化的开发工作，包含跨机房备份方案、K8S 容器化部署、数据服务平台等。

• ClickHouse 是这两年引入，用于一些重点的运单场景，进行了 K8S 集群化改造，很好的满足了资源快速交付的需求。

• Presto 在顺丰也使用的很多，主要用于 Hive 数据的查询。我们针对 Presto 进行了 Yarn 集群部署的改造，很好地用到了 Yarn 队列的资源。

• Kylin 使用的相对较少，目前只在财经线的几个业务上作为试点。

当前痛点及产品选型

顺丰通过内部容器化建设、组件深度定制、组件平台的建设，组件的一些突出问题、共性问题已经解决，但是还有一些难以解决的组件自身的痛点问题。我们对这些组件的问题进行了一些总结：

• 一、多版本多框架并存、基础组件升级难。由于历史原因，同时存在多个版本在线上运行，但因为多个版本的不兼容性，用户业务在线上稳定运转，主动切换意愿不高，导致版本难以统一，组件升级方案复杂、操作风险高，也是组件升级难的另外一方面原因。

• 二、用户选用组件容易一刀切。在实际的应用中，有很多用户进行大数据选型时，缺乏对组件本身的了解，导致大量的使用不合理的情况，如使用 ES 做大量的聚合计算、使用 Presto 做报表、使用 Kafka 做批量交互等。

• 三、使用难/运维难。各种组件的使用/运维不尽相同，需要用户和运维都要具备相应的专业知识。

OLAP 产品选型

目前 OLAP 场景，各家百花齐放。可以选择的组件很多，选择合适的组件需要方法论的支持。目前我们顺丰在选型上，遵照了以下原则：

• 组件的核心能力要够强，短板不明显。

• 组件交付的版本工程质量高。

• 核心诉求/大的生产环境的问题响应足够及时。

• 可塑性强，未来长期发展潜力大。

• 运维的门槛要低。

我们针对性进行了相应的评估，评估包含下面一些方面：

• 不同产品之间使用标准测试集的横向评估，主要选取评估的组件有 ClickHouse、Presto、Apache Doris、StarRocks。

• 中等业务规模的业务体验：10 亿规模的契合度高的场景，带 Join。

• 公司内典型场景的需求评测：百亿规模的运单场景的典型 SQL 等。

• 重点功能项的评测：如大数据数据导入、大表 Join 、failover 等。

从评估的结果来看，对于 StarRocks 我们整体还是比较满意的，最终我们选择了 StarRocks ，基于如下的考虑：现阶段 StarRocks 性能、稳定性占优；StarRocks 处于高速发展期，能够提供专业的技术支持、生产环境问题/需求的快速反应；StarRocks 拥有强大的运维管理系统，用户开发、运维的功能很全面。

StarRocks 应用实践

整体目标

顺丰引入 StarRocks 的目标是：使 StarRocks 成为一站式的大数据分析平台的底座。从数据的源头来看，包含三条数据流：

• 实时数据、离线数据导入，通过 StarRocks 原生的几种 Load 任务完成。

• 通过 Flink/Spark 的 Connector 完成数据 ETL。

• Hadoop、Elasticsearch、MySQL 等环境中的数据，作为数据源，通过 StarRocks 外表导入。

从数据使用的角度来看，通过 JDBC 接口给数据使用者提供服务，主要的数据使用者包含：

• 组件开发/组件维护，目前顺丰环境对应的是大数据组件平台。

• BI 工具平台，在顺丰内部叫作丰景台。

• 数据中台，如数据服务、数据字典等。

• 业务平台的访问，比如数据平台临时查询导数的平台，及其他一些业务平台。

为了应对统一的大数据分析底盘的诉求，需要一些场景化的能力，这里列一些我们主要的诉求：

• 替代 Presto，在 BI 工具平台快速查询 Hive 数据。

• 替代 ElastcSearch、ClickHouse、Kylin 做 OLAP 明细、汇总数据的存储。

• 较好的数据导出能力，便于业务做二次分析。

StarRocks 应用进展

业务接入

• 运单级别的业务已经完成开发，正在灰度运营中。

• 其他几个细分业务领域也完成了接入，如财务、快运、国际等。

• 其他也有一些业务正在接入、体验中。受限于前期的机器采购预算未申报，接入节奏不算快。

统一的 OLAP 平台能力建设

• 已经可以进行 BI 工具平台打通。

• 全链路的多个集群环境的搭建，包含测试集群/预发布集群/生产公共集群/容灾公共集群/重点业务私有集群。

• 大数据平台 DataX 集成、Flink / Spark Connector 的集成正在开发/测试中。

• 中台的数据服务、数据字典等正在进行相关的设计，目前也和鼎石团队在一起看如何拿到元数据。

实践案例

在物流行业，运单场景是最典型的场景。这里给大家分享一个顺丰最大体量级别的运单场景。这个场景原来是在 Oracle 上单机运行，更新频繁、对时效要求高。业务上存在着许多的痛点，业务数据成倍增长导致原来系统已经不堪负荷，主要表现为可用性不高、速度变慢、数据多份、时效性不高等。业务侧的诉求是希望接入 StarRocks 以后，性能和时效性大幅度提升，能够在现有业务翻倍双 11 场景下的撑得住，提供高可用的方案，能够快速扩容等等。

需求澄清

接到这个任务后，我们梳理了一遍需求：

• 硬性指标，双 11 要满足单行数据 2k 左右大宽表、8 万 TPS 写入诉求。

• 业务峰值效应明细，未来还会有大的增长空间。

• 数据保存三个月以内的数据，目前数据量在百亿级别以内。

• 旧业务改造需要考虑已有 BI 平台工具的 2K+报表的平滑过渡。

• 数据导出需求，供业务侧做二次分析。

数据导入

针对需求，我们做了数据导入和查询两个方面的方案设计和优化。从数据导入来看，核心问题是提升单机数据写入性能。

• 表设计按照日期分区，按照运单号分桶，第一个问题就是如何进行数据分布的设计，从使用经验来看，Kafka 分区个数与 StarRocks 的 BE 节点个数、导数任务并行度要一致，导入效率才最高。

• 由于源头数据来源于不同的业务系统加工成大宽表，需要通过配置字段的 replace_if_not_null 支持部分字段更新，另外为了避免 Json 数据字段增删导致导数失败，需要每个字段指定 Json 位置。

• StarRocks 导入能力与单条记录的字节数、合并效率有很大关系。为了更高的导入性能，我们把大宽表的按列分拆为两个，更新少的数据放入一个表（这里叫公表）、更新频繁的放到另外一个表（私表），多表的导入的任务数会增加。

• 机器选型上，由于写入频繁，我们升级了单机 6 盘到 12 盘，未来考虑使用 ssd；StarRocks 向量化优化深入，我们升级了 40 核到 80 核，提升 QPS。

• 系统按照日期进行分区，由于数据来源于多个业务系统，存在分区时间没有的情况，需要反查，初期方案是从 StarRocks 跨区查，效率较低，后面采用了 Flink 的 RocksDB 方案。

• 跨机器跨磁盘的副本均衡问题：由于机器 down 机或者增删磁盘造成的，目前跨机器的副本均衡已经在最新版本解决，跨磁盘的副本均衡期待在后续版本解决。

• 版本数问题：如果版本数过多会导致 BE 节点暂停从 Kafka 消费，导致数据导入效率下降。这里可以通过调整 Kafka 消费时间、合理设置分片、分区个数、副本个数减少版本数。

查询

• 为解决原有系统的 2K+ 报表的平滑迁移问题，由于拆成了两个表，新增加了一个视图，保持跟原有表结构一致，降低迁移成本。

• 跟 BI 平台合作，做了一些查询并行度限制核数据缓存策略，提高系统的稳定性。

为了提高的查询性能，做了一些针对性的优化工作：

• 对于最常用的查询条件字段，加到 key 列，如客户的公司等。

• 通过增加布隆过滤器索引提升查询效率。

• 大表间的 Join ，调整 Join 的顺序（未开启 CBO ）。

• 两表 Join 时，增加冗余字段并放在 ON 条件里面使条件能够下推，减少扫描量。

• 问题：为了提升查询性能，将查询条件中的非 key 列的加到了 key 列，对于此非 key 列的变更变成了删除+插入两步操作，可能会造成未合并的版本数累积。

目前系统的整体数据来源于多个业务系统，通过 Flink 进行计算后写入一个新的 Kafka ，StarRock 通过 Routine Load 从新的 Kafka 拉取数据，很好的实现了 Exactly Once 语义，各个系统的耦合度很低，可用度高。

为了更高的可用性，我们采用了双机房、双写、双活的方案。通过两种域名配置方式以负载均衡方式给 BI 工具和业务 APP 使用。业务 APP 通过域名、 JDBC LB 方案具有更高可用性，机器迁移、down 机无影响。

这里是我们具体的表设计：

1）聚合表模型、同时支持明细表和物化视图。

2）按照使用更新频度分成两个表，提高导入任务个数。

3）按照寄件日期分区，运单号分桶。

4）通过 replace_if_not_null 支持部分字段更新。

5）变化不频繁字段加到 key 列，并两个表冗余，提高查询效率。

6）两表按照 Collocate Join 提升 Join 效率。

7）按照日期动态分区，支持数据淘汰。

8）查询条件增加布隆过滤器索引，提升检索效率。

在适应性更高的场景、如不更新、数据量 10 亿以下等，StarRocks 更加得心应手，性能强大。这里是目前顺丰接入的其他一些非运单明细的场景，StarRocks 都有良好表现，如原财务系统，时常会出现告警。接入 StarRocks 以后，使用 1/3 的资源消耗即可良好的运行。

后续规划和社区共建

我们后续在 OLAP 方面的规划如下：

• ClickHouse 的新业务接入已基本停止。

• 明年准备大规模接入 StarRocks ，已经全面启动相关的机器采购预算申请，运单级别的业务系统已经有几个规划会进行改造接入。

• 另外在云上数仓项目上，期待继续深入使用 StarRocks。

目前 StarRocks 已经源代码开放，面向未来，StarRocks 有更多的可能性。顺丰也有基于 StarRocks 建设统一、全场景、极速 OLAP 分析平台的诉求：

• 从终端用户来看：建设一站式的开发/运营平台。

• 从资源管理来看：达到 serverless 的管理目标、可衡量。

• 从运维层面来看：更高可用性、更多的工具。

• 从数据模型来看：更多的场景化模型支持。

• 从统一查询平台：各种数据库引擎的更好支持。

• 从生态来看：深入各个周边场景提供更多能力。

我们愿意与 StarRocks 社区一起，携手共进，为社区贡献我们的一份力量。