如何从 0 到 1 ，打造全新一代分布式数据架构

导读：本文从 DIKW（数据、信息、知识、智慧） 模型视角出发，探讨数字世界中数据的重要性问题。接着站在业务视角，讨论了在不断满足业务诉求（特别是 AI 需求）的过程中，数据系统是如何一步一步发展到体量庞大、性能飘忽、框架复杂。面对业务对性能、正确、实时三大核心需求，重点讨论了一种全新架构对已有系统问题的新解法，并回归业务原点演绎新思路如何一步一步落地的全过程，最终打造出新一代数据系统 - 分布式 Data Warebase。最后，通过结合电商和广告行业的实际案例，展示了这一新系统如何为企业带来技术和商业上的深远价值突破。

作者：杨克特

整理：Taylor

本文整理自 ProtonBase 技术副总裁杨克特在 SECon 上海站的演讲《分布式 Data Warebase - 面向 AI 时代的数据架构》。

---

01/数字世界的 DIKW 模型

人类世界的智慧是怎么来的？1989 年 Russell Ackoff 提出了一种信息层次模型：DIKW（Data、Information、Knowledge、Wisdom），描述了一条从数据到智慧抽象加工链路，帮助组织和个人在决策中有效利用信息。

怎么理解这个模型呢？这里举个例子。

当只看到一个数据 9.8 的时候，你可能会一脸疑惑，What？这是因为并没有给到你，这个数据对应的上下文信息。当你收到的是“一个一千克的铁球以 9.8 米/秒²的加速度在下落”，你就大概就知道了这个 9.8 指的是铁球的加速度。

这个时候你可能好奇，拿着其他材质、其他形状的球进行观察，发现它们下落加速度都是 9.8 米/秒²，于是你会归纳出“所有物体都会以 9.8 米/秒²的加速度下落”。这种归纳和抽象使信息能够转化为知识，从而可以推广预测，比如可以推断 8 kg 的铅球也将以 9.8 米/秒²的加速度下落。

基于上一步的总结和归纳，在深入抽象和理解之后，你可能会进一步得推断出“重力加速度与落体本身的特性无关”，进一步可以将其推广到时空维度，这就是广义相对论的核心思想。

现在，其实我们已经进入到了数字世界。这个世界就是基于数据一步一步构建而来。

数字世界的智慧构建也经历了跟 DIKW 相似的过程。从最开始的找到数据、对数据进行组织规划、统计分析。这个刚好对应了数据的价值链条，即从数据采集、业务建模、数仓建模分析。

底层数据的好与坏，决定了上层应用产生的洞察质量。比如数字化运营场景，因为数据收集不全或者不完整，基于有误导性的信息，推导出偏离反映业务实际的结论，进而错误得指导投放策略，最后没能拿到预期的商业结果。

所以在数字时代，数据更重要。

个业务系统构成了数字世界最核心的基础。那数据是如何被一步一步用来构建起庞大的业务数据系统呢？

02/企业级数据系统架构演进

这里以一个民宿平台为例，讨论在不断满足业务需求的同时，业务数据系统是如何从单一到多元、从简单到复杂。

💡 从 MVP 打磨到业务起量

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

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

随着业务体量增长，遇到五一或者国庆这样的假期，民宿的需求往往爆发式增长，很快就会发现简单的单机关系型数据库会遭遇性能瓶颈，这个时候我们一般有两种选择：在已有的关系型数据库上进行分库分表；或者引入 NoSQL 类型的数据库，比如 MongoDB。主要因为以下三点：

• 通过简单增加服务器资源，就可以实现水平扩容以有效应对更高的业务负载；
• 分布式架构和优化的数据存储方式，更适合处理大数据量的业务场景；
• 灵活的数据模型，能适应多变应用需求。

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

此时的数据架构大约是这样：

💡 传统 AI 助力运营精细化

首先解释下，这里的传统 AI 是相对于当下比较火热的生成式 AI 而言。这里主要讨论传统 AI 下，常见的业务应用需求：含业务洞察和实时决策。

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

