引言：随着企业数字化转型进入深水区，越来越多的企业视湖仓一体为数字变革的重要契机，湖仓一体也受到了前所未有的关注。当然，关注度越高市场上的声音也就越嘈杂，很多过时甚至错误的湖仓一体技术和理念不胫而走，很有可能将转型中的企业引入歧途，推高数据孤岛，造成资源浪费甚至错过数字化转型的战略时机。
伪湖仓一体自然是我们不愿看到的，而想要理解什么是真正的湖仓一体，则需要对技术背景及其演进历程有清晰的认知，当然这对多数读者都很挑战，因此笔者尝试从技术背景和发展脉络的角度给出湖仓一体的终极答案。
一、从数据仓库说起
1990 年，数据仓库之父比尔·恩门 (Bill Inmon) 率先提出了数据仓库的概念，其专著《建立数据仓库》指出数据仓库为分析决策服务，是一个面向主题的、集成的、非易失的且随时间变化的数据集合。2000 年开始，数据仓库在国内得到了广泛的推广，电信和银行业最早建立起数据仓库。
比尔·恩门 (Bill Inmon)
1、发展背景
业务增长源源不断的产生数据，这些数据存储在业务数据库中，也就是我们常说的 OLTP 数据库。当积压的历史数据越来越多，对业务数据库产生负载，导致业务系统运行速度降低；同时，在日益激烈的市场竞争中，企业需要对积累的数据进行分析，获取更加准确的决策信息来完成市场推广、运营管理等工作。由此，提出将历史数据存储到数据仓库 (OLAP)，改善业务系统数据库性能的同时，可以更专注的提升数据分析效率，辅助企业决策。
2、技术演进
传统关系型数据库的技术架构，尤其是 OLTP 数据库无法有效满足大量历史数据的存储、查阅以及数据分析需求。随着数据仓库技术进一步发展，分布式数据库产生，出现了以 Teradata 为代表的一体机 MPP 数据库产品，此后又出现了 Greenplum 和 Vertica 等基于标准 x86 服务器的 MPP 数据库，他们采用无共享架构 (Share-nothing) 以支持数据仓库的建设。这个阶段主要建设 OLAP 类型的系统，如数据仓库、ODS、数据集市、应用数据库、历史数据库以及报表、分析报告、数据挖掘、客户标签画像等。
OLAP 系统建设
在数据模型方面，以银行业为例，很多银行建立主题模型都选用 Teradata FS-LDM (Financial Services Logical Data Model) 和 IBM BDWM (Banking Data Warehouse Model)。不同行业有不同的数据模型。
Teradata FS-LDM 图例
3、阶段特点
该阶段早期，不少企业直接采用了共享存储架构的 Oracle 和 Db2，也有不少客户采用了 MPP 无共享 Share-nothing 架构的产品。早期 MPP 采用软硬一体的专有服务器和昂贵的存储，比如 Teradata，后期 MPP 大多采用标准 x86 服务器，架构依然是无共享 Share-nothing 架构，数据以结构化为主，集群的扩展能力有限。基于共享存储架构的数据库集群规模通常在几十节点，MPP 基本在百节点级别，支持数据体量有限，很难超过 PB 级别。
典型 MPP 架构
二、大数据平台逐渐流行
时间来到 2012 年，国内一些技术发展较快的行业，如电信和头部银行（国有大行和股份制银行）基本都完成了数据仓库的建设。彼时 Hadoop 技术快速普及，大数据平台开始受到关注，尤其受互联网行业迅速发展的影响，大数据平台迎来历史的高光时刻。
Hadoop 生态
1、发展背景
互联网以及很多行业线上业务的快速发展，让数据体量以前所未有的速度增长，企业对海量数据的处理有了更高要求，如非结构化数据处理、快速批处理、实时数据处理、全量数据挖掘。由于传统数据仓库侧重结构化数据，建模路径较长，面对大规模数据处理力有未逮，而企业亟需提升大数据处理时效，以更经济的方式发掘数据价值。
2、技术演进
企业开始使用 Hadoop 分布式大数据计算和存储，同时 Hive，Spark、Impala 等数据处理技术进一步发展，Spark Streaming、Flink 等实时数据处理技术也让大数据平台具备了实时数据处理能力。Hadoop 一般使用 HDFS 存储数据，其计算引擎使用 MapReduce，Spark 等实现。虽然 Hadoop 逻辑上实现了计算和存储分离，但是其物理部署架构依然强调在每一个节点同时部署计算节点和存储节点，通过将计算置于存储所在的位置，利用数据本地性提升计算性能。
3、阶段特点
Hadoop 得到了广泛的认可，大数据热让人们对 Hadoop 抱有更高的期待，认为既然 Hadoop 平台能解决很多数据处理和分析问题，自然可以替代传统的数据仓库。但是，随着 Hadoop 大数据平台建设逐步推广，企业尝试将 Hadoop 用于一些非核心场景（如银行的三方数据平台）之后，发现 Hadoop 不仅性能和并发支持有限，而且事务支持弱，交付运维成本高，企业最终意识到基于 Hadoop 的大数据平台终究无法替代核心数仓。投身 Hadoop 技术的两家头部企业 Cloudera 和 Hortonworks 经历了上市的高光时刻，最终在合并后退市了。
三、无奈之举，湖仓分体
1、发展背景
无法替代数据仓库，但是 Hadoop 逐渐形成了自身特殊的定位——数据湖。Gartner 曾指出，数据湖存储着各种数据资产，这些资产使用与源数据类似或者相同的格式。数据湖对全量的、各种类型的数据进行存储和挖掘，为数据科学家提供基于任意原始数据开发应用的敏捷性，而不必局限于数仓的数据，这是数据湖优于传统数仓之处。但数据湖却始终无法满足用户在性能、事务等方面的要求，所以企业的 IT 建设通常先让所有数据入湖，便于自由灵活的数据分析和探索，在某个分析逐步成熟时，将其转移到数据仓库，这样就形成了数据湖和数据仓库互补的方式（如下图所示）。
数据湖+数据仓库 互补
除了技术特性互补，数据湖和数据仓库在项目投入成本方面也有互补性。由于湖和仓的架构不同，长期项目投入的“性价比”差异很大。数据湖起步成本低，但随着数据体量增大，项目成本快速上升；数据仓库则恰恰相反，前期建设投入大，后期管理成本较低。
湖与仓项目长期成本的差异曲线
2、技术演进
湖和仓相互协作的前提是各自的技术都相对稳定成熟，在此阶段，湖和仓都出现了一些典型产品，既有 Greenplum、Vertica、GaussDB 等 MPP 数据仓库，也有 Cloudera、AWS、阿里云、腾讯云等厂商基于 Hadoop 的数据湖解决方案。企业在构建数据湖的同时，也使用MPP，即湖+仓模式，湖是湖，仓是仓，湖仓各自独立部署，数据通过ETL的方式打通，这就是业内常说的 Hadoop+MPP 模式，我们称之为湖仓分体模式。
3、阶段特点
这个阶段最大的特点和问题就是数据孤岛。造成数据孤岛的原因有几个方面：
1）湖仓分体方案基本上是以湖、仓和其他组件构成，逻辑上为用户提供统一的数据管理，但物理层面湖和仓仍然是分离的，同一份数据在多个集群冗余存储，导致分体模式下的湖和仓各自形成数据孤岛。
2）除了技术架构原生造成的数据孤岛，集群规模受限又进一步造成数据孤岛。多数的湖通过 Hadoop 构建，数仓是 MPP 数据库，当数据达到 PB 级别，由于 Hadoop 和 MPP 集群规模受限，企业往往会部署和使用多个 Hadoop 集群和多个 MPP 集群，事实上进一步造成了数据孤岛。目前业界的实践确实也是多集群同步进行，例如字节跳动有多达几十个 Hadoop 集群，很多国有大行有多达几十个 MPP 集群。
3）越来越多的分析应用场景导致了逐渐高涨的并发查询需求，面对动辄就查询数百 TB 的业务场景，无论是Hadoop 还是 MPP 都法支撑这种复杂查询的并发需求。MPP 数据仓库单一集群支持的并发数仅达到几十左右，而 Hadoop 支持的并发则更低，一个复杂查询可能会遍历数百 TB 数据，使整个系统的性能受到很大影响。此外，SQL 的编写问题也可能会影响到系统其它用户，很多 DBA 都经历过每次应用上线时的胆战心惊，生怕新应用导致既有业务应用崩溃。为了满足高并发，企业不得不把业务分割到更多的集群中，造成更严重的数据孤岛。
技术层面无法实现湖仓一体化，自然要通过打通湖仓疏解数据孤岛，这个过程又催生了一系列复杂的实施和运维问题，如 ETL 逻辑复杂，数据变更困难，数据不一致，数据治理困难。此外，湖仓分体模式在前文提到的项目成本方面，也无法发挥湖和仓的成本互补性。
四、技术崛起，湖仓一体
1、发展背景
湖仓分体模式持续筑高数据孤岛并引发一些列实施、运维和成本问题，那么湖仓一体能否彻底解决这些问题？应该从哪些方面入手？湖仓一体有何标准？Gartner 认为湖仓一体是将数据湖的灵活性和数仓的易用性、规范性、高性能结合起来的融合架构，无数据孤岛。
前文总结的造成数据孤岛的三点主要原因：(1) 数据多集群冗余存储、(2) 集群规模受限、(3) 集群高并发受限，都应该在湖仓一体架构中得以解决。除此之外，近年来数字化转型带来的业务需求和技术难点也应该在新一代的湖仓一体架构中得到关注和解决，具体包括如下四个方面：
1）随着线上业务迅猛发展，摸着“数据”过河，小步快跑推动了企业“实时”需求的升级。在很多线上场景中，实时性成为了提升企业竞争力的核心手段。但是目前的湖、仓、或者湖仓分体都是基于 T+1 设计的，面对 T+0 的实时按需分析，即便引入流处理引擎实现了部分固定模式的实时分析，仍无达到 T+0 全实时水平。
2）从 Snowflake 在资本市场赚足眼球，到 Databricks 和 Snowflake 因 TPC-DS 测试结果在湖仓战场正面对决，我们发现云原生数据库已经逐渐成熟，成为了湖仓一体落地的重要法门。
3）为释放数据价值提升企业智能化水平，数据科学家等用户角色必须通过多种类型数据进行全域数据挖掘，包括但不限于历史的、实时的、在线的、离线的、内部的、外部的、结构化的、非结构化数据。
4）传统 Hadoop 在事务支持等方面的不足被大家诟病，在高速发展之后未能延续热度，持续引领数据管理，因此事务支持在湖仓一体架构中应得到改善和提升。
2、ANCHOR 定义湖仓一体
理解了上文湖仓一体应该关注的重点，湖仓一体的本质和要求也就呼之欲出——真正的在数据和查询层面形成一体化架构，彻底解决实时性和并发度，以及集群规模受限、非结构化数据无法整合、建模路径冗长、数据一致性弱、性能瓶颈等问题，有效降低 IT 运维成本和数据管理的技术门槛。
为此我们总结出湖仓一体 ANCHOR 标准，ANCHOR 中文译为锚点、顶梁柱，或将成为湖仓一体浪潮下的定海神针。ANCHOR 具有六大特性，其 6 个字母分别代表：All Data Types（支持多类型数据）、Native on Cloud（云原生）、Consistency（数据一致性）、High Concurrency（超高并发）、One Copy of Data（一份数据）、Real-Time（实时T+0）。使用 ANCHOR 六大特性很容易判断出某一系统设计是否真正满足湖仓一体。
ANCHOR 六大特性
3、ANCHOR 的业务价值
满足 ANCHOR 定义的湖仓一体将在哪些方面为企业带来价值？可以概括为以下六个方面。
1）实时 T+0（Real-Time）：通过全量数据 T+0 的流处理和实时按需查询，满足基于数据的事前预测、事中判断和事后分析。
2）一份数据（One Copy of Data）：所有用户（BI 用户、数据科学家等）可以共享同一份数据，避免数据孤岛。
3）超高并发（High Concurrency）：支持数十万用户使用复杂分析查询并发访问同一份数据。
4）数据一致性（Consistency）：通过支持完善的事务机制，保障不同用户同时查询和更新同一份数据时的一致性。
5）云原生（Native on Cloud）：适合云环境，自由增减计算和存储资源，按用量计费，节约成本。
6）支持多类型数据（All Data Types, Structured & Unstructured）：支持关系表、文本、图像、视频等结构化数据和非结构化数据存储。
接下来，我们展开分析下满足 ANCHOR 的湖仓一体为企业带来的价值。
1）实时 T+0（Real-Time）
通过全量数据 T+0 的流处理和实时按需查询，满足基于数据的事前预测、事中判断和事后分析。
当下，瞬息万变的商业社会要求企业更快的做出商业决策。从“双十一 ”和春晚直播实时大屏、银行和税务的风险实时阻断、机器学习建模逐步在线化等趋势中，我们可以发现，企业除了离线数据分析还有大量的实时数据分析需求。
运营层面：实时业务变化，实时营销效果，当日分时业务趋势分析等；
C 端用户层面：搜索推荐排序，实时行为等特征变量的生产，为用户推荐更精准的内容；
风控层面：实时风险识别、反欺诈、异常交易等都是广泛应用实时数据的场景；
生产层面：实时监控系统的稳定性和健康状况等。
具备实时能力的湖仓一体架构除了满足传统离线分析，还满足了实时分析和实时数据服务。常见的实时数据服务包括通过系统日志点查方式得到的「直接特征」，如点击、浏览、下载、支付；此外，还有更为复杂也更具应用价值的「衍生特征」：
某一产品 5 分钟的点击量；
某一页面 1 周的访问量；
某一用户 30 天内查询征信报告的次数。
这些特征通过实时数据服务的形式提供给决策系统或推荐系统。满足此类 T+0 实时数据处理的最佳方案是新一代 Omega 全实时架构（Lambda 和 Kappa 的下一代架构），下文会单独介绍 Omega 全实时架构的演进和实现。
2）一份数据（One Copy of Data）
所有用户（BI 用户、数据科学家等）可以共享同一份数据，避免数据孤岛。
不同的用户在不同的应用场景会使用很多同样的数据，比如银行做反洗钱应用需要使用交易数据，做营销用户画像也需要使用交易数据。在传统的湖仓分体架构中，同样的数据会有多个副本，不同用户使用各自的副本并更新其副本，这样就产生了数据冗余存储以及数据更新引发的数据不一致等问题，因此，基于不同数据得出的相关分析结论可能会有较大出入，各个应用基于同样的定义计算出的指标也可能不一致，这当然是企业管理层和决策者不愿看到的。
ANCHOR 标准保障所有用户可以共享同一份数据，避免数据孤岛，这样的优势对业务管理和发展有非常大的帮助，极大降低了业务人员和技术用户使用和运营数据的难度。当然，这也在技术层面向基础数据平台提出了更高的要求。
3）超高并发（High Concurrency）
支持数十万用户使用复杂分析查询并发访问同一份数据。
正如前文所提到的小步快跑，我们依靠数据进行决策的频率越来越高，智能应用场景越来越多，企业内部的数据科学家和分析团队的规模、用户数也越来越大。比如一个大型国有银行，并发进行分析查询的作业和用户数可达到上万。如果单集群实现不了高并发，就只能分库分表使用多个集群，数据在不同集群内部重复存储，不可避免的形成数据孤岛。
如何实现分析类复杂查询的高并发呢？有必要了解下分析型数据库（OLAP）的现状。几乎每个中国网民都对“双十一在线剁手”和“12306 春运抢票”都有深刻体会，似乎百万用户同时在线访问同一应用已不是难题，但是，人们可能不清楚传统的交易型数据库（OLTP）中的查询基本只访问单行数据，可通过索引实现毫秒级操作，因此 OLTP 支持百万用户在线访问数据库并不难。然而，在分析型场景中很多查询都是复杂查询，有时甚至会扫描几百 TB 的数据，单个查询可能达到分钟乃至小时级，当分析型的 MPP 或者 Hadoop 进行复杂查询达到几十并发的时候，其吞吐量就会下降，如前文所述，一个涉及海量的复杂查询可能会影响到整个系统的性能。ANCHOR 要求的超高并发在新技术的迭代中成为可能，进而支持百万用户同时在线查询分析。
4）数据一致性（Consistency）
通过支持完善的事务机制，保障不同用户同时查询和更新同一份数据时的一致性。
何为事务？其本质是一组单元化操作，这些操作要么都执行，要么都不执行，是一个不可分割的工作单位。事务（Transaction）所应该具有的四个要素：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），这四个基本要素被称为 ACID 特性。
以最为常见的银行转账为例，我向张三转 1 万元，在毫秒内要完成：
第 1 步：将我的余额减去 1 万
第 2 步：将我的余额更新到数据库
第 3 步：将张三的余额加上 1 万
第 4 步：将张三的余额更新到数据库。
假设在执行第 2 步骤之后，服务器忽然宕机，就会发生一件诡异的事情——我的账户少了 1 万，但是钱并没有到张三的账户上，这 1 万凭空消失了！
要解决这个问题，就要保证转账过程所有数据库的操作是不可分割的，要么全部执行成功，要么全部失败，不允许出现中间状态的数据。
因此湖仓一体 ANCHOR 完善的事务尤为重要。想象一下，企业的数据分析师和数据科学家等众多用户同时进行数据查询和更新，数据一致性无法保证对数据分析工作将造成怎样的影响，严重的话可能会影响到企业关键的管理决策。
5）云原生（Native on Cloud）
适合云环境，自由增减计算和存储资源，按用量计费，节约成本。
云原生架构的本质是存算分离技术，基于云原生架构的数据云平台会为企业带来哪些价值？可以概括为四个方面：降低技术门槛、减少维护成本、提升用户体验、节省资源费用。
降低技术门槛：无论是自建机房还是使用公有云，都离不开底层大数据技术，大数据技术俨然成为了企业的标配技能，然而并不是每个企业都能组建专业的人才团队，尤其是一些传统行业和中小企业。像集群性能调优等较为硬核的能力，更是很多已经搭建数据平台的企业所缺失的。云原生技术使得 dbPaaS 为企业提供更好的数据平台服务，正如 Snowflake 所倡导的：用户不需要调优，只要按需设置性能参数。
减少维护成本：即便勉强跨过技术门槛，全方位的运维也是需要企业投入大量精力和资源的。技术运维主要包括但不限于：
集群搭建
集群扩缩容
日常运维
监控告警等
而这些其实都可以作为服务从云上的供应商获得。
提升用户体验：假如一个分析查询使用 10 个节点需要跑 1 个小时得到查询结果；如果将计算节点扩大 10 倍至 100 个节点的话，同样一个查询则只需要跑 6 分钟。这两种配置在公有云按量计费模式下的成本是相同的，但是用户的体验和效率却可以提升 10 倍。
节省资源费用：首先我们先要清楚资源是怎么浪费的，这主要来自两个方面：
数据不断增长让技术负责人不得不为今后的数据管理留出资源冗余，在数据规模接近资源边界之前，企业的资源都一直处于未完全利用的状态，这就造成了早期投资的浪费，而当企业数据规模或者应用场景增多，往往是计算资源提前耗尽而无法有效支持业务场景；
另一方面，即便在一段时间内数据规模和应用场景变化不大，不同时段的资源利用水平和需求也不一样，比如白天和夜晚、工作日和休息日，平台资源都处于不同程度的闲置状态。
因此，节省资源费用必然要从弹性扩容缩容出发，云原生技术在弹性方面具备天然优势，这也是为什么国外各大云厂商和独立数据库厂商都提供了云原生数据仓库。但在具体的资源供给和计费方面，各个厂商的表现却有差异，比如在弹性计算资源及计费方面，国外厂商起步较早，国内阿里云 ADB（基于 MPP 数据库 Greenplum）和腾讯云 TDSQL-A 目前都不支持计算资源单独配置和计费，相比云厂商，偶数科技等云中立的数据库厂商则更为专注于云原生数据仓库的发展。
6）支持多类型数据（All Data Types, Structured & Unstructured）
支持关系表、文本、图像、视频等结构化数据和非结构化数据存储。
任何企业的全量数据都会包含多样的数据类型，这些数据可能来自历史的、实时的、在线的、离线的、内部的、外部的、结构化的、非结构化，因此支持多类型数据也是湖仓一体 ANCHOR 的基本要求。
传统数据库通常利用数据查询及可视化报表来分析业务成因，而机器学习可以超越关系归纳自动找出数据模型与关系的特征，这已然超越了我们经验、知识和想象力，比如著名的“超市中尿布和啤酒常被同时购买”的案例。但是，很多关系特性隐藏于我们不常关注的非结构化数据中，数据科学家等相关用户角色只有通过多种类型的全域数据进行挖掘，才能真正发挥数据价值进而提升企业在数据智能领域的竞争水平。
五、湖仓一体技术分析
1、技术演进
公有云和私有云的普及让一切软件上云成为趋势，为了保证存储和计算可以独立的弹性扩展和伸缩，数据平台的设计出现了一个崭新的架构，即存算分离架构。
显然，传统 MPP 和 Hadoop 都不适应云平台的要求。MPP 数据库存算耦合，而 Hadoop 不得不通过计算和存储部署在同一物理集群拉近计算与数据的距离，仅在同一集群下构成存算分离。在此阶段，Snowflake 和 OushuDB 突破了传统 MPP 和 Hadoop 的局限性，率先实现了存算完全分离，计算和存储可部署在不同物理集群，并通过虚拟计算集群技术实现了高并发，同时保障事务支持，成为湖仓一体实现的关键技术。
以 OushuDB 为例，实现了存算分离的云原生架构，并通过虚拟计算集群技术在数十万节点的超大规模集群上实现了高并发，保障事务支持，提供实时能力，一份数据再无数据孤岛。同时，偶数科技通过首创的 Omega 架构保障了湖仓一体 ANCHOR 的实时性，形成了具备全实时能力的实时湖仓一体。关于实时处理技术架构的发展，会在下文单独讨论。
偶数湖仓一体架构
在 Hadoop 近期的生态发展中，Iceberg，Hudi 以及 Delta Lake 通过存储层的设计，基于 HDFS/S3 实现数据更新的事务一致性。为了使用支持事务的存储层，上层计算引擎不得不继续使用 Spark 或 Flink 等。由于 Spark 和 Flink 在并发和实时查询等方面的局限性，Iceberg，Hudi 等的创新还未能在 Hadoop 基础上产生更深远的影响。
2、方案比较
目前常见的湖仓一体方案主要基于 Hudi、Iceberg、Delta Lake、Snowflake、OushuDB。从下表分析可以看出来，湖仓一体解决方案大致可以分为两大类：
1）基于 Hadoop 的改造方案（Hudi、Iceberg、Delta Lake 方案）
2）基于新一代云原生数据仓库架构的方案（Snowflake、OushuDB 方案）
基于 Hadoop 改造方案主要从事务特性出发做优化，比如 Iceberg 和 Hudi 等基于 HDFS 或 S3 实现一个支持事务的存储层，其他方面与 Hadoop 区别不大。而从新的基础架构发展出的云原生数据仓库，其存算分离特性更具有技术前瞻性，该架构将是未来的发展趋势。
下表给出了主要湖仓一体解决方案的特性，并结合 ANCHOR 六要素进行对比，我们可以发现并非所有湖仓一体的方案都完全满足 ANCHOR，尤其在 T+0 实时特性方面。
六、Omega 保障 ANCHOR 实时特性
前文我们列举了湖仓一体实时特性的典型应用场景，如运营层面的实时营销效果、C 端用户层面的实时行为等特征、风控层面的实时风险识别、生产层面的实时系统监控。这些都是基于业务场景的，而站在技术角度可以将实时需求分为三类：实时流处理、实时按需分析、离线分析。
为什么是这三类需求？Gartner 给出过明确的分析：通过下图，以一个事件发生的前后作为时间轴，可以将时间线分为三个阶段，分别是事件发生的同时、事件发生后短时间内、事件发生后较长时间，对应的实时要求分别是实时流处理、实时按需分析、离线分析。
实时分析处理三大场景
以一次银行转账为例，交易发生的同时要进行交易反欺诈检测，通过实时流处理系统将本次交易的时间、金额、位置等要素进行加工形成衍生特征提供给反欺诈应用系统；该笔交易结束后，需要立即反映到实时报表和统计分析中，同时业务用户也会按照特定需求查询到该笔交易（比如近 10 分钟内新增的大额交易），由于实时报表和实时统计分析需求千变万化，流处理系统难以满足，所以需要实时按需分析；这笔交易发生后的较长时间内，都会被用来进行报表统计、数据挖掘和机器学习，因此传统的离线分析也是基本需求之一。
目前，实时处理有两种典型的架构：Lambda 和 Kappa 架构。出于历史原因，这两种架构的产生和发展都具有一定局限性。
1、Lambda架构
1）Lambda产生背景
当运行大量数据时，Hadoop 所耗费的时间也会变得越来越多，无法满足一些需要实时分析处理的场景（比如抖音、淘宝的动态推荐），因此新的流式计算引擎如 Spark Streaming、Flink、Storm 等开始出现。流处理、批处理配合使用才能满足绝大部分应用场景，因此Lambda 架构被提出。
2）Lambda实现原理
Lambda 架构通过把数据分解为服务层（Serving Layer）、速度层（Speed Layer，亦即流处理层）、批处理层（Batch Layer）三层来解决不同数据集的数据需求。在批处理层主要对离线数据进行处理，将接入的数据进行预处理和存储，查询直接在预处理结果上进行，不需再进行完整的计算，最后以批视图的形式提供给业务应用。
Lambda 架构逻辑图
批视图听起来有些抽象，由于服务层通常使用 MySQL，HBase 等实现，供业务应用查询使用，此处的批视图就是 MySQL 或 HBase 中的一些表（见下图），这些表存储着批处理作业产生的结果；流处理层主要是对实时增量数据进行处理，新数据通过流计算不断的更新实时视图，比如针对实时大屏场景，实时视图通常就是 MySQL 中的一张表，流处理作业在新数据到来后不停更新实时视图提供给到业务层；服务层主要是响应用户的请求，根据用户需求把批处理层和流处理层产生的数据合并到一起得到最终的数据集。
Lambda 架构部署图
Lambda 在实际生产环境中的部署通常要比上图更加复杂，下图是贴近实际部署的典型示例。可以看出，实际情况要通过一系列不同的存储和计算引擎 (HBase、Druid、Hive、Presto、Redis 等) 复杂协同才能满足业务的实时需求，此外多个存储之间需要通过数据同步任务保持大致的同步。Lambda 架构在实际落地过程中极其复杂，使整个业务的开发耗费了大量的时间。
Lambda 架构在企业落地的实际情况
3）Lambda 优势与不足
优点：是将流处理和批处理分开，很好的结合了批处理和实时流计算的优点，架构稳定，实时计算成本可控，提高了整个系统的容错性。
缺点：(1) 由多个引擎和系统组合而成，批处理 (Batch)、流处理 (Streaming) 以及合并查询 (Merged Query) 的实现需要使用不同的开发语言，造成开发、维护和学习成本较高；(2) 数据在不同的视图 (View) 中存储多份，浪费存储空间，数据一致性的问题难以解决。
2、Kappa 架构
1）Kappa 产生背景
既然 Lambda 架构难保证数据一致性，双倍维护系统成本，那么一套系统解决批处理和流处理的诉求就产生了，对应的解决方案便是 Kappa 架构（即批流一体）。
2）Kappa 实现原理
Kappa 架构在 Lambda 架构的基础上移除了批处理层，利用流计算的分布式特征，加大流数据的时间窗口，统一批处理和流处理，处理后的数据可以直接给到业务层使用。因为在 Kappa 架构下，作业处理的是所有历史数据和当前数据，其产生的结果我们称之为实时批视图（Realtime_Batch_View）。
Kappa 架构逻辑图
在 Kappa 架构中，输入数据在源端采集后通常存储在 Kafka 中，在流处理程序需要升级迭代时，会启动一个新版本作业（StreamJob_Version_N+1）, 该作业会从 Kafka 中读取所有历史数据和新增数据，直到追上旧版本作业（StreamJob_Version_N），旧的作业版本才可以停掉。Kappa 架构通过这种方法升级流处理程序。
Kappa 架构的流处理系统通常使用 Spark Streaming 或者 Flink 等实现，服务层通常使用MySQL 或 HBase 等实现。
Kappa 架构部署图
3）Kappa 优势与不足
优点：由于所有数据都通过流处理计算，开发人员只需要维护实时处理模块，不需要离线实时数据合并，运维简单，生产统一。
缺点：(1) 依赖 Kafka 等消息队列来保存所有历史，而 Kafka 难以实现数据的更新和纠错，发生故障或者升级时需要重做所有历史，周期较长；(2) Kappa 依然是针对不可变更数据，无法实时汇集多个可变数据源形成的数据集快照，不适合即席查询。
Kappa 架构实际应用起来有较大的局限性，因此 Kappa 架构在业内生产落地的案例不多见，且场景比较单一。
3、Omega 架构
1）Omega 产生背景
既然 Kappa 架构实际落地困难，Lambda 架构又很难保障数据的一致性，两个架构又都很难处理可变更数据（如关系数据库中不停变化的实时数据），那么自然需要一种新的架构满足企业实时分析的全部需求，这就是 Omega 全实时架构。Omega 架构由偶数科技于 2021 年初提出，同时满足实时流处理、实时按需分析和离线分析。
2）Omega 实现原理
Omega 架构由流数据处理系统和实时数仓构成。相比 Lambda 和 Kappa，Omega 架构新引入了实时数仓和快照视图 (Snapshot View) 的概念，快照视图是归集了可变更数据源和不可变更数据源后形成的 T+0 实时快照，可以理解为所有数据源在实时数仓中的镜像和历史，随着源库的变化实时变化。
因此，实时查询可以通过存储于实时数仓的快照视图得以实现。实时快照提供的场景可以分为两大类：一类是多个源库汇集后的跨库查询，比如一个保险用户的权益视图；另一类是任意时间粒度的分析查询，比如最近 5 分钟的交易量、最近 10 分钟的信用卡开卡量等等。
另外，任意时间点的历史数据都可以通过 T+0 快照得到（为了节省存储，T+0 快照可以拉链形式存储在实时数仓 ODS 中，所以快照视图可以理解为实时拉链），这样离线查询可以在实时数仓中完成，离线查询结果可以包含最新的实时数据，完全不再需要通过 MPP+Hadoop 组合来处理离线跑批及分析查询。
Omega 架构逻辑图
流处理系统 WASP 既可以实现实时连续的流处理，也可以实现 Kappa 架构中的批流一体，但与Kappa 架构不同的是，OushuDB 实时数仓存储来自 Kafka 的全部历史数据（详见下图），而在 Kappa 架构中源端采集后通常存储在 Kafka 中。
Omega 架构部署图
因此，当需要流处理版本变更的时候，流处理引擎不再需要访问 Kafka，而是访问实时数仓 OushuDB 获得所有历史数据，规避了 Kafka 难以实现数据更新和纠错的问题，大幅提高效率。此外，整个服务层可以在实时数仓中实现，而无需额外引入 MySQL、HBase 等组件，极大简化了数据架构，实现了湖仓市一体（数据湖、数仓、集市一体）。实现了全实时 Omega 架构的湖仓一体，我们也称之为实时湖仓一体。
Omega vs. Lambda vs. Kappa
七、湖仓一体典型案例
1、建设银行湖仓一体
案例背景：
为满足建设银行及其客户的大数据建设需求，建行和偶数科技成立了高性能大数据联合实验室，结合金融、政府、互联网等行业的业务特征，合作开发出基于云原生数据库技术的湖仓一体方案，满足 ANCHOR 特性，支持存算分离、分布式事务处理、SQL 兼容性、云化弹性供给、Hadoop 生态、性能优化等关键特性，有效助力企业实现降成本、提性能、全融合的大数据建设目标。
案例价值：
支持将机构全量数据（结构化/半结构化/非结构化数据）清洗转换后统一存储于分布式存储 HDFS 和对象存储，支持对数据进行如数据切片、拉链处理等预处理，对外部提供近源数据的发布订阅功能，解决数据存储规模小、数据种类少、时间周期短等问题。
支持标准 SQL 语法，能够将数据整合为一套数据，减少重复存储，重复加工，通过建立统一数据指标与模型，提供一致的数据供应，提供多样的数据服务，让不同类型用户便捷使用数据。
建行通过湖仓一体技术的理论研究与工程实现，不仅能够使用同一套技术栈、统一存储进行数据湖及数据仓库的双重能力建设，有效解决集群规模扩展受限、大数据资源利用率低、一致性难保障、集群管理复杂等痛点。
2、美国第一资本 (Capital One)
案例背景：
据 CNBC 报道，美国是世界上信用卡欺诈最易发生的国家。对于金融机构来说，信用卡欺诈的威胁是长期存在的。
美国欺诈风险分布图，红色为高风险，蓝色为低风险
Capital One 基于长期实践的方法论 6W (What, Who, When, Where, Why, What-if) 总结出信用卡信息被泄露的各种情况，以及通过数据进行异常检测和识别欺诈的应对手段。例如远离实际位置用卡，地理空间检测被盗卡信息，以及确定欺诈行为的时间逻辑。但由于当下信用卡欺诈的攻击、响应和策略变化非常迅速，新的挑战不断出现。
1）欺诈行为更隐秘：检测欺诈最有效的方法是查看最终用户的全部行为。只看交易或订单是不够的，需要跟踪交易前后的事件。这最终会产生大量结构化和非结构化数据。
2）欺诈行为发生得更快：当下的欺诈实施和响应更快，利用机器学习系统实时更新可以在几毫秒内更新欺诈检测模型并预防攻击。
3）欺诈策略不断迭代：欺诈策略的调整更加迅速，凭人力难以察觉，而静态的规则引擎系统较难及时更新，需要利用机器学习适应不断变化的行为。
案例价值：
Capital One 使用 Databricks 湖仓一体，同时利用机器学习算法，在数据集上训练机器学习模型（包括信用卡交易数据、持卡人的卡信息和人口统计信息等），先于欺诈者动态地检测欺诈交易。利用 Capital One 存储在 Amazon S3 中的原始数据，用户可以通过 Databricks 快速无缝集成 S3 及其框架之间的交互，并通过 MLflow 大规模扩展机器学习模型训练、验证和部署。在 AWS 中的自定义集群上训练和验证模型，并使用 MLflow API 直接通过 SageMaker 部署。
写在最后：
通过理清历史发展的脉络，我们理解了湖仓一体的真正内涵，也注意到湖仓分体不但没有从数据平台层面消除数据孤岛，反而催生了更为复杂的基础架构。
每个新概念的诞生都离不开业务场景和技术的双重驱动，在概念落地时，难免会出现一些认知上的偏差和技术上的弯路。作为 2020 年出现的新技术，湖仓一体也才刚刚走过一年多的时间，探索者的不断尝试和试错正推动市场形成共识。
本文的初衷是让更多的人了解湖仓一体、读懂湖仓一体、实践湖仓一体，让更多的企业理解湖仓一体的价值与本质。随着企业数字化转型进入深水区，越来越多的企业视湖仓一体为数字变革的重要契机，希望企业和用户能够从嘈杂的市场环境中找到真正有利于自己的技术方案。
