京东物流基于 StarRocks 的数据分析平台建设

原创
02/02 14:08
阅读数 707

作者:京东物流 数据专家 刘敬斌

小编导读:

京东集团 2007 年开始自建物流,2017 年 4 月正式成立京东物流集团,截至目前,京东物流已经构建了一套全面的智能物流系统,实现服务自动化、运营数字化及决策智能化。

京东物流在运营数字化及决策智能化过程中,实时化运营分析的业务需求越来越多,原有平台架构中的数据孤岛、查询性能低、运维难度大、开发效率低等问题日益凸显。2022 年,京东物流基于 StarRocks 打造了 Udata 统一查询引擎,高效解决了数据服务与数据分析的众多痛点。

近两年来,京东物流在 StarRocks 的使用中不断进行性能提升优化,取得了良好的效果。在 StarRocks Summit 2023 上,京东物流数据专家刘敬斌为大家介绍了 StarRocks 的应用经验,并重点分享了湖仓查询的优化经验和效果。另外,据刘敬斌介绍,在 2023 年京东双十一大促期间,京东物流 StarRocks 集群规模已经达到了 3 万核以上。

京东物流的用数特征和痛点

一个企业的业务特征决定了用户的用数习惯,而用数习惯往往会演变出一些用数痛点,在京东物流的数据分析服务场景中存在 4 大痛点。

找数难

在我们的业务场景中,当一个订单从商城域进入物流域后,会经过很多环节,从仓储到分拣,再到配送、拓投,链条非常长,中间系统特别多,数据也比较多,各个系统产生的数据被存储到各种各样的异构存储里,一线运营人员在找数据时存在一定困难。

做数难

京东物流划分了很多省区,每个省区都有自己的运营策略,一线运营人员各自都有不同的做数方法论去适配自己的运营策略,而数据分析平台目前面对的用户大部分都是一线运营人员,数据需求千人千面,此外我们还希望让运营人员能像使用 Excel 一样的去使用大数据,降低大数据使用门槛,这也是我们面临的重要任务。

用数难

Hadoop 平台把数据算出来之后,一线运营人员通过内部的云盘系统,将数据下载到本地,然后导入到本地 Excel,这种用数模式存在一些问题:

  • 整个过程中有很多半人工方式,效率非常低;

  • 每个省区的数据来源都不一致,可能会导致数据口径不统一;

  • Excel 对于大数据的处理能力有很多缺陷;

协同难

报表生成之后,有时需要互相传阅,在 Excel 非常多的情况下,大家互相传输,有时会用到一些线下的传输工具,导致数据来源不明晰,由于传输过程中有很多人工参与,协同比较困难,数据的时效性、安全性都得不到保障,并且存在大量重复性工作,性能体验非常差。

基于 StarRocks 的解决方案

京东物流 Udata 里面关于数据分析服务有两个概念:

  • 数据服务:当数据通过 SQL 方式提供对外赋能时,SQL 比较固化,查询场景也比较固定;

  • 数据分析:类似 Ad-hoc 查询,用户进行数据探索;

数据分析

在数据分析场景中,我们要解决 4 个问题:

  • 找数,运营人员对业务非常了解,他们的需求和业务语义比较贴近,但是数据保存在大数据库,和研发人员更加贴近,这中间不可避免存在割裂,如何让运营人员用业务语义去找到对应的数据表?我们会把数据以指标表维度打上业务标签,建立数据视图,让一线找数的人员可以按照业务视角,通过图数据库的数据血缘关系快速找到想要的数。

  • 做数,一线运营人员对于决策非常了解,但是如何生成 SQL?Udata 通过无代码点选式的方式来让一线用户只需在线拖拖拽拽,就能将业务意图翻译成 SQL 语句。我们希望构建覆盖京东生态全部数据源的接入能力,让用户可以随时随地查询各种各样的数据,StarRocks 强大的联邦查询能力起到了非常关键的作用。

  • 用数,借助 Udata 的线上 Excel 能力,实现了将线下报表快速迁移到线上的方案,并且报表一次配置永久生效,通过 StarRocks 包括物化视图在内的一些高级特性,可以高效地得到查询结果。

  • 协同,当报表线上化之后,能够通过链接、邮件等方式实现 PC 和移动端随时随地看数的目标。

