分布式 Data Warebase - 构筑 AI 时代数据基石

导读:作者以人类世界一个信息层次模型 DIKW 为出发点,引出对计算机世界(系统)处理数据过程的介绍。接着以一个民宿平台数据架构随业务发展而不断演进的过程,展示了这场信息革命中,在具体应用场景下,一个系统是如何一步一步变得庞大、复杂的,伴随而来的是运维、开发、业务中的一系列棘手问题。最后作者引入解决问题的一种新思路:以扩展关系型数据库为基础,引入分布式事务并支持更多数据模型。基于此打造了解决性能瓶颈的新一代数据系统------分布式 Data Warebase,开启了数据系统的新时代,让数据涌现智能。

本文结构如下:

  1. 人类世界 DIKW 模型
  2. 计算机世界的"DIKW"
  3. 一个典型数据系统的演进过程
  4. 现有数据架构存在着哪些痛点
  5. 新一代数据系统------分布式 Data Warebase
  6. 数据系统新使命:让数据涌现智能

01/人类世界 DIKW 模型

1989 年 Russell Ackoff 提出了一种信息层次模型:DIKW,描述了从数据到智慧的转化过程,帮助组织和个人在决策中有效利用信息。

其主要包含 4 个层次,以下以一个铁球的例子来解释这些概念:

  • 数据(Data):数据是未经加工的、原始的事实和数字,缺乏含义。比如"9.8"本身并不具备确切的物理含义。
  • 信息(Information):当数据被整理、分析,赋予一定的背景后,就成为了信息。信息是具有意义的结构化数据,能够帮助理解数据的内容。比如"一个 1 千克的铁球以 9.8 米/秒²的加速度下落"这句话中的"9.8"就传达了特定的信息,即铁球下降的加速度。
  • 知识(Knowledge):知识是对信息的理解和归纳。比如,根据观察,1 千克、5 千克、10 千克的铁球都以 9.8 米/秒²的加速度下落,可以归纳出"所有的铁球都以 9.8 米/秒²的加速度下落"这一知识。进一步,我们发现铜球和银球也以相同加速度下落,于是进一步归纳出"所有物体都以 9.8 米/秒²的加速度下落"。这种归纳和抽象使信息转化为知识,从而能够预测未来,如推断 8 千克的铅球也将以 9.8 米/秒²的加速度下落。
  • 智慧(Wisdom):智慧是对知识的深入理解和抽象,具有前瞻性和创造性,能够做出高质量的决策。例如基于"所有物体都以 9.8 米/秒²的加速度下落"这一知识,可以推断重力下加速度与落体本身的特性无关,而是时空的一种几何性质。这就是广义相对论的核心思想,体现了智慧。智慧是最高级的智能,它需要复杂的推理论证和深刻的洞察,目前仅人类具备这种能力。

以上是人类世界中,对数据的一步步加工利用过程。从数据到智慧,对事物的抽象程度越来越高,理解也越来越深,那计算机世界是如何实现这一过程的呢?

02/计算机世界的"DIKW"

这里参照 DIKW 模型,介绍每一层在计算机世界是如何实现的。

1. 数据层:比特

对计算机而言,机器使用比特(Bit),即 0 和 1 来表达数据,比如发送的消息、聆听的音乐、观看的电影,在计算机里就是一串 0 和 1。在这一层,机器实现了对数据的存储,我们知道单独的数据是没有意义的,那计算机如何为这串比特赋予意义呢?

2. 信息层:数据模型

在信息层,会为数据赋予上下文意义,并以一定的结构化方式进行组织。数据就此被升级为信息,能够被计算机理解和处理。这里我们通过一个例子来展开介绍,"小明预订了 2024 年 6 月 1 日的两个标间"。

首先机器会以比特的形式将这些文字存储为数据,但机器并不理解这个句子的含义。为了让机器理解它,计算机先将这段文字分解(结构化),分别为关键数据和对关键数据的描述(业内也称元数据),比如关键数据小明,其描述是预订人。以这种方式,一条信息就被计算机转化成具有相互关联结构的一条记录,更多的记录进而形成数据表,我们把这种相关联的信息组织在一起的方式称为数据模型,也可以理解为信息的语言。