同时伴随业务用户量的增加，不仅带来人群的多样性，更带来了需求的多元化。以往面向全量用户的运营方式收到的效果开始变得越来越小，甚至有时还会产生亏损。同时伴随着市场环境由增量市场转变为存量市场，面对用户的运营更加呼唤企业精细化运营。

有了数据分析，运营人员就可以根据用户画像，找到自己活动推广的目标人群，完成定向投放的精细化运营，并根据投放的效果，可以实时看到活动的效果。当然手法更加细腻的市场或运营人员，会采用 AB 实验的方式，验证了有效果之后再从小量推到全量。整个活动的全链路都依赖于数据系统强大的汇总分析能力。

这里举两个例子：业务洞察、实时决策。

离线 AI：业务洞察

民宿房东希望更多住客来自家民宿，所以他决定通过折扣来做推广。为了提高推广的成功率，他希望只发送给全量用户中，对价格敏感的那一群人。为了做到这点，首先理解用户，根据用户的基本信息、以及用户和平台交互的各种行为信息，构建出描述用户的知识。这个知识可以表达为潜空间中的一个嵌入向量，为每个用户构建了相应的嵌入向量后，就可以对这些嵌入向量分类，进而判断出一个用户是否对价格敏感。找到这部分价格敏感的人群包，就可以交由运营或市场部门进行营销活动。

从工程实现上讲，需要首先对大量的用户行为数据，包括业务数据等进行数据的预处理，筛选出丰富的人群特征，之后交由模型训练，找出判断价格敏感用户的关键特征，最后从用户表中找到符合特征的用户人群。

此时的数据架构大约是这样：

实时 AI：实时决策

民宿是较受季节因素影响的行业，有淡旺季之分，因此如果民宿价格全年保持不变，多少显得有些不合理，也不符合市场经济学的基本规律。淡季时，可能长时间无人租住，给老板带来一笔不小的损失。所以房东为了提高淡季入住率，在总体空置率比较高的时候，更倾向降低价格以吸引潜在的租客。同样的道理，在旺季时候，在不影响入住率的前提下，稍微提高下价格，能够给自己带来更好收入。于是，就产生了价格波动。这类情况同样在民航、房地产、钢铁等行业中存在。

价格什么时候变动？变动多少？怎么调整可以让利益最大化？如果人工判断将会是一件复杂又有些繁琐的事情，相信老板内心也是拒绝的。可以试着使用传统的 AI 来做这件事。民宿老板想产生更多盈利的业务诉求，就转变为系统上如何实现价格的自动调整问题。

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

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

为了给这个在线模型服务提供高吞吐、低延迟的特征输入，需要有个在线的特征存储，特征的数据量往往比较大，通常会采用 MongoDB 或者 HBase 这类存储作为在线特征存储。由于训练时用到的一些特征也可能被当作模型服务的输入，这部分离线的特征必须同步到在线的特征存储中。

此时的数据架构大约是这样：

2022 年底出圈的大模型技术，让生成式 AI 带给业务应用新的想象力，某红衣大叔曾说过：“任何行业都值得用大模型重做一遍”。

💡 生成 AI 创新应用新常态

大模型号称超越所有人类的知识储备，这一点毋庸置疑，但在细节颗粒度上，其表现可能并不尽如人意。以公司为例，如果询问大模型关于员工停车位的具体安排，它可能会给出答案，但这些答案的准确性或实用性，往往不及直接查阅文档或向相关人员咨询。实际上，公司内部存在大量内容型文档，如员工手册、流程规范、项目工程管理等。如果将这些资料整合进大模型的学习体系，系统的实用性和准确性将显著提升。通过结合 RAG（检索增强生成）技术，大模型能够有效补充外部知识库，从而实现更精准和具有实际价值的输出。

这里简单提下 RAG 技术实现思路。

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

此时的数据架构大约是这样：

业务诉求的不断发展，让业务数据系统变得越来越庞大。面对如此复杂、大体量的数据架构，很难想象它能很好的满足业务高可用、高效率的、高质量的诉求。这种架构往往也存在一些显著的痛点。

03/问题与需求之间的解空间

🔍 那些不得不提的痛点

