标题：湖仓：新一代一体化数据仓库和先进分析的开放平台
作者：Michael Armbrust1, Ali Ghodsi1,2, Reynold Xin1, Matei Zaharia1,3
均来自Databricks公司，二作是Databricks CEO，三作是Databricks首席架构师，四作是Databricks CTO。

编者的总结

1. 清晰地解释清除了现代OLAP存在的问题，以及改善的必要性。
2. 整体上是一个湖上建仓的方案，即在已有的HDFS或S3上，赋予更多的数据库的性能。针对地是数据分析，尤其是ML数据服务的过程。
3. 文章其实没有提出更新的管理技术，而是将已有的技术进行整合，提出一个很有商业场景的架构，且实现起来难度有限，显然在Databricks已经初步完成其框架。

编者的思考

1. 考虑到ML的工作负载，lakehouse似乎确实比MPP数据库的前景要好一些，不过这都取决于具体的文件格式和查询优化，如果能做到SQL查询和ML负载的高性能，至少在短期内也能获得市场优势。
2. 和HTAP的关系尚有些模糊，HTAP能否直接替代lakehouse，或者说只用HTAP会比lakehouse的成本高多少？HTAP+lakehouse的组合会是未来十年最先进的技术架构吗？即事务逻辑+实时分析走HTAP，历史数据和大吞吐的数据I/O走lakehouse。

Abstract

作者论断：现在的数据湖马上就要逐渐消亡，取而代之的是新一代湖仓系统：

1. 基于直接访问的文件格式，比如Parquet，ORC
2. 将ML和数据科学的优先级放在第一位
3. 性能强劲

湖仓将帮助解决现代数仓的几个主要问题：

• 数据新鲜度
• 数据可靠性
• 两份存储成本
• 数据的开放访问
• 功能性

1 Introduction

数仓第一代

• 第一代数仓是说从各个操作型DB收集数据到中心化的数仓，此时仍然是写时模式，也就是Schema要首先确定好，然后才能导入，后续的BI商业分析模式也必须提前敲定。
• 这一代数仓在大约00-10年代就出现了问题，最大的问题就是存储、计算都必须事先确定好消费的最大规模，然后按照峰值来进行预算，太浪费；
• 第二个问题就是对非结构化数据，比如图像、视频、文本，几乎没法存储、查询。

数仓第二代

• 作者将Hadoop等技术归类为第二代数仓，即数据湖，所有原始数据都以文件形式丢进湖（HDFS）中，采用读时模式，存储方面既敏捷又便宜，但是把数据质量和保障方面的问题丢给了下游来处理。在这种架构下，最终一小部分数据最后会丢给下游数仓（其实就是OLAP数据库，比如Teradata）.
• 从大概2015年左右，云数据湖（比如S3）开始替代HDFS，主要原因仍然是便宜。然后下游仍然接给OLAP（Redshift或者Snowflake）。
• 作者称，这个架构是目前几乎所有财富500强公司的选择。
• 这样的架构表面上看把存储和计算分离开了可以很便宜，实际上这种两层的架构对用户来说已经很复杂了。
• 另外，这两代数仓或数据湖都没法对ML有很好的支持。

现代数仓四大问题

1. 可靠性：数据湖（Hadoop or S3）和数仓（Teradata,snowflake）之间保持同步是很难的。两者之间的ETL过程的每一步都有可能出错。
2. 数据新鲜度：数仓里的数据新鲜度是落后于湖内的，经常是落后几天【编者注：不同公司、不同业务可能不一样，有实时需求的可能落后几小时，编者曾经编写的系统是按天同步的】。作者认为这是相对于第一代数仓的倒退，第一代数仓基本可以做到实时的，虽然劣势也明显。当然，数仓流水线也可以设计得更加实时一点【编者：比如用kafka构建实时数仓】，但是毕竟更困难。
3. 不支持ML：现代的ML系统比如pytorch，基本没有能构建在现有的数仓之上的。另一方面，ML任务和BI任务完全不一样，BI可能只需要简单聚合，抽取一小部分数据；ML训练任务逻辑复杂，需要反复大批量读取数据，如果使用SQL来读取数据则太低效了。
   • 注意现有的数仓，比如teradata，它的数据文件存储格式只能由它自己的存储引擎来解析，用户想要直接从数据文件中读取数据是不可能的，至少没有方便可靠的工具。
   • 用户要想从数仓训练个模型，要么得从数仓导出数据文件（那将又是一次ETL！），要么直接去数据湖（比如S3、HDFS）里面捞数据，但是数据湖里面（很多时候）没有任何DB方面的质量保障，比如索引、ACID、数据版本等等。
