引言：我们已经深处数字世界。通勤的地铁上看文章，在线设计平台上圆形设计，电商平台上买个东西，过节了给远方的亲朋发个红包… 所有这些便利都离不开一个东西：业务系统。按照 MECE 的法则，业务系统可以分为四个部分：UI（用户接口）、网络、业务逻辑、DB（数据库）。数据库是各种业务应用系统承载的基石，本文尝试以数据库视角出发，讨论下数据库经历过哪些迭代，以及它是如何一步步的构建起完整的业务系统的？

极简数据库发展史

文件系统时代（1950-1960 年代初期）

是的，你没看错。可能大家熟悉了库表形式的数据库之后，有些朋友或许对文件有些疑惑。是的文件也是一种存储数据的形式。这个阶段，应用程序需要自己管理数据的存取和更新。电影的应用就是磁带或磁盘存储系统。因为通常数据存储没有统一的结构，导致数据大量的冗余、更新复杂等问题。这一时期对应的是计算机从晶体管时代向集成电路时代转变。

网层型数据库（1960-1970 年代）

为了解决文件系统的冗余问题，这个时候开始对数据本身的组织形式进行了变革，比如以树形结构组织，每个记录有一个父记录的层次型数据库（Hierarchical Database），像 IBM 的 IMS，大名鼎鼎的 Apollo 登月计划就是用的这套系统。比如采用更灵活的图形结构，允许记录之间有多个父记录关系的网状型数据库（Network Database），像 CODASYL。但是，这种数据组织方式上带来了新的问题，最典型的就是扩展性差、维护极其复杂。

关系型数据库（1970 年代）

1970 年，埃德加·F·科德（Edgar F. Codd）提出了关系型数据库（Relational Database）的概念，他通过“关系模型”定义了如何用表格形式组织数据。1970 年代末，IBM 的 System R 和 Oracle 等数据库开始实现关系模型，因关系型数据库结构化的数据组织方式、脚本化的查询语言（SQL）、以及数据完整性和一致性保障，逐步替代了层次型和网状型数据库。典型的应用场景就是银行、电子商务、企业管理系统等。同一时间，计算机进入到微处理器和个人计算机时代。

对象数据库（1980-1990 年代末）

骨灰级程序员都清楚，编程语言早起主要以汇编、C、C++语言为主，早起主要是面向过程的语言。这一时期，随着 OOP（面向对象编程）的兴起，将对象存储方式与数据库相结合的 OOD（Object-Oriented Database）开始得到关注，支持复杂的数据类型和方法。但是由于此时关系型数据库已足够成熟，并且用户和开发者对于对象存储模型的需求不大，这种数据库系统未能广泛普及。这一时间，计算机进入到了以互联网为核心的计算机应用时代。同样是这一时期，1994 年 4 月 20 日中国正式接入国际互联网，现在著名的几个互联网大厂大都创业在这一时间，比如网易、搜狐、新浪、腾讯等。

NoSQL 和大数据时代（2000 年代至今）

随着互联网的高速发展和大数据时代的到来，传统的关系型数据库面临扩展性和高性能的挑战。特别是社交媒体、物联网、电子商务的爆发，带来海量的数据、非结构化存储、以及高并发应用，以及海量数据的搜索与数据分析。迫切需要能够提供灵活架构，能够水平扩展并处理分布式数据系统。这个时候就产生全新一类的数据库：NoSQL 数据库（"Not Only SQL"）。包括了文档型、键值型、列族型和图形型等，常见的数据库产品有：MongoDB、Cassandra、CouchDB、HDFS 等。这些新的数据库产品很好的满足了社交网络、物联网和大数据分析等场景的业务需求。

一个典型的例子就是区块链，键值存储数据库很好的支持了存储区块数据和交易索引，使用 MongoDB 存储与区块链的原始数据（如交易、区块），使用 Cassandra 处理实时交易信息或市场数据。

NewSQL 数据库（2010 年代至今）

虽然 NoSQL 能够在数据的处理速度、数据类型上能够较好的满足业务需求，但是 NoSQL 在数据库事务、一致性上问题表现同样比较明显。同时也为了弥补传统关系型数据库在扩展性问题上的先天不足，就产生了新一代的数据库系统：NewSQL。比如如 Google Spanner、CockroachDB。它们结合了关系型数据库的强一致性和 NoSQL 的扩展性。

以上从时间角度，整体上梳理了数据库的发展历史，可以看到一条清晰的数据库产品发展路径，围绕着数据的组织形式、数据类型、数据存储量级、性能等方面展开，随着上层业务的不断发展，数据库产品也会不断地进行迭代和系统升级。