运维视角：面对庞大的业务系统，感受最近同时也是最深的要属运维人员，同时运维这么多业务系统或数据产品，势必带来运维复杂度的上升。比如 CPU 抖动下系统就挂掉，特别是数据同步，它往往是一个系统中最薄弱的环节，很容易导致系统的不稳定、上层数据的异常。同时因为一份数据需要在多个产品中重复存储，一致性方面存在很大挑战也带来了更大的成本。

开发视角：构建这样复杂的架构有较高的开发门槛。开发人员需要学习和理解多个不同的数据产品，每个数据产品都有其局限性，开发人员需要去理解并绕开这些问题。对很多中小公司来说，招聘大量优秀的数据和 AI 工程师是个挑战，这就导致很多数据的业务价值并没有被完全地挖掘出来。即使团队很幸运拥有这样工程师，面对业务诉求，工程师们可能会采用多种数据产品或技术，以尝试满足满足业务诉求，这个时候大量的时间其实花在了繁琐的数据同步上，这无疑极大地降低了开发效率，降低了业务的迭代节奏，也相对阻碍了业务的发展速度。

业务视角：尽管我们刚才所讨论的架构是从业务需求倒推而来，但从业务视角来看，它仍然存在一定的不足。一个显著的问题是数据同步，特别是不同产品之间的数据传递与更新，这不可避免地带来了数据延迟。数据延迟往往会导致业务系统中的数据不一致，从而影响决策的准确性，甚至引发业务问题。对于创新型业务而言，数据延迟问题尤为突出。因为这类业务通常涉及多个系统的协作和数据流转，任何延迟都会显著放慢从概念到落地的进程，拖慢业务的实施速度。这样一来，业务就难以在短期内形成市场竞争力，错失快速响应市场需求的机会。

🔍 真真实实的业务诉求

在数据系统的应用中，性能、正确性和实时性是至关重要的要求，直接影响用户体验和业务运作的效率。

性能方面，系统需要克服单机容量瓶颈，提升查询任务效率，并支持水平扩展。这不仅关系到用户的体验，还可能直接影响业务的顺畅进行。举个例子，用户希望通过即席查询快速获得数据，却因查询延迟而只能看着加载圈转动，无法及时获取所需信息。再如，当任务量增加时，机器资源的不足可能导致系统崩溃，造成业务运营中断，第二天早上运营人员无法及时查看前一天的数据，严重影响业务处理和决策。

正确性则是数据系统的基础要求，关乎数据的准确性和一致性。保证数据的正确性不仅能支撑业务的正常运转，也为业务拓展提供可靠的数据支持。如果数据系统频繁出现问题，带来的不仅是经济损失，更重要的是会削弱业务用户的信任，影响系统的长期使用与推广。

实时性日益成为许多应用场景的核心需求。特别是在像股票交易、实时风控和电商推荐系统等关键业务中，实时性直接决定了业务的成败。例如，在风控场景下，数据的实时处理与分析能够立即识别风险，防止潜在的资金损失；在电商推荐系统中，实时数据分析能够提升用户体验，精准推送个性化推荐，增强用户粘性。随着实时需求的不断增加，数据系统必须具备快速响应和处理的能力，以适应这些关键且高效的业务场景。

🔍 创新思维下解题新思路

在业务不断发展的过程中，架构上的问题往往会被推到一旁，特别是在经济爬坡周期，企业更倾向于加速探索新的业务模式，架构中的数据同步、性能瓶颈和延迟等问题，可能在这种环境下愈加突出。尽管如此，业务依然不会因此停止其发展节奏，反而可能带来更多的压力和挑战。

现有的庞大数据架构，实际上是在当时的技术条件和公司系统环境限制下逐步构建起来的。多数情况下，企业只能采用增量方式来应对问题，也就是基于现有系统的基础，逐步加以优化和调整。可是，如果我们跳出当前架构的框架，从第一性原理出发，是否可以从零开始，打造一个全新的、创新的数据系统呢？一个不仅能完美满足业务核心诉求，还能彻底解决当前架构臃肿、低效、不可扩展等问题的系统？

