查看原文
其他

从 Data 到 Data+AI,数据基础设施第三次演进的观察与思考

曲宁 DataFunSummit
2024-09-11

导读 随着数据基础设施的不断演进,数据分析和人工智能技术也在不断发展。本文将分享关于数据基础设施第三次演进的观察与思考,结合云器科技的实践经验,探讨新一代数据平台架构的演进思路以及面临的挑战,并展望未来数据平台发展趋势,希望为数据基础设施发展提供一些思路和启示。

主要内容包括以下四大部分:

1. 当前数据平台发展现状综述

2. 新一代数据平台架构演进思路与验证

3. 面向未来的几个发展趋势和未解难题

4. 总结

分享嘉宾|曲宁 云器科技 产品总监

编辑整理|张浩

内容校对|李瑶

出品社区|DataFun


01

当前数据平台发展现状综述

1. 2023,迎来数据平台技术第三次革命

首先,站在历史的脉络上来看一下数据平台技术的发展变革。

数据平台的发展可以分为三个阶段:数据库时代、大数据时代,以及今天的生成式 AI 时代。

数据库和大数据平台为当今企业的数字化创新的基础设施奠定了基石。常见的数据相关的创新,例如商业智能(BI)和智能搜索推荐等一些智能应用,都是前两次技术革命带来的落地应用。

近两年来,以 ChatGPT 为代表的生成式人工智能(AI)技术,为行业带来了新的可能性和智能能力。目前,业界正在思考如何将数据平台与 AI 能力更好地集成,以创造新的数据应用创新。

刚才是从历史的脉络来看,如果我们换个角度来审视这三次创新,根据 Gartner 技术成熟度曲线可以看到,数据平台经历的三次革命性技术变革,其成熟度各有不同。

从最右侧来看,以数据库为代表的技术已经非常成熟。从厂商和营收的角度来看,以 Oracle 为代表的数据库产品,截止到 2023 年,其年营收已经达到 500 亿美元。尽管其增长速度放缓,但数据库技术依然是现代数字基础设施的基石。然而,其发展速度已经不够快。

第二波创新以大数据技术为代表,产生了很多商业成功的公司。以 Snowflake 为例,这家公司在技术上已经相对成熟,但在整个行业和应用中仍在快速推进。从大数据平台服务化供应商的角度看,年收入达到 20 亿美元,同时年增长率达到了 50%。进一步可以看到,在数据分析领域,行业接受度和普及度仍在快速增长,但已经不再是几百倍的快速增长。

回到今天,大家关注的热点是生成式 AI,这种技术为我们带来了更多智能的可能性。以往,主要通过统计关系代数或机器学习的预测来产生很多知识和洞察。生成式 AI 则为我们带来了新的能力,它能够基于数据推理出更多的可能性,具有更大的创新性。目前,这部分能力是各行各业都在重点关注的。对于数据平台的从业者来说,我们也在积极地探索这种革命对数据平台演进发展的影响。

2. 2023,数据平台技术架构的“变”与“不变”

在进一步展开之前,我们需要从数据平台技术架构的视角出发,审视当前的数据平台中哪些部分是稳定的,哪些部分在进一步固化或标准化,以及在新的技术浪潮下,哪些部分会面临挑战和演进。

让我们回顾一下当前主流的数据平台架构。

从物理结构上看,数据平台的基本工作流程如下:首先从生产系统中采集数据,然后将这些数据集中存储在一个统一的数据存储中心。这个存储中心可能包含多种异构存储系统。数据集中后,我们可以通过 BI(商业智能)或 AI(人工智能)的方式从中发现规律,形成分析洞察,并与上层数据应用对接,生成数据应用产品。

站在另外一个视角,从技术组件的视角来看,构建数据平台涉及许多成熟的组件,无论是商业化的还是开源的。然而,搭建和运营这样一个平台并不简单,需要处理许多分层和技术组件,以满足不同的需求。

在今天主流的数据平台中,其实已经能够处理结构化和非结构化数据。不同行业关注的焦点各有不同。以医疗大数据为例,其中包含了大量的非结构化数据,这就要求技术平台具备相应的能力来支撑这些数据的处理。目前,主流的方法是使用以 Hadoop 为代表的数据湖方式来存储和管理非结构化数据。然后,利用 AI 或机器学习模型的能力,从非结构化数据中提取相关知识和洞察,再与后续的数据应用进行对接。在我们当前的数据架构中,数据湖和 MPP 架构的数据仓库共同构成了一个整体的解决方案,用于管理各种类型的数据。

