挑战 Spark 和 Flink？大数据技术栈的突围和战争｜盘点

编辑｜Tina

十年的轮回，正如大数据的发展一般，它既是一个轮回的结束，也是崭新的起点。大数据在过去的二十年中蓬勃发展，从无到有，崛起为最具爆炸性的技术领域之一，逐渐演变成为每个企业不可或缺的基础设施。然而，在这个时刻，我们不禁要问：当前的大数据架构是否已经趋于完美？2023 年，伴随着人工智能的跃变式爆发，数据平台将如何演进，以适应未来的数据使用场景？

这并非简单的问题，更是一个关乎企业生存与发展的命题。在过去的十年中，我们目睹了 Spark、Flink 和 Kafka 等系统的崛起，它们成为大数据领域的支柱。然而，现在是否有新的力量崭露头角，希望挑战它们的地位？2023 年，大数据领域有哪些实质性进步吗？

在 2023 年年终盘点之际，InfoQ 有幸采访了大数据领域的资深专家，包括 关涛、李潇、王峰（莫问）、吴英骏、张迎（按姓名拼音排序）。他们共同探讨了数据堆栈技术的演变过程，深入剖析了技术快速演变所带来的挑战。在这次专访中，我们将揭示技术变革的背后原因和逻辑，为大家呈现大数据领域的现状以及未来可能的发展方向。

流存储 Kafka 诞生在 2011 年，而流计算 Flink 到今年也刚好满了十年。

十年前，软件范式是利用虚拟化技术来发挥硬件性能。此外，云服务也只是刚刚兴起，存算分离等云原生概念尚未普及。

如今时过境迁，一切都在快速变化。当今的应用程序每天可以处理多达数万亿个事件，维护数 TB 的数据。硬件的迭代速度飞快，相对十年前的 SSD，NVMe 速度提升十倍，价格也降至原来的 20%。S3 越来越多地被用作基础设施服务的核心持久层，而不仅仅是作为备份或分层存储层，例如 Snowflake、Databricks 等。

对象存储是云时代的产物，支持原始数据存储、分布式可扩展、高灵活性、低价，都是对象存储之所以被选择的原因。可以预计在未来会有更多的数据业务完全基于对象存储而构建。

--2021 年，滕昱《使用对象存储，数据湖才能重获新生》

这也给一些初创公司带来了巨大的机会：不需要用分层架构去实现存算分离，而是干脆用更加极端点方式去做存算分离，即直接建立在 S3 对象存储之上。

基于对象存储的构建也大大降低了构建新数据系统的门槛，催生了一系列这样的“垂直”基础设施初创公司：今年诞生的兼容 Kafka 的 WarpStream、AutoMQ，去年拿到 A 轮融资的 Neon Database、流数据库 RisingWave，等等。

然而 S3 虽然价格便宜，能省成本，但高延迟是一个问题，数据系统构建者需要费点周折才能处理好需要低延迟的工作任务。恰好在今年底，AWS 发布了 S3 Express One Zone，一种新的低延迟 S3 存储类别，可以说是在正确的时间提供了正确的技术（目前价钱昂贵）。

推动数据库和数据产品发展的主要因素主要有两方面。一方面是数据本身，另一方面是硬件的发展。S3 是硬件层面的变化，这势必会给大数据领域带来巨大的变革。

众所周知，在数据库的历史上，每次存储介质的变化都会引发软件的变革。

--2023 年，曹伟《数据库的下一场革命：进入对象存储时代》

“低延迟 S3 的发布，对于我们这些从事数据基础设施业务的人来说，这是今年最大的一个新闻。”RisingWave（risingwave.com）创始人 & CEO 吴英骏认为。

站在当前的时间点，对于大数据系统的易用性问题，采访嘉宾给出了“不够好”、“不够便宜”，“太过复杂”的评价，可以说当今的大数据技术栈是公认的“难用”。

大数据架构在过去漫长的 20 年里经历了从场景到系统的完整迭代。