常见的数据模型有两种:关系模型和文档模型。

  • 关系模型:我们所举的例子就是一种关系模型,将数据进行结构化,并赋予这些数据上下文信息,这样数据就能够被机器理解和处理,从而变成信息。作为一种描述信息的语言,关系模型对数据的要求非常严格,要求所有数据结构必须完全一致。
  • 文档模型:这种方式下数据被组织为文档结构,文档内部数据具有一定的结构,但数据间结构可以不完全一样,这种数据也被称为半结构化数据。文档模型将数据组织为一种树状结构,这种结构能够较好地表达实体间一对一、一对多的关系。文档模型是让半结构化数据变成信息的语言。

数据模型进一步带动了数据产品的兴起,比如以关系模型为基础发展而来的关系型数据库,以文档模型为代表的 NoSQL 数据库,还有面向 BI 分析场景,引入分布式、列式存储等功能的数据仓库。数据库产品能够很方便地把数据转化为信息,并且高效地存储、检索和管理这些信息。不同的数据产品共同构筑了信息革命强大的基石。

3. 知识层:嵌入向量

人们通过对信息的整理、归纳、总结形成知识。基于数据模型,在计算机的世界要如何进行这一过程呢?这就要提到知识的一种表示方式:嵌入向量。

前面提到"所有物体都以 9.8 米/秒²的加速度落地",这就是对大量相关信息的归纳总结。除了这种归纳之外,相关信息的汇聚也能形成知识。比如一个民宿所有信息聚集在一起就形成了一种知识,这个知识刻画了民宿各个方面的信息,比如价格信息、住宿环境信息、交通信息等。之后我们使用数学语言对各个方面的信息进行量化,形成计算机能够理解的一个向量。我们把承载这个向量的空间称之为潜空间。

为方便解释,这里我们选取三个方面对民宿进行评估并进行向量化处理,之后对其进行三维可视化,效果如图所示。

一旦选用了一种数学语言去表达这种知识,我们就可以在这个潜空间中执行各种数学任务:分类、回归、重建。通过两个嵌入向量间的距离,来衡量它们所代表的知识的相似程度。两个嵌入向量的距离越短,它们所对应的民宿就越相似。

简单地根据输入特征生成的高维向量,在潜空间中的度量不一定能反应它们所代表的知识的相似度,所以实现层面上,通常需要通过模型来生成嵌入向量。这些模型可以是专门的嵌入模型,此外神经网络的每一层也是一个不断从输入信息中抽象更高级知识的过程,这些中间层产出的向量也代表了不同抽象程度的知识。

03/一个典型数据系统的演进过程

基于数据模型搭建起来的各类数据产品,让行业对数据和信息的应用以空前规模发展起来。特别是门户互联网和移动互联网时代的到来,大大加速了各类数据产品的迭代和应用。这里以一个民宿平台为例,剖析如何运用这些数据产品,不断满足业务从简单到多元的发展过程。

1. 业务初期到经营分析阶段

业务初期,民宿的房东将自己的房子上架到民宿平台,有需求的用户在平台上浏览,查寻自己感兴趣的民宿,之后可能会在平台上完成预订、入住、离店、以及评价等常规业务操作。

实现这样一个民宿平台应用,首先从核心的应用服务搭建出发,一开始业务体量相对有限,产品功能一般会按照 MVP 的思路进行设计。从数据架构角度看,概括而言就是简单查询,所以最初一般会把所有的数据都存储在关系型数据库中,比如 MySQL 或者 PostgreSQL。

随着业务体量增长,遇到五一或者国庆这样的假期,民宿的需求往往爆发式增长,简单的单机关系型数据库很快就会遭遇性能瓶颈,这个时期需要引入 NoSQL 类型数据库,比如 MongoDB,主要引入原因是这类数据库只需简单增加机器,就可以实现水平扩容,有效应对更高的业务负载;其分布式架构和优化的数据存储方式,更适合处理大数据量的业务场景;并且其灵活的数据模型,能够适应多变的应用需求。

