大模型、实时需求推动湖仓平台走向开放

大模型、实时需求高涨

AGI 时代，以 ChatGPT、Midjourney 等为代表的大模型迅速应用加速了 AI 普及，越来越多的企业选择搭建自己的 AI 基础设施，训练行业大模型。

另一方面，企业为了在瞬息万变的市场环境中更快的做出商业决策，正在将数据平台从离线转向实时数据平台。“双十一 ”和春晚直播实时大屏、银行和证券交易行为实时监控、电商和短视频的实时个性化推荐等只是全行业在线化的冰山一角。

AI + 实时，俨然成为了企业数据平台无法避免的技术焦点。那么，如何让企业数据平台拥抱AI+实时的双重能力？
为什么难实现？

对于现阶段的大数据平台和传统数据仓库等企业数据平台，姑且不论同时整合 AI + 实时，单独的 AI 平台或者实时数据平台都不得不通过复杂架构，耗费大量资源和人力来实现。我们不妨先来分别看看现在的 AI 和实时架构是如何实现的。

AI 与数据平台

机器学习和人工智能的模型训练采用结构化数据和非结构化数据。结构化数据价值非常高，数据质量也非常好，因此有些 AI 问题主要基于结构化的数据建模。一个很典型的例子就是银行基于结构化数据，面向个人客户开发的信用评分卡，既有可解释性，又能满足实时的信用评估。

那么，传统数仓的大量结构化数据该如何被用于训练 AI 模型呢？常见的方式是，当机器学习平台需要访问数据集时，需要先通过 JDBC 或者外部表的形式把数据从数据仓库导出到分布式存储中，然后再并行处理这些数据，用以进行模型训练和分析。在大规模数据处理场景中，这种不断导出数据的方式显然是不现实的，因为导出 TB 或者 PB 级别的数据通常得花好几个小时甚至几天的时间，既费力又费时。

在过去几年中，在业界产生广泛影响力的机器学习和 AI 模型几乎都是从非结构化数据中获取的。尽管在传统数据仓库中，可以将非结构化数据视为简单的文本或二进制类型 (TEXT、VARCHAR、BLOB)，然而通过这种方式训练AI模型效率低下，同样需要从数据仓库中导出数据后再做建模。

因此，企业逐渐选择数据湖这种更加开放的形态来训练 AI 模型。结构化数据和非结构化数据（文本和图像等）直接进入数据湖，以数据湖开放的存储格式存储，如 ORC 和 Parquet，使用开源工具去直接操作数据。传统数据湖平台通常由 Hadoop 实现，因为 Hadoop 的局限性，比如缺乏事务支持，缺乏很好的数据治理方法等等，数据湖都难免形成数据沼泽。

实时数据平台

传统数据平台不仅在 AI 模型的支持上出现了诸多问题，在实时数据处理方面也面临着极大挑战。

传统数据平台的数据处理流程一般是这样的。首先，从业务系统 CRM、ERP 或者其他数据源把这些业务数据收集过来，然后经过离线数据 ETL 对数据进行数据清洗、数据加工。在这个过程中会涉及数据建模和分层，最终会把加工后的数据提供给 BI 工具，或者写到数据库并推到一个在线服务系统，供用户进行访问，这些用户包括用户、运营人员或管理团队等等。

我们可以发现，即便在没有做实时数据处理的情况下，这样的数据处理链路就已经很冗长了。然而，当我们不解决既有离线问题的情况下就向实时转型，问题将更加复杂。

实时数据是如何处理的？

目前主要采用传统 Lambda 和 Kappa 架构。以 Lambda 架构的实现方法为例，Lambda 以传统的离线数仓为主，然后引入了实时数据的处理链路。T+1 数据仍然是走传统离线数仓链路，然后再加上一个实时的数据链路，再把这些实时数据和离线数据汇总到一起，然后再通过一个服务层提供数据服务，对外提供的服务可能是点查询，也可能是做复杂分析。