简单来说,我们需要从企业的各种数据来源处收集数据。在收集和存储数据时,数据往往是异构的,因为数据的形态不同,比如流式数据、离线数据、文本数据和结构化数据,这就需要不同的存储模型来存储它们。同时,不同类型的数据需要不同的计算引擎来处理。因此,在搭建数据平台时,需要配备相应的结构化数据分析引擎和非结构化数据的处理能力,以满足不同的应用需求。这样,形成了一个典型的 Lambda 架构,成为今天主流的技术方案。

总结而言,当前的数据平台架构基本上是以结构化数据为主的 Lambda 架构,同时结合数据湖和一些 AI 平台,组成一套集成化的解决方案。从这张图我们可以看到,数据平台的数据存储以数据湖和数据仓库为存储层的代表,它们分别处理不同的数据类型。上层则配备不同的处理引擎,以满足批处理、流式处理和实时分析的需求。每个引擎都自带存储,因为不同的存储模型为不同的分析场景进行了优化。进一步,我们通过数据应用将这些能力组织编排在一起。数据平台更多的是作为 AI 平台的数据处理和数据准备的角色,将数据开放给 AI 平台进行联动。

02

新一代数据平台架构演进思路与验证

介绍完数据平台的现状后,接下来探讨一下在当前环境下,数据平台可能有哪些发展方向。

1. 结构化数据分析架构,开始定型“不变”,主要挑战?

我们认为结构化数据的处理逻辑或体系框架已经相对成熟,但它在某些方面仍存在挑战和不足:

  • 首先,从存储层面来看,我们能够明显地意识到企业的整体数据资产分布在不同的系统中。存储层带来的问题是数据的冗余和重复,这增加了成本。更为严重的是,这些数据往往存在不一致性,处理和加工逻辑的口径不同,导致数据消费时会出现许多数据质量问题。

  • 其次,由于我们需要使用众多技术组件,这些组件的使用、维护和搭建成本相对较高。

  • 在今天,当我们拥有更多数据并希望进行数据创新时,管理、使用和资源的成本,包括人力和资源的成本都过高,导致许多本可以实现的应用由于成本和复杂度问题而无法快速迭代成为数据应用进行尝试。这些问题表明,当前的系统缺乏灵活性。

2. 结构化数据分析演进之一-湖仓一体

为了解决这些问题,从业界来看,自 2019 年开始,大家开始共同认识到,在存储层使用低成本的存储介质来管理结构化数据的重要性。市场上出现了许多以表格格式和文件格式来表达结构化数据的解决方案,这些解决方案带来了数据一致性、更新能力和流处理能力的提升。

解决这些问题的关键在于采用一种标准的、开放的存储介质结构。这种结构允许我们向上与各种引擎开放对接,解决了之前每个系统都需要进行数据存储和优化的问题。通过单一副本的数据(single copy),可以支持批处理、流处理和分析的能力。这就是我们所说的“湖仓一体”,它在存储层面能够解决之前提到的问题,并逐渐成为业界的普遍认知。然而,“湖仓一体”在实际落地时,也呈现出不同的形态和企业的不同理解。一些厂商的方案或企业内部的组织方案,是以数据仓库为核心,数据湖作为联邦查询的数据源,存储原始数据。在进行分析和对接时,主要使用高性能的数据仓库,而将一些长尾的历史数据存储在数据湖中,通过联邦查询的方式统一用户查询接口。

我们认为,尽管业界对此达成了一定的共识,但这并不是一个最终状态。最理想的情况是,所有的数据都持久化在一个公共的存储之上,所有场景都通过缓存或索引的方式进行优化,而数据本身只有一份元数据,统一存储在一个地方。这被认为是“湖仓一体”的发展趋势。

3. 结构化数据分析演进之二-“云原生”变成架构概念

在 2000 年大数据时代,主要是通过使用成本较低的 X86 方案构建分布式集群,以降低数据处理的单位成本。2000 年之后,云计算或云原生架构的能力得到了广泛应用。云原生对数据平台产生了巨大影响,实现了存储和计算的分离,因为无论是公共云还是私有云的基础设施,都已经相当普及。

数据可以持久化在低成本的存储上,而计算则通过弹性计算方式,比如使用 Kubernetes(K8S)进行管理,所有资源都实现了池化。这对数据平台带来了几个好处:

  • 首先,池化资源能够更高效地利用,因为数据负载和业务负载本身具有潮汐性和周期性,可以根据需要从资源池中动态分配资源,进一步降低资源成本和平台成本。

  • 其次,云原生的能力解决了过去数据负载之间的争抢和隔离问题,能够很有效地进行资源隔离和弹性伸缩。这意味着在一份数据、一份元数据的基础上,可以有独立的批处理计算引擎和交互式分析、流式计算引擎,它们使用独立的资源进行处理。