两个重要的数据库

有两个数据库对当前社会影响深远，HDFS（Hadoop Distributed File System）、向量数据库。

早在上个世纪 90 年代左右，Bill Inmon 提出了数据仓库的概念，Ralph Kimball 提出了“以数据集市为中心”的维度建模理论，从此开启了数据仓库的分层架构（数据源层、数仓层、数据应用层）以及 BI 分析时代。指示这个时期，由于数据量级、计算机存储和计算技术有限，数仓和 BI 分析的价值并没有显现出来，直到本世纪初，数据量开启了指数级增长过程，列式存储、分布式计算、MPP，特别是 2010 年后的以 Hadoop 为主流大数据技术的出现，开始让人们逐渐意识到数据的巨大价值。可以指导业务精细化运营，可以通过大数据进行市场洞察并指导企业战略决策。这一切大数据光鲜亮丽的背后，是以 HDFS 为代表的大型分布式存储数据库为基础建立的。

同样是 2010 年前后，CV（计算机视觉）领域，深度学习技术在 ImageNet（李飞飞教授主导的大模型视觉数据库）上的突破，带领 AI 领域实现从学术实验室到大规模工业界的飞跃。在这个基础之上，直接促成了当前火热的 AI 底层算法 Transformer 的诞生，使得以 Transformer 为技术框架的 AI 大模型迎来了大众时刻。大模型的训练和推理最核心的一个关键点就是，它使用的不是一般的数据，而是向量数据。多模态的数据都需要先进行向量化才能被大模型拿来训练和推理。

一个不断发展的行业，往往会出现很多概念，实际工作中，不同背景的人往往会有概念混用的情况，以下我想对数据领域里面那些重要的概念，结合实际工作经验，谈一谈最新的理解。

对核心概念的深入理解

数据仓库与数据湖

这个是不管工作中，ToB 的市场营销中，或者是技术媒体的分享中，经常见到的词。其具体所指内容，不同人所讲的大都是有些出入。

从时间角度，数据仓库产生于 20 世纪 90 年代左右，数据湖的概念是伴随着大数据技术的发展成熟之后出现的概念，大约是在 2010 年前后的时间。

从发展角度看，数据湖是数据仓库的升级和进化。主要是因为传统数仓面向结构化的数据设计，且数据一般需要经过较严格的 ETL（清洗、转换、加载）及数仓架构设计，面对非结构化、动态变化的数据源，存在着比较明显的灵活性不足和成本高的问题。重要的是，企业需求向着实时性（行为日志分析）、多样性（多种数据类型）、深度分析（结合 AI 和机器学习对原始数据进行深度挖掘）发展。实际的生产环境下，数据科学家和分析师有时候更希望访问原始数据，比如探索性分析和机器学习场景，而不是受限于经过清洗之后的结构化数据。结合云计算和云平台的发展，自然而然就出现了数据湖的概念。其实从定义来看，数据湖是一个原始数据存储和管理的统一平台，能够存储任意类型的数据，结构化的、半结构化的、非结构化的。

简单来说，数据湖相对数据仓库，存的数据类型更多了，不需要严格的 ETL 过程，还有一点结合云平台让存储和计算的成本显著的降低。当然你也可以成这是升级版的数据仓库。2020 年，开始流行仓湖一体的 Lakehouse 架构，提供跨云的数据管理能力，如 国外的 AWS、Azure、GCP（Google Cloud Platform），开源的 Apache Hudi、Delta Lake、Iceberg、kudu，以及商业化的 Databricks、Snowflake、Cloudera 等。

实际工作中发现，数据分析或者商业分析的场景下，讲数据仓库的多一些。在市场、品牌、营销的部门讲数据湖的多一些。

关系型/NoSQL/NewSQL

关系型：这个概念是针对数据结构，这个是说存储的都是严格结构化的数据，一般会伴随着 AICD 的概念。

NoSQL：这个概念是针对数据结构，或者说数据模型而言的，扩展了数据库支持的数据类型，比如 Postgre 里支持几何型数据点线面。相比关系型数据库强一致性要求，NoSQL 追求“最终一致性”的理念。同时采用分布式存储和计算架构。

NewSQL：这是一个典型的“既要又要”的场景。是一个集成的概念，整合了分布式的大规模数据存储与处理，整合了关系型数据库的事务特性 AICG，整合了 NoSQL 支持不同数据类型特性。NewSQL 代表了当前数据库产品发展的最新形态。

从早期的文件存储到如今多样化的技术发展，数据库经历了许多创新。目前关系型数据库在许多传统应用中仍占主导地位，而 NoSQL 数据库则在处理大规模、非结构化数据时表现出色，NewSQL 在云计算的时代逐渐成为发展主流。

