Data + AI Summit：数据工程和 AI 的结合

发表于 | 分类于

Databricks 在最近召开的 Data+AI Summit，发布了很多数据工程和 AI 相结合的功能和应用，每一个和数据相关的工程师都应该仔细看一看，AI 时代里，如何用 AI 赋能 DATA，以及 DATA 该如何服务 AI，是我们应该密切关注的领域方向。

Keynote 介绍

Keynote 部分由两天组成：

  • 第一天（Wednesday）主要由 Databricks CEO Ali Ghodsi 来主持，主要将今年 Databricks 计划展示的几个大 Feature 做了背景介绍，其中包括 LakeHouse、English Programming、Delta Live Table、Delta Lake 3.0 和 Unity Catalog；
  • 第二天（Thursday）的前半部分主要由 Databricks 的技术人员详细介绍了 Spark 和 Delta 的最新进展，后半部分主要是各个合作公司在 AI 方面的 PR；

Ali Ghodsi 提到了几个点，我觉得很有意思：

  1. Innovations dont’s become technology revolutions until they’re democratized.

Ali Ghodsi 在会议上将团队的使命定义为 democratize DATA + AI，并尝试解释为什么现在是做 Data 和 AI 结合最重要的时间点。

比如 Computing 技术在 1950s 出现，却在 1980s 随着 PC 而推广；Internet 在 1970s 出现，却在 1990s 随着 Web 浏览器技术而普及；同样可适用于 2012 年出现的 Deep Learning，可能在 2023 伴随着 Generative models 而有机会让每个人都能成为用户。

  1. Lakehouse unifieds Data and AI

Data 领域和 AI 领域的区别比我们想象的要更大，除了结构化和非结构化数据的区别，还有在技术栈、数据监管、计算范式等多方面的区别。Databricks 提出了 Lakehouse 的概念，以 Delta Lake 为底层存储， 通过 unify Data 领域和 AI 领域的 Catalog，在上层打造出了一体化的 Data + AI 产品。

这里提到的 AI democratized to every employee / product，是一个很好的产品化的理念，用 Python 跑一个训练模型的 demo 或许很简单，但是在工业界和实际的企业应用场景，随着人员分工细粒度化和部门职能垂直化，在 DATA 和 AI 领域分别会引入更多的垂直化技术和概念，能够完整理解 end-to-end 流程的工程师往往不会太多，更别提让更多其他工程师之外的同事来使用 AI 了。

本次 Keynote 其实并未介绍太多性能相关的话题，后面介绍的用 English 来 Programming，以及将 Data 领域和 AI 领域的资产统一到 Catalog 等功能，其本质上都是为了提升 AI 的易用性并扩大其生态。我在业界实践中观察到，Data 和 AI 领域各自有很多专业的人才，但却对彼此领域了解不足，导致很多合作无法开展，或是无法达到一个完美的预期，Databricks 做 Data 引擎和数仓场景起家，后续在 ML 上也做出了不错的产品，期待后续有更多亮眼的介绍吧。

核心 Feature 介绍

English as Programming Language

这是在最新版本 Spark release 的功能，Reynold Xin 在介绍的 PPT 有这样一段话：

data_ai_summit_5

English + Generative AI + Python，我们来看看当前这个组合是什么？ SQL / Java / Scala / Python + SQL Planner + JVM。如果 AI 时代，Data 领域的技术栈要向这几个方向发展，那对当前工程师的工作内容简直会是一次变革。

来看一下 Databricks 在这个新的 API 里能实现的功能：

  • Data Transformation
  • Visualization
  • Interpretability
  • Data Validation
  • …

从 Databricks Blog 里摘了几个例子：

(1) create dataframe and transform
spark_ai = SparkAI()
auto_df = spark_ai.create_df("2022 USA national auto sales by brand")
auto_top_growth_df=auto_df.ai.transform("top brand with the highest growth")
auto_top_growth_df.show()

(2) plot
auto_df.ai.plot("pie chart for US sales market shares, show the top 5 brands and the sum of others")

由于 English API 有 verbose 功能，所以我们能看到，English 最后是被翻译成了 Python / SQL 语言（可能有些类似 GPT-4 最新的 Code Interpreter 功能??）。以我的理解，其实这里面单独的例子拿出来可能在 LLM 时代都不会觉得有什么困难的点，但让我比较吃惊的是，他可以持续对话，并在之前结果上做出修改。

比如演示过程中，使用 English SDK 创建了一个 Spark PR 数随时间变化的趋势图：

data_ai_summit_1

然后有一个新想法，比如想在这个趋势图中加入 Spark Release 的版本信息和时间点，只需要给出恰当的 prompt，就能成功产生如下结果：

data_ai_summit_2

Demo 后 Reynold 也开玩笑的说，这个世界上能用 Python / PySpark 代码在 30min 内完成上面的功能实现，并且过程中不需要上网查询 API / 手册的人，可能只有几百人。