因此,在云原生架构下,数据平台的成本可以更低,用户体验更好,服务等级协议(SLA)也更强。

4. 结构化数据分析演进之三-计算引擎的一体化

接下来讨论计算引擎。市面上有许多成熟的计算引擎,例如在批处理领域的 Spark,以及流式计算和交互式引擎领域的许多产品。这些产品存在一些问题:

  • 首先,在数据上存在冗余;

  • 其次,不同的计算引擎导致了数据处理时用户需要感知不同的 SQL 开发语法和语义的差异。

  • 数据流转之间可能存在不一致性,不仅会增加资源成本,更增加了开发成本,导致新业务的响应时间变慢。

过去的 Lambda 架构通过不同的计算引擎解决了数据处理中的三个关键价值点,首先是追求数据新鲜度,满足数据即时处理和分析的需求;其次是面对海量数据,追求成本效益;第三是追求查询性能。过去,这些需求是通过不同的引擎来实现的。然而,随着技术的发展,我们认为这三方面有可能实现统一。

5. 下一代的数据平台架构的推荐架构

总结刚才的讨论,我们认为下一代数据平台至少应具备以下趋势:

  • 首先,从计算引擎的角度来看,应能够通过 single engine 单一引擎满足不同计算需求,这需要技术上和工程上的创新。例如,可能需要更高效的 native 执行引擎,同时为了支持流式计算,需要引入增量处理能力。在追求更好的查询性能时,引擎需要支持 pipeline 调度模型,以加速分析过程。这背后是计算引擎创新的体现。

  • 其次,我们认为存储系统需要向统一的湖仓架构演进,形成一种统一的存储系统。这种架构能够通过开放的 table format 将结构化数据暴露出来。同时,这套存储系统面向单一引擎,能够满足数据处理需求,从而大大简化开发过程并加快业务上线时间。

  • 最后,湖仓一体的数据平台天然适合为 AI 相关的 workload 做准备。例如,平台能够与 AI 模型对接,能够将大模型的能力和数据平台管理的结构化数据与非结构化数据相结合。在这种情况下,AI 的能力成为一种计算引擎,类似于 Spark。AI 能力可以封装成一个 function,我们所需做的就是调用这个 function,将数据传递给 AI 的 model 进行处理或分析。这样,就形成了一个开放式的架构。

03

面向未来的几个发展趋势和未解难题

1. “变化中的”AI 新计算范式的四个趋势

面向未来的数据平台有四个发展趋势。

(1)趋势 1:数据平台体系架构从 1:1 到 M:N

回顾过去的数据平台,主要以结构化数据为主。从底层向上看,最底层是结构化数据的存储。传统的数仓 MPP 系统天然面向结构化存储,通常与计算紧密绑定,上面有结构化数据的分析,以 SQL 或者 Data Frame 这种编程框架来开发。随着 AI 能力的兴起和扩展,AI 技术增强了数据处理能力,能够处理更多类型的数据。例如,我们正在与一些客户探索新的场景。他们可能拥有大量 PDF 文件,包含合同等各类数据。我们需要在数据平台中提取这些海量非结构化数据中的信息,并将其结构化。这时,数据管理平台面临一个问题:首先,数据平台需要能够管理以文件和目录形式表达的非结构化数据。我们可以看到,存储层的发展目标是能够很好地管理这些非结构化数据。但在实现这一目标时,我们需要考虑许多方面:

  • 首先,元数据系统需要能够表达非结构化数据。

  • 其次,我们需要对这些非结构化数据进行标注,扩展元数据的增强信息。通过提升数据管理能力,可以更好地与上层的 AI 能力对接。

  • 此外,还需要考虑文档处理能力和文本处理能力。文本处理有多种方式,有些文本可能使用全文检索,面向搜索场景使用。在当前的大模型时代,许多数据需要被向量化并有效存储。这些数据能力都是我们在存储层需要解决的问题。

总的来说,存储方面发生了很多变化,我们需要根据上层场景的需求来组织存储模型,并通过元数据系统进行统一管理。

除了结构化数据之外,新一代数据平台还应整合大模型的能力。以云器自身的探索为例,我们通过函数的方式,无论是利用 OpenAI 的 API ,还是国内大模型的 API 能力,都能调用外部 AI 能力。我们需要解决的是如何将这些 AI 能力与我们管理的非结构化数据相连接。例如,前面提到的场景,包括图片数据、车损数据、合同数据等,都可以通过相应的方法进行 ETL 处理,从而洞察出有价值的信息。因此,数据融合和 AI 能力的集成是当前的一个新趋势。