其实，行业中已经有一些成功的探索和实践。数据库技术已经发展了十多年，逐渐走向成熟。那么，假如我们回到业务发展的起点，利用当今最前沿的技术思想和相对成熟的解决方案，重新构建一个完全符合未来业务需求的数据系统，结果会是怎样？

为了便于说明，我们将这个全新构建的数据系统命名为“巨鲸座”（这一名字取自许多企业在研发新系统时所用的代号，往往寓意着宏大和先进，如“盘古”“天枢”等）。这个代号不仅象征着系统的雄心，也代表着我们对未来数据技术突破的期待与创新。

04/拆解核心技术打造新一代系统

接下来一起回到业务最初的状态，看巨鲸座是如何一步一步，从 0 到 1 打造新一代数据系统。

✨ 简单查询：解决分布式、一致性问题

此时，业务系统面临的最大痛点是：单机系统的存储容量瓶颈及扩展性严重不足。因此，很多人会想到，将数据存储分布在不同的机器上，借此解决扩展性问题。然而，这样的做法也引发了一个天然的问题——一致性。

在分布式架构中，一个操作可能涉及到多个机器上的多张表。例如，用户表和订单表可能分布在不同的机器上。当业务方需要删除一个用户时，系统需要在多台机器上找到该用户的记录，并同时删除与之关联的多个订单。如何确保操作的一致性，并避免出现“脏数据”或不一致的结果，是一个关键问题。

为了解决这个问题，出现了两种思路：

1. 在关系型数据库基础上实现分布式，同时解决一致性问题。
2. 使用 NoSQL 数据库，特别是文档型数据库，在扩展性方面天然具有优势。

在第二种思路中，NoSQL 文档型数据库通过一种“取巧”的策略来简化一致性问题：将相关信息（例如，用户和订单）存储在同一个文档中，这样所有的数据操作就仅仅针对单个文档执行，避免了跨机器的数据同步问题。然而，这种方式仅适用于 1 对 1 或 1 对多的场景。在多对多的场景下，例如商品表与订单表之间的关联，数据操作依然会跨越多个机器和多张表，导致 NoSQL 数据库的处理复杂度大大增加。

基于上述问题，巨鲸座决定采用第一种思路，即在传统关系型数据库的基础上实现分布式架构。这种方式不仅能继承关系型数据库成熟的事务一致性保障能力，还能充分利用 SQL 生态圈的优势，尤其是在复杂查询和数据模型上的支持。

通过使用分布式事务和类型扩展，巨鲸座可以替代传统的 MySQL/PostgreSQL 和 MongoDB，满足业务对大数据量和高一致性要求下的简单查询支持需求。这样，企业在构建大规模分布式系统时，不仅能实现数据的扩展性，还能保持高效、可靠的一致性保障。

以民宿平台为例，通过采用巨鲸座，民宿老板可以优化其数据架构。例如，在管理系统中，民宿描述和条件信息的修改会立即反映到数据库中，而不需要等待延迟同步。搜索引擎和业务系统的数据同步问题也可以通过巨鲸座的分布式关系型数据库架构得到解决，使得业务数据和搜索数据同步更新，避免了由于同步延迟导致的业务损失。

总之，巨鲸座提供了一个兼具高性能、高一致性和灵活扩展性的解决方案，为分布式架构中的一致性难题提供了全新的解法，并助力各行业系统架构的优化与创新。

✨ 改造关键字搜索：解决实时性诉求

我们继续以民宿平台为例，假设民宿老板为了提高自家民宿的曝光率，升级了民宿的描述和条件，并将这些信息录入后台数据库系统中。老板使用了“免费停车”、“下午茶”等关键字进行搜索，然而，当他在平台上进行检索时，仍然找不到自己民宿的相关信息。

从技术角度来看，这个问题的根源在于业务库和搜索引擎之间的数据同步出现了延迟或问题。通常情况下，系统会设置一些同步策略（例如每 15 分钟同步一次），这意味着当业务库中的数据更新时，搜索引擎的索引并不会立刻同步更新，造成了数据的不一致和延迟。虽然这种延迟在技术上是可以预见的，但从业务角度来看，它显然无法满足实时性需求，尤其在民宿预订量高峰期，如节假日前夕，客户希望能够在短时间内找到自己的房源，这种延迟可能会直接影响订单量，从而影响商业收入。