接着业务用户量开始迅速上升,用户需求也越来越多元,用户不再局限于通过全名的方式去查找民宿,而是希望能够根据一些关键词找到自己感兴趣的民宿,在这方面 MongoDB 提供的能力相对有限。于是系统引入 ElasticSearch,因为其提供了强大的搜索能力,采用内存数据处理使得查询速度非常快,可以达到近乎实时的数据处理。为了让搜索引擎能够提供搜索服务,首先需要把数据导入到搜索引擎之中。数据的导入一般分为两种形式,第一种是全量数据导入,关系型数据库和 NoSQL 数据库里面的数据会定期以全量的方式导入搜索引擎。第二种是增量数据导入,如果应用对数据的时效性有比较高的要求,还要再引入增量的数据同步链路,比如采用 Kafka 和 Flink 这样的技术把上游的增删改同步到搜索引擎之中。当搜索引擎有了这些数据后,就可以为应用提供高性能的关键词搜索了。

至此,通过利用各类数据产品,业务系统具备了基础信息的存储和高效提取能力。

这个时期的业务,已经渡过了最初的用户量少、商家少、业务数据量少的状态,我们希望对业务进行各种分析,比如节假日平台 GMV 的同环比情况,民宿预订量 Top10 的城市是哪些,用户画像是怎样等等。所以系统开始引入 Snowflake 或者 Hive 这类数仓产品。这时需要把各种业务数据从各个数据库同步到数仓之中,然后就可以使用 ClickHouse 或者 Hive 对数据进行全面的 BI 分析。

可以看到伴随业务的发展,系统持续引入不同的数据产品。又因为各系统依赖的数据来源不同,系统内部存在大量复杂的数据同步作业。此时的数据架构如图:

2. 传统式 AI 助理精细化运营阶段

首先解释下,这里的传统式 AI 是相对于当下比较火热的生成式 AI 而言,主要包含业务洞察和实时决策等商业智能的内容。

业务用户量的增加,带来人群的多样性和需求的多元化。以往面向全量用户的运营方式收到的效果开始变得越来越小,甚至有时还会带来亏损。同时伴随着市场环境由增量市场转变为存量市场,面对用户的运营更加呼唤企业精细化运营,于是离线洞察和实时决策等需求开始成为这个阶段企业的普遍需求。

💡 离线洞察

民宿房东希望更多住客入住自家民宿,所以他决定通过折扣来做推广。为了提高推广的成功率,他希望只发送给对价格敏感的客户。为了做到这点,首先就要理解用户,根据用户的基本信息,以及用户和平台交互的各种行为信息,构建出描述用户的知识。如前文所述,这个知识可以表达为潜空间中的一个嵌入向量,为每个用户构建了相应的嵌入向量后,就可以对这些嵌入向量分类,判断出个体用户是否对价格敏感。

为了满足这样的需求,首先需要对数据进行预处理,比如筛选有用的用户特征数据,之后交给模型训练,找出对价格敏感的人群,然后就可以将这个人群包发给业务进行营销推广活动。到这一步,数据架构方面新增了数据预处理和模型训练。

💡 实时决策

民宿是受季节性因素影响的行业,有淡旺季之分,如果民宿价格全年保持不变就会有些不合理。淡季的时候,需求变少,如果民宿大量空置会给老板带来不小的损失,所以房东为了提高淡季入住率,在以往空置率较高的季节,更倾向降低价格以吸引潜在的住客。同理,旺季时在不影响入住率的前提下,适当提价能够为房东带来更高的收入。于是就有了价格波动。

价格什么时候变动?变动多少?怎样调整可以让利益最大化?如果人工判断将会是一件复杂而繁琐的事情,相信老板内心也是拒绝的。假如使用传统 AI 来处理这件事,民宿老板想获取更多收益的业务诉求,就转变为系统如何实现价格自动调整的问题。