这些不同特性的数据库产品，是如何一步一步构建起庞大的业务系统，不断的满足业务从简单到多元发展过程呢？

数据库角度看业务系统的演进

这里我们以内容媒体平台为例，暂且叫“小紫薯”吧。

业务初期到经营分析阶段

业务初期，内容创作者把自己的作品发布到小紫薯，用户好奇地在平台上浏览起来，寻找着自己感兴趣的内容，之后可能会在平台上完成点赞、收藏、评论等常规内容交互。

实现这样一个内容平台应用，首先从核心的应用服务搭建出发，一开始业务体量相对有限，产品功能设计一般会按照 MVP 的思路进行设计。从数据架构角度看，概括来说就是简单查询，比如根据内容的一级分类：知识、游戏、科技等。所以最初一般会把数据存储在关系型数据库中，比如 MySQL 或者 PostgreSQL。

随着市场营销、推广、运营等操作，越来越多的人开始在平台上发布作品，也吸引到更多的用户在平台上浏览内容。很快就会发现简单的单机关系型数据库会遇到性能瓶颈，这个时期会引入一种新型 NoSQL 类型数据库，比如 MongoDB。主要因为其简单增加机器资源，就可以实现水平扩容以有效应对更高的业务负载；因其分布式架构和优化的数据存储方式，更适合处理大数据量的业务场景；因其灵活的数据模型，能适应多变应用需求。

用户量的上升，伴随而来的是需求越来越多元，用户不在局限于通过简单分类的方式去查找感兴趣的内容，而是希望能够根据一些关键词快速找到自己感兴趣的，在这方面 MongoDB 提供的能力相对有限。于是业务系统引入了 ElasticSearch，主要其提供了强大的搜索能力，采用内存数据处理使得查询速度非常快，近乎实时的数据处理等。

为了让搜索引擎能够提供搜索服务，首先需要把数据导入到搜索引擎之中。数据的导入一般分为两种形式。第一种是全量的数据导入，关系型数据库和 NoSQL 数据库里面的数据会定期以全量的方式导入到搜索引擎。第二种，如果应用对数据的时效性有比较高的要求，还要再引入增量的数据同步链路，比如采用 Kafka 和 Flink 这样的技术把上游的变动及时地同步到搜索引擎。当搜索引擎有了这些数据后，就可以为应用提供高性能的关键词搜索了。

至此，通过利用各类数据库产品，业务系统具备了基础信息的存储、简单查询和高效搜索能力。

这个时期的业务，已经渡过了最初的创作者量少、内容消费者少、业务数据量少的状态，我们希望对业务进行各种业务分析，比如节假日平台播放量的同环比是什么情况，最受欢迎的内容作品 Top50 是哪些，涨粉量 Top10 是哪些博主，平台的用户画像是什么样等等。业务系统开始引入了像 Snowflake 或者 Hive 这类数仓产品，把各种业务数据从各个数据库同步到数仓之中，然后就可以使用 ClickHouse 或者 Hive 对数仓进行的全面的 BI 分析。

可以看到随业务量从小到起量，业务系统会引入不同的数据产品来解决不同的场景问题。又因为各系统依赖的数据来源不同，系统内部存在大量的、复杂的数据同步作业。此时的业务系统数据架构大致如图：

传统式 AI 助力精细化运营阶段

首先解释下，这里的传统是 AI 是相对于当下比较火热的生成时 AI 而言。传统 AI 最典型的应用包含了业务洞察和实时决策等商业智能的内容。

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

离线洞察

品牌商家在广告投放的时候，希望更多的触达自己投放内容的目标用户关注和浏览到。比如一个做母婴品牌的内容，更希望自己的内容被 25 岁-35 岁的非单身女性看到，结果你让朝气蓬勃天天关注 NBA 的年轻小伙看到，他肯定不感兴趣，很快就会滑走。为了做到这点，就要首先理解用户，根据用户的基本信息、以及用户和平台交互的各种行为信息，甚至是用户与内容的评论信息，构建出关于用户的不同维度下的标签信息。

有些标签可以根据用户的基本属性就可以得到，但另一些标签可能就要通过规则或者算法的方式生产，比如说例子中我们说的是否单身，是否有小孩。这个时候，就要用到离线业务洞察，首先对平台用户数据做分类、规整、预处理等操作，之后找出生产指定标签所需要的特征，这一步就是算法开发中的重要一步：特征工程。最后根据拿到的特征进行模型的训练。

这样品牌广告主在投放的时候，就能自主的根据自己的产品目标群体定位，相应到通过平台上的标签体系圈选出感兴趣的人群，然后将这个人群包跟自己投放的内容一起打包，进行营销推广活动。

