AI与数据融合的

基础设施发展展望
陈文光 蚂蚁技术研究院 / 清华大学
 大数据：数据量，数据生成的速度和多模态
•物联网、边缘设备和用户
行为产生大量数据
•数据量(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/
 典型数据处理链路
Apps
实时链路

Database Queue RealTime ETL OLTP

(MySQL) (Kafka) （Flink,SPARK) （Hbase, KV,ES)

ETL
DataLake
离线链路
（Flink,Spark
（MPPDB，HDFS)
+HUDI)

Analysts OLAP
（Presto,CK)
 数据处理的深度也在增加

https://medium.com/hackernoon/the-ai-hierarchy-of-needs-18f111fcc007
 典型数据+AI处理链路
Model Serving
(PyTorch,TF)
Apps
实时链路
Online Model
Update
(PyTorch,TF)
Database Queue RealTime ETL OLTP
(MySQL) (Kafka) （Flink,SPARK) （Hbase, KV,ES)

ETL
DataLake
离线链路
（Flink,Spark
（MPPDB，HDFS)
Batch +HUDI)
Training/Test
(PyTorch,TF)

Analysts OLAP
（Presto,CK)
 主要挑战
• 在线离线一致性

• 基于JVM的数据处理系统的性能问题
• 123

• 大数据处理与AI融合问题
 问题1. 在线离线一致性问题
在线模型（策略）表现与离线不一致
• 数据不一致
• 模型效果不一致
Model Serving
(PyTorch,TF)

Apps

Online Model
实时链路
Update
(PyTorch,TF)
Database Queue RealTime ETL OLTP
(MySQL) (Kafka) （Flink,SPARK) （Hbase, KV,ES)

ETL
DataLake
（Flink,Spark
（MPPDB，HDFS)
Batch
+HUDI) 离线链路
Training/Test
(PyTorch,TF)

Analysts OLAP
（Presto,CK)

https://medium.com/hackernoon/the-ai-hierarchy-of-needs-18f111fcc007
解决方案 – 以蚂蚁集团图计算为例
基于图的风控解决方案（全图风控）架构 1
Message
Application
Queue

在线近线数据不一致
Data Streaming 模型效果不一致
Serving Write
TuGraph TuGraph TuGraph
Dataflow Dataflow
DB

Rule based Decision Making

Serving
Decision Engine Historical
Playback

TuGraph DB :分布式图数据库，支持自定义图查询语言GQuery
TuGraph Dataflow: 流图计算系统，支持Gremlin
 解决方案 – 以蚂蚁集团图计算为例
基于图的风控解决方案（全图风控）架构 2，支持探索-仿真-上线的一致性
Message 保证在线近线数据一致
Application
Queue
• 以在线数据库内容为准，
同步到近线系统
Data Streaming
Serving
TuGraph
Write
TuGraph TuGraph 在线近线系统使用同样
Dataflow Dataflow
DB
的查询语言
• 避免不同语言语义的不一
Rule based Decision Making 致性
Serving
Decision Engine Historical • 很多细节，比如Nodelimit
Playback

TuGraph DB :分布式图数据库，支持国际标准图查询语言ISO-GQL
TuGraph Dataflow: 流图计算系统，支持国际标准图查询语言ISO-GQL
 问题2.基于JVM的数据处理系统的性能问题

• Spark处理性能较差 单机
Spark
单线程C++ 多线程
C++
时间(秒) 186 458.99 15.54
• C++手写Word Count与Spark的
Word Count相比，单机加速比12倍 WC-R PR-R PR-F KM-R KM-F
虚函数调用 25.1 20.3 8.7 0.9 20.7
• Java运行时： 迭代器 4.1 1 6.6 0 0
Java运行时带来了较高的数据对象 装箱/拆箱 0.3 3.2 9.9 0.2 0
转换开销。例如，序列化/反序列 序列化 0.4 2.2 14.6 0 0
化 总计 29.9 26.7 39.8 1.1 20.7

• Spark执行策略： 用VTunes分析3个大数据负载（单词计数WC、网页排名PR、
Spark每次仅处理一个元素的执行 聚类分析KM）的计算热点
策略带来了较高的函数调用开销 配置：2路E5-2680 v4、256GB内存、
https://github.com/deepmind/pg19 44GB文本数据集
 问题2.基于JVM的数据处理系统的性能问题
