PieCloudDB Database：云原生分布式虚拟数仓的诞生之旅

杭州拓数派科技发展有限公司 （OpenPie）的旗舰产品 PieCloudDB Database 是一款云原生分布式虚拟数仓。PieCloudDB 通过多种创新性技术将物理数仓整合到云原生数据计算平台。PieCloudDB 可以动态创建虚拟数仓，按需灵活计算，从而打破数据孤岛，支撑更大模型所需的数据和计算。

PieCloudDB 于 2022 年 10 月 24 日发布 1.0 版本，实现计算和存储分离，实现了弹性计算与弹性存储，做到了计算和存储均可按需付费，并实现了多租户隔离。2023 年 3 月 14 日，拓数派正式发布了 PieCloudDB 的云上云版本，云上云版本目前构建在阿里云上，并将很快扩展到其他云平台。云上云版将满足用户多样化的数据分析需求，打造公共云数仓服务最佳实践。

PieCloudDB 目前已有四个产品版本，分别是：

• 云上云（CoC）版本（免费试用）
• 社区版（免费下载）
• 企业版
• 一体机版本

PieCloudDB 云上云版为企业构建坚如磐石的虚拟数仓，以云资源最优化配置实现无限数据计算可能。 PieCloudDB 企业版与社区版可为企业提供全新基于云数仓数字化解决方案，助力企业建立以数据资产为核心的竞争壁垒；PieCloudDB 国产软硬件一体机，采用 eMPP 专利技术实现存算分离，适配信创环境，为甲方企业降低运维成本，节省开发时间。

PieCloudDB 拓数派研发团队之所以会选择云原生作为主要赛道，主要出于多方面的考量。首先，在传统的 MPP 数据库的客户环境中，往往存在一个共同的痛点，那就是：数据孤岛。客户的生产环境中 MPP 数据库集群数量过多，即使采用数据联邦等处理方式，也可能会导致数据一致性性问题，还会对存储空间造成一定的浪费。第二，数据作为新的生产要素需要流通起来才会产生更大的价值。为了解决这些痛点问题，PieCloudDB 通过实现存算分离的架构，将数据存储在共享存储（S3，HDFS，NAS）中，将元数据信息存储在共享 NoSQL 数据库 FoundationDB 中，实现了存储资源和计算资源的独立弹性伸缩，从而能够在维持高性能的同时，更加灵活的进行扩缩容，帮助用户降本增效。

下面我们来回顾一下 PieCloudDB 的诞生之路。之所以没有从数据库底层进行重新设计研发，是因为所谓” 术业有专攻”，就像制造跑车的并不会亲自生产车轮一样，协调下面的轮子来跑的更快更稳才是我们所专注的。而数据库底层组件就像车轮一样，PieCloudDB实现分布式与存算分离，充分利用 源源不断的创新能力和资源，结合拓数派研发团队的创新能力，针对分布式、OLAP 及云原生场景进行了大量极致优化，成就了这款云原生虚拟数仓 PieCloudDB。

1. PieCloudDB 的诞生之路

我们主要是从四个方面来进行设计和打造 PieCloudDB 的：元数据管理、数据存储、数据访问加速、分布式化。

1.1 元数据管理

为了打破数据孤岛，PieCloudDB 设计了存储计算分离的方案。在这种设计方案下，用户可能启动了多个虚拟数仓来操纵同一份数据，因此可能会发生一个虚拟数仓在更新数据而另一个虚拟数仓在读取数据的情况。为了保证在多个虚拟数仓（multi - coordinator）情况下数据的一致性，我们设计了元数据服务，把元数据和用户数据以及虚拟数仓解耦合。元数据服务使得同一组织下不同租户的元数据是共享的，用以实现分布式事务和分布式锁。

PieCloudDB 的元数据服务基于 FoundationDB 实现，PieCloudDB 通过借助 FoundationDB 的串行化事务模拟轻量级锁功能，并通过实现分布式锁来保证数据的一致性。

由于 PieCloudDB 的元数据被存储在 FoundationDB 中，每个分发器都会去读取 FoundataionDB 中的元数据，会对 FoundationDB 造成一定的压力。因此 PieCloudDB 的元数据管理通过缓存的设计、以及将不会改的元数据预先持久化存储，来减少对 NoSQL 数据库的访问。

1.2 数据存储与简墨（JANM）的诞生

PieCloudDB 为了被打造成一款 OLAP 云原生数据库，需要针对 OLAP 和云原生场景进行大量优化和改进。

PieCloudDB 作为一款云原生虚拟数仓，在设计存储引擎时需要考虑支撑云平台的廉价对象存储同时也要支持高性能查询，在实现过程中，PieCloudDB 需要能够兼容 S3 存储，并需要保证高效的访问性能。S3 等对象存储的优势是使用方便价格低廉，缺点是访问时网络延相对迟较大并且文件的随机访问性能较差等。