为了优化用户体验，如何实现实时响应呢？

一个大胆的思路是：既然数据同步带来了延迟，那能否直接去除同步环节？也就是说，能够在原始业务库数据上进行实时搜索。这就需要解决的最后一个问题是：如何确保搜索性能。

对于搜索引擎来说，它之所以能够提供快速的关键字查询，依赖于一种叫做“倒排索引”的技术。倒排索引通过构建文档与关键词之间的映射关系，从而快速定位到相关数据。为了实现这一点，巨鲸座在其分布式关系型数据库的基础上，直接实现了倒排索引，同时引入了全局二级索引。通过异步方式，将数据库表中被索引的列与主键列自动同步到索引表中，这种同步通常会在毫秒级别内完成，几乎没有延迟。

通过这种方式，巨鲸座不仅实现了原始业务库上的实时搜索，而且省去了引入额外搜索引擎的需求，解决了数据同步带来的延迟问题。

基于这一架构，民宿平台的数据系统可以进行如下改造：

• 业务数据实时更新：无需等待数据同步周期，业务库和搜索索引保持实时一致，用户搜索时能够快速获取最新信息。
• 简化架构：通过将数据存储和搜索引擎功能集成在同一个系统中，减少了维护成本和系统复杂性，同时避免了数据同步带来的潜在问题。
• 提升响应速度：通过倒排索引和全局二级索引技术，搜索查询的响应速度得到了大幅提升，能够实现秒级响应。

这种改造不仅能显著提升用户体验，还能帮助民宿平台在竞争激烈的市场中脱颖而出，增强业务的实时响应能力。

到这里，民宿应用数据系统架构可以改造如下：

✨ 改造数据仓库：解决离线、实时问题

目前绝大多数情况下，大数据主要基于离线数仓搭建，离线数仓有个很大的问题，为了追求速度和效率的平衡，在写操作上，会依赖于前值系统的攒批，也就是会每隔固定的时间去执行。这种实现方式天然的很难到达实时性要求。

大数据的另一种是基于实时数仓的方式搭建，其实是间隔更小粒度的离线数仓，数据写入追求最终一致性。这就会导致出现一些比较隐晦的场景，比如张三跟李四转账 50 元的场景，由于中间链路问题，可能会出现李四账户先进行处理（先收到消息），假如在这个时间节点上发起了一个平台账户余额的查询请求，就会发现平台凭空多了 50 元。当然业务系统处理时，可能会采取一些策略方式，来避免这种小概率问题的产生，但这种问题还是依然存在。

而这种事务性方面的问题，天然的是关系型数据库擅长解决的，用一致性保障实时查询的要求。巨鲸座要想完全实现数据仓库，还需要拿下数据仓库最核心的三个技术点：

列式存储：大数据的分析通常情况下采用多维分析的比较多一些，所以相比行数据，更关心某一列或某几列的数据，所以才去列式存储更适合分析的场景，同时同一维度的内容语义上更接近，压缩效率更高，更有利于存储性能提升。

向量执行：计算方面，大数据需要处理的数据量级很大，在计算方面，算子通常将操作应用于一组数据（向量）而不是单个数据点，从而来实现高效并行处理，减少查询执行时间和提升整体性能。

物化视图：这是一种在建模方面，通过预计算的一种方式，避免相同的数据查询请求反复执行，降低系统开销同时加速查询速度。

✨ 改造语义搜索：解决向量化问题

大模型最核心的底层能力在于语义搜索，其数据支持层面依赖于向量数据库，而向量数据库最核心的技术点在于两个：向量类型、向量索引。

向量类型借助关系型数据库的类型扩展能力，就可以相对方便的实现。就像搜索召回系统依赖于倒排索引一样，在大模型的应用领域中的向量召回依赖的是向量的索引，同样的也可以在关系型数据库的类型扩展中实现。

