LakeHouse湖仓一体架构

背景

当下数据爆炸式的增长，以及新的数据分析方法的蓬勃发展，使得企业对数据集中式管理的诉求越来越严苛。 需要一种新的架构能够满足当下更快、更可靠、更开放、易于扩展、便于集中管理的需求。在聊LakeHouse前， 我们先了解一下数据存储架构的一些关键特性。

存储架构的特性

从几十年前的数据库，到近十几年前的数据仓库，再到几年前的数据湖。数据存储的解决方案在不断的优化。 下面是数据存储架构需要的一些特性：

1. 可扩展以及高性能
   根据数据体量能够扩展，并提供数据读写的高吞吐以及低延迟，满足各种场景的需求。

2. 支持事务
   复杂场景一般需要读写并发操作，为了保证结果的准确性。对事务ACID的支持显得格外重要。

3. 支持多样的数据格式
   能存储非结构化数据（例如像原生日志一样的文本文件），半结构化数据（比如JSON文件）以及结构化数据（表格数据）。

4. 支持多种使用场景
   • 使用SQL的传统BI分析
   • 原生非结构化数据的ETL批处理
   • 实时监控以及预警的流处理
   • 推荐以及生产预测的ML和AI
5. 开放性
   以开放的数据格式支持广泛的使用场景，通过标准的API使得各种工具、引擎能够访问到数据。针对不同的场景使用最优的方案，提供更好的商业决策分析。

一直以来，各种各样遵循以上特性的解决方案被提出。他们有着其独特的优势以及一些缺陷。我们先探讨一下数据架构从数据库到数据湖的演变，然后去深入了解有着数据湖的灵活性和数据库事务性保证的新一代的架构LakeHouse。

数据库

过去的几十年，数据库已经成为存储商业核心数据最可靠的解决方案。数据库将结构化数据以表格的方式存储，然后通过SQL的方式查询数据。数据必须遵循严格的文件格式，这允许数据库管理系统高度协同优化数据存储和处理。也就是说，它们将磁盘文件中的数据和索引的内部布局与它们高度优化的查询处理引擎紧密耦合。从而提供了对存储数据非常快速的计算以及所有读/写操作的强事务性ACID保证。数据库上的SQL使用场景大致可以分为两类：

• Online transaction processing (OLTP)
  比如银行账户的事务就是典型的高并发、低延迟读取、更新数据的OLTP场景。

• Online analytical processing (OLAP)
  例如周期性数据报表需要高吞吐数据扫描的复杂查询就属于OLAP场景。

数据库的局限性

在过去十年中，数据分析场景出现两种主要的新趋势：

1. 数据体量的高速增长
   随着大数据行业的高速发展，越来越多企业为了了解趋势、用户行为，几乎将所有的数据收集起来（包括页面访问 ，点击等等） 数据量从GB到过去十几年的TB到现在的PB级别。
2. 数据分析方式的多样性
   随着海量数据的收集，就需要更深入的数据分析。直接导致了复杂分析的爆炸性增长比如机器学习，深度学习。

然而由于以下一些限制，数据库在适应这些新趋势方面已显示出相当不足:

1. 数据库向外扩展的成本非常高
   尽管数据库在处理单台机器上的数据方面非常高效，但数据量的增长速度远远超过了单台机器性能的增长速度。 处理引擎向前发展的唯一途径是向外扩展，即是用多台机器并行处理数据。然而，大多数数据库，尤其是开源数据库，并不是为向外扩展以执行分布式处理而设计的。 少数能够远程跟踪满足处理需求的工业数据库解决方案往往是运行在专业的硬件上的商业解决方案。因此，获取和维护的成本都非常昂贵。
2. 数据库不太支持基于no-sql环境下的数据分析
   数据库以复杂的(通常是特有的)格式存储数据，这些格式通常经过高度优化，只供数据库的SQL处理引擎读取。 这意味着其他处理工具，如机器学习和深度学习系统，不能有效地访问数据(除非低效地从数据库读取所有数据)。 数据库也不能像机器学习那样易于扩展以执行no-sql的分析。

数据库的这些局限性促使了一种完全不同的数据存储架构的发展，称为Data Lake数据湖。与大多数数据库相比，数据湖是一种分布式存储解决方案，它运行在普通硬件上，可以轻松地横向扩展。数据湖架构与数据库架构不同，它将分布式存储系统与分布式计算系统解耦。这允许每个系统根据使用场景的需要向外扩展。此外，数据被保存为开放格式的文件，这样任何处理引擎都可以使用标准API读写数据。这个理念是在21世纪后期由于Hadoop文件系统而流行起来的。

数据湖

不同的公司在构建自己的数据湖时都大同小异，主要是以下的几个方面有着各自的选择：

1. 存储系统
   HDFS集群或者是 AWS S3 、Azure Data Lake Storage、阿里云OSS等云对象存储。
2. 文件格式
   根据下游分析场景的需要：结构化的 Parquet、ORC 半结构化的 JSON 非结构化的文本、图像、音频或是视频。
3. 处理引擎
   • 批处理的 Spark Presto Hive
   • 流处理 Spark Flink
   • 机器学习的 Spark MLlib, scikit-learn, R

灵活选择最适合当前使用场景的存储系统、开放数据格式和处理引擎的能力——是数据湖相对于数据库的最大优势。总的来说，对于相同的性能特征，数据湖通常提供比数据库便宜得多的解决方案。这一关键优势导致了大数据生态系统的爆炸式增长。

数据湖的局限性

数据湖并非没有缺陷，尤其是对以下这些事务性保证的缺失：

1. 原子性以及隔离性
   处理引擎以分布式的方式在数据湖中写入尽可能多的文件。如果操作失败，就没有机制来回滚已经写入的文件，从而留下可能损坏的数据(当并发修改数据时，问题会加剧，如果没有更高级的机制，就很难提供跨文件的隔离)。
2. 一致性
   对失败的写操作缺乏原子性会进一步导致读取到不一致的数据结果。事实上，即使是成功写入的数据，也很难保证数据质量。例如，数据湖的一个非常常见的问题是，意外地以与现有数据不一致的格式和模式写出数据文件。

为了解决数据湖的这些缺陷，开发人员使用了各种各样的技巧。以下是一些例子:

• 数据湖中的大量数据文件通常根据列的值被子目录“分区”(例如，一个大的parquet格式的Hive表按日期分区)。为了实现对现有数据的原子修改，通常会重写整个子目录(即，写入临时目录，然后交换引用)，只是为了更新或删除一些记录。
• 数据更新作业(如每日ETL作业)和数据查询作业的调度(例如，每日报表)通常是交错排列的，以避免并发访问数据和由此引起的任何不一致。

为了解决这些实际问题，于是就出现了新一代的数据存储架构：LakeHouse。

todo …