针对 S3 的这些特点，PieCloudDB 打造了独创的存储引擎简墨（JANM）。简墨的名字出自于 “竹简墨书”，纵向的竹片被横向的链接起来，形成竹简，形象地说明了 PieCloudDB 行列混存的存储模式。简墨的独特设计既能利用 S3 的优势又通过一些措施克服了访问延迟和随机读写的劣势。作为数据库的存储引擎，简墨保证了一个 S3 文件内所有的数据 MVCC 可见性一致。为了提高查询销量，简墨采取了很多优化措施：例如收集统计数据被单独存储在 KV 存储中，在查询时用于实现 Data Skipping，针对 SUM、COUNT 等聚集计算的预聚集等查询优化。此外，简墨也实现了包括 TDE（透明数据加密）、数据压缩、支持大字段列（Large - size column）、内存 Arrow Format、、Cache 友好等特性。简墨的数据块大小设定为 16M，这样可以避免产生很多小文件从而加大元数据的管理难度，也有效的避免了执行 UPDATE/DELETE 时产生的文件随机的读写操作。

此外为了充分利用现代硬件的性能，PieCloudDB 的存储引擎设计时还考虑了为现代 CPU 和 GPU 的高速缓存访问进行了设计，并且对数据的局部性进行了进一步优化以支持 SIMD、SIMT 和并行计算。

在存储引擎的选型过程中，研发团队也曾调研过 Parquet 等开源存储格式。最终团队决定打造自己的存储格式，而不直接使用 Parquet 等开源存储格式，主要出于以下几点原因：

• 不需要存储 Schema：Parquet 等很多存储格式自带 Schema，而 PieCloudDB 对 Schema 的存储需求较小；
• 原生 Postgres 感知的存储格式：可以在避免读取存储数据时，需要去做一些额外的反序列化等工作；
• 灵活可控：在实现类似 TOAST 的功能时，不会受约束，可操作性更强，更加灵活可控。

虽然没有直接使用 Parquet 等开源存储格式，但为了保证用户的数据存储格式的灵活性，PieCloudDB 支持通过 Foreign Data Wrapper 功能访问这些存储格式。

1.3 数据访问加速

PieCloudDB 的存储引擎简墨支持 S3 等对象存储。由于 S3 存储本身会存在一些局限性，包括带宽延迟、对随机写不友好。针对这些瓶颈，PieCloudDB 做了大量优化，以提高数据的访问速度，使得存储不再是查询执行过程中的瓶颈：

• 缓存：使用缓存是加速数据访问的常用措施，PieCloudDB 实现了本地缓存，更加高效的分布式缓存也在规划中；此外，PieCloudDB 还针对数据的访问频率对缓存实现了 “冷”、“温”、“热” 的分级管理。
• 一致性哈希缓存文件：PieCloudDB 实现了本地缓存，因此可能会发生跨节点读取缓存数据情况，为了避免跨节点的缓存读写，PieCloudDB 实现了一致性 Hash 存储缓存文件，提高缓冲的命中率。
• Data Skipping：为了实现更好的查询性能，PieCloudDB 做了大量查询优化功能，Data Skipping（Block Skipping）可以跟进预先计算数据统计信息从而判断数据块中是否有需要的数据，从而跳过不包含所需数据的数据块；
• S3 访问通用优化：并行化、预读、异步、MPP 引擎 “Steal” 等。

1.4 PieCloudDB 的分布式化

PieCloudDB 实现了分布式化引擎。元数据只在 Coordinator 上访问 FoundationDB，减少了对 FoundationDB 的访问次数，避免对其造成过大的压力。而执行器数据主要由分发器精准高效 Dispatch，并针对分发器进行了大量优化。

在完成这四步的打造后，PieCloudDB 诞生了。接着，我们为了在维持稳定性的同时，让 PieCloudDB 拥有更加优异的查询性能，对元数据管理系统进行了持续的性能优化，支持了聚集下推、预计算、Block Skipping 等功能。并完成了海量数据修改与增强、初步备份功能、VACUUM 增强、统计数据自动收集更新等优化。

2. 道阻且长，行则将至

PieCloudDB 还在不断成长，下一步，我们将继续打磨 PieCloudDB 内核，在元数据存储、用户存储以及计算引擎方面不断迭代，并让优化器对 OLAP 场景更加友好。

• 元数据存储
  在元数据存储方面，首先我们将深度优化缓存，通过高效的缓存系统进一步的大幅减少对 FoundationDB 的访问。其次实现元数据将于状态解耦，让无需可靠存储的状态不用被存储在 FoundationDB 中。再次并通过一定的重构，抽象更多解耦，降低复杂度，提高稳定性。
• 用户数据存储
  针对用户数据存储，将根据计算需求优先级提供包括 dict page、bloom filter 等更多功能，并在分布式缓存和调度等方面进行优化。
• 计算引擎
  计算引擎将是 PieCloudDB 下一步迭代的重点。首先我们计划完成 SIMD 执行器和各种计算优化。接着，我们会完成 Pipeline 引擎，充分发挥多核 cpu 计算能力，提高 cpu 利用率，让单台节点的性能被充分利用，进一步降本增效。我们会在第三步完成计算引擎资源调度隔离，让 PieCloudDB 成为一个数据计算的 “操作系统” 与基石，这将是 PieCloudDB 的长期目标。

这就是 PieCloudDB 的诞生之路，欢迎大家前往官网试用 PieCloudDB 云上云版。也期待大家加入我们的技术社区，与我们携手同行！