到这一步，数据架构方面新增了数据预处理和模型训练。

实时决策

对于内容平台来讲，会经常做一些运营活动，比如一段时间内，对作品发布量达到指定数量，粉丝量达到指定数量或者用户互动量达到指定量的时候，给内容创作者一定的奖励，比如流量支持或者解锁平台新功能。

并且一段时间之内可能会存在多个运营活动，这就需要平台能够实时地根据用户的行为，进行标准的判断，是否给到用户活动奖励。

技术实现上，这个功能需要依赖于一个在线的模型服务：激励策略模型，一般基于强化学习在线优化奖励策略。

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

除了实时的运营活动以外，实时决策还应用于个性化推荐、RTB（广告实时竞价）、流量分发、内容审核等场景，这里就暂时不过多展开。这个阶段，数据架构大致迭代升级为如图：

大模型 AIGC 助力业务创新应用

2022 年底，以 ChatGPT 为代表的大模型，让 GenAI（生成式 AI）开始出圈。这不仅带来了技术应用上的新突破，也带来了人机交互模式上的创新：基于自然语言的对话。

比如在小紫薯平台上，用户输入“有什么适合冬天穿的高级又保暖的搭配推荐吗？”，“推荐一些简单易学的家庭健身计划，活动量不需要太大”等等。系统基于大语言模型理解用户意图，并结合内容平台的海量笔记数据，就可以生成结果列表。

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

相比传统 AI，生成式 AI 训练的数据集要大几个数量级。最先进的大语言模型几乎使用了人类所有公开的高质量文本语料，因此它具备非常广泛的知识和智能。当你和 ChatGPT 这样一个先进的大语言模型交互时，它往往能够对很多问题给出很好的回答。

这依赖于大模型领域重要的几个技术。上下文学习、向量搜索、检索增强生成-RAG、微调。这里对技术不做过多展开，只简单提下 RAG 和微调。

检索增强生成-RAG

把向量搜索技术和大模型上下文学习的能力相结合，就发展出了检索增强生成技术，即 RAG。当用户提交一个问题，先让大语言模型改写这个问题，然后用文本嵌入模型为改写好的问题生成嵌入向量。再通过向量搜索找出跟这个问题对应的嵌入向量最近的一些嵌入向量。然后再把知识库内容以及用户的问题同时作为上下文输入给大语言模型，大语言模型就可以通过刚才所说的上下文学习（也就是 In-context-learning）的能力去理解这些信息，并且根据这些信息给出答案。

模型微调

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

在实际的应用中，往往会把这几种方式结合在一起，还可能使用外部的工具，我们把这类智能的应用叫做数据智能体，即 AI Agent。

最终，业务系统数据架构迭代至如图：

至此，一个典型的平台型业务系统，从应用角度来说包含了，简单查询、搜索、推荐、数据分析、推理的能力。这就要求数据库产品要有事务、分布式、离线分析、实时处理、训练推理等能力。

以上这些内容数据库产品和业务应用，在电商、金融、游戏、媒体、企业服务等行业的业务系统中广泛的存在，它们构成了一个个系统的关键功能，共同构建了大家日常应用的数字环境。

数据库产品发展预测

随着本世纪前 20 年，大数据、机器学习、深度学习的发展，助力社会快速进入数字时代。特别是以 ChatGPT 为代表的新一代 AI 大模型技术，深刻地影响着人与系统的交互模式，随着大模型技术的不断完善与迭代，人机交互范式大概率会由触摸交互向自然语言智能交互转变，这将加速人与目标信息的链接效率。如我们所举的例子那样，你用自然语言表达好你的需求，剩下的交给智能体帮你完成就好了。

当然这个需要时间去一步一步实现。此外当业务系统开始有了初步的语义理解和推理能力之后，各种半自动化、全自动化的业务需求也将会越来越多，这也是传统人机交互模式的另一个重要趋势：自动化。

可以预见的是，业务需求的不断变化，会不断的有新的数据库产品出现。作者认为，数据库会有两个发展方向：

一类是在专有特定场景下的数据库，比如满足移动环境、嵌入式环境，会针对存储、性能、功能进行特定的优化。

另一类是融合型的数据库。以上业务系统的生长过程可以看到，大量不同类型数据库集成在一起，且因业务实现需要存在大量数据同步任务，这会带来一致性、时序、性能等各种问题，这些问题正式下一代数据库的发展方向。

Postgre 也许是一条解决问题的思路，即以关系型数据库为基础，扩展支持的数据类型、引入分布式、高性能、快速检索等特性。