存算分离的云原生数据湖仓架构，如何提升数据价值?

设计 | 梓涛

编者按

数据仓库技术如今已经演进到基础架构的云原生、数据架构的湖仓一体，这给企业带来具备更优体验的数据管理方式。数据库厂商们也不断进行创新和探索实践。

滴普科技的实时湖仓平台FastData，便是典型产品之一。滴普科技资深技术专家将对不同类型的产品进行解析，并阐释滴普科技的创新实践。

撰文 | 维亮 编辑 | 昕然本文共计2400字，阅读需要5分钟

上次提到了在云上和云原生环境下，云数据库特别是OLAP系统、数据湖仓 LakeHouse，采取存算分离架构带来的种种好处。（点击链接可直接回顾文章）

那么，这种架构有没有什么短板呢？答案是肯定的。在现实中，云计算存储基础设施（S3等对象存储和分布式文件系统）与计算之间有着巨大的带宽差距和高延迟，对 Ad hoc 类查询的执行时间和最终用户的体验有着直接的影响。

在这种情况下，在架构上我们有没有什么优化的手段呢？本期文章以云数仓的引领者 Snowflake 和 Delta Lake 为例，探讨一下我们可以从传统数据库领域借到哪些法宝解决这个问题。

1
Snowflake 的存算分离架构
Snowflake 是云数仓领域的开拓者、采用存算分离架构的首倡者，Snowflake 将这个创新的架构称之为multi-cluster，shared-data架构。
从整体上看，分为3层：Cloud Services、Virtual Warehouse（VW）和 Data Storage。VW 是一个或多个 AWS EC2（虚拟机）组成的 Cluster，Cluster 本身是 Snowflake 私有的基于 shared-nothing 架构的计算层。Data Storage 采用AWS 的S3 服务（可替换成Azure Blob存储，或Google Cloud Storage），作为共享的存储层。Cloud Services 公共服务则集成了 optimizer、Metadata storage等服务。
Cache 在计算机系统架构是一个非常重要的概念，对系统的性能起着关键作用。Snowflake 将数据分为冷数据和热数据，冷数据（和全量数据）保存在S3存储，热数据（部分表、列和索引）cache 在VW节点的本地磁盘（利用SSD硬盘可以取得最好的性能），以尽量减少计算节点与存储节点之间的流量。一旦 cache 完成了预热，性能可以接近甚至超过传统 shard-nothing 数仓。

图1: Multi-Cluster，Shared Data架构

在 cache 算法方面，Snowflake（在早期）采用常见的LRU（最近使用）替换算法，对于独立的 query 来说这个过程是透明的。为了提升 cache 命中率，避免 VW 的多个 worker 节点 cache 冗余的 table 文件，query optimizer 将输入的文件集通过一致性哈希（Consistent hashing）算法（在文件名在做hash）分布在不同的 worker 节点上。同时hash的过程是lazy的，当 worker node 集发生改变时，并不会立即对cache的数据进行重新的shuffle，而是依赖LRU算法对cache的数据进行逐步替换。同时为了应对cache的数据倾斜，Snowflake 还采用了 file stealing 技术避免某个worker节点过载。
当然，如上期文章讲到的，Snowflake 采用存算分离架构，节省基础设施成本并不是唯一的目的。在这种架构下，计算节点的高可用和在线升级（弹性扩容）也成为可能。对于计算节点的高可用，通过将 VW 的状态数据（元数据等）通过高可用的 Cloud Service 统一管理，计算节点的 provisioning 的统一管控，可以做到让用户不感知节点的宕机。
对于 on-premises 的 OLAP 系统，系统升级是一个复杂、耗时的运维工作，对现有业务有比较大的冲击，需要提前进行详细的规划和预演。对于 Snowflake 来说，在线升级可以极大缩短软件开发周期、提高系统的可用性。
2
Databricks Lakehouse平台存算分离架构
Databricks 作为 Spark 的创造者和 Lakehouse（数据湖仓）概念的创造者，从一开始就坚定地走 All in Cloud 路线，实践了数据湖仓领域的存算分离架构理念。
从存算分离角度看，Data Lake 作为公共的数据存储层、Delta Engine（仅结构化数据的处理，对于机器学习有Spark）作为计算层的核心引擎，同时最有特色的是 Delta Lake 层，作为一个中间层扮演了类似传统数据库领域的元数据、缓存和索引组件的功能。
从下图可以看出，Lakehouse 系统是构建于 Data Lake 数据湖存储之上的。数据湖存储开放数据格式（如Parquet和ORC）的数据文件；而 Lakehouse 的核心组件包括3层：元数据、缓存（caching）和索引（indexing）层。
从 Lakehouse 的设计来看，实际上包含了多模数据（结构化、半结构化和非结构化数据）的处理和管理，对于 SQL 类工作负载，Databricks 引入了基于 Spark的、C ++写的Delta Engine；对于机器学习类的工作负载，则使用 Databricks 自研的 ML runtime 运行在GPU集群上。

