共计 6674 个字符，预计需要花费 17 分钟才能阅读完成。
2023 年 5 月，由 Stackoverflow 发动的 2023 年度开发者考察数据显示，PostgreSQL 曾经超过 MySQL 位居第一，成为开发人员首选。PostgreSQL 在国内的热度也越来越高。6 月 17 日，PostgreSQL 数据库技术峰会在成都顺利召开。本次大会以“新机遇、新态势、新倒退”为主题，邀请泛滥行业大咖参加本次流动。PieCloudDB 产品总监陈金豹也受邀在大会中发表演讲《云原生虚构数仓 PieCloudDB 的架构和要害模块实现》。
随着云计算时代的到来，云平台提供了近似有限丰盛的计算资源，同时也使得计算成本极大的升高，开释出数据计算产生智能的更多机会。早在 2019 年，Gartner 便做出预测：数据库市场的将来在云上。随着云计算技术的倒退，企业也都在向这一趋势聚拢，越来越多的将本人的业务数据往云上迁徙。咱们置信数据库的将来在云上，这也是咱们打造 PieCloudDB 这款云原生数据仓库的起因。
PieCloudDB 于 2022 年 10 月正式问世。它是一款云原生分布式数据仓库，提供齐备的 SQL 语言反对，高效的分布式计算能力和齐备的事务反对。同时又实现了繁多数据集的多集群，秒级的弹性和只为必要的计算和存储付费的能力。
1. Why We Need PieCloudDB？
1.1 NoSQL 和数据湖已不能满足用户的剖析需要
在过来的很长一段时间里，NoSQL + 数据湖解决方案在数据分析畛域占据了支流市场，而 Hadoop、HDFS 等 NoSQL 数据库也是次要的数据分析平台。然而，随着 Cloudera 发表进行对 CDH 技术支持，对 Hadoop 等 NoSQL 平台的质疑声音也越来越大。
这一景象正是因为 NoSQL + 数据湖体系在简单查问反对、高并发隔离性和一致性等重要数据分析个性方面存在显著有余，现有基于规范 SQL 的 BI 工具难以集成，且 NoSQL 自身对高级剖析（如图形剖析、地理信息剖析等）的反对较弱。因而，NoSQL 开始被人们贴上“过期”的标签，不再占据数据分析畛域的次要市场份额。
此外，基于 NoSQL 和数据湖的基础设施所需的剖析工具不容易集成和部署。应用数据湖进行数据分析须要整合部署多个组件，而这须要大量的开发工作。因为不足对 ANSI SQL 的反对，用户通常须要具备专门的技术技能，并且须要承当较高的技术和老本要求。此外，平台所需的专用引擎 / 工具（如图形数据库）往往难以与记录系统集成，升高了数据分析的可操纵性和创新性。
这些限度和挑战推动了对更弱小、更易于集成、更易于应用的数据分析平台的需要。 企业和组织越来越偏向于采纳基于规范 SQL 的剖析平台，这些平台可能满足用户宽泛的剖析性能、易于集成和部署等需要，并且与现有的数据存储和解决技术相兼容，对技术和老本的要求更低。
1.2 以关系型数据库为根底的数据仓库很难适应云环境
包含 Teradata、Greenplum 等泛滥支流传统数据仓库都是以关系模型来组织数据的关系型数据库。这些数据仓库具备许多长处，包含良好的 SQL 兼容性、高效运行简单查问以及反对事务 ACID 个性。然而，这些传统的 MPP 数据库也存在一些缺点，例如弹性性能较差、高可用性方面不够满足要求、数据孤岛等问题。
这些问题导致传统的数据仓库在云环境中无奈充分利用私有云的劣势。私有云绝对于公有环境具备许多劣势，其中最显著的两个是：
- 近乎有限的弹性计算资源：私有云提供了弹性计算资源，用户能够依据理论需要按需分配资源，并依据须要进行弹性扩缩容。用户能够依据业务需要申请所需的计算资源，而不须要保护和治理本人的硬件基础设施。
- 便宜且有限容量的对象存储：私有云提供便宜且具备简直有限容量的对象存储。对象存储的价格绝对较低，能够为用户提供大规模的存储容量，帮忙用户降低成本并提高效率。
为了更好地适应云环境并充分利用私有云的劣势，新一代的数据仓库逐步崛起。新一代云原生数据仓库具备云原生的架构设计，可能更好地利用私有云的弹性计算和对象存储能力。它们能够在私有云中疾速部署和扩大，并提供高性能的数据处理和剖析能力，以满足古代数据分析的需要。
1.3 一个兼顾关系型数仓和私有云劣势的产品
用户须要一个可能兼顾关系型数仓和私有云劣势的产品，来适应云时代的到来。计算引擎方面，须要具备关系型数仓的泛滥劣势，可能具备反对齐备的 SQL 语言，具备高效的分布式计算能力，且可能具备齐备的事务 ACID 个性。私有云个性方面，实现存算拆散，提供弹性的计算集群，让用户得以只为必要的计算付费，充分利用私有云带来的劣势。这就是 PieCloudDB 的设计指标。
2. PieCloudDB 能给用户带来什么？
作为新一代的云原生数据仓库，PieCloudDB 实现了云上数仓计算与存储的拆散，兼顾了传统关系型数仓的泛滥劣势和私有云带来的泛滥利好。
2.1 对 SQL 的齐备反对
PieCloudDB 对 PostgreSQL 进行了重大改良，实现了分布式计算和存算拆散的性能。并对锁、事务、日志、零碎表和用户表的存储等模块进行了彻底重写，带来了颠覆性的改革。同时，PieCloudDB 也保留了 PostgreSQL 对 SQL 规范的残缺反对，包含简单查问如聚合（Agg）、子打算（Subplan）、子链接（Sublink）、外连贯查问（Outer Join）、窗口聚合函数（Window agg）和物化视图（Materialized View）等。这些改良使得 PieCloudDB 可能提供更高效、更弱小的查问性能，同时放弃与 SQL 规范的兼容性。
2.2 高效的查问优化和与之匹配的执行器
PieCloudDB 实现了专为简单查问设计的优化器和与之匹配的高效执行器。
- 专为简单查问设计的优化器
PieCloudDB 的优化器提供了一系列全面的逻辑优化性能，其中包含谓词下推、子查问子连贯晋升和外连贯打消等。此外，优化器基于纯正的代价模型进行深度优化，在多阶段汇集过程中对每个节点进行代价估算，并利用动静布局等算法生成多条门路，最终抉择代价最低的门路来执行查问。这些性能旨在进步查问性能和效率，从而优化 PieCloudDB 的查问执行过程。
作为一款分布式数据库，PieCloudDB 须要实现泛滥分布式运算，包含屡次数据重散布（reshuffle）和分布式聚合运算（agg）。为了可能在跨表查问时进行高效的分布式表连贯，PieCloudDB 的优化器须要全面形容数据分布个性，以便进行分布式代价估算。
通过全面的数据分布个性形容，PieCloudDB 的优化器可能思考到数据在不同节点上的散布状况，从而更精确地估算跨表查问的代价。这使得优化器可能生成高效的查问打算，防止不必要的数据重散布操作，进步查问性能和效率。 - 分布式环境高效执行器
为了配合专为简单查问设计的优化器，PieCloudDB 实现了高效的执行器，以在分布式环境下执行查问操作。通过采纳多组别多阶段执行模型，并进行大量的数据交换，PieCloudDB 的执行器可能在分布式环境下高效地执行查问操作。这种执行模型能够充分利用分布式系统的计算资源，并进步查问的并行性和整体性能。同时，通过与优化器的紧密配合，PieCloudDB 能够依据优化器生成的查问打算个性来优化执行器的执行策略，进一步提高查问性能和效率。
2.3 对事务（ACID）的齐备反对
PieCloudDB 提供了对事务的齐备反对，包含事务的 ACID 个性：原子性、一致性、隔离性和持久性。
- 原子性（Atomicity）：PieCloudDB 确保事务中的操作要么全副胜利实现，要么全副失败回滚。如果一个事务中的某个操作失败，那么该事务中的所有操作都将被回滚，数据库状态会回到事务开始之前的状态，保持数据的一致性。
- 一致性（Consistency）：PieCloudDB 在事务提交之前，会查看事务的操作是否合乎预约义的束缚和规定，以确保数据库的一致性。如果事务执行实现后，数据库依然放弃一致性，那么该事务被认为是胜利的。
- 隔离性（Isolation）：PieCloudDB 反对两个罕用的隔离级别：Read Committed（读提交）和 Repeatable Read（可反复读）。在 Read Committed 级别下，事务只能看到其余事务曾经提交的批改，而在 Repeatable Read 级别下，事务在整个事务过程中可能看到一个统一的快照，不受其余并发事务的批改影响。
- 持久性（Durability）：PieCloudDB 确保一旦事务提交胜利，其对数据库的批改将永恒保留，即便产生系统故障或解体。这是通过将事务日志记录在稳固的存储介质上来实现的，以便在复原过程中能够重放事务日志。
通过提供对事务 ACID 个性的齐备反对，PieCloudDB 提供了牢靠和统一的数据管理机制。无论是在并发环境中还是在面临故障的状况下，PieCloudDB 都能确保数据的完整性和可靠性。
2.4 极致的计算集群弹性
PieCloudDB 具备极致的计算集群扩缩容能力，可能实现计算集群疾速的扩大和膨胀操作。PieCloudDB 的 Executor 节点并不持有长久化的数据，扩大和膨胀操作不波及数据的挪动。此外，Executor 节点也不间接拜访零碎表、事务和锁。在进行计算集群的扩大时，PieCloudDB 只须要在新的虚拟机节点上部署二进制并向元数据服务注册。这样的设计确保了扩缩容操作的高效性。
PieCloudDB 为用户提供了一个独立的计算池，该计算池是为了反对疾速的扩缩容而筹备的。在这个计算池内，PieCloudDB 能够在肯定范畴内实现秒级的扩容和膨胀操作。这意味着当用户须要减少计算资源时，PieCloudDB 能够迅速增加新的计算节点，使得整个集群可能解决更多的并发申请。反之，当用户须要缩小计算资源时，PieCloudDB 也可能疾速地膨胀计算节点，以节省成本和资源。
2.5 多集群与高可用
PieCloudDB 反对多集群。用户能够在同一个数据集上起多个集群。在生产环境中，经常会遇到不同的部门对集群大小的需要不一样。这种状况下，如果只有单集群，就须要依据最大的集群需要来创立集群，造成资源的节约。在多集群场景下，不同部门可依据本身需要创立不同大小的集群，工作完结时能够敞开集群，多个集群拜访同一个数据集，并共享同一个 ACID 个性。
因为 PieCloudDB Executor 是无状态的，当某个 Executor 呈现故障，Coordinator 会执行下个 Query 时，由剩下的 Executor 来执行工作。此过程中，用户无感知，不会对业务产生影响。
通过这些个性，PieCloudDB 在 OLAP 场景下，能够让用户像应用 PostgreSQL 一样应用 PieCloudDB。用户只需为曾经产生的计算和存储付费。用户能够按需启动和敞开多个不同大小的集群，以适应不同类型的工作，从而获得性能和开发效率的均衡。
3. PieCloudDB 云原生架构的实现
为了适应云环境，PieCloudDB 实现了弹性伸缩的集群和多集群这两个次要的云原生个性，打造了齐全无状态的 Executor 节点、独立的零碎表和分布式的锁。
3.1 虚构数仓
PieCloudDB 为了实现在扩缩容过程中无需挪动数据，将用户数据拆散到对象存储中。此外，Executor 节点上不存储系统表、事务和锁信息，而是依赖 Coordinator 来解决这些问题，从而使 Executor 节点成为无状态的节点，实现秒级扩缩容。
为了实现 Multi-master 架构，并实现有状态的 Coordinator 节点，PieCloudDB 应用元数据服务来实现这些性能。零碎表以 Key-Value 的模式存储在 KV 数据库 FoundationDB 中，并通过 FoundationDB 的短时间、小体量的事务个性，实现了分布式锁和分布式事务。这样，PieCloudDB 可能在 Coordinator 节点上解决分布式锁和事务，并保证系统的一致性和可靠性。
通过这一系列的设计和操作，PieCloudDB 实现了齐全无状态的虚构数仓。用户能够依据须要创立和敞开虚构数仓，而在扩缩容过程中无需挪动数据，并且可能疾速进行节点的扩大和膨胀。这使得 PieCloudDB 可能高效地适应不同规模和负载的需要，并提供灵便的数据存储和计算资源管理。
- 零碎表：mStore
PieCloudDB 将元组以 Key-Value 的模式存储到 FoundationDB 中，并利用 FoundationDB Key 的天然排序来实现索引。在 PieCloudDB 中，每个元组都被编码为一个 Key-Value 对，其中 Key 示意元组的索引信息，而 Value 则蕴含了元组的数据内容。通过利用 FoundationDB Key 的天然排序，能够高效地进行范畴查问和索引查找，从而实现疾速的数据检索和拜访。
为了实现多版本并发管制，PieCloudDB 应用了 Xmin、Xmax 和 cid 等机制。Xmin 和 Xmax 记录了事务对元组的可见性信息，其中 Xmin 示意最早可见的事务，而 Xmax 示意最晚可见的事务。cid（Commit ID）则示意事务的提交标识。通过这些机制，PieCloudDB 能够实现并发事务的隔离性和一致性，并反对多版本的查问和回滚操作。
通过将元组存储为 Key-Value 对，利用 FoundationDB 的天然排序和采纳 MVCC 机制，PieCloudDB 可能高效地解决数据的存储、索引和并发拜访，从而提供高性能和牢靠的数据库服务。 - 数据表：oStore
PieCloudDB 通过将数据拆散到对象存储（如 S3）上，利用 oStore 构建了对象存储上的用户表。因为对象存储自身只反对插入（insert）和删除（delete）操作，而不反对更新（update）和追加（append）操作。PieCloudDB 在 mStore 中创立辅助表来实现 MVCC（多版本并发管制）的个性。
在 mStore 的辅助表中，每 个 tuple 对应 oStore 的一个 block，oStore 的 block 中存储了一部分的用户数据。这样，辅助表的每个 tuple 的可见性就与对应的 block 的可见性相关联，从而实现了 MVCC 的个性。当执行更新（update）或删除（delete）操作时，PieCloudDB 会生成一个新的 block，将未发生变化的 tuple 放入新的 block 中，并将更新后的用户数据放入新的 block 中（例如，在 block 4 上执行更新操作后，生成一个新的 block 5，将更新后的用户数据放入新的 block 5 中）。最初，辅助表将实现更新（update）操作。
通过这种设计和操作，PieCloudDB 可能在对象存储上实现 MVCC 个性，并通过辅助表来治理数据的版本和可见性。这使得 PieCloudDB 可能反对更新和删除操作，同时保持数据的一致性和并发管制的正确性。
- 分布式锁和事务
PieCloudDB 利用 FoundationDB 的事务提交抵触（commit conflict）机制来实现锁的共享区的正确拜访，从而实现了分布式的锁。
在 PieCloudDB 中，多个事务须要访问共享区时，它们会通过 FoundationDB 的事务机制进行竞争和协调。每个事务尝试获取锁并执行对共享资源的操作。如果多个事务同时申请同一个共享锁，FoundationDB 的事务提交抵触机制会确保只有一个事务可能胜利获取锁并进行操作，而其余事务将被阻塞或回滚。
通过利用 FoundationDB 的事务提交抵触机制，PieCloudDB 可能实现分布式的锁治理，确保对共享区的正确拜访和资源的互斥操作。这种机制保障了多个事务之间的隔离性和一致性，防止了数据竞争和抵触的产生，并提供了牢靠的分布式锁性能。
此外，PieCloudDB 还在 FoundationDB 上实现了分布式的事务，并通过 mStore、oStore、分布式锁和事务的实现，构建了一个云原生的分布式架构。这样的架构可能提供高可靠性、高性能的数据库服务，并反对分布式的数据操作和治理。
优良的架构设计是一款数据库产品胜利的第一步，OpenPie 研发团队将对 PieCloudDB 产品进行一直迭代，针对性能推出了汇集下推、预计算、Block Skipping 等性能，并很快将推出 Time Travel、Branch、Data Sharing 等系列进步用户的应用体验。PieCloudDB 将继续前进，在 eMPP 分布式专利技术、服务器无感知（Serverless）及 通明数据加密（TDE）等多项核心技术加持下，为企业构建高安全性，高可靠性，高可用性的「坚如磐石」的云原生虚构数仓，助力企业实现数据价值最大化，欢送关注！