大数据的起源可以追溯到谷歌的 MapReduce 框架，这标志着大数据的最初阶段。在此之前，数据库方面主要有一些顶级产品，如 Oracle、SQL Server 和 IBM DB2。Google 提出了一个通用的、折中的方案，即不必购买 Oracle、DB2 或 Microsoft Server，使用简单的模型让大规模并行计算在拥有大量普通计算机的科技企业中变得可行：利用 MapReduce，不使用数据库，就能完成大数据计算，只不过用户需要去承担这些复杂性。

这里还有个大家可能忘却的典故：数据库专家 David DeWitt 与 Michael Stonebraker（同样是图灵奖获得者）在 2008 年发表了《MapReduce: A major step backwards》，对 MapReduce 进行了批评，称其为开历史倒车。

要充分利用这些资源，MapReduce 提出的方法是，将底层编程接口封装成 Map 和 Reduce 函数之后，便直接暴露给有编程经验的用户，让用户自己实现具体业务逻辑，并自己可以操控程序并行度等细节。用户不再是使用 SQL，而是使用 C 或 Java 等编程语言，需要承担编写底层代码的复杂性，处理更多的编码工作，这也意味着很高的学习壁垒，让许多人望而却步。

在这期间，批处理和流处理在 Spark 和 Flink 的引领下率先成熟。

截图来源：https://zhuanlan.zhihu.com/p/662659681

近几年，交互分析，也称直接在线服务能力（Operational Analytics） 随 Clickhouse 等通用实时数仓流行，并已是事实上完成主流客户的部署。随流、批、交互三类计算场景成为标配，Lambda 架构也成为（国内的）事实标准。Lambda 架构能够满足客户场景上的诉求，最大的缺陷就是复杂：数据开发、组件运维、数据管理均复杂。

毕竟并不是所有公司都跟 Google、Facebook 或 Twitter 这样的大型科技公司一样，拥有强大的工程团队，能够管理复杂的流处理系统来实现他们的需求。也并不是所有用户都像阿里和拼多多这样有着非常大的数据量，复杂的分布式系统阻碍了十几或几十个人的小公司或一些传统企业的采用，对它们来说，这是一件成本高、挑战大的事情。

吴英骏认为，大数据架构里，如流处理，应该回归第一性原理了。

“现在的系统，诞生于十年前，与当下云时代设计的系统相比，从本质上来说肯定是不同的，这表明大数据生态在这十年间并没有取得实质性进步。”

“在当前时刻，我们再设计这个系统时，肯定会思考能否基于现有系统实现性能提升。”

语言层面，新系统需要提供一个更高层次的语言，比如 SQL 或 Python。另外，云上最核心的一个点在于“存算分离”，站在现在这个时间节点上，新一代的系统从设计上的第一天开始就应该是“存算分离”的。跟分级存储架构不一样，现在的系统可以将所有数据直接放到 S3，而不仅仅是将历史数据放到 S3，那么这样就可以更加极端的去实现存算分离，设计、实现和运维自然都会更加简单。

RisingWave 于 2023 年 6 月发布了 1.0 稳定版本，并通过数月的大量性能测试，得出了“比 Flink 快 10 倍”的结论。

“性能比较不是关键，易用才是关键。基于对象存储并能在性能和效率方面取得提升，那肯定是因为整体基础架构正在发生变化，这是一个核心点。”

“简单易用”同样是 Spark 社区的主要发力重点。在 Databricks 今年的 Data and AI Summit 主题演讲中，Reynold Xin 谈及了三个 Spark 社区在易用性的最新进展。

首先，需要提供一套简单好用的 API。Python 和 SQL 已经成为了整个数据处理行业的主流语言。在过去几年，Python 已成为 TIOBE 指数显示的排名第一的编程语言，这种受欢迎的原因来自于它的简单性和易学性，使其成为初学者和专家的首选语言。Python 的广泛库和框架简化了数据分析和机器学习中的复杂任务。各大数据系统都提供了它自己的 Python DataFrame APIs。PySpark 的 PyPI 下载量（https://pypistats.org/packages/pyspark）仅在 2023 年最后一个月就达到了来自 169 个国家的 2800 万次下载。为了方便 pandas 用户，PySpark 也提供了 pandas API 的支持。可以说，API 的简单易用已是大势所趋。特别值得一提的是，即将发布的 Spark 4.0 版本中，一个全新的 Python 的数据源接口被特别设计来强调易用性。这一更新将使 Python 用户更加轻松地创建和管理自己的数据源，进一步增强 Spark 平台的用户友好度和灵活性。