(2)趋势 2:Data Centric AI - **数据**是 AGI 时代最大的 Differentiator

其次,我们观察到,当企业真正实施大型模型时,模型和算力本身是标准化的。对于更广泛的企业来说,他们可能不会进行算力处理或模型的开发和训练,而是更多地使用现成的解决方案。这时,企业如何更好地将自有的私有数据与现有能力相连接,就成为了差异化竞争的关键点。然而,这项工作本身,正如大家所熟知的,最常见的落地应用,例如以 IG 为例的应用,大部分前期工作还是要从企业数据中提取所需信息。当我们想要应用这些技术时,需要收集客服数据,从车险车损相关场景中提取照片、工单等,并将它们分门别类地管理在数据平台中。

这里讨论的是非结构化数据管理,可能通过目录形式表达的元数据来管理。不同的目录管理着不同类型的对象,因为其背后的 AI 处理模式或应用需求不同,从而形成了新一代的数据集和 ETL 处理能力。在人工通用智能(AGI)的应用中,大部分前期工作与传统数据平台相似,需要从企业中提取大量数据,并进行分类整理。元数据需要得到有效管理,以便数据科学家能够访问并处理数据,可能包括数据清洗或通过向量化处理。这些处理流程与传统数据平台的处理流程几乎一致。

因此,我们可以看到,在新的 AI 应用中,大约 80% 的工作仍然是数据处理。这包括数据的采集、清洗、转换和向量化,以便为后续的分析或 AI 应用做好准备。

(3)趋势 3:数据平台架构重回搜索时代

之前的数据平台主要侧重于商业智能(BI)分析,数据的采集和加工都是为了使 BI 系统就绪,便于进行分析。外部通常会有一个偏服务的引擎,以实现快速查询和检索。

现在的数据平台在进行模型应用时,需要一个类似于搜索的技术框架和链路。例如,在智能问答系统(RAG)中,我们处理大量的非结构化数据,以文本为例,我们需要收集文本,进行切片,然后向量化。向量化后,进行查询和召回,进行相似问题的相似性检索,并通过 prompt 方式进行处理。这一流程与数据平台对结构化数据的加工几乎相同,包括数据的采集、转换,以及为了分析或 AI 就绪而进行的存储。

后半部分则涉及到与大模型的对接。随着数据平台的进一步发展,它需要解决非结构化数据的处理问题,包括非结构化数据的采集、管理、转换加工、保存和 serving 能力。这些都是数据平台在发展过程中需要考虑的天然问题。

(4)趋势 4:统一元数据管理,重要性提升 10 倍,构建难度也提升 10 倍

然而,目前非结构化数据的管理还不够成熟。据来自 Gartner 的报告显示,企业中有 80% 的数据实际上是所谓的暗数据,即那些非结构化数据,在处理之前我们并不知道它们是什么。许多先进的企业已经建立了良好的数据中台和企业数仓,拥有详尽的数据资产地图。通过搜索方式,我们可以知道企业中有哪些供应商数据、销售数据等,并通过资产地图有效地检索这些企业数据资产,进而进行数据应用的开发和查询。然而,非结构化数据目前还没有这样的能力。企业中大量的数据集仅仅是存储在磁盘上,我们并不清楚它们具体包含哪些信息。

因此,我们认为接下来面临的机遇和挑战是,这些非结构化数据由于大模型和 AI 技术的发展,带来了更好的解析能力和基于现有数据的创作能力。这意味着,随着技术的进步,我们有机会更好地挖掘和利用这些暗数据,从而为企业创造更大的价值。这部分数据如何能够进入数据管理平台,像结构化数据的表一样被资产化、被打标签,并通过一些预处理方式提前增强其元数据信息,这些都是我们认为在下一代数据平台中统一元数据非常关键的部分。

2. 三个未解决的难题

针对上述四大趋势,很多厂商,包括云器在内都做了大量探索和尝试,在这一过程中我们也遇到了许多问题,这里分享一些我们的观察和思考。

  • 疑问一:SQL VS Python,当自动代码生成成为主流,赢家会是谁?