内存占用多
内存使用量（GB）

• 1000

900

800

700

• 图计算迭代算法上Spark需要的内存容量是原 600

始数据集的20倍[1] 500

400

300

• 内存消耗多原因主要来自Java运行时： 200

100

0
enwiki-2013 twitter-2010 uk-2007-05 weibo-2013 clueweb-12

• 不紧凑对象排布： GraphX PowerGraph Gemini

图计算内存用量比较
例如，右图三元组表示的边需要76字节，
比数据本身所需的16字节膨胀了近5倍

• 垃圾回收内存管理机制:
为了避免频繁垃圾回收需要预留内存 header 指针 数据
Java三元组内存排布示意图
[1] Zhu, Xiaowei, et al. "Gemini: A Computation-Centric Distributed Graph Processing System." OSDI. 2016.
 新型大数据处理内核“诸葛弩”*
• 设计理念

• 效率优先：Spark虽然强调可扩展性但是忽视了执行效率。

• 灵活性优先：提供用户更多定制、控制的机会，为高效支持各种应用提供基础。

• 新设计试图解决Spark RDD存在的问题

• 采用native语言（C++）缓解Spark运行时环境带来的问题

• 针对Spark RDD逐个元素处理模式带来的开销问题，Chukonu设计了常见数据
的紧凑数据表示，并利用编译优化来进行高效批处理
*图片来自： https://www.deviantart.com/master-artcher/art/Chu-Ko-Nu-105615698
 实施策略
• 选项1：完全重建大数据生态

• 性能好，但构建成本高

• 选项2：只替换Spark RDD核心部分�

• 效率高，功能完善，假设Spark除核心外的其它部分没有问题
支持SQL
性能评估 – 非结构化数据
性能评估 – 图计算
性能评估 – 机器学习
性能评估 – 内存占用
性能评估 – TPC-DS
 问题3. 大数据处理与AI融合问题
• AI计算在数据中心的比例将持续显著增加，主要是Python生态
• 分布式大数据处理主要是Java生态
• “小数据”处理主要是Python生态
AI 大数据处理 小数据处理
处理器 GPU或AI加速器 通用CPU CPU
网络 NVLink + 10Gbps – 25Gbps -
IB/100Gbps+
主要编程语言 Python Java / Scala Python
编程框架 PyTorch,Tensorflow, Spark, DataFrame Pandas，Numpy，
PaddlePaddle SciPy,Notepad

AI和大数据处理在硬件层面也有很大差别
 数据与AI独立生态的问题

Spark TF/PyTorch Spark

预处理 神经网络 后处理

• 两类软硬件生态的开发、调试、部署和维护都更加复杂
• 系统间数据传输开销降低性能
• 需要招聘两类程序员，或精通两者的程序员
 一种尝试：BigDL 深度学习的Java化 SoCC ’19, November 20-23, Santa Cruz, CA
* Trovato an

• 只支持CPU，不支持
GPU和异构加速器

• 重新开发深度学习模块，
不能复用TF中的功能

• Spark本身性能有缺陷

*Dai, J. J., Wang, Y., Qiu, X., Ding, D., Zhang, Y., Wang, Y., ... & Wang, J. (2019, November). Bigdl: A distributed deep learning
Figure 1 : The end- framework for classi
to-end text big data.cation
SoCCpipeline
2019 (including data loading, processing, training, prediction, etc.)
and BigDL
另一种尝试：Spark的Python化
• PySpark支持Dataframe和
SQL

• Koalas是Pandas的Spark封
装，现在已经被合并进入
Spark3.2

• PySpark在Spark用户中的使
用已经接近一半

• Python由于无静态类型，编
译优化方面有难度，在常见查
询中与Java性能有约50%的
落后
 融合大数据和AI生态的愿景
• AI将成为主要计算形式，数据处理
生态应该围绕AI来建设

• 研究支持数据处理的编译优化技
术，使PySpark性能达到native执
行的水平

• 加速器支持与弹性任务调度

• 一次编写，到处执行