当企业须要建设独立的数据仓库零碎来撑持BI和剖析业务时，有了“数据湖+数据仓库”的混合架构。但混合架构带来了更高的建设老本、治理老本和业务开发成本。随着大数据技术的倒退，通过在数据湖层减少分布式事务、元数据管理、极致的SQL性能、SQL和数据API接口能力，企业能够基于对立的架构来同时反对数据湖和数据仓库的业务，这就是湖仓一体架构。本篇持续介绍星环科技Inceptor和Apache Delta Lake。

— 星环科技Inceptor—

星环科技 Inceptor是一个分布式的关系型剖析引擎，于2013年开始研发，次要用于ODS、数据湖以及其余结构化数据的剖析型业务场景。Inceptor反对绝大部分ANSI 92、99、2003 SQL规范，兼容传统关系型数据库方言，如Oracle、IBM DB2、Teradata等，并且反对存储过程。2014年起，国内一些银行客户开始尝试将一些本来在DB2上一些性能有余的数据加工业务，迁徙到Inceptor上，而这些本来构建在关系型数据库上的数据工作有大量的并发update、delete的需要，并且存在多个数据链路加工一个后果表的状况，因而有很强的并发事务性能要求。此外，因为用户不仅冀望实现数据批处理业务从关系数据库迁徙到Hadoop平台上，并且冀望性能上有数量级上的晋升，因而星环科技从2014年开始研发基于HDFS的分布式事务机制，以撑持局部数据仓库的业务场景，到2016年随着Inceptor 4.3版本正式公布了相干的技术，并后续几年在数百个金融行业用户落地生产，技术成熟度曾经金融级要求。

Inceptor的总体架构图如上，因为ORC是列式存储，有十分好的统计分析性能，咱们抉择基于ORC文件格式来二次开发分布式系统。因为HDFS也不反对文件的random access和文件内的事务操作，因而对数据的并发update和delete，咱们采纳了MVCC机制，每次提交的数据更新，不间接对数据文件进行改写，而是对数据文件减少一个相应的新版本，一个事务内的所有的数据操作都写入一个delta文件中。读取数据的时候再将所有文件数据读入内存，并且在内存中对多个文件中的同一个数据依照事务程序和可见性来做合并，也就是Merge on Read机制。

须要强调一点，数据仓库上都是数据批处理加工，批处理的数据业务每个SQL都可能操作的数据量比拟大，单个的SQL操作须要的延时可能是几十秒甚至是分钟级以上，它对分布式事务的性能要求是几十到几百TPS，而不是分布式数据库面向交易型业务须要的几万甚至更高的TPS。锁抵触是批处理状况下并发性能的一个次要瓶颈点。如果同时有多个ETL工作在加工一个数据表，那么这个表很有可能就会呈现锁抵触，从而导致数据工作之间呈现锁期待而拖慢最终加工节奏。为了解决性能问题，咱们开发了一个独立的Lock Manager来治理分布式事务的产生与可见性判断，同时锁的粒度包含Database、Table和Partition三个粒度，这样就缩小了很多的不必要的锁抵触问题。

此外，在数仓加工过程中，很多表既是上一个加工工作的后果表，也是其余数据工作的数据源头，因而也会存在读写抵触问题，局部状况下会导致并发受限。为了解决这个问题，咱们引入快照（snapshot）机制和Serializable Snapshot的隔离级别，数据表的读操作能够间接读取某个快照，这样就无需跟写操作产生事务抵触。在咱们的设计中，快照不须要长久化，无需减少大量的物理存储，而是一个轻量级的、全局统一的逻辑概念，在事务处理中能够疾速判断数据的某版本该当蕴含还是排除。

在事务的隔离性上，Inceptor反对Read uncommitted、Read committed、Repeatable reads、Serializable和Serializable Snapshot这5种隔离级别。在并发控制技术上，Inceptor 提供了乐观和乐观两类可序列化隔离级别：基于严格的两阶段锁的串行化隔离级别和基于快照的序列化隔离级别。用户能够依据业务场景抉择适宜的隔离级别类型。严格的两阶段锁的序列化隔离（S2PL Based Serializable Isolation）是一种乐观的并发控制技术，其次要特点是先取得锁，再解决读写，直到事务提交实现后才开释所有锁。它的实现比拟不便，次要难点是解决好死锁问题（通过环检测解决）。该技术的读写无奈并发，因而事务处理的并发性能较差。而可序列化快照隔离（Serializable Snapshot Isolation）可能进步事务处理的并发性能，采纳了基于乐观锁的可序列化快照隔离，该技术的劣势是不会产生两阶段锁技术中读写操作相互阻塞的状况，使得读写互不阻塞，进步了并发度。尽管快照隔离也不会呈现脏读、不可反复读、幻读景象，但它并不能保障可序列化，在解决并发的事务时，依然可能因为不满足束缚（Constraints）而产生异样，称之为写偏序问题（Write Skew）。为解决写偏序问题，Inceptor引入对可序列化快照抵触的查看，减少了对快照隔离级别下事务间的读写依赖关系中环的检测来发现相干的抵触问题并abort异样的事务。