4. 两份存储成本：数据湖一份+数仓一份。一个最近的解决方案是直接干掉数据湖，数据直接进数仓，数仓内部进行存算分离【编者注: Clickhouse,TiDB,Doris可能属于这一类】。但作者认为可行性不高，用户使用的也不多，主要原因是非结构化数据还是很难存下来，另一方面ML负载也不好直接访问数据。

本文的核心问题

能否将基于开放文件格式（Parquet、ORC等）的数据湖转变为一个高性能的、完备的（DBMS的性质）数仓系统？

• 作者认为，开放的文件格式是服务ML负载的最有效手段；
• 高性能和完备性可以服务于BI，即基本查询。

这样一个系统，就称之为湖仓一体系统lakehouse.

image.png

湖仓的解决方案

那具体来说，湖仓是如何解决上述的四个问题呢？

1. 对数据湖中的数据（其实就是一些文件）也提供一些关键的数据管理功能，比如事务、回滚、版本等，现在有一些文件格式就能做到这件事，比如Delta Lake, Iceberg。这样的话，ML系统就方便于直接访问高效数据格式。
   • 另一方面，湖仓也提供ETL的功能对数据做清洗，提升数据质量。但至少不用清洗完再用ETL导到别的地方去做查询。
2. 高性能可以通过直接对Parquet,ORC,Iceberg这类文件格式进行优化达成，Databricks就曾经做过一个Delta engine，跑下来性能就很好。

2 Existing steps towards Lakehouses

由于对开放文件格式的需求和ML负载的增加，现在直接在数据湖上做查询的工具越来越多，主要分以下两类：

1. 直接在数据湖上运行的SQL引擎：比如presto, impala, spark, AWS Athena等等；
2. 数仓/OLAP数据库提供的外部表功能，可以直接访问数据湖的文件。

但是这两类工具仍然有问题，一个是性能方面还不够，基本上还是建不了索引；另一方面是数据质量管理和DB的基本功能方面还是很欠缺。

3 The Lakehouse Architecture

作者对于湖仓的定义也很简单，要满足两个方面：

1. 低成本，开放的访问存储，比如S3,HDFS上用Parquet, ORC来存储；
2. 有传统DBMS的完整功能，事务、数据版本、审计、索引、缓存、查询优化等等。

• 最大的挑战就是怎么把这两种优势结合到一起，即，如何在开放的数据文件格式上去做各种功能
• 另外，作者提及这样的设计本身非常适合云环境，存算分离；当然要放在一个预置系统中也可以。

3.1 Implementing a Lakehouse System

实现一个湖仓，分4步走：

1. 存储层采用S3等低成本对象存储；
2. 在开放文件格式上加一个metadata层，用于数据质量管理，以此引入事务和数据版本功能。
   • 已经开发出来的技术比如Delta Lake和Apache Iceberg已经得到了广泛使用。
3. 实现缓存、索引、查询优化等性能加速技术；
4. 在metadata层之上，实现声明式的Dataframe API。
   【以下为编者的解释】
   • Dataframe API熟悉pandas或者spark sql的朋友很容易理解，其实就是数据库中表在开发时的数据结构抽象；
   • 声明式和命令式相对应，这里主要体现在延迟执行上，给优化留出足够的空间。

3.2 Metadata Layers for Data Management

基本思路就是每个表额外存一个文件用来表管理，或可称为meta文件。
已有的技术包括Delta Lake (Databricks)，Iceberg (Netflix), Hudi (Uber)等.