第一个问题是关于数据平台本身,如何利用生成 AI 更好地进行用户开发。众所周知,许多厂商在落地时,都会遇到 BI 问题,即通过分析回答问题。这时,我们面临一个挑战:很多时候,业务分析师(BA)提出的 SQL 查询可能不够准确。因为 SQL 本身是一个声明式的编程框架,它背后有许多优化,这些优化和自然语言的翻译或理解并不直观。在业界,一些领先的厂商,例如 Databricks,提供了自然语言翻译工具,能够将自然语言翻译成 Python 语言。这得益于公开互联网上大量的 Python 知识和数据处理知识,使得自然语言可以被翻译成 Python 脚本来提高处理的准确性。对于我们的数据平台来说,SQL 作为传统的开发语言,Python 也将成为另一种主流的开发语言。所有的引擎都需要适应这一场景,能够通过 Python 作为用户开发接口或编程接口,提供编程能力。

  • 疑问二:数据平台的“自动驾驶”多久能实现?

第二个问题是,在 ChatGPT 之后,数据平台普遍在进行问答式的取数和分析,除了问答式分析之外,是否有其他新的应用尝试?我们看到的另一部分工作是数据工程和数据开发。如果我们能够利用大型模型,借助其知识和推理能力,通过问答的方式帮助构建数据开发 pipeline,同时根据业务需求进行数据模型优化。你可能不需要理解如何构建宽表、分区、分桶优化,或者如何设计计算资源的高并发,只需提出业务需求,系统就能自动生成开发 pipeline,让开发者能够以自然语言进行开发,这也是一个值得探讨的问题。

令人欣喜的是,我们观察到许多厂商正在推出创新产品,例如谷歌 BigQuery 最近在做的一个产品叫 Data Canvas,它提供了一个拖拽式的画布,用户可以通过自然语言的方式与之交互。例如,用户可以拖拽数据并询问需要的特定年份销售数据,然后进一步过滤特定类型的数据,最后希望生成某种趋势报表。这种交互方式是自然语言的,而系统背后会帮助生成相应的数据处理 pipeline。同时,它还有机会在处理过程中进行数据模型和计算资源的优化,这也是未来的一个发展方向。

  • 疑问三:半/非结构化数据,知识的*显式*表达最终方式是什么

结构化数据通常以二维表的形式来表达和利用,而大约 80% 的数据是非结构化的,,这些数据的利用方式之一,是将其与大型模型结合,转化为知识。

大家都知道,开发智能应用时,我们最常利用的大模型的一个关键工程点就是将企业数据转化为知识。这种知识是一种上下文,通过这种上下文的方式,将企业知识传递给大模型。大模型结合自身的背景模型能力,帮助我们进行一些创新性的决策或分析。这其中涉及到如何在企业内部将这些数据转化为知识。业界普遍采用的方法之一是向量化存储。各种数据经过向量化处理后,可以进行相似度检查。然而,许多关系结构可能无法通过向量化准确表达,这时就需要图数据库来处理。

还有一些知识隐藏在结构化数据中。比如,当我询问某款耐克 2023 年的鞋子销量如何时,背后的需求并不是元数据,而是希望找到企业内部的商品表中某个耐克鞋子对应的 SKU ID 来进行分析。这时,我们需要通过标量的方式,将许多数据中的低笛卡尔级、低基数的数据标识出来,使其成为元数据的一部分,转化为知识空间,提供给大模型,帮助其更好地进行整理。因此,我们可以看到,在知识管理这一领域,目前正处于快速变化且尚未定型的阶段,这也是值得大家关注的一个点。

04

总结

在本次分享中主要探讨了如下三个方面的内容:

  • 首先回顾了当前数据平台的发展和现状;

  • 接着分享了云器科技关于下一代平台的一些思考和我们的实践经验;

  • 最后展望了下一代面向 AI 的数据平台中的一些问题和发展方向。

以上就是本次分享的内容,谢谢大家。


分享嘉宾

INTRODUCTION


曲宁

云器科技

产品总监

目前负责云器科技 Lakehouse 平台产品的产品工作。10 年以上数据平台产品建设及商业化推广经验,曾负责某头部云厂商核心数据平台的产品规划、迭代及商业化推广工作。

往期推荐


当数据库有了Copilot,DBA不用再灭火了!

Elasticsearch 8 让企业更快更好地落地 RAG 应用

腾讯智能科技进展与产业创新实践

有效解决数据驱动型人工智能面临的 I/O 挑战

大语言模型训练中的数据管理

Apache Hudi 从零到一:揭秘类聚和空间填充曲线(六)

ChatBI+Agent引领的数据产品新形态!

智能NPC的多维进化:腾讯在AI领域的探索与应用

让大模型更懂情感,我看到了巨大的市场潜力

大模型在小爱同学应用实践

点个在看你最好看

SPRING HAS ARRIVED

继续滑动看下一个
DataFunSummit
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存