从工业实践来看，要用向量的话，或许并不需要一个单独向量数据库，可能一个插件就够用了，比如 PostgreSQL 中通过 Vector 插件的方式就能集成向量能力。

当在关系型数据库系统中，同时实现了向量类型和向量索引的话，还会有一个意外的好处：更有的搜索效果。当只在向量这个维度做召回，有时候效果也许并不是最好的，其实也可以结合关键词搜素领域里面的处理策略，比如一种考虑了文档长度和词频的饱和效应、改进的 TF-IDF：BM25。比如以下这篇 Paper 中，作者发现采用结合了关键字和向量的混合向量召回技术，其效果比两种形式微调之后的大模型相比，效果更好。

到这里，巨鲸座已经集成了众多能力，最终其对民宿应用数据系统架构的终极改造如下：

这是一个极简的业务系统数据架构。也许你会问，原有系统也能满足这样的业务诉求，除了表面上看上去的系统架构精简之外，还有其他区别吗？这里就不得不提到整合的系统带来的最大好处：极致的用户体验。

统一 API：原有架构中，每一套数据库系统都有自己的 API，当需要集成的时候，就得要熟悉每套系统的 API，同时了解对其他系统的能力边界、兼容性等问题，还要在系统之间去磨合这些差异。当巨鲸座把所有的能力都集成在一个系统中之后，系统底层作为一个完整的产品，把这些差异都有效处理，对上层提供统一的 API（SQL），极大地降低技术门槛，让技术人员专注于公司业务需求的开发。

兼容已有生态：基于标准化的查询语言，这样巨鲸座就可以无缝隙的介入已有的 SQL 工具生态，比如可以直接使用 Navicat 进行客户端的连接和操作。

隔离：作为数据库事务管理 ACID 四大核心特性之一，事务是保证分布式数据库一致性的关键。通过 MVCC（多版本并发控制）、隔离级别、依赖协议、优化算法，实现高效的隔离与分布式隔离。

自适应：特别是在高并发、实时分析、多租户等环境，自适应是保证系统稳定的重点。通过查询优化器动态选择最佳执行计划，比如当发现单条的写入计划只会影响某一个数据分片时候，就可以采用一阶段提交的方式优化写。当遇到一个聚合查询涉及的数据量非常大的时候，可以选择分布式的执行计划。此外还有通过负载均衡，能够根据节点的负载情况动态调整数据分布和任务调度等。

05/Data Warebase 新一代数据系统

这里，我们给代号巨鲸座定义了一个新的名字：Data Warebase，它整合了两项发展相对成熟的数据系统技术能力：Database（数据库）和 Data Warehouse（数据仓库）。这意味着 Data Warebase 同时具有 Data Warehouse 和 Database 的所有能力和优势。

我们来整体的梳理下，分布式 Data Warebase 所具备的完整能力地图。

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

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

挑战极限：将所有的技术能力，基于统一的设计打造的分布式 Data Warebase ，在性能、正确性、和实时性上挑战物理极限。

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

06/客户应用检验实战效果

✔️ 跨境电商

该客户是一家在全球已有超过 200 万的粉丝，覆盖来自 100 多个国家的消费者的跨境出海品牌。其主要对数据库产品的诉求集中在分布式事务、实时 OLAP、高并发关键字查询、大数据分析。业务系统的不断迭代中，主要有以下痛点：

架构：构建复杂的系统要求研发人员熟悉多种产品及其特性，这显著提高了开发的难度和门槛。多种产品的共存增加了运维工作的复杂性，尤其是在数据同步任务方面，给运维团队带来了额外的挑战。尽管整体数据架构是随着业务需求逐步演进而形成的，但随着业务的发展，也暴露出了一些问题。一方面，系统内部多点数据同步不可避免地会导致一定的数据延迟；另一方面，这样的架构设计也可能引发数据不一致的情况。

性能：之前使用的 PostgreSQL 在线上持续运行一段时间后，会发生某些场景查询越来越慢的问题。重启或手动执行 VACUUM FULL 后可恢复正常性能，但是 VACUUM FULL 会锁表影响线上服务，因此只能选业务低峰期执行。存在较慢查询。如在 ERP 线物流场景下，大部分查询需求秒级返回，但从之前线上某天日志来看，单日最慢查询达 147 秒。在大数据场景下使用 C 产品，涉及一个几十亿大表和其他表有比较复杂的关联和统计查询，只能支持最多一个月内的统计查询，时间范围有限，超出限制会出现内存溢出。

