北京
上周，Apache Spark 4.2 发布了。比起版本号，这次更新真正值得关注的是它正在从纯粹的数据处理引擎，逐渐长成一套能够一站式支撑AI应用的基础平台。过去，工程团队要把数据搬来搬去、拼凑不同系统才能跑完的流程，在这个版本里开始被拉到同一个屋檐下。
变化的核心，是几项围绕AI工作负载设计的功能：可治理的业务指标视图、向量检索原语、更紧密的Python互操作性，以及让代理直接调用Spark引擎的机制。它们都指向同一个方向——让已经在用Spark的团队可以少维护几套系统。
先说治理指标视图。企业里最常见的麻烦是：同样一个“活跃用户数”，市场部、数据团队和算法组各自有一套定义。时间久了，报表对不上，AI应用如果直接消费这些数据，更会给出前后矛盾的结果。Spark 4.2 把“指标视图”提升成一等公民：组织可以在一个地方定义好某个业务指标，然后这个定义被所有查询所遵守。Spark引擎将维护正确的聚合语义，不管是谁、用什么方式查，拿到的都是一个统一的结果。
更具结构意义的更新是原生向量搜索。习惯RAG流水线的开发者都清楚，把数据从Spark搬到外部的向量数据库，再做嵌入和相似性检索，中间有多少磨损和运维成本。Spark 4.2 直接在SQL里提供了向量距离和相似度函数、向量标准化、向量聚合，以及一个名为NEAREST BY的操作符，用来做Top-K相似搜索。这意味着数据不需要离开Spark，就能完成从清洗、嵌入到检索的全过程，流水线被压缩在同一套平台里。
Python互操作性也被明显加强。新版同时支持Arrow C Data Interface和PyCapsule协议，Spark DataFrame可以直接传给Polars、DuckDB这类原生工具，而无须复制或序列化底层数据——只要双方都遵循同一套标准。此外，PySpark得到扩展，Arrow优化的UDF执行现在已是默认行为，Python数据源还内建了耗时和内存分析能力，让自定义连接器的调试舒服了不少。
另一个容易被忽略但很有想象空间的功能是Spark Connect。简单说，它让Spark引擎可以被外部代理程序调用。过去和分析型工具交互，需要走JDBC/ODBC或者RESTful包装，现在Spark Connect提供了一条更轻量的通道。当越来越多的AI代理需要直接问Spark要一份清洗后的数据、跑一个预定义的指标视图时，这种调用方式会大幅减少中间层。
在AI应用越来越依赖高质量、一致且低延迟的数据供给的趋势下，Spark 4.2 做出了一个清晰的表态：它不再只负责做好离线批处理和流计算，而是试图把自己的数据资产封装成API，把向量检索、指标治理和Python生态的协同都收拢进来。对于那些已经在Spark上建有大规模数据湖的团队来说，未来或许真的可以少维护一个专用向量数据库，因为检索、聚合和一致性保障，已经可以在原地完成。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