Spark 社区在这方面继续发力，过去一年的一个主要项目，Spark Connect，引入了一种分离的客户端 - 服务器架构，允许从任何地方运行的任何应用程序远程连接到 Spark 集群。这种架构的改进涉及到了稳定性、升级、调试和可观测性多个方面。Spark Connect 使得用户可以在他们喜爱的集成开发环境（IDE）中直接进行交互式的调试，并且可以使用应用程序自身的指标和日志库进行监控。

其次，一个稳定成熟的数据系统必须具备一套稳定的 API，这也是 Spark 社区对 API 行为和语义的变更制定严格规范的原因，目的是让用户更顺畅地升级至最新版本。在上个月，最流行的 PySpark 版本就是最新的 Spark 3.5，这体现了用户始终倾向于使用最新版本的趋势。为了迎合这一趋势，Spark 社区努力保证向后兼容。

此外，错误信息的标准化也是 Spark 社区过去一两年里的努力方向。尽管这看似技术复杂度不高，但这实际上是使系统更加简单易用的基本需求。今年的 Spark 4.0 release 还会进一步标准化日志，以使用户能够更好地进行系统调优和代码调试。

而随着生成式 AI 的发展，未来 API 将变得更加简单易用，自 ChatGPT 大流行到现在，我们发现它已经对 PySpark 有了深入的了解。这得益于 Spark 社区在过去十年里提供了丰富的 API 文档、开源项目和教学资源。Spark 社区开发了一个叫做 English SDK 的项目，将 Spark 专家的知识融入到 LLM 中。这样一来，用户就可以通过简单的自然语言指令来操作 PySpark，而不需要自己写复杂的代码。这种方法让编程变得更容易上手，学习过程也更简单。

从 2014 年诞生之后，Flink 已经确立了其在全球实时流计算领域的地位。阿里、Amazon、Azure、Cloudera、Confluence 等众多企业都提供了支持和托管服务。

树大招风，实际上今年不止一家企业宣称在流处理技术上实现了 10-1000 倍的效率提升，如果这些技术确实可以在生产环境得到验证，像阿里、腾讯、抖音这样的大型公司每年可能会节省数十亿的机器成本。尽管目前还没有看到哪家公司在真正的生产环境中实现了这一效果，但这一趋势表明流处理技术的不断创新将在未来带来更多的机遇和成果。与此同时，Flink 的发展现状 和未来演进则更加引人关注。

事实上，Flink 一直在不断完善和创新。Kafka 已经在商业版中实现了一个“分级存储”架构来实现了存算分离的改造。同 Kafka 一样，Flink 也会从存算耦合转为存算分离的架构。

据莫问介绍，目前 Flink 也在不断学习和自我革新，2024 年将是 Flink 项目的第一个十周年，Flink 社区也会发布 Flink 2.0 新的里程碑，彻底的云原生存算分离架构、业界一流的批处理能力、完整的流批融合能力都会是全新的亮点。

莫问认为，随着云原生概念的逐步普及，未来主流的计算负载一定是运行在 Cloud 上，全球范围内都是这个趋势，因此大数据架构也需要更好地适配云底座，利用好云的弹性优势。存算分离将会是未来大数据架构的标配，不过存算分离在带来了诸多好处的同时也带来了额外的性能挑战，目前看来在对 latency 敏感的场景下，多级缓存和冷热分层将是对存算分离架构的有益补充，2024 年将发布的 Flink 2.0 也会采用这套最新的架构。