离线链路用 Hive/Spark，实时用 Flink。但在实际的落地中，如果需要引入实时查询，可能要再加上 ClickHouse/Drill/Presto；如果需要做数据的离线归档，还需要 Hive；为了满足一些高并发点查询需求，还要再引入了 HBase 和 MySQL。引入这么多产品组件，本质原因还是缺少一个在并发、性能和开放性兼顾的产品。

因此 Lambda 架构并没有从源头上解决传统离线数仓的问题，而是在传统离线数仓上加了一条链路，让整个系统变得更加复杂。数据可能会存两份或者存多份，实时链路和离线链路数据也不统一。除此之外，整个架构维护起来是非常复杂的，学习和开发成本比较高。

如何破局？

为了实现用更丰富的数据源训练 AI 模型，我们以极高的代价将数仓的数据导出后再并行处理；为了实现实时数据处理，我们不惜选择冗长的数据处理链路，造成多份数据和多个计算引擎烟囱林立。这些痛点都将我们引向对一个问题的思考：我们能不能只用一份数据，精简计算引擎？

答案是可以的。

当下，存储和计算的数据无非是结构化、非结构化和流式数据。破局的第一步，就是在数据的存储方面采用开放格式的一份数据，如 Parquet、ORC、Hudi 等。各个计算引擎都使用开放的数据格式（如 ORC 或 Parquet 等），数据以开放文件格式被写入数据平台，之后就能被多个引擎多次直接读取和使用。

有了存储的开放性，在计算引擎方面，我们就可以尽量优化和减少计算引擎的数量，并针对结构化数据、非结构化数据和流式数据，选用各具优势的计算引擎：● 针对流数据的计算，采用常见的 Flink；● 针对非结构化数据和机器学习，可以采用 Spark；● 针对结构化数据，需要兼容开放数据格式，兼顾实时查询、离线分析、高并发和高可用的分析引擎，比如偶数的 OushuDB。

至此，开放格式，一份数据，多个引擎的架构初步形成，这样的“一数多擎”架构形成了可以破局当前企业数据困境的方案——实时湖仓（Realtime Lakehouse）。

“一数多擎”是我们在多个行业的湖仓一体项目落地中不断迭代的最佳实践。企业在选择多个引擎时一定需要基于“化繁为简”和“扬长避短”原则，比如 OushuDB 可以完全实现Hive、Presto、ClickHouse、HBase 等引擎的功能，引入 OushuDB 后就不需要再依赖这些引擎，这样可以极大简化系统开发和运维的复杂度。Flink 擅长流处理，就使用 Flink 做流处理，而不是使用 Flink 来做 SQL 查询，Spark 擅长做机器学习，就使用 Spark 做机器学习，而不是使用 Spark 来做流处理和 SQL 查询。Hive 查询慢，就不必再保留 Hive，可以使用 OushuDB 取代。

开放的“一数多擎”
带来哪些价值？

●首先就是开放本身的价值，开放直接解决了当前数据平台在AI模型训练和实时数据处理过程中多份数据造成的数据冗余和数据不一致。同时，开放的格式让湖仓一体很容易获得最优的 SQL 引擎、ETL、流处理引擎和机器学习引擎的支持。●其次，一份数据整合了非结构化数据和结构化数据存储，图像、文本可以直接用于 AI 模型训练，结构化数据也无需被多次读取、复制和导出。●再次，“一数多擎”必然要求彻底的存算分离架构，让企业湖仓平台不受集群规模的限制，动态扩展集群规模。

● 另外，由于过往实时、离线数据处理链路极其冗长和复杂，造成数据建模、元数据管理、数据治理都难以高效的实施，“一数多擎”精简了不必要的引擎组件，整个架构变得简洁，既为数据建模、数据治理提供了平台基础，又让学习、开发和维护成本都大幅下降。