图2 Lakehouse系统设计

在实现 Lakehouse 系统的过程中，Databricks 的元数据层（Delta Lake）提供了ACID事务、元数据多版本等特性（提供类似特性的还有Apache Iceberg）。
另外，为了更好地优化 SQL 工作负载的性能，数据仓库可以采用SSD存储热数据、维护统计信息、构建高效的数据访问方法，如索引、数据格式与计算引擎的组合优化等。
对于 Lakehouse 来说，由于对象存储的特点，底层数据文集及其存储格式是不可变的，需要有其他的优化手段：缓存（caching）、辅助数据结构（auxiliary data structures, 如索引和统计信息）和数据布局优化(data layout optimizations)。需要注意的是，Lakehouse 做的这3个方面的优化与具体的数据文件格式是不相关的，这与传统的 Data warehouse 不同。
缓存：结合 Delta Lake 的元数据层，在计算节点上，可以安全地把对象存储上的数据文件缓存在SSD或者RAM设备上，因为元数据层的事务能力，可以知道在读取缓存时，数据是否还是有效的。另外，为了实现类似传统数仓的数据格式结合引擎的优化，缓存的文件内容是可以转换格式的，例如可以把Parquet格式的文件进行部分解压。
辅助数据：Delta Lake 通过Delta Engine维护了某个表所有Parquet文件中列的min-max统计信息，并保存在事务日志中。当表的基础数据（非辅助数据）通过特定的列聚集（clustering）的时候，就可以利用数据跳过（data skipping）这个优化技术。这个做法类似于传统数仓中的 zone map 概念，虽然使用的是开放的数据格式，给定一个数据范围，查询引擎可以据此快速定位到需要访问的数据文件，从而大大减少I/O。
数据布局：数据布局在数据存取性能中扮演一个很重要的角色。即使固定采用一种数据格式，如 Parquet，还是有多种数据布局的优化策略可以选择。最简单的一个方法就是数据记录排序（record ordering），哪些数据需要聚集（clustering）在一起，从而使得一起读取这些数据记录变得更容易。在 Delta Lake 中，记录排序支持基于单独维度，或者使用空间曲线（如Z-order和Hilbert曲线）进行跨多个维度的本地化数据读取。
3
总 结
从上述2个云原生 OLAP 系统在存算分离架构上的实践，我们可以看到，即使存在计算层和存储层之间的高I/O延迟等不利因素，通过在这2个层次之间增加一个湖仓层，包括了元数据、缓存、索引（包括辅助数据和数据布局的优化）等综合的优化手段，减少计算和存储层之间的I/O流量，吸收了传统数仓中的 query optimization 手段，优化了 OLAP 工作负载的性能，在性能（性能价格比）上取得了持平、甚至超越传统数据的成绩。
FastData DLink 作为一个基于存算分离架构的实时湖仓引擎，我们实践了缓存（文件缓存、结果集缓存、语义缓存等）、索引（基于 Apache Iceberg 的Z-order、Bloom Filter索引）、统一元数据架构等创新技术，并将不断在这些领域深入研究，持续优化。期待在后续的文章中和大家详细分析这些技术。