AI 与数据融合的基础设施技术展望
如果无法正常显示，请先停止浏览器的去广告插件。
1. AI与数据融合的
基础设施发展展望
陈文光 蚂蚁技术研究院 / 清华大学
2.
3. 大数据：数据量，数据生成的速度和多模态
•物联网、边缘设备和用户
行为产生大量数据
•数据量(Volume) 和数据生成
速度(Velocity)
•多模态数据 (Variety)
•图片，文档，图，时序，交易
(in zettabytes)
Volume of data/information created, captured, copied, and consumed worldwide from 2010 to 2025 © Statista 2021
https://www.statista.com/statistics/871513/worldwide-data-created/
4. 典型数据处理链路
Apps
Database
(MySQL)
实时链路
Queue
(Kafka)
RealTime ETL
（Flink,SPARK)
ETL
（Flink,Spark
+HUDI)
Analysts
OLTP
（Hbase, KV,ES)
DataLake
（MPPDB，HDFS)
OLAP
（Presto,CK)
离线链路
5. 数据处理的深度也在增加
https://medium.com/hackernoon/the-ai-hierarchy-of-needs-18f111fcc007
6. 典型数据+AI处理链路
Model Serving
(PyTorch,TF)
Apps
Database
(MySQL)
Queue
(Kafka)
Batch
Training/Test
(PyTorch,TF)
Analysts
RealTime ETL
（Flink,SPARK)
ETL
（Flink,Spark
+HUDI)
Online Model
Update
(PyTorch,TF)
DataLake
（MPPDB，HDFS)
OLAP
（Presto,CK)
实时链路
OLTP
（Hbase, KV,ES)
离线链路
7. 主要挑战
• 在线离线一致性
• 基于JVM的数据处理系统的性能问题
•
•
123
大数据处理与AI融合问题
8. 问题1. 在线离线一致性问题
在线模型（策略）表现与离线不一致
• 数据不一致
• 模型效果不一致
Model Serving
(PyTorch,TF)
Apps
Online Model
Update
(PyTorch,TF)
Database
(MySQL)
Queue
(Kafka)
Batch
Training/Test
(PyTorch,TF)
Analysts
RealTime ETL
（Flink,SPARK)
ETL
（Flink,Spark
+HUDI)
实时链路
OLTP
（Hbase, KV,ES)
DataLake
（MPPDB，HDFS)
OLAP
（Presto,CK)
https://medium.com/hackernoon/the-ai-hierarchy-of-needs-18f111fcc007
离线链路
9. 解决方案 – 以蚂蚁集团图计算为例
基于图的风控解决方案（全图风控）架构 1
Message
Queue
Application
Data
Serving
TuGraph
Streaming
Write
DB
Rule based
Serving
在线近线数据不一致
模型效果不一致
TuGraph
Dataflow
TuGraph
Dataflow
Decision Making
Decision Engine
Historical
Playback
TuGraph DB :分布式图数据库，支持自定义图查询语言GQuery
TuGraph Dataflow: 流图计算系统，支持Gremlin
10. 解决方案 – 以蚂蚁集团图计算为例
基于图的风控解决方案（全图风控）架构 2， 支持探索-仿真-上线的一致性
Message
Queue
Application
Data
Serving
TuGraph
Streaming
Write
DB
TuGraph
Dataflow
保证在线近线数据一致
•
TuGraph
Dataflow
在线近线系统使用同样
的查询语言
•
Rule based
Serving
Decision Making
Decision Engine
Historical
Playback
以在线数据库内容为准，
同步到近线系统
•
避免不同语言语义的不一
致性
很多细节，比如Nodelimit
TuGraph DB :分布式图数据库，支持国际标准图查询语言ISO-GQL
TuGraph Dataflow: 流图计算系统，支持国际标准图查询语言ISO-GQL
11. 问题2.基于JVM的数据处理系统的性能问题
•
Spark处理性能较差
•
C++手写Word Count与Spark的
Word Count相比，单机加速比12倍
•
•
Java运行时：
Java运行时带来了较高的数据对象
转换开销。例如，序列化/反序列
化
Spark执行策略：
Spark每次仅处理一个元素的执行
策略带来了较高的函数调用开销
时间(秒)
虚函数调用
迭代器
装箱/拆箱
序列化
总计
单机
Spark 单线程C++ 多线程
C++
186 458.99 15.54
WC-R
25.1
4.1
0.3
0.4
29.9
PR-R
20.3
1
3.2
2.2
26.7
PR-F
8.7
6.6
9.9
14.6
39.8
KM-R
0.9
0
0.2
0
1.1
KM-F
20.7
0
0
0
20.7
用VTunes分析3个大数据负载（单词计数WC、网页排名PR、
聚类分析KM）的计算热点
配置：2路E5-2680 v4、256GB内存、
https://github.com/deepmind/pg19 44GB文本数据集
12. 问题2.基于JVM的数据处理系统的性能问题
•
内存占用多
内存使用量（GB）
1000
900
800
•
图计算迭代算法上Spark需要的内存容量是原
始数据集的20倍 [1]
700
600
500
400
300
•
内存消耗多原因主要来自Java运行时：
200
100
0
• 不紧凑对象排布：
例如，右图三元组表示的边需要76字节，
比数据本身所需的16字节膨胀了近5倍
• 垃圾回收内存管理机制:
为了避免频繁垃圾回收需要预留内存
enwiki-2013
twitter-2010
GraphX
uk-2007-05
PowerGraph
weibo-2013
clueweb-12
Gemini
图计算内存用量比较
header
指针
数据
Java三元组内存排布示意图
[1] Zhu, Xiaowei, et al. "Gemini: A Computation-Centric Distributed Graph Processing System." OSDI. 2016.
13. 新型大数据处理内核“诸葛弩”*
•
•
设计理念
• 效率优先：Spark虽然强调可扩展性但是忽视了执行效率。
• 灵活性优先：提供用户更多定制、控制的机会，为高效支持各种应用提供基础。
新设计试图解决Spark RDD存在的问题
• 采用native语言（C++）缓解Spark运行时环境带来的问题
• 针对Spark RDD逐个元素处理模式带来的开销问题，Chukonu设计了常见数据
的紧凑数据表示，并利用编译优化来进行高效批处理
*图片来自： https://www.deviantart.com/master-artcher/art/Chu-Ko-Nu-105615698
14. 实施策略
•
选项1：完全重建大数据生态
•
•
性能好，但构建成本高
选项2：只替换Spark RDD核心部分�
•
效率高，功能完善，假设Spark除核心外的其它部分没有问题
15. 支持SQL
16. 性能评估 – 非结构化数据
17. 性能评估 – 图计算
18. 性能评估 – 机器学习
19. 性能评估 – 内存占用
20. 性能评估 – TPC-DS
21. 问题3. 大数据处理与AI融合问题
• AI计算在数据中心的比例将持续显著增加，主要是Python生态
• 分布式大数据处理主要是Java生态
• “小数据”处理主要是Python生态
处理器
网络
AI
GPU或AI加速器
NVLink +
IB/100Gbps+
主要编程语言
Python
编程框架
PyTorch,Tensorflow,
PaddlePaddle
大数据处理 小数据处理
通用CPU
10Gbps – 25Gbps CPU
-
Java / Scala
Spark, DataFrame Python
Pandas，Numpy，
SciPy,Notepad
AI和大数据处理在硬件层面也有很大差别
22. 数据与AI独立生态的问题
Spark TF/PyTorch
预处理 神经网络
Spark
后处理
• 两类软硬件生态的开发、调试、部署和维护都更加复杂
• 系统间数据传输开销降低性能
• 需要招聘两类程序员，或精通两者的程序员
23. 一种尝试：BigDL 深度学习的Java化
SoCC ’19, November 20-23, Santa Cruz, CA
• 只支持CPU，不支持
GPU和异构加速器
• 重新开发深度学习模块，
不能复用TF中的功能
• Spark本身性能有缺陷
*
Trovato an
*Dai, J. J., Wang, Y., Qiu, X., Ding, D., Zhang, Y., Wang, Y., ... & Wang, J. (2019, November). Bigdl: A distributed deep learning
framework
for classi
big data. cation
SoCC pipeline
2019
Figure 1 : The end-
to-end text
(including data loading, processing, training, prediction, etc.)
and BigDL
24. 另一种尝试：Spark的Python化
• PySpark支持Dataframe和
SQL
• Koalas是Pandas的Spark封
装，现在已经被合并进入
Spark3.2
• PySpark在Spark用户中的使
用已经接近一半
• Python由于无静态类型，编
译优化方面有难度，在常见查
询中与Java性能有约50%的
落后
25. 融合大数据和AI生态的愿景
• AI将成为主要计算形式，数据处理
生态应该围绕AI来建设
• 研究支持数据处理的编译优化技
术，使PySpark性能达到native执
行的水平
• 加速器支持与弹性任务调度
• 一次编写，到处执行
26.