顺丰科技有限公司隶属于顺丰速运团体，成立于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社区一起，携手共进，为社区奉献咱们的一份力量。