通过上述问题描述可以发现,影响价格的重要因素有两个:民宿和市场。民宿方面,基础的操作需要根据民宿的各种特性,比如装修风格、年份、房间数、地理位置等通过模型产生出一个代表民宿知识的嵌入向量。然后获取市场相关的信息,比如民宿所在地区当前的总入住率、相似民宿的价格、入住率等信息。AI 模型通过将这些信息和知识整合在一起,实时推断出一个最优价格,从而实现民宿实时自动定价功能。

技术实现上,这个功能需要依赖一个在线的模型服务,同时这个服务也会依赖上文提到的数据预处理和模型训练。

为了给这个在线模型服务提供高吞吐低延迟的特征输入,需要一个在线的特征存储。由于特征的数据量比较大,通常会采用 MongoDB 或者 HBase 这类存储作为在线特征存储。由于训练时用到的一些特征也可能被当作模型服务的输入,这部分离线的特征必须同步到在线的特征存储中。除此之外,为了得到更好的效果,还可能需要实时计算一些特征,这进一步增加了系统的复杂度。

除了实时定价以外,实时决策还应用于个性化推荐、实时类营销任务等场景,这里暂时不过多展开。这个阶段,数据架构迭代升级为下图:

3. 生成式 AI 助力业务创新阶段

2022 年底,以 ChatGPT 为代表的大模型,让 GenAI(生成式 AI)进入公众视野。这不仅带来了技术应用上的新突破,也带来了人机交互模式上的创新:基于自然语言的对话。

💡 生成式 AI:通用知识提取

生成式 AI 的崛起,特别是基于 Transformer 架构的大语言模型在理解和生成文字,以及基于 Diffusion 的图像模型生成图像上取得了重大突破。生成式 AI 能生成高质量的文本甚至代码,能够通过文生图、图生图的方式生成图像,能够通过文字生成音频甚至视频,这一系列能力不仅极大地拓宽了 AI 的使用场景,也在重新定义什么是非结构化数据,它以一种全新的方式给传统的非结构化数据赋予结构,从中提取知识。

相比传统 AI,生成式 AI 训练的数据集要大几个数量级。最先进的大语言模型几乎使用了人类所有公开的高质量文本语料,因此它具备非常广泛的知识和智能。当你和 ChatGPT 这样一个先进的大语言模型交互时,它往往能够对很多问题给出高质量的回答。这可能会带来错觉:数据不再重要,拥有这样一个大语言模型就可以解决一切业务问题。事实恰恰相反,数据在生成式 AI 时代将会变得更为重要

这里以九间堂民宿为例,介绍生成式 AI 的实际应用价值。

💡 业务数据驱动的生成式 AI

九间堂民宿计划在江苏地区开展广告宣传活动,希望利用 AI 技术生成相关营销图片。上图左侧即是初步由 AI 生成的图片,图中展现了九间房屋,位于地图上的江苏。由于通用模型仅掌握有限的基本信息,因此生成了这一初步效果。尽管合格,但广告效果仍有提升空间。为此,我们搜集并整理了九间堂在江苏最受欢迎的几处民宿的描述和图片资料,并将这些信息输入大模型进行学习和优化。经过对业务数据的深入理解后,AI 生成了右侧的新图,相比之下,其广告效果显著提升。

业务数据除了在以上内容设计方面具有价值外,还能通过不同的方式让业务更智能。

上下文学习(In Context Learning)

这里举一个例子,用户对某个民宿感兴趣,但是他不确信这个民宿是否能够让家里的所有成员都住得比较舒适。当然他可以自己去详细地了解这个民宿的所有信息,然后再看是否能住下,但这无疑是件繁琐的事情。

于是我们想利用大语言模型的能力来完成这样一个规划,把这个民宿的描述等信息给到大语言模型,然后再向大语言模型提问,请它安排家人的住宿。大家可以看到大语言模型在了解了这些信息之后,给出了一个非常合理的安排。这就是大语言模型一个核心的能力,它可以从上下文当中学习知识,并且把自己的智能应用在这些新学的知识上。