• 作者称已有的技术实验表明这些技术的性能不输给在裸的Parquet/ORC文件；
• 另外易于迁移，原有的数据文件不用动，额外补充meta文件即可；
• 在这一层里可以记录日志、访问控制、ACID、审计等数据质量管理的功能。
• 尚存在的不足：
  1. 目前meta文件以及日志和数据一起存在S3里，这会导致query延迟增加，毕竟在S3/HDFS里做insert/append不是一个推荐的操作。
  2. 扩表的事务目前还没有实现；
  3. log的格式和大小还有进一步优化的空间。

3.3 SQL Performance in a Lakehouse

性能是湖仓设计的最大挑战，即如何在S3上做到和OLAP数据库一样的性能。
性能问题本身是很综合的，和能给出的资源息息相关，比如能否实现Cache层，能否改文件格式等等。因此作者在这里提出了和文件格式无关的一系列优化方案，综合到Databricks Delta Engine里面，最终满足性能需求，具体包括：

• caching：有了metadata layer的事务支持之后，cache就可以加上了，可以在SSD或者内存中；
• 辅助数据/索引：尽管没办法改文件格式，但可以维护每列每个文件上的min-max索引，bloom filter或者其他索引；
• 数据排列：Delta Lake就可以提供单列排序，或者多列的z-order/hibert-order曲线排序。进一步文件内部的排序和压缩也可以被优化设计。

上述三项是lakehouse的核心设计点，对于经典负载来说，频繁访问的热数据一般都已经在Cache中了，所以访问延迟会很低；对于冷数据更重要的是吞吐量和减少I/O，在有了后两条之后也能得到性能提升。

• 下图展示了TPC-DS（30k放大）的实验结果（960核CPU+本地SSD缓存），结果显示Lakehouse的设计是性能强大且廉价的。

  
  
  image.png

• 未来的研究方向：

  1. 更强大的开放文件格式；
  2. 上述三项优化技术的革新；
  3. 微服务的模式是否可能降低查询延迟？（比如Sigmod'20上发表的Starling）

3.4 Efficient Access for Advanced Analytic

为ML提供支持，最方便的办法就是提供Dataframe API库，几乎所有ML框架都是以Dataframe作为数据结构的，因此在lakehouse中，我们只需提供这样一个命令式库，然后将命令改写成spark SQL交给spark执行即可。
由于Spark会把Selection和projection的环节下推至存储引擎，那lakehouse上述的三点优化就有了用武之地。

• 未来的研究方向：
  1. 总之这是一个全新的领域，未来当然可以有完全不同的ML数据接口设计；
  2. 另外加强对ML全流水线的支持也是一个研究方向，比如现在就有Feature store的概念。lakehouse中重视表的版本也是一个考虑。

4 Research Questions and Implications

4.1 Are there other ways to achieve the Lakehouse goals?

有没有其他架构方式不用lakehouse呢？
比如给OLAP数据库上面弄一个服务层，让它能支持ML负载就好了？

• 作者认为在成本、性能、可用性上，都不如lakehouse.
• 因为这实际上是让服务层自己挑选一个高效的能从内部格式轻松转换出来的文件格式，【编者：因为ML负载要高频大吞吐数据I/O，所以要把压缩索引过的数据独立拿出来；不过我觉得这依赖于OLAP数据库的文件格式怎么设计了】；
• 作者强力推崇开放文件格式，因为用户不希望和一家产品强绑定，这样换技术会成本很大。

4.2 What are the right storage formats and access APIs?

文件格式+存储访问+SQL格式，这三者的设计如何才是最优的，目前尚无定论。

4.3 How does the Lakehouse affect other data management research and trends?

lakehouse会如何影响其他数据管理研究和趋势？

1. 像polystore这样的多存储查询，可能更多地都会落在lakehouse上；
2. 数据集成和清洗可以考虑快速并行访问所有数据，比如跨表的join和clusert；【编者：像spark SQL现在已经是这样在做的了，不知是否有误解】
3. HTAP可以是lakehouse的前置层，直接把一致性数据/归档给湖仓系统，让湖仓来负责一致性快照数据的查询。
4. 专门为ML设计的数据管理系统可以直接改到lakehouse上面来，声明式的ML引擎可以加在lakehouse之上；
5. 云原生的微服务查询引擎可以和metadata layer结合；
6. 公司数据管理的组织架构可以用湖仓方便组织。