分级存储侧重于在计算节点上进行缓存，远端存储主要存储历史记录。相较之下，新的直接建立在 S3 上的系统将所有数据完全存储远端，但也会造成性能的下降，这需要在产品设计方面去做一个权衡。

在存算分离上，Flink 会有一个迭代的过程，吴英骏认为，“大家的最终思想都是统一的。如果我们将时间拉长，放到五年之后，我们可能会看到这两种系统实际上非常相似。在未来发展中，双方都会在自己的短板上进行弥补。比如说，RisingWave 从第一天起就将内部状态放在对象存储上，而这意味着 RisingWave 需要思考如何降低对象存储所带来的高延迟问题。而对于 Flink 来说，面临着使用本地磁盘存储状态而导致的大状态管理困难的问题。它可能需要引入一个分级存储的架构，来降低处理大状态计算时的资源消耗，同时避免系统直接挂掉。”

“但在目前一两年里，这两种系统在架构上仍然会有相当大的区别。架构的调整不是一朝一夕能够完成的。”

新兴软件和成熟软件之间有了较量，那么用户进行选型时，会关注哪些因素呢？

作业帮于 2019 年底调研 Flink 1.9 版本，并在 2020 年内部搭建了实时计算平台，现在流和批都在几千任务的规模。其大数据架构师张迎表示，选型时，主要根据业务诉求，结合多云融合能力、成熟度、已有技术积累、云厂商的支持力度、成本等综合考虑。

这几年使用大数据技术栈时主要有两点比较强的感受：生产环境的可用性、周边系统的建设，这两点一定要跟得上。一个用户可以写出来几百个 SQL 任务，但是出了问题往往不知道如何追查和改进。后面的工作，例如调优、自动化测试、日志、监控报警、高可用也都是围绕这类需求展开的。

原来需要写代码的实时任务，很多可以通过 SQL 完成。（在 2015 年后，随着流处理的成熟，流计算引擎纷纷选择了支持 SQL 通用编程语言）。SQL 越来越复杂，配置越来越多，一定程度上还是将复杂度留给了数据流的构建者。“对于简单的数据流，开发和运维都变得更简单了。而对于复杂且重要的数据流，我们的态度也一直是谨慎保守为主，避免盲目求新。”

关于 SQL 的说法，跟莫问预测流处理引擎未来进化方向之一是一致的，即：“全面 SQL 化，提升体验，降低门槛”。大数据处理从离线向实时升级的趋势已经确立，大量行业已经开始实时化升级，并取得非常好的业务收益。为了让更多用户能够享受到实时流计算带来的价值，流处理引擎需要进一步提升端到端的易用性，全面 SQL 化 ，提升用户体验，降低使用门槛，让流计算能够在更多场景和行业中被生产使用起来。

云原生架构的不断发展，也同步推动了数据湖存储方案的加速落地。数据湖具备的开放和成本优势，必然使得越来越多的数据流入湖中，从而成为天然的数据中心，湖上建仓的 Lakehouse 架构正在成为主流，下一步客户一定是希望数据在 Lakehouse 中能够更加实时的流动起来。

Apache Paimon 是从 Flink 社区中孵化出来的新项目，定位就是流批一体实时数据湖格式，解决 Lakehouse 数据实时化的问题。

基于 Flink + Paimon 可以构建出新一代的 Streaming Lakehouse 架构，让 Lakehouse 上的数据可以全链路实时流动起来。此外，基于计算和存储端到端流批一体的特性，也更加方便用户在 Lakehouse 架构上实现实时离线一体化的数据分析体验。

“Paimon 是一个好的尝试，”关涛对此评论道。

之前 Flink 流批一体缺乏对应的存储系统配合：Flink 自带的状态存储无法满足批处理通用数仓的需求，Paimon 则是补全这个短板的关键。

莫问指出，在实时流处理这条链路上，确实也存在一些新的机会和变化。众所周知，Flink 和 Kafka 目前已经分别成为流计算和流存储的事实标准，但 Kafka 真的是最适合流分析的存储方案吗？