向量搜索

基于嵌入向量的相似性搜索。比如基于 Transformer 的文本嵌入模型能够为民宿的描述和评论等文字生成嵌入向量。两个民宿越相似,它们对应嵌入向量的欧氏距离也就越接近。我们把高效地查找与某个指定向量最相近的若干向量的搜索叫作向量搜索

检索增强生成-RAG

通过结合向量搜索技术与大模型的上下文学习能力,发展出了检索增强生成(RAG)技术。当用户提出一个问题,例如"靠近西湖、适合一家四口居住且为简约风格的民宿",我们首先让大语言模型对问题进行改写,再利用文本嵌入模型为改写后的问题生成嵌入向量。接着,通过向量搜索找到与该问题最接近的嵌入向量对应的民宿列表,将这些民宿的描述和用户的问题一同作为上下文输入给大语言模型。基于上下文学习(In-context Learning)能力,大语言模型能够理解这些信息,并生成符合用户需求的答案。

模型微调

检索增强生成技术通过文本嵌入模型把数据变成嵌入向量,也就是知识。模型微调的基本思路是让通用模型去学习业务相关的领域知识,从而让这些领域知识成为模型的内在能力。微调的流程首先把业务数据做各种清洗加工,然后让大语言模型去学习这些高质量的数据集,从而成为一个理解业务数据的大语言模型。微调的方式一般会分为四种:无监督微调、蒸馏、监督微调、以及强化学习。

这里简单介绍一下这些微调方式的原理:

  • 无监督微调:简单而言就是博览群书。比如想让大语言模型理解古文,需要先找到一些高质量的古文书,然后让大语言模型阅读这些书。通过这种泛读的方式,大语言模型就能总结出古文用字的一些内在规律,就有了一定的古文素养,从而有知识和能力做和古文相关的任务。
  • 蒸馏:这种方式可以理解为找一个老师,跟着一个古文素养很高的老师学,借助老师能够更快更好地学到古文的精髓。
  • 监督微调:除了上面提到的两个没有明确目的的素质教育之外,应试教育在某些场景也同样重要。即便大语言模型经过各种素质教育,有了比较好的古文素养,并不代表着它在考试中一定可以得到高分。比如让大语言模型去参加科举考试,如果没有培训过八股文的写作,那它就可能因为写的文章不符合规范而得不到好的成绩。应试教育做的就是这种对齐工作,让大语言模型知道人类在完成某些任务时的一些偏好。最直接的对齐方式是监督微调。在这个例子里,就是让大语言模型学习历届八股文的考题和范文。通过这种方式,大语言模型就明白了八股文的规范,就学会了如何把古文能力用八股文这种方式表现出来。
  • 强化学习:这种学习方式不会告诉模型什么是正确答案,但是会给模型写的文章进行打分,告诉模型这篇文章写得好还是不好。通过反复的试验模型就会找到获得高分的写作手法,从而按照人类的期望高质量地完成任务。

简单总结一下,生成式 AI 和业务数据结合有四种方式:上下文学习、向量搜索、整合了向量搜索和上下文学习的检索增强生成即 RAG、模型微调。在实际的应用中,往往会把这几种方式结合在一起,还可能使用外部的工具,我们把这类智能的应用叫做数据智能体,即 AI Agent。

回到民宿这个例子中,可以想象有一个虚拟旅游顾问,用户可以向它咨询任何关于旅游的问题。比如为一家四口人设计一个杭州三天的旅行计划,并且根据用户反馈进行修改,形成用户满意的方案后自动完成各种机票、民宿、以及景点的预定。为了完成这些功能,虚拟旅行顾问就需要利用大语言模型的能力去做规划,使用推荐系统找出用户可能喜欢的杭州的景点,找出这些景点附近用户可能喜欢的民宿,等等。这样一个 AI Agent 能够综合大语言模型的能力并且灵活使用外部的工具。

最终,数据架构迭代至如下情况:

面对如此庞大、复杂的数据架构,你很难想象它能很好地满足业务高可用、高效率、高质量的诉求。这种架构往往存在一些显著的痛点。

04/现有架构存在的痛点

  • 运维视角:感受最直接也最深的当属运维人员,同时运维这么多产品,势必会使运维复杂度上升。特别是数据同步,它往往是一个系统中最薄弱的环节,很容易导致系统的不稳定。同时因为一份数据需要在多个产品中重复存储,一致性方面存在很大挑战,也带来了更大的成本。
  • 开发视角:构建这样复杂的架构有较高的开发门槛,开发人员需要学习和理解多个不同的数据产品,每个数据产品都有一些局限性,开发人员还需要理解和绕开这些问题。对很多中小公司来说,招聘大量优秀的数据和 AI 工程师是一大挑战,从而导致很多数据的业务价值并没有被完全挖掘出来。即使团队很幸运拥有这些工程师,他们也需要把大量时间花在繁琐的数据同步上,这无疑极大地降低了开发效率,降低了业务的迭代速度,阻碍了业务的发展。
  • 业务视角:虽然我们刚才所看到架构是从业务需求倒推出来的,但是从业务视角来看,它也不是完美的。因为需要做各个产品之间的数据同步,就无法避免数据延迟的问题。数据延迟会导致业务看到的数据可能不一致,进而导致其它业务问题。特别是对于创新性业务,可能涉及多个业务系统,这样新业务从想法到落地的过程大大加长,让业务难以在短时间内形成市场竞争力。

接下来将介绍 ProtonBase 是如何解决这些痛点的。

05/新一代数据系统

1. 基于第一性原理的解题新思路

从以下几个方面分析和拆解存在的痛点:

  • 之所以存在各种各样的数据库,核心原因在于针对不同的业务和性能需求选用不同的数据库,面向查询速度引入 ES,面向 BI 分析引入列式存储,面向巨量数据和安全引入分布式等;
  • 之所以系统会越来越庞大,核心在于业务驱动下,传统的解题思路一般是做加法,而非按照第一性原理,用系统的思维去结构化问题。这在公司场景下算是正常现象。
  • 之所以数据架构变得复杂起来,核心在于一个业务需要多种已处理好的数据支持,这就要求在数据架构内部不同系统之间进行大量数据同步,同步伴随着带来数据延迟和一致性问题。为了能够让系统没有数据延迟,唯一的选择是让数据同步不再是一种必要而是一个选择。这就意味着我们需要用同一份数据支持各种场景。

综合评估下,关系型数据库的功能最完备,离我们的最终目标最接近,所以我们决定以关系型数据库为出发点去吸取其他产品的一些核心技术

从语言层次角度考虑,关系型数据库使用的语言是关系模型,它本身就能够很好地支持表达结构化的数据。为了能够很好地表达半结构化的数据,可以引入 JSON 类型。知识层的语言是嵌入向量,可以引入高维向量这种类型。这样我们在一个表里同时存储结构化数据、半结构化数据、以及表达知识的嵌入向量,从此数据同步不再是必须,而是可选的。

从性能的角度考虑,新一代系统应该达到什么样的标准?这就要从现在业务所需要的技术说起:

💡 分布式事务:为了能够通过增加更多机器的方式提升系统的性能并且保持数据的一致性,就需要实现分布式事务,然后就能通过数据分片这种横向扩展方式提升系统的性能。

💡 丰富的索引:速度是系统性能当中最重要的指标之一,特别是在搜索场景。之所以引入搜索引擎,是因为关系型数据库即使在单机的情况下搜索的效率也很差。为了提升单机搜索性能,可以引入像倒排索引这样的索引结构。同样为了提升向量搜索的性能,也可以引入向量索引。

💡 列式存储:数字化全力推进的当下,为了支持高效汇总分析,引入列式存储。它能够提升数据压缩率,避免大量不必要的 IO,提升系统的分析性能。

💡 向量化执行:通过将操作应用于一组数据(向量)而不是单个数据点来实现高效处理,从而减少查询执行时间,提升整体性能。

