最佳实践京东实时计算架构演进之路

Posted 2021-07-04 小伟り

一、背景：

从 2004 年开始，京东进军互联网线上化开始到至今，随着京东的高速发展，京东商城的订单量从万级到百万级、最终到达亿级。而对于实时的数据需求也是层出不穷，实时计算架构随着数据量的增长，不断进行革新。

二、京东实时计算架构演进之路

2.1 订单量万级、百万级(以京东海外站为例)

在订单量万级、百万级别的时候，也存在不少实时的数据需求，比如：商家需要看看自己每天的成交量、老板需要看看整体的成交金额，以为后续的融资做准备。类似于现在很多的 a、b 轮创业公司数据体量。

解决方案：而此时为了节省更少的资源，减少更少花销。在实时架构设计上就需要尽量用更少的成本来解决这种问题。基于 mysql 的实时数据统计方案就比较适合了。

步骤：将线上业务系统数据实时同步到大数据中心(在 mysql 的基础上搭建了一套大数据架构)，避免了 Hadoop 生态庞大复杂的体系。基于 mysql 数据宽表进行数据统计，将统计结果写到 mysql 指标结果表中，输出一些报表或者服务。详细步骤见下图。

架构优缺点：

1. 开发简单，基于 mysql，同时避免 hadoop 生态复杂的体系，节省开销。
2. 数据量过大，查询和聚合性能较差，mysql 单表量级在百万级别。
3. 在此架构中需要对 mysql 及其熟练，如何设计索引，如何进行查询统计优化。

2.2 订单量亿级(以京东主站为例)

随着公司的发展，数据体量的增大，达到千万甚至亿级别时，基于 mysql 的数据统计方案已经完全没办法满足统计需求了，mysql 查询也查不动了。基于此产生了一套新的技术方案：flink 接 kafka 消息数据，直接进行指标计算，写入到 redis 里面，最后提供对外服务。详细步骤见下图。

架构优缺点：

1. 能够支撑亿级数据量的统计需求，对于大数据量友好
2. 时效性高，计算延迟较低
3. 技术方案相对复杂，新增指标需要重新开发，上线任务。

2.3 订单量亿级(以京东主站为例)

上述基于 flink 直接指标计算的方案，优点非常明显，缺点也非常明显，如果新增指标，需要重新开发上线，对于频繁的业务需求变更，已经很难满足了，因此产生了基于 OLAP 的技术方案。Flink 接 kafka 消息，将明细数据写入到 OLAP 引擎(clickhouse、apache doris)当中，构建一张宽表，然后直接进行数据查询统计基于 OLAP 引擎，对于新增指标只需要新增不同的 sql 查询语句就能解决需求，而不用重新开发，提高了整体效率，能够应对业务的频繁变更。详细步骤见下图。

架构优缺点：

1. 能够支撑亿级数据量的统计需求，对于大数据量友好
2. 时效性较高
3. 开发简单，能够快速应对业务需求。

三、总结

随着公司高速发展，数据体量的改变对于技术的选型也是不断进行变更的。只有了解不同的技术架构的优缺点，在合适的阶段选择不同的数据架构，才能够更好的服务于业务。同时根据自己所处的公司当前的发展状况，预估公司后续的发展，在技术架构选型上也是有前瞻性的。