与原生Spark 3.0相比，我们在AI应用领域取得了明显的优化效果
介绍OpenMLDB及其相对于原生Spark的优势
背景介绍
Spark已经迅速成为大数据处理的事实标准，没有必要再介绍了，但Spark在AI场景下仍有很多不足之处。
- 好。原生Spark在Hadoop集群中擅长大数据处理
- 不足。SparkSQL的短板在特征提取领域逐渐暴露出来
- 不足。Koalas，Apache Spark上的熊猫API
即使SparkSQL和Koalas项目可以提供一些重要的数据处理功能，但对特征提取所需的功能支持仍然非常有限。支持的时间序列特征计算的性能并不令人满意。它只能支持离线分析，但对于人工智能生产，还需要在线计算。而且由于这个过程要反复使用UDF/UDAF，开源Spark和AI的整合还有很大的改进空间。
目前，业界出现了越来越多的原生执行引擎解决方案，如Databricks的Photon模块，英特尔的OAP项目，Nvidia的Spark-rapids项目，以及阿里巴巴的EMR服务。这些项目都有其亮点。它们可以通过底层的原生代码生成，充分利用CPU矢量化和GPU并行计算的特点，并在特定场景下显著提高Spark的性能。但仍有一些不足之处。首先，它只能支持离线计算和在线特征计算，以及人工智能场景落地所需的在线模型估计服务。其次，对于常用的时间序列计算功能（SQL Over Window）没有进一步优化，最后，对于AI场景，特征提取功能也缺乏支持。
几个Spark引擎的比较
图片由作者提供
于是我们发布了我们的OpenMLDB的项目（SparkFE是OpenMLDB的引擎）。它可以弥补上述项目的不足，在AI应用中取得更好的性能。基于LLVM的优化，性能比原来的Spark提高了6倍以上。
优势
- 基于LLVM优化，高性能表现比原来的Spark提高了6倍以上。
- 针对人工智能，扩展SQL语法，支持更多的FE函数和时间序列特征计算。
- 在线和离线一致性，通过时间序列数据库的窗口特征聚合计算，实现SQL的一键在线。
- 无迁移成本，兼容SparkSQL应用，Scala、Java、Python、R等应用无需修改代码即可享受性能提升。
- 所以，最后，无论是时间序列特征计算场景，还是机器学习的特定组表场景，最终的性能测试结果显示，OpenMLDB在不增加硬件成本的情况下，可以实现6倍到数百倍的性能提升。
时间序列特征提取。图片由作者提供
用于机器学习的自定义表连接。图片来源：作者
与原生Spark3.0相比的性能优化。
这里我们介绍一些OpenMLDB的应用场景，重点是性能优化方法。
第一个优化是原生窗口计算。
底层是基于C++的双向队列数据接口，有效地实现了标准的窗口和子窗口功能。扩展SQL实现的ROWS_RANGE边界，也可以更好地解决同一毫秒数据的计算顺序问题。本机窗口计算
- 本机窗口计算
- ➡性能提升
- ➡ ROWS_RANGE边界
- ➡带有联合表的窗口
- ➡ 处理微秒级的冲突
select trip_duration, passenger_count,
第二个优化点是本地LastJoin的实现。
这种扩展的Join类型可以保证表组装后的结果与拼接前的结果相同。在Spark源代码层面的原生实现可以比基于Spark 3.0的实现快一百倍以上，而且可以节省更多的内存。
SELECT t1.name FROM t1 LAST JOIN t2 WHERE t1.id == t1.id
LastJoin的性能。图片由作者提供
第三个优化点是对多窗口并行计算的优化。
将Spark默认的串行执行优化为并行计算，充分利用集群计算资源，SparkSQL整体任务时间也可以大大缩短。
SELECT
图片由作者提供
第四点优化是时间窗口的数据倾斜计算
与表格偏斜优化类似，窗口对偏斜数据进行了两次分割，大大提升了任务的计算并行度，充分利用了集群资源，降低了整体TCO（总体拥有成本）。
选择前，并行性：2.作者的图片
选择后，并行性：4.作者的图片
SparkFE（现在合并为OpenMLDB）有很多优化，不能重复。因为它与SparkSQL API兼容，所以应用场景与Spark相似，尤其是在AI相关的时间序列特征计算、数据表拼接方面。
- 时间序列特征提取
- 多窗口的并发性
- 自定义表连接
- 自定义特征提取功能
- 斜度优化
- 原生聚合函数
下面是OpenMLDB的架构，欢迎大家加入我们的社区。
图片由作者提供
与Native Spark 3.0相比，我们在人工智能方面取得了明显的优化效果》最初发表于Towards Data Scienceon Medium，人们通过强调和回应这个故事来继续对话。
