共计 13910 个字符，预计需要花费 35 分钟才能阅读完成。
引言：随着企业数字化转型进入深水区，越来越多的企业视湖仓一体为数字改革的重要契机，湖仓一体也受到了前所未有的关注。当然，关注度越高市场上的声音也就越嘈杂，很多过期甚至谬误的湖仓一体技术和理念不翼而飞，很有可能将转型中的企业引入歧途，推高数据孤岛，造成资源节约甚至错过数字化转型的策略机会。伪湖仓一体天然是咱们不愿看到的，而想要了解什么是真正的湖仓一体，则须要对技术背景及其演进历程有清晰的认知，当然这对少数读者都很挑战，因而笔者尝试从技术背景和倒退脉络的角度给出湖仓一体的终极答案。一、从数据仓库说起 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 年呈现的新技术，湖仓一体也才刚刚走过一年多的工夫，探索者的一直尝试和试错正推动市场造成共识。本文的初衷是让更多的人理解湖仓一体、读懂湖仓一体、实际湖仓一体，让更多的企业了解湖仓一体的价值与实质。随着企业数字化转型进入深水区，越来越多的企业视湖仓一体为数字改革的重要契机，心愿企业和用户可能从嘈杂的市场环境中找到真正有利于本人的技术计划。
