共计 4284 个字符，预计需要花费 11 分钟才能阅读完成。
当企业须要建设独立的数据仓库零碎来撑持 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 级别的反对。
随着各个我的项目逐渐实现了初始设计指标，他们都想进一步扩充实用场景，也都在进入各自的畛域，各个我的项目的疾速倒退也推动着湖仓一体架构的疾速迭代。