如上文所述，Inceptor在分布式事务的并发能力、事务隔离性、SQL性能等方面的技术积攒比拟残缺，此外从2016年就开始被金融业大量采纳，在数据仓库的场景下Inceptor的成熟度比拟高。因为Inceptor设计上不是为了机器学习的场景，因而没有提供间接给机器学习框架应用的数据API层。另外，Inceptor也没有独自设计面向实时数据写入的架构，也不能无效的反对流批一体的架构，不过星环科技在分布式数据库ArgoDB中解决了流批一体的需要问题。

— Apache Delta Lake —

因为Databricks Cloud上大量用户运行机器学习工作，因而Databricks的次要设计指标包含：

优良的SQL性能
数据分析的性能是BI和剖析类软件的外围要求，因而须要采纳列式文件格式（如Parquet等）等适宜统计分析的格局，以及向量式计算引擎、数据拜访缓存、层级化数据存储（如冷热数据拆散存储等技术）等技术，来晋升数据湖内SQL统计分析的性能，达到数据仓库的技术要求

提供分布式事务和schema反对
数据湖的存储多以文件形式，采纳的schemaless形式，这位数据分析提供了灵活性，然而就无奈实现数据库的ACID治理能力。Delta Lake欠缺了文件存储，提供严格的数据库schema机制，之后研发了一套基于MVCC的多版本事务机制，这样就进一步提供数据库的ACID 语义，并且反对高并发的update和delete的SQL操作。此外，Delta Lake基于凋谢的数据格式（Parquet），这样既能够间接操作HDFS，也让其余计算引擎能够拜访相干的数据，进步了生态兼容性。

灵便对接机器学习工作和摸索式剖析的数据API
机器学习和AI训练任务对Databricks的外围业务场景，因而Delta Lake在设计上十分重视保障的这类业务的撑持，其不仅提供DataFrame API，还反对Python、R等编程语言接口，还强化了对Spark MLlib、SparkR、Pandas等机器学习框架的整合。

基于以上能力，联合Spark的计算能力和Delta lake的存储能力，就能够实现齐全基于Databricks存算技术的数据架构，能够反对BI统计分析、实时剖析以及机器学习工作，另外Delta Lake基于凋谢的数据存储格局，也能够对接其余的计算引擎如Presto做交互式剖析。

在我的项目的初始设计指标上，Hudi侧重于高并发的update/delete性能，Iceberg侧重于大量数据状况下的查问性能，而Delta Lake设计的外围是为了更好的在一个存储上同时反对实时计算和离线计算。通过与Spark Structured Streaming的深刻整合，delta table不仅能够做Streaming的数据源，也能够间接作为Streaming的指标表，此外还能够保障Exactly-Once语义。Delta社区联合multi-hop数据架构设计了一套流批一体的参考架构设计，可能做到相似Kappa架构的一份数据存储响应流批两种场景需要。

因为Databricks对Delta Lake的开源绝对受限，局部性能须要依赖Databricks File System以及Engine能力比拟好，因而社区外面的关注度上不如Huid和Iceberg。此外，设计上Delta Lake并不提供主键，因而高并发的update/delete不如Hudi，也不提供相似Iceberg的元数据级别的查问优化，因而查问性能上可能不如Iceberg，然而Delta Lake强调的是联合Spark造成的流批一体的数据架构以及对机器学习类利用的原生API级别的反对，可实用的业务场景有很好的普遍性。

— 小结—

从工夫维度上看，星环科技Inceptor是最早开始摸索在数据湖上提供数据仓库能力的产品，并且在2016年即实现产品的规模化上生产，因而产品成熟度较高，尤其是在分布式事务实现的齐备性上更是有显著的劣势。

Hudi在设计上适宜有高并发的update/delete的业务场景，与星环科技Inceptor 相似，这两个技术也都是基于Hadoop提供update、delete的能力，而相对来说，Hudi在分布式事务的实现细节上还须要更多的工夫和生产打磨来欠缺。

Iceberg我的项目在设计上适宜有大量分区但少事务操作的海量数据的剖析场景，对互联网类企业比拟适宜，加上Iceberg在软件设计上做了十分好的形象，对各种计算引擎的反对比拟齐备，在partition等优化上做的十分粗疏，对一些事务性要求不太高的场景还是有很强的吸引力。

Databricks对Delta Lake的开源绝对受限，局部性能须要依赖Databricks File System以及Engine能力比拟好，因而社区外面的关注度上不如Hudi和Iceberg。Delta Lake在性能上没有突出的设计，在分布式事务的实现上绝对比较简单，事务并发和隔离性实现都还处于晚期阶段，目前该我的项目更强调的是联合Spark造成的流批一体的数据架构以及对机器学习类利用的原生API级别的反对。

随着各个我的项目逐渐实现了初始设计指标，他们都想进一步扩充实用场景，也都在进入各自的畛域，各个我的项目的疾速倒退也推动着湖仓一体架构的疾速迭代。