当前位置 博文首页 > leesf:Lakehouse: 统一数据仓库和高级分析的新一代开放平台
数仓架构在未来一段时间内会逐渐消亡,会被一种新的Lakehouse架构取代,该架构主要有如下特性
Lakehouse可以解决数据仓库面临的几个主要挑战,如数据陈旧,可靠性,总成本,数据格式不开放和有限场景支持。
数据仓库将业务数据库的数据收集到集中式仓库来帮助企业领导者获得分析见解,然后将其用于决策支持和商业智能(BI),仓库使用写模式(schema-on-write)写入数据,对下游消费者进行了优化,此为第一代数据分析平台。
慢慢地第一代系统开始面临若干挑战,首先是计算与存储耦合使得扩容成本增加;其次越来越多的数据集是非结构化的,例如视频,音频和文本文档,数据仓库无法存储和查询这些数据。
为了解决这些问题,引入第二代数据分析平台,其将所有原始数据导入数据湖:具有文件API的低成本存储系统,该API以通用且通常是开放的文件格式保存数据,例如Apache Parquet和ORC,可以基于HDFS实现低成本数据湖存储,数据湖是一种读模式(schema-on-read)架构,可以灵活地以低成本存储任何数据。
该架构中的一小部分数据随后将被ETL到下游数据仓库以提供最重要的决策支持和BI应用程序。
从2015年起,S3,ADLS,GCS,OSS等云数据湖开始取代HDFS,云上的架构与第二代系统中的架构基本相同,云上有Redshift、Snowflake和ADB等数据仓库,这种两层的数据湖+数仓架构在行业中占主导地位(财富500强企业中几乎都在使用)。但这种架构也面临了一些挑战,尽管由于分开的存储(例如S3)和计算(例如Redshift)而使云数据湖和仓库的体系架构表面上便宜,但是对于用户来说,两层体系结构却非常复杂。在第一代平台中所有数据都从运营数据系统直接ETL到仓库,而在这种架构中,数据首先被ETL到数据湖,然后又被ELT到数仓,引入额外的复杂性、延迟和故障率,而且企业用例中包括机器学习之类的高级分析,数据湖和仓库都支持得不理想,具体来说,当前的数据架构通常会遇到如下四个问题:
一种被广泛采用的解决方案是不使用数据湖,将所有数据存储在内置了计算和存储分离功能的仓库中,但这种解决方案可行性有限,因为其不支持管理视频/音频/文本数据或从ML和数据科学工作负载中直接访问。
随着越来越多的业务应用开始依赖运营数据和高级分析,Lakehouse架构可以消除数据仓库中的一些主要挑战,Lakehouse的时机已经到来。
Lakehouse为以下关键问题提供解决方案:
当前的行业趋势表明客户对两层数据湖+数仓架构并不满意,首先近年来几乎所有的数据仓库都增加了对Parquet和ORC格式的外部表支持,这使数仓用户可以从相同的SQL引擎查询数据湖表(通过连接器访问),但它不会使数据湖表更易于管理,也不会消除仓库中数据的ETL复杂性、陈旧性和高级分析挑战。实际上这些连接器的性能通常较差,因为SQL引擎主要是针对其内部数据格式进行了优化,而仅凭这些分析引擎并不能解决数据湖的所有问题并取代仓库,数据湖仍然缺乏基本的管理功能(例如ACID事务)和有效的访问方法(例如与数据仓库性能匹配的索引)。
Lakehouse可定义为基于低成本,可直接访问存储的数据管理系统,该系统还提供传统的分析型DBMS管理和性能功能,例如ACID事务,数据版本,审计,索引,缓存和查询优化。因此Lakehouse结合了数据湖和数据仓库的主要优势:开放格式的低成本存储可通过前者的各种系统访问,而后者则具有强大的管理和优化功能。而核心问题是能否可以有效地结合这些优势:特别是Lakehouse对直接访问的支持意味着它们放弃了数据独立性的某些方面,这一直是关系型DBMS设计的基础。
Lakehouse特别适合具有单独计算和存储的云环境:不同的计算应用程序可以在完全独立的计算节点(例如ML的GPU群集)上按需运行,同时直接访问相同的存储数据,但也可以在本地存储系统(例如HDFS)上实现Lakehouse。
实现Lakehouse的第一个关键思想是使用标准文件格式(如Apache Parquet)将数据存储在低成本的对象存储(例如Amazon S3)中,并在对象存储上实现元数据层,其定义哪些对象是表版本一部分。这使系统可以在元数据层实现诸如ACID事务处理或版本控制之类的管理功能,同时将大量数据保留在低成本对象存储中,并允许客户端使用标准文件格式直接从该存储中读取对象,尽管元数据层增加了管理功能,但不足以实现良好的SQL性能,数据仓库使用多种技术获得很好的性能,例如将热数据存储在SSD等高速设备、维护统计信息、构建有效的访问方法(例如索引)以及优化数据格式和计算引擎。基于现有存储格式的Lakehouse中无法变更格式,但是也可以实现在保持数据文件不变情况下的其他优化,包括缓存、辅助数据结构(例如索引和统计信息)和数据布局优化。
Lakehouse既可以加快高级分析负载,又可以为其提供更好的数据管理功能。许多ML库(例如TensorFlow和Spark MLlib)已经可以读取数据湖文件格式(如Parquet)。因此将它们与Lakehouse集成的最简单方法是查询元数据层,以确定哪些Parquet文件属于表,然后将它们传递给ML库。
Lakehouses的第一个组件是元数据层,其可以实现ACID事务和其他管理功能。诸如S3或HDFS之类的数据湖存储系统仅提供了低级的对象存储或文件系统接口,在这些接口中,即使是简单的操作(如更新跨多个文件的表)也不是原子的,这个问题使得一些组织开始设计更丰富的数据管理层,从Apache Hive ACID开始,其使用OLTP DBMS跟踪给定表版本中哪些数据文件是Hive表的一部分,并允许操作以事务方式更新此集合。近年来一些新系统提供了更多功能和改进的可伸缩性,如2016年Databricks开发的Delta Lake,其将有关哪些对象是表中一部分的信息存储在数据湖中,作为Parquet格式的事务日志,使其能够扩展到每张表数十亿个对象;Netflix的Apache Iceberg也使用类似的设计,并支持Parquet和ORC存储;Apache Hudi始于Uber也类似,尽管它不支持并发写入(正在支持中),该系统侧重于简化流式数据入数据湖。
这些系统的经验表明它们可以提供与原始Parquet/ORC数据湖类似或更好的性能,同时还增加了非常有用的管理功能,例如事务处理,零拷贝和时间旅行。元数据层对数据质量非常重要,例如可以对Schema进行校验,使其不破坏数据质量,另外元数据层可以实现诸如访问控制和审核日志记录之类的治理功能,例如元数据层可以在授予客户端凭据以从云对象存储读取表中的原始数据之前,检查是否允许客户端访问表,并且记录所有访问行为。
未来方向和替代设计。由于数据湖的元数据层非常新,因此存在许多悬而未决的问题和替代设计。例如Delta Lake设计为将事务日志存储在它运行的同一对象存储中(例如S3)以简化管理(消除了运行单独存储系统的需要)并提供高可用性和高读取带宽,但对象存储的高延迟限制了它可以支持的每秒事务处理速率,在某些情况下将元数据使用更快的存储系统的设计可能更可取。同样Delta Lake,Iceberg和Hudi仅支持单表事务,但也可以扩展以支持跨表事务,优化事务日志的格式和管理对象的大小也是未解决的问题。
Lakehouse方案的最大技术问题可能是如何提供最新的SQL性能,同时又放弃了传统DBMS设计中很大一部分的数据独立性,有很多解决方案,例如可以在对象存储上添加一个缓存层,以及是否可以更改数据对象存储格式而不使用现有的标准(例如Parquet和ORC(不断改进这些格式的新设计不断涌现))。无论采用何种设计,核心挑战在于数据存储格式已成为系统公共API的一部分以允许快速直接访问,这与传统DBMS不同。
我们提出了几种技术可以在Lakehouse中优化SQL性能,并且与数据格式无关,因此可以将其与现有格式或未来数据格式一起使用,这些与格式无关的优化大致如下:
对于分析系统中的典型访问模式,这三个优化可以很好地协同工作。典型的工作负载中大多数查询倾向于集中在数据的"热"子集上,Lakehouse可以使用与数据仓库相同的优化数据结构对其进行缓存,以提供相同的查询性能。 对于云对象存储中的"冷"数据,性能的主要决定于每个查询读取的数据量,在该情况下数据布局优化(将共同访问的数据聚类)和辅助数据结构(如区域图,使引擎快速确定要读取的数据文件范围)的组合可以使Lakehouse系统与数仓一样最小化I/O开销,尽管使用标准的开放文件格式(相比于数仓内置文件格式)。
高级分析库通常不是使用SQL命令编写,其需要访问大量数据,如何设计数据访问层以最大程度地提高运行在顶部的代码的灵活性,仍然可以从Lakehouse的优化中受益。
机器学习API迅速发展,但是一些数据访问API(例如TensorFlow的tf.data)没有尝试将查询语义推入底层存储系统,一些API还专注于CPU到GPU的传输和GPU计算,这在数据仓库中并未引起太多关注。
我们需要标准ML接口以使数据科学家能够充分利用Lakehouse(甚至数据仓库)中强大的数据管理功能,如事务,数据版本控制和时间旅行等。
Lakehouse还提出了其他一些研究问题,功能日益丰富的数据湖的行业趋势也对数据系统研究的其他领域产生了影响。
在开放的数据湖文件格式上实现数据仓库功能的统一数据平台体系结构可以为当今的数据仓库系统提供具有竞争力的性能,并有助于应对数据仓库用户面临的许多挑战,尽管限制数据仓库的存储层以标准格式直接访问看起来似乎是一个重大限制,但诸如热数据缓存和冷数据数据布局优化之类的优化可以使Lakehouse获得很不错的性能,另外鉴于数据湖中已有大量数据,并且有机会大大简化企业数据架构,行业很可能会向Lakehouse架构逐步过渡。