这个功能还是蛮惊艳的，理想态的话，数据处理 + 画图的工作如果能用 Prompt 替代，如今需求驱动的很多 Data Analyst 在未来，可能真的会失业。不过我也咨询了正在从事大模型行业的朋友，从技术原理上看，实现一个 demo，达到 Spark 的效果可能并不会难，并且 Spark 是个开源社区，文档和社区交互建设的都非常规范，有大量的训练数据可以使用，后续我有时间的话，也会尝试一下试试看。

Lakehouse AI: Fast, Easy and Cheap

data_ai_summit_3

Reynold 以数仓建模的实际场景为例，提出了 Fast、Cheap、Easy 三者无法同时兼容，两两组合，我们看看实际可行性：

  • Fast & Cheap：根据用户的查询模式，建立各种细粒度构建索引，尽量减小读写放大和存储冗余，分析各种查询 pattern，相当于是一次 fine-tune，无法满足“Easy”；
  • Fast & Easy：常规方式建立多种索引，引入额外 shuffle 和存储，无法满足“Cheap”；
  • Cheap & Easy：若不增加成本和不花时间来 Tune 数仓建模，通常都做不到 “Fast”；

同时回顾我们过去在数仓建模上的优化，大部分时间的优化都是在做性能和开销在不同使用场景的 trade-off，在 VLDB 的这篇文章中 How Good Are Query Optimizers, Really? 中提到，25% 的预估都是有大量偏差的。AI 时代中，优化器的工作似乎对 AI 是一个绝佳的应用场景，因为

  • 大量的 Query 信息；（数据量足够）
  • 复杂的分析场景；（参数多）
  • 通常使用场景的变化不会很快发生改变；（可预估）

使用 AI 建立了三个 Feature：

  • Indexless Indexes：
    • 用户不需要再手动指定 Partition By / Cluster By，AI 根据 HBO 自动预测 IO 情况智能化建立索引；
  • Automatic Data Layout Optimization：
    • 典型应用场景比如 File Size，自动合并小文件等功能，这里可以省去用户一大批的参数定义；
  • Intelligent Workload Management：
    • 自动调度能力，分辨高优和低优作业，无需用户做额外的资源隔离等操作；

虽然在 SUMMIT 中没有找到 Deep Dive 自动调优原理的 Talk，不知道在业务实际场景中应用如何，但 Reynold 提出的这个问题，确实在工作中深有同感。我们使用大数据组件时，除去开发的时间，基本上 80% 的时间都在调优，和考虑各种 trade-off 的优化， 而这种 trade-off 往往在未来某个时间点，随着业务升级和变化又要重新思考和重构。

Unity Catalog

在介绍 Unity Catalog 时，Ali Ghodsi 和 Matei Zaharia 反复提出这是 Databricks 相比于其他产品最出色的一点。Unity Catalog 指的是将放置在各处的碎片化资源，如 Hive Table、Models、Notebooks、非结构化数据文件，都通过统一的 Catalog 来进行管理。

data_ai_summit_4

进入到 Data + AI 更紧密结合的时代，Databricks 认为未来会有三个比较重要的应用：

  • Enterprise-wide reach：（Lakehouse Federation）
    • Databricks 对接了各个系统的元信息，并让用户和平台轻松实现跨产品的连接；使用统一的用户界面，用户无需跳转在各个产品之间，提升用户体验；
    • 举个例子：用户在接入 CDC 流时会同时使用 MySQL、Spark、Redis 作为数据源、处理框架、存储；在这个过程中，涉及到 3 个组件，是否需要频繁跳转和路由？通过 Unity Catalog 和适当的界面设计，可以做到用户的一站式开发体验；
  • Governance for AI：（Unity Catalog for AI）
    • 解决 AI 相关的治理问题，比如“怎么确定这个模型是可信的？”，“如果我删除一个字段会怎么样？”，比较典型的应用就是 Data 和 AI 之间的血缘信息；
  • AI for Governance：（Lakehouse Monitoring and Observability）
    • 由于 DATA+AI 的链路会涉及到 Data Engineer（Processing）、Data Scientist（Model）、Backend Engineer（Serving），彼此之间领域和技术栈都完全不同，监控和数据的流转需要血缘才能串联起不同的领域；

其他

  • Uni Form（Unify Formats）：兼容了 Hudi、Iceberg 的 metadata，用户可以 直接使用 Delta 来读写 Hudi 和 Iceberg 的 Table，同时不带来额外的损耗；
  • Spark Connect：为了方便用户调用 Spark，通过 gRPC 协议可以在任意地方把 Spark plan 上传并返回结果；

结语

这次 DATA + AI SUMMIT 凸显了两者结合在数据领域的潜力， LakeHouse、English Programming、Delta Lake 3.0 和 Unity Catalog 都是 DATA 和 AI 结合的产物。随着生成式 AI，以及 AI 的门槛逐步降低，数据工程领域的工程师们可以更多尝试 AI 应用的机会，未来 DATA 领域的开发模式会不会发生变化呢？vim