数据服务

物流的业务发展比较快,当角色发生变化后,业务管理者需要及时看到数据,这对于数据的交付要求越来越高。一方面,数据的性能要求很高,另一方面,数据的可复用性比较低,因此我们需要投入更多的研发资源来应付大量的数据需求。

基于 StarRocks,我们得以通过界面的方式快速地开发数据服务接口。目前已经在很多场景应用了数据服务快速开发能力,基本能达到当日交付的响应速度。与传统方式相比,数据资产变现效率提升了 5 倍,开发成本降低了 80%,支持了我们很多的业务。

Udata 数据分析平台

Udata 数据分析平台产品设计

图中是 Udata 数据分析平台的产品设计,从下往上看分为 4 个部分:

  • 数据源,现在可以兼容的数据源包括 MySQL、Elasticsearch、ClickHouse、Hive 等,还有一些 API,覆盖了京东大部分数据源,完成了京东生态对接;

  • 底层引擎,基于 StarRocks 打造,数据源会以外表挂载形式接入到查询引擎,底层的查询引擎分为两层:StarRocks 实时数仓,应用了 StarRocks 的数据快速摄入能力和高性能的数据查询能力。基于 StarRocks 打造的联邦查询,实现各种数据源跨数据源跨集群的查询,只要数据接入到系统就能进行查询。

  • 产品功能,从数据接入到数据管理、数据使用,以及数据接口编排、在线 Excel,涵盖了数据的生命周期,解决了找数用数的问题。

  • 数据赋能,主要通过数据分析和数据服务来对外赋能,支持的业务场景包含报表分析、办公协同、数据探索、指标监控、数据大屏等等。

湖仓新范式下的数据全景图

图中为湖仓新范式下数据全景图,从下往上看分为 4 层:

  • 最下层左侧是生产系统数据区;中间是实时数据加工区,通过 Flink 接收众多系统接入的消息队列消息,然后加工到 OLAP 层;右侧是离线加工区,京东有很多历史数据都存在 Hadoop 里,我们会通过 Spark、Hive 来加工,存到 HDFS、Hive 里。

  • 往上一层是 OLAP 层,包含 MySQL、Elasticsearch、ClickHouse 等数据库,另外还有 StarRocks、Paimon。右则是离线区,采用了 Hive 和 HDFS。

  • 再往上是采用 StarRocks 搭建的一个支持超级联邦查询的集群引擎。

  • 最上层是 Udata 对外赋能提供的能力,包括数据地图、在线分析、数据服务、办公协同等。

为什么选择 StarRocks

每个公司选择分析型数据库产品时都有很多关注点,我们主要关注的是实时性、应用性、灵活性、性能、生态等 5 个方面,StarRocks 在这些方面的表现都非常优秀,联邦查询、湖仓一体查询、实时更新等特性完全符合我们的需求,其中,湖仓一体查询是我们现在的主打方向。

因为一些历史原因,京东采用了很多 Elasticsearch,Elasticsearch 在搜索和倒排索引方面非常优秀,用来进行数据分析却可能不太适合,我们曾经接到过一个业务需求,需要从 Elasticsearch 把数据和业务迁移到 StarRocks,当时的集群规模约 800 CPU 左右,数据量约 2.5 TB,查询 QPS 大约 10,在业务同等满足的情况下,Elasticsearch 的 CPU 使用率高达70%,基本上无法再提供别的服务,StarRocks 的 CPU 使用率则在 30% 以下。显然,StarRocks 在主建模型和批量更新的加持之下,比 Elasticsearch 更适合这种数据分析。

