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

科技资讯2021-11-25 11:44
穿越到手机

微信扫一扫 分享更精彩

举报与纠错 打印本文

  顺丰科技有限公司隶属于顺丰速运集团,成立于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应用实践

    整体目标

  #FormatImgID_1#

  顺丰引入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)两表按照CollocateJoin提升Join效率。

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

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

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

    后续规划和社区共建

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

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

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

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

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

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

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

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

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

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

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

  我们愿意与StarRocks社区一起,携手共进,为社区贡献我们的一份力量。(作者:严向东,顺丰科技大数据平台架构师)

特别提醒:本网信息来自于互联网,目的在于传递更多信息,并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益,请及时,本站将会在24小时内处理完毕。

[责任编辑:擎天柱]

论坛爆料:平昌在线论坛 在线投稿:爆料台 邮箱投稿: news#20827.cn (请把#换成@)

读完这篇文章后写点感想吧 你还可以 收藏 留以后再看

关于平昌在线网 | 本网动态 | 联系方式 | 投稿荐稿 | 免责声明 | 广告投放 | 微信平台 | 意见反馈 | 删帖须知 | 友情链接 | 网站地图 | RSS订阅 | 手机站
Copyright © 2007-2019 20827.cn All Rights Reserved.
电信与信息服务业务经营许可证编号:蜀ICP备20004761号-2