Kafka 和很多消息队列类似，都是一种消息中间件，而非为大数据分析而生。例如：Kafka 并未对数据提供结构化的 Schema 描述， 也无法提供完整的 Changelog 语义，且 Kafka 中的数据时无法进行实时更新和探查分析的。

“但以上这些缺陷，都是实时流分析需要的特性和能力，我们也正在思考这个问题，并探索新的解决方案，希望能够在明年发布一款更加适合流分析的流存储技术。”

近些年各种不同的大数据基础设施雨后春笋般的涌出，一方面为用户提供了多样化的选择，但另一方面也为用户带来了幸福的烦恼。通常情况下，用户要搭建一套大数据业务系统，需要非常多的核心技术组件才能完成，少则三到五种，多则五到十种，这主要带来以下几方面的问题：

1. 技术组件繁多，必然提升系统架构的复杂度。通常来讲，系统稳定性风险和系统复杂度成正比，过于复杂的体系必然带来更大的稳定性隐患；

2. 每一项技术组件都需要有对应的专家来运维管理以及客户支持，对于中小企业来说，这必然带来高昂的人力资源成本；

3. 过多的同质化组件存在，也会为用户带来选择的困扰，并行保留多个同质化组件不仅给运维团队带来了额外的运维负担，也给开发者带来了额外的学习成本。

因此，未来数据技术的演进会逐渐出现一些整合的趋势，走向更加简洁的架构，核心目标不仅是让每个组件运行得更快，还需要考虑为用户提供更加简单、一致性的开发体验，以及全局最优的运维成本。

从 Lambda 架构到 Kappa 架构的演进。 当前数据分析平台的典型架构是 Lamdba 架构（由三层系统组成：批处理 BatchLayer，流处理层 Speedlayer，服务层 Servinglayer），随批、流、交互三种引擎诞生和成熟组装而成。这种架构的典型缺陷，包括复杂度高，数据冗余度高，学习成本 / 开发成本高等等。针对 Lamdba 架构的缺陷，Kappa 架构应运而生。但多年过去了，Kappa 架构仍然更像是参考架构，并没有很多引擎 / 平台做到 Kappa 架构的要求。2023 年是个拐点，除了部分已有引擎开始拓展边界相互渗透，还有一些新的设计和计算模式被提出。例如云器科技提出“通用增量计算”的新计算范式统：Lambda 架构到 SingleEninge，用一个引擎覆盖流批交互三种模式。

目前业界主流的几款 Streaming、Batch 和 OLAP 引擎都开始相互渗透，例如：Flink 在发力流批一体、流批融合计算能力，Databricks 也基于 Spark 和 Delta 推动了 Delta Live Table 淡化流批的差异，StarRocks 在提供 OLAP 极致查询能力的同时，也开始通过物化视图形态提供对数据湖上数据的 ETL 处理能力。本质上各大主流计算引擎都在不断扩展自己的能力边界，淡化流、批、OLAP 边界，希望为用户提供全场景一致性的数据分析体验。这也是技术发展的必然趋势，各家都会逐渐补齐短板，但也都有各自核心的优势。

在最近几年的数据技术趋势演进的路线中，我们可以清晰的看到两个趋势变化 ：一是数据架构的云原生化。 几乎所有的大数据公司都选择了拥抱云原生，推出了基于多云的 PaaS/SaaS 计算服务，从 Serverless 到 BYOC，为用户提供了在云上不同类型的托管服务。二是数据分析的实时化。 在技术上，数据的“实时化”包括了两个因素：数据的新鲜度，以及数据的查询速度。用户也不再盲目地只追求速度，而是更注重新鲜度、性能和成本的平衡。在时效性上， Iceberg 赢得了更多关注，数据湖存储技术为我们提供了构建近实时（near-online）数仓的可能性，在成本不变的情况下可以支持更快、更多的流量数据。

数据集成上，SeaTunnel 成功毕业，Flink CDC 3.0 演变成以 Flink 为基础的端到端流式 ELT 数据集成框架。比如作业帮目前主要在使用 SeaTunnel 以降低异构数据源间数据处理的开发成本。