StarRocks 的性能提升优化和效果

在 StarRocks 的使用中,我们进行了一些性能提升,其中对湖仓查询的性能优化尤为重视。我们的湖主要是 Hive,关于 Hive 的查询,首先 HDFS 需要快速的文件访问能力,其次元数据的拉取也要足够快,另外基于 CBO 的查询优化也非常关键,尤其在进行 Join 查询时,更加需要采用最优的执行计划。

SQL 优化

跨集群查询时,需要从另外一个集群里面拉取大量数据,网络开销比较多,所以针对有计算能力的外表引擎,我们进行了计算下推,就是把类似于 group by、limit 的聚合计算尽可能推到外表引擎上去,直接从跨级群拿到的是外表引擎里面已经计算后的结果,数据量会显著下降。

Hive 优化

数据分区分桶是 Hive 非常重要的特性,可以在查询时尽可能扫描更少的数据。在实际使用中,有些用户不太了解 Hive 里的分区键和列有哪些关系,对此,我们通过检查用户的 SQL 语句,帮助用户尽量将 Hive 的分区列应用到 SQL 里,这是我们对于湖的一个优化。 访问 HDFS 会带来远程 I/O 消耗,我们通过 data cache 减少了这部分性能开销。此外,第一次查询时因为要拉取大量的元数据,也会导致一些性能开销,而我们有一些表特别大,有时分区达到上百万,这也是我们在解决的一个问题,我们让 Hive 元数据的更新以事件通知到 FE,触发 FE 主动更新缓存,从而使第一次查询也能比较快。与此同时,我们还对 FE 里的 hive meta cache size、ttl 等也进行了改造。另外,我们把 Hive 里的一些大分区表尽也可能地进行了治理。

HDFS 优化

当 HDFS 集群有大量任务时,查询性能会有一些抖动,对此我们进行了 Heged read 的优化,优化之后效果非常显著。另外我们也希望在离线的湖上面的查询进行一些物化视图的加速。

大查询保护

Hive 上的数据都特别大,有时一次查询会占上百 G 的数据,甚至可能把集群的资源全部占用,为了避免这种情况,我们进行了一些防护,比如限制 Hive 分区数目、限制扫描的 HDFS 文件大小,对查询时间较长、CPU 占用较高的一些大查询进行熔断。 经过这些改造,目前京东物流已经落地的 Udata 产品做到了数据使用从线下到线上的转变。现在数据使用实现了透明化、安全化,使用过程中没有人为参与因素,查询性能也比较高。

京东双十一的流量考验

今年双十一大促期间,我们的数据查询 QPS 最高达到 150,相比平时呈几倍增长,并且通常要从海量数据里面进行查询,在 QPS 150 的情况下,扫描数据的峰值高达 300G 每秒,每秒扫描的数据行数达 95 亿行。对于数据写入,RPS 基本上是 40,数据写入峰值达 4.2G 每秒,每秒写入 234 万行。大促期间,StarRocks 集群规模已经达到了 3 万核以上。

未来规划探索

存算分离

我们目前采用的是混合架构,查询引擎多而全,本地表和外表共存,未来希望从这种架构迁移到存算分离架构,使计算可以弹性扩展,数据存储分而治之。

离线数据的实时化

我们希望当 Hive 里的数据、Hadoop 里的数据发生变化之后,能够快速查询最新数据,现在也在考虑如何让 Hive 的数据更新及时通知 FE 进行更新,同时尽量消除实时更新带来的性能影响。

数据湖加速

对于我们来说,数据湖的数据量都比较大,带来的网络开销非常大,另外元数据的性能开销也会影查询体验,现在我们在积极地尝试包含 data cache 在内的方式来减少远程 I/O,同时采用物化视图加速查询,此外我们还在探索包括 Paimon、Hudi 在内的多种异构湖存储。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
3 收藏
0
分享
返回顶部
顶部