💡 物化视图:通过物化视图这种预计算的方式去避免反复执行同样的查询,进一步提升系统的性能。

2. 分布式Data Warebase

基于以上介绍的新一代技术路线和性能要求标准,ProtonBase 构建出一类全新的数据产品:分布式 Data Warebase。Data Warebase 这个词是 Data Warehouse 和 Database 这两个词的组合,它意味着 Data Warebase 同时具有了 Data Warehouse 和 Database 的所有能力和优势。

⭐️ 数据类型:基于关系模型的设计,分布式 Data Warebase 天然支持结构化的数据。通过扩展 JSON 这种文档模型,可以很好地支持半结构化数据。通过引入高维向量,支持从传统意义上的非结构化数据中提取的知识。

⭐️ 应用场景:除了基础的简单查询外,它还能够很好地支持关键词查询、以及 BI 方面的汇总分析,同时基于向量的引入,支持通过向量搜索提取知识。

⭐️ 挑战极限:分布式 Data Warebase 在性能、正确性、和实时性上挑战物理极限。

⭐️ 极简体验:分布式 Data Warebase 为用户提供了极简的体验,它兼容已有的生态,减少学习成本,充分发挥现有生态工具的能力。它通过隔离,保证不同场景之间互不影响。通过自适应保证它不仅在最苛刻的业务场景达到性能、正确性、和实时性的最优,而且在用户的实际场景里也能够挑战极限,达到具体场景里性能、准确性和实时性的最优。

分布式 Data Warebase 在数据架构上带来了怎样的改变?

3. 新产品带来数据智能新范式

分布式 Data Warebase 可以看作是对传统数据系统架构基于第一性原理的重构。通过对传统架构核心痛点的解构,采用全新的技术路线,一站式支持上层业务。极大地简化了架构,让技术重心重新回到对业务的高效响应上。

06/数据系统新使命:让数据涌现智能

当更多的业务开始基于自然语言的交互方式来创新产品的时候,当更多的业务数据开始结合大模型能力的时候,当奇点到来、AGI 实现之后,机器也将会和人一样具有智慧,可以对知识做深刻的推理,并做出战略性的决策。也许当那天到来我们将会发现表达智慧的新语言。

上层技术的不断创新和业务的不断迭代,对数据系统的要求也不再局限于存储、提取、管理、以及汇总分析信息,生成式 AI 的火爆出圈使得数据系统对知识的表达、理解、使用提出了新要求。伴随着数据从信息的载体越来越成为智能的燃料,我们断言数据系统新的使命将会是:让数据涌现智能

​​​​​​​

相关推荐
开着拖拉机回家1 分钟前
【Ambari】使用 Knox 进行 LDAP 身份认证
大数据·hadoop·gateway·ambari·ldap·knox
中草药z6 分钟前
【Spring】深入解析 Spring 原理:Bean 的多方面剖析(源码阅读)
java·数据库·spring boot·spring·bean·源码阅读
地球资源数据云7 分钟前
全国30米分辨率逐年植被覆盖度(FVC)数据集
大数据·运维·服务器·数据库·均值算法
QQ_77813297412 分钟前
基于深度学习的图像超分辨率重建
人工智能·机器学习·超分辨率重建
梦想画家21 分钟前
Python Polars快速入门指南:LazyFrames
python·数据分析·polars
INFINI Labs22 分钟前
Elasticsearch filter context 的使用原理
大数据·elasticsearch·jenkins·filter·querycache
Allen Bright23 分钟前
RabbitMQ中的普通Confirm模式:深入解析与最佳实践
分布式·rabbitmq
清 晨24 分钟前
Web3 生态全景:创新与发展之路
人工智能·web3·去中心化·智能合约
X_StarX32 分钟前
数据可视化期末复习-简答题
计算机视觉·信息可视化·数据挖掘·数据分析·数据可视化·大学生·期末
公众号Codewar原创作者1 小时前
R数据分析:工具变量回归的做法和解释,实例解析
开发语言·人工智能·python