社区希望能表格式能够统一，但实际还有一段路要走。

Lakehouse 平台在数据仓储领域的使用正迅速增加。这反映了一个重要的趋势：组织正从传统的数据处理平台过渡到更加灵活、集成和效率更高的现代数据架构。据 2023 年 MIT Technology Review Insights 报告，全球 74% 的首席信息官（CIOs）表示他们已经在使用 Lakehouse 架构。自 Databricks 在 2020 年推出此概念以来，Lakehouse 作为一个新类别得到了广泛的采纳。几乎所有还未使用 Lakehouse 的首席信息官都计划在未来三年内部署此类平台。

有专家认为，Lakehouse（湖仓一体）和 Iceberg 表格式已成为事实标准。但是，当前根据 Slack users、 Github Stars、Github PRs、Github Forks、Issues 各个指标显示，Delta、Hudi 和 Iceberg 还是三分天下。虽然 Delta、Iceberg 和 Hudi 起源地不同，但是各个社区都在努力地提升开源社区的活跃度，让用户社区和开发者社区更加健康的发展。随着社区的竞争加速，基础功能的差异在不断减少。

三种表格式（Table Format）均基于 Apache Parquet 数据格式，但这些格式各自会创建出相似、但又不尽相同的元数据，从而影响数据向应用程序和分析工作负载的表达方式。结果就是，Delta、Hudi 和 Iceberg 之间存在一定的不兼容性。表格式的最终统一还有难度，未来还得看哪种表格式能给出更好的性能、更好的易用性和更持续的创新能力，接下来的一年肯定更加精彩。

头部的云厂商的产品都或多或少地支持不同的表格式。Snowflake、BigQuery、Athena 都已支持 Iceberg，而微软和 Databricks 都以 Delta Lake 为主要存储格式。因为当前数据处理引擎的格式支持缺陷，用户不得不将数据以不同格式存成多份。格式的兼容性读写会是未来一个值得关注的方向。比如 10 月份发布的 Delta Lake 3.0 增加了 Delta UniForm 通用格式，Delta Uniform 自动为 Iceberg 和 Delta Lake 生成元数据，提供了一个实时数据视图，而底层它们共享的同一份 Parquet 数据，因此用户可以避免额外的数据复制或转换。另外，同时能支持 Hudi、Iceberg 和 Delta Lake 的元数据自动转换和生成的 XTable 也于 2023 年底正在申请进入了 Apache 孵化器。

无论是大公司还是小公司，大家都渴望从生成式 AI 的热潮中分到一杯羹。当然，作为大公司，无论是 Databricks 还是 Snowflake，它们确实更有实力来进行生成式 AI 的开发。

今年 Databricks 不仅率先发布了开源可商用的大模型 Dolly，还于 6 月底宣布以 13 亿美元的价格，收购生成式 AI 公司 MosaicML 。

在 LLM 服务方面，对数据栈的依赖主要集中在知识库的构建和查询上，包括但不限于向量数据库。有人认为在短期内很难看到深层次 AI 对数据湖或数据仓库方面带来重大变革，但也有人认为数据是服务于 AI 的：大数据是燃料，大模型训练已经涵盖了大量已有的大数据技术，而数据湖则作为存储系统在其中扮演重要角色。

Databricks 李潇对此也进行了解释，他认为数据湖仓（Lakehouse）的作用是为 GenAI 提供了一个集中、高效和可扩展的数据存储和管理环境。它结合了数据湖的灵活性和数据仓库的高性能，支持结构化和非结构化数据的存储和处理，这是 AI 应用的数据需求的基石。

“今年，Databricks 的最大进展主要体现在将人工智能集成到数据平台中。“

作为大数据行业里一个非常重要且典型的企业，Databricks 在 GenAI 也反映了整个大数据行业的技术演进。现在我们可以通过它在数据智能平台投入来看看生成式 AI 将对数据和分析产生的影响。

