在Delta Lake官网上提到的一篇新一代湖仓架构的论文.
这篇论文由Databricks团队2021年发表于CIDR会议. 这个会议是对sigmod和vldb会议的补充.
可以看到这篇论文和前一篇Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores发表时间仅隔了一年. 论述的内容也是对Delta Lake这套架构的补充(场景拓展).
Warehouse, lake, lakehouse
第一代数仓只将数据库操作的结构化日志通过ETL清洗存储到专门的数据仓库中, 典型的如基于Hive的数仓. 这一代数仓的主要服务的目标场景是BI分析. 他的架构也是一种计算存储紧耦合的架构, 例如hive上计算节点就和存储的数据节点部署在一起, 通常还会有data colocate的优化.
第二代演化成了2层的结构, Data Lake 可以存储半结构化, 和非结构化的数据, 例如视频, 音频
这种架构下可以支持非结构化数据, 也支持直接的数据访问, 可以更好的对接非SQL的机器学习系统. 但目前自己在业界没有明显的感受到这种两层的结构, 可能是因为我对AI场景没怎么接触
论文中描述这已经是绝大部分公司的架构了
那么有没有将传统基于标准格式的数据湖转化成既有数仓管理能力, 高性能的分析能力, 又有快速的开放的数据访问的架构呢?
答案是 Lakehouse = Data Lake + Data warehouse.
数据直接存储于Object store之上, 而上层的BI系统, 机器学习, 数据科学计算都直接从Lakehouse中取数分析, 这样就实现了存储层的统一. 通过Data Lake 和 Data warehouse的结合实现了两者能力的结合.
而Lakehouse 就可以基于前文所介绍的Delta lake来构建, 可以看出Lakehouse是对传统数仓的一次升级. 但是纯粹这样的架构性能也许没有原先数仓中计算存储紧耦合的性能好, 毕竟多了额外的跨网络拉取数据的开销
最大的问题就是性能问题
Lakehouse架构
- 基于可以直接访问的, 标准的文件格式, 典型的如Parquet. 所以Lakehouse提供是一套基于文件的接口, 可以直接访问存储的数据, 并且提供了事务性的保障
- 基于云上的廉价对象存储
- 通过元数据层实现事务机制
- 对机器学习和数据科学的支持是第一优先级
- 提供性能保障
如何保障性能呢?
- caching 对于热数据通过本地ssd缓存加速查询
- auxiliary data structures such as indexes and statistics, and data layout optimizations. 通过索引, 数据重排和数据排布的优化. 对于热数据, 通过缓存可以实现和传统数仓中数据co-locate的优化, 而对于冷数据, 影响最大的是数据读取的多少, 因此通过一系列辅助数据, 可以大大减少需要扫描的数据量
- Data layout: Zorder
- 查询引擎自身优化, 向量化执行引擎
有待探索的优化
- 专为Lakehouse所设计的format, 虽然在一直强调standard format: Parquet/Orc, 但是看出来还是有设计一套新的format的意图, 不知道Databricks在Parquet/Orc有碰到什么痛点 🤔
- 更多的索引和layout优化
与传统数仓的性能和cost对比. 咋没有snowflake呢? 不管是性能和性价比上都非常不错.
不过, 在SQL上能很好的利用下推, 剪枝优化. 但是机器学习库的很多api, 并没有将query的语义下推到存储层, 导致这种框架中就无法很好的利用这些statistics.
因此这里就需要重新设计这些机器学习库的api.
Related work
M. Brantner, D. Florescu, D. Graf, D. Kossmann, and T. Kraska. Building a database on S3. In SIGMOD, pages 251–264, 01 2008. 看到一篇2008年就尝试将DBMS存储落在s3上, 真是先进
总结
这篇论文的干货比较少, 感觉只是把Delta lake的使用场景泛化了一下, 推出了一个新名词, lakehouse. 现在确实有这个演进的方向, 统一存储, 并在统一的存储上运行各种workload. 不过其中的性能挑战也不小.