弹性：随着业务发展，线上各云产品实例随时有扩容需求。目前绝大多数云产品扩容时效性都在分钟以上，有的甚至需要 10 分钟，在面对扩容场景时有些力不从心。另外在扩容过程中服务也会受到一定影响，甚至需要停服进行升级。

多云：部分数据库产品和云数仓产品与云平台绑定。当客户有搬云或者出海等迁移需求时，在目标云上寻找替代品往往存在两大问题：数据同步、瓶替缺失。数据同步本身就是比较薄弱的环节，容易出错，同步后数据校验也需大量人力。无对应替代产品：某些数据产品与云平台绑定，换云后可能找不到对应替代品。

引入 ProtonBase（基于分布式 Data Warebase 理念打造的产品）之后，对业务系统的备份库统一迁移到 ProtonBase 中，同时提供分析支持。最终的效果如下：

在高效查询方面，ProtonBase 相对于 PostgreSQL 有明显的性能优势。在全量查询下，最慢的 query 查询性能从 147 秒提升到了 14 秒，是原来的 10.4 倍。针对高频更新优化，稳定的查询体验。平均延时方面降低了 5 倍效率。统一的架构带来冗余存储的大幅度减少，特别是让存储成本降低了 50%。

✔️ 广告行业

在数字广告领域，实时性和精准性是成功的关键。广告平台需要处理海量的实时竞价请求、用户行为数据以及广告投放效果数据，以实现精准投放和高效的广告优化。面对高并发访问、毫秒级响应、实时数据分析以及复杂用户画像构建的需求，传统的数据库架构已难以满足。

主要的挑战在于数据容量、服务质量（SLA）、实时高并发。

广告实时竞价（RTB）要求平台在毫秒级内完成从接收广告请求、匹配用户画像、计算竞价到返回广告内容的全过程。数据库需要支持超低延迟的查询和事务处理，任何性能瓶颈都会导致竞价失败，直接影响广告收入。这方面 ProtonBase 支持到 10K rps 的峰值数据写入。

广告平台需要同时处理全球范围内的大量请求，高峰期每秒可能有数百万次的竞价和广告投放请求。系统必须支持高并发的读写操作，确保在高负载下仍能稳定运行，防止系统崩溃或响应延迟。在方面 ProtonBase 帮助客户数据处理性能提升 8 倍。

为实现精准投放，需要对用户的行为数据进行实时分析，构建复杂的用户画像。这涉及对海量数据的实时计算和更新，传统批处理方式无法满足实时性要求，可能错失商机。替换为 ProtonBase 之后，使得广告转化效率提升，营收提高了 20%。

ProtonBase 提供了一个高性能、安全可靠、易于扩展的数据处理平台。通过利用 ProtonBase 的多云原生、存算分离架构，提供强大的实时数据处理能力和弹性扩展能力，实现毫秒级的竞价处理、实时的用户画像分析以及投放效果评估。同时，ProtonBase 的高并发事务处理能力确保广告平台在高峰期的稳定运行，从而提升广告投放效果和运营效率。

最后，AI 加速数字社会的构建，企业的数据将比以往任何时候更加重要，同时 AI 给数据平台提了更高的要求，更大量级的数据处理速度、更高的实时性能要求等。Data Warebase 不仅能够解决当下数据平台的普遍痛点，还能满足未来 AI 的更多需求。

作者简介：

杨克特，ProtonBase 技术副总裁，负责产品的设计和研发工作。

毕业于浙江大学计算机系，获硕士学位，具备 10 多年核心系统设计和研发经验。曾任阿里巴巴资深技术专家，负责过搜索引擎、资源调度、实时监控等系统的设计和研发。

具备丰富的开源经验，是 Apache Flink 和 Apache Druid 的 PMC 成员，以及 Apache 软件基金会成员。