Databricks 是由一群 Apache Spark 的原创者所创建。Spark 的诞生阶段，始于 2010 年，标志着 Hadoop 技术时代的结束。它的出现大幅降低了大数据处理的门槛，使得大数据开始与机器学习和人工智能结合，成为统一的分析引擎。2020 年，Lakehouse 架构的推出打破了传统数据湖和数据仓库的界限。Lakehouse 架构结合了数据湖和数据仓库的最佳元素，旨在降低成本并加速数据及人工智能项目的实施。Lakehouse 架构建立在开源和开放标准之上，它通过消除历史上复杂化数据和 AI 的孤岛，简化了数据架构。

而现在，则是到了生成式 AI 大潮下的 Lakehouse 阶段。Databricks 构建了一个基于数据湖仓（Lakehouse）的数据智能平台（Data Intelligence Platform），该平台的目标是实现数据和 AI 的平民化，使用自然语言极大简化了数据和 AI 的端到端体验。它利用生成式 AI 模型来理解数据的语义，并在整个平台中应用这种理解。可以让用户可以在保持隐私和控制的同时，从头开始构建模型或调整现有模型。

同时，Databricks 还提供了 Unity Catalog 数据治理工具来确保数据的质量和安全。Databricks 还于今年推出了 Lakehouse Federation (联邦查询) 的功能，用户可以跨多个数据平台（如 MySQL、PostgreSQL、Snowflake 等）发现、查询和管理数据，而无需移动或复制数据。另外，Databricks SQL（Lakehouse 上的无服务器数据仓库）使用量也获得了大幅增长。

Databricks 认为，在不久的未来，每个领域的赢家都是那些可以最有效利用数据和 AI 的，并坚信对数据和 AI 的深刻理解是每个赢家的必备技能。

未来的大数据架构将是一个高度集成、智能化和自动化的系统，它能够有效地处理和分析大量数据，同时简化数据管理和 AI 应用的开发过程，为企业提供竞争优势。

“未来的大数据架构，我们可以称为‘数据智能平台（Data Intelligence Platform）’。它正是顺应了两个主要趋势：数据湖仓（Data Lakehouse）和生成式人工智能（AI）。”李潇表示。

这一架构建立在数据湖仓的基础上，它提供一个开放、统一的基础，用于所有数据和治理，由一个理解用户数据独特语义的数据智能引擎 (Data Intelligence Engine) 驱动。这是相对现有 Lakehouse 架构下的，最大的突破。

智能化方面，这个引擎能理解客户数据的独特语义，使平台能自动优化性能和管理基础设施。操作简化方面，自然语言大大简化了用户体验。数据智能引擎理解客户的语言，使搜索和发现新数据就像询问同事一样简单。此外，自然语言还助力编写代码、纠错和寻找答案，加速新数据和应用程序的开发。

在隐私保护方面，数据和 AI 应用需要强大的治理和安全措施，尤其是在生成式 AI 的背景下。提供一个端到端的机器学习运维（MLOps）和 AI 开发解决方案，该方案基于统一的治理和安全方法。这允许在不妥协数据隐私和知识产权控制的情况下，实现所有人工智能目标。

总的来说，未来的大数据架构将更加重视智能化、操作简化和数据隐私，为企业在数据和 AI 应用方面提供竞争优势。这将使企业能更有效地利用数据，推动创新，同时保护数据安全和发展 AI 技术。

关涛，云器科技联合创始人 &CTO

李潇，Databricks 工程总监、Apache Spark Committer 和 PMC 成员

王峰（莫问），Apache Flink 中文社区发起人、阿里云开源大数据平台负责人

吴英骏，RisingWave（risingwave.com）创始人 & CEO

张迎，作业帮大数据架构师

在 2023 年结束之际，InfoQ 编辑部重磅推出“年度技术盘点与展望”专题，聚焦 AIGC 引发的变革，与 50 多位头部专家深度对话，希望能为你揭示架构、前端、运维、大数据、云计算、编程语言、数据库等领域的核心变化和演进逻辑，明晰金融、汽车、制造、零售等行业的数字化、大模型应用思路和路径。