数据仓库、数据湖、湖仓一体浅谈
一、数仓架构发展史
1.发展史
时代的变迁，生死的轮回，历史长河滔滔，没有什么是永恒的，只有变化才是不变的，技术亦是如此，当你选择互联网的那一刻，你就相当于乘坐了一个滚滚向前的时代列车，开往未知的方向，不论什么样的技术架构只有放在当前的时代背景下，才是有意义的，人生亦是如此。
时间就是一把尺子，它能衡量奋斗者前进的进程；时间就是一架天平，它能衡量奋斗者成果的重量；时间就是一架穿梭机，它能带我们遨游历史长河,今天我们看一下数仓架构的发展，来感受一下历史的变迁，回头看一下那些曾经的遗迹。准备好了吗 let's go!，在此之前我们先看一下，数据仓库在整个数据平台中的地位
开始之前，我们先上一张大图，先有一个大概的认知，从整体到局部从概括到具体，看一下导致机构变化的原因是什么，探究一下时代背景下的意义，我们顺便看一下什么是数仓
那么什么是数仓，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策，数据仓库在数据平台中的建设有两个环节：一个是数据仓库的构建，另外一个就是数据仓库的应用。
数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展 这就是架构升级的原因，其实就是外部环境变了，现有的体系不能满足当前的需求，既然找到了原因，我们就来欣赏一下历史长河中哪些闪亮的星
“我们正在从IT时代走向DT时代(数据时代)。IT和DT之间，不仅仅是技术的变革，更是思想意识的变革，IT主要是为自我服务，用来更好地自我控制和管理，DT则是激活生产力，让别人活得比你好”
——阿里巴巴董事局主席马云。
2.经典数仓
在开始之前，我们先说一点，其实数据仓库很早之前就有了，也就是说在离线数仓之前(基于大数据架构之前)，有很多传统的数仓技术，例如基于Teradata的数据仓库，只不过是数据仓库技术在大数据背景下发生了很多改变，也就是我们开始抛弃了传统构建数仓的技术，转而选择了更能满足当前时代需求的大数据技术而已，当然大数据技术并没有完整的、彻底的取代传统的技术实现，我们依然可以在很多地方看见它们的身影
经典数仓可以将数仓的数仓的不同分层放在不同的数据库中，也可以将不同的分层放在不同的数据库实例上，甚至是可以把不同的分层放在不同的机房
大数据技术改变了数仓的存储和计算方式，当然也改变了数仓建模的理念，例如经典数仓数据存储在mysql等关系型数据库上，大数据数仓存储在hadoop平台的hive中（实际上是HDFS中），当然也有其他的数仓产品比如TD、greenplum等。
3.离线数仓(离线大数据架构)
随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构。
随着数据量逐渐增大，事实表条数达到千万级，kettle等传统ETL工具逐渐变得不稳定，数据库等存储技术也面临着存储紧张，每天都陷入和磁盘的争斗中单表做拉链的任务的执行时间也指数级增加，这个时候存储我们开始使用HDFS而不是数据库；计算开始使用HIVE(MR)而不是传统数仓技术架构使用的kettle、Informatica 等ETL工具；
公司开始考虑重新设计数仓的架构，使用hadoop平台的hive做数据仓库，报表层数据保存在mysql中，使用tableau做报表系统，这样不用担心存储问题、计算速度也大大加快了。在此基础上，公司开放了hue给各个部门使用，这样简单的提数工作可以由运营自己来操作。使用presto可以做mysql、hive的跨库查询，使用时要注意presto的数据类型非常严格。
4.Lambda架构
后来随着网络技术、通信技术的发展，使得终端数据的实时上报传输成为可能，从而业务实系统发生变化，进而导致了我们对需求的时性要求的不断提高开始之前我们先看一下，网络技术和通信技术到底对我们的生活有什么样的影响
为了应对这种变化，开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，然后和离线计算进整合从而给用户一个完整的实时计算结果，这便是Lambda架构。
为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。
需要注意的是流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果（这仅仅是流处理引擎不完善做的折中），Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm，Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。
如果抛开上面的Merge 操作，那么Lambda架构就是两条完全不同处理流程，就像下面所示
存在的问题
同样的需求需要开发两套一样的代码，这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）·
实时链路和离线链路计算结果容易让人误解，昨天看到的数据和今天看到的数据不一致
下游处理复杂，需要整合实时和离线处理结果，这一部分往往是我们在呈现给用户之前就完成了的
5.Kappa架构
再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。当然这不要实现这一变化，还需要技术本身的革新——Flink，Flink 的出现使得Exactly-Once 和状态计算成为可能，这个时候实时计算的结果保证最终结果的准确性
Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构
Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。
Kappa架构的重新处理过程
选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如Kafka，可以保存全部历史数据,当然还有后面出现的Pulsar，以及专门解决实时输出存储的Pravega
当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。
当新作业赶上进度后，应用切换数据源，使用新产生的新结果表。停止老的作业，删除老的结果表。
存在的问题
Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补
Pravega(流式存储)
想要统一流批处理的大数据处理架构，其实对存储有混合的要求
对于来自序列旧部分的历史数据，需要提供高吞吐的读性能，即catch-up read对于来自序列新部分的实时数据，需要提供低延迟的 append-only 尾写 tailing write 以及尾读 tailing read
存储架构最底层是基于可扩展分布式云存储，中间层表示日志数据存储为 Stream 来作为共享的存储原语，然后基于 Stream 可以向上提供不同功能的操作:如消息队列，NoSQL，流式数据的全文搜索以及结合 Flink 来做实时和批分析。换句话说，Pravega 提供的 Stream 原语可以避免现有大数据架构中原始数据在多个开源存储搜索产品中移动而产生的数据冗余现象，其在存储层就完成了统一的数据湖。
提出的大数据架构，以 Apache Flink 作为计算引擎，通过统一的模型/API来统一批处理和流处理。以 Pavega 作为存储引擎，为流式数据存储提供统一的抽象，使得对历史和实时数据有一致的访问方式。两者统一形成了从存储到计算的闭环，能够同时应对高吞吐的历史数据和低延时的实时数据。同时 Pravega 团队还开发了 Flink-Pravega Connector，为计算和存储的整套流水线提供 Exactly-Once 的语义。
6.混合架构
前面介绍了Lambda架构与Kappa架构的含义及优缺点，在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。
Kappa架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。
还有就是Kappa这种以实时为主的架构设计，除了增加了计算难度，对资源提出了更改的要求之外，还增加了开发的难度，所以才有了下面的混合架构，可以看出这个架构的出现，完全是处于需求和处于现状考虑的
7.实时数仓
实时数仓不应该成为一种架构，只能说是是Kappa架构的一种实现方式，或者说是实时数仓是它的一种在工业界落地的实现，在Kappa架构的理论支持下，实时数仓主要解决数仓对数据实时化的需求，例如数据的实时摄取、实时处理、实时计算等
第一层DWD公共实时明细层 实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用
第二层DWS公共实时汇总层 以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入ADS，用于前端产品复杂的olap查询场景，满足自助分析；高度汇总层写入Hbase，用于前端比较简单的kv查询场景，提升查询性能，比如产出报表等
实时数仓的的实施关键点
- 端到端数据延迟、数据流量的监控
- 故障的快速恢复能力 数据的回溯处理理，系统⽀支持消费指定时间端内的数据
- 实时数据从实时数仓中查询，T+1数据借助离线通道修正
- 数据地图、数据⾎血缘关系的梳理理
- 业务数据质量的实时监控，初期可以根据规则的⽅方式来识别质量状况
数据保障
- 集团每年都有双十一等大促，大促期间流量与数据量都会暴增。实时系统要保证实时性，相对离线系统对数据量要更敏感，对稳定性要求更高
- 所以为了应对这种场景，还需要在这种场景下做两种准备： 1.大促前的系统压测； 2.大促中的主备链路保障
8.数据湖
最开始的时候，每个应用程序会产生、存储大量数据，而这些数据并不能被其他应用程序使用，这种状况导致数据孤岛的产生。随后数据集市应运而生，应用程序产生的数据存储在一个集中式的数据仓库中，可根据需要导出相关数据传输给企业内需要该数据的部门或个人，然而数据集市只解决了部分问题。剩余问题，包括数据管理、数据所有权与访问控制等都亟须解决，因为企业寻求获得更高的使用有效数据的能力。
为了解决前面提及的各种问题，企业有很强烈的诉求搭建自己的数据湖，数据湖不但能存储传统类型数据，也能存储任意其他类型数据(文本、图像、视频、音频)，并且能在它们之上做进一步的处理与分析，产生最终输出供各类程序消费。而且随着数据多样性的发展，数据仓库这种提前规定schema的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是schema on write，数据湖模式是schema on read
9.总结
Kappa对比Lambda架构
在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。
这两个架构都是实时架构，都是对离线架构的扩展
实时数仓与离线数仓的对比
离线数据仓库主要基于sqoop、hive等技术来构建T+1的离线数据，通过定时任务每天拉取增量量数据导⼊到hive表中，然后创建各个业务相关的主题维度数据，对外提供T+1的数据查询接口
实时数仓当前主要是基于实时数据采集工具，如canal等将原始数据写⼊入到Kafka这样的数据通道中，最后⼀一般都是写 入到类似于HBase这样存储系统中，对外提供分钟级别、甚⾄至秒级别的查询⽅方案。
二、数据仓库分层概念
1.ODS
- ODS层最好理解，基本上就是数据从源表拉过来，进行etl，比如mysql 映射到hive，那么到了hive里面就是ods层。
- ODS 全称是 Operational Data Store，操作数据存储.“面向主题的”，数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪(例如有一条数据中人的年龄是 300 岁，这种属于异常数据，就需要提前做一些处理)、去重(例如在个人资料表中，同一 ID 却有两条重复数据，在接入的时候需要做一步去重)、字段命名规范等一系列操作。
2.数据仓库层DW
数据仓库层(DW)，是数据仓库的主体.在这里，从 ODS 层中获得的数据按照主题建立各种数据模型。这一层和维度建模会有比较深的联系。
细分：
- 数据明细层：DWD（Data Warehouse Detail）
- 数据中间层：DWM（Data WareHouse Middle）
- 数据服务层：DWS（Data WareHouse Servce）
（1）DWD明细层
明细层(ODS, Operational Data Store,DWD: data warehouse detail)
- 概念：是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细层跟stage层的粒度一致，属于分析的公共资源
- 数据生成方式：部分数据直接来自kafka，部分数据为接口层数据与历史数据合成。
- 这个stage层不是很清晰
（2）DWM 轻度汇总层(MID或DWB, data warehouse basis)
- 概念：轻度汇总层数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满足一些不可预见的需求而进行沉淀;轻度综合层则面向分析型应用进行细粒度的统计和沉淀
- 数据生成方式：由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
- 日志存储方式：内表，parquet文件格式。
- 日志删除方式：长久存储。
- 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
- 库与表命名。库名：dwb,表名：初步考虑格式为：dwb日期业务表名,待定。
- 旧数据更新方式：直接覆盖
（3）DWS 主题层(DM，data market或DWS, data warehouse service)
- 概念：又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
- 数据生成方式：由轻度汇总层和明细层数据计算生成。
- 日志存储方式：使用impala内表，parquet文件格式。
- 日志删除方式：长久存储。
- 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
- 库与表命名。库名：dm,表名：初步考虑格式为：dm日期业务表名,待定。
- 旧数据更新方式：直接覆盖
2.APP
数据产品层(APP)，这一层是提供为数据产品使用的结果数据。
主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、Mysql 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。
如我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
应用层(App)
- 概念：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用。
- 数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。
- 日志存储方式：使用impala内表，parquet文件格式。
- 日志删除方式：长久存储。
- 表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
- 库与表命名。库名：暂定apl，另外根据业务不同，不限定一定要一个库。(其实就叫app_)就好了
- 旧数据更新方式：直接覆盖。
4.数据的来源
数据主要会有两个大的来源：
业务库，这里经常会使用 Sqoop 来抽取
我们业务库用的是databus来进行接收，处理kafka就好了。
在实时方面，可以考虑用 Canal 监听 Mysql 的 Binlog，实时接入即可。(有机会补一下这个canal)
埋点日志，线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用 Flume 定时抽取，也可以用用 Spark Streaming 或者 Storm 来实时接入，当然，Kafka 也会是一个关键的角色。
还有使用filebeat收集日志，打到kafka，然后处理日志
注意： 在这层，理应不是简单的数据接入，而是要考虑一定的数据清洗，比如异常字段的处理、字段命名规范化、时间字段的统一等，一般这些很容易会被忽略，但是却至关重要。特别是后期我们做各种特征自动生成的时候，会十分有用。
5.ODS、DW → App层
这里面也主要分两种类型：
- 每日定时任务型：比如我们典型的日计算任务，每天凌晨算前一天的数据，早上起来看报表。 这种任务经常使用 Hive、Spark 或者生撸 MR 程序来计算，最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
- 实时数据：这部分主要是各种实时的系统使用，比如我们的实时推荐、实时用户画像，一般我们会用 Spark Streaming、Storm 或者 Flink 来计算，最后会落入 Es、Hbase 或者 Redis 中。
6.维表层DIM
维表层（Dimension）
最后补充一个维表层，维表层主要包含两部分数据：
高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万
7.层级的简单分层图
见下图，对DWD层在进行加工的话，就是DWM层（MID层）(我们的数仓还是有很多dwm层的)
这里解释一下DWS、DWD、DIM和TMP的作用。
- DWS：轻度汇总层，从ODS层中对用户的行为做一个初步的汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度做一些统计值，比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效，在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算，而不是ODS。
- DWD：这一层主要解决一些数据质量问题和数据的完整度问题。比如用户的资料信息来自于很多不同表，而且经常出现延迟丢数据等问题，为了方便各个使用方更好的使用数据，我们可以在这一层做一个屏蔽。（汇总多个表）
- DIM：这一层比较单纯，举个例子就明白，比如国家代码和国家名、地理位置、中文名、国旗图片等信息就存在DIM层中。
- TMP：每一层的计算都会有很多临时表，专设一个DWTMP层来存储我们数据仓库的临时表。
总结
三、数据仓库、数据湖、湖仓一体
（一）数据仓库
数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。
早期系统采用关系型数据库来存放管理数据，但是随着大数据技术的兴起，人们对于多方面数据进行分析的需求愈加强烈，这就要求建立一个能够面向分析、集成保存大量历史数据的新型管理机制，这一机制就是数据仓库。
数据仓库通常存储来自不同源的数据，集成源数据以提供统一的视图。这些资源可以包括事务系统、应用程序日志文件、关系数据库等等。
数据仓库的特征
数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。这个定义有些复杂并且难以理解，针对定义中的关键词，我们分别来看看数据仓库所具备的特点。
- 数据仓库的数据是面向主题的
与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。在较高层次上完整、统一地刻划各个分析对象所涉及的企业各项数据，以及数据之间的联系。 - 数据仓库的数据是集成的
数据仓库的数据是从原有的分散的数据库数据中抽取得来。数据进入数据仓库之前，必然要经过统一与综合处理。 - 数据仓库的数据是随时间不断变化的
为了发现业务变化的趋势、存在的问题，或者新的机会，需要分析大量的历史数据。换句话说，数据仓库中的数据是反映了某一历史时间点的数据快照，这也就是术语“随时间变化”的含义。同时，在从数据集成输入数据仓库开始到最终被删除，数据又是有生存周期的。 - 数据仓库的数据是非易失的
非易失指的是，一旦进入到数据仓库中，数据就不应该再有改变。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。
（二）数据湖
随着当前大量信息化发展和电子设备产品普及，产生大量的照片、视频、文档等非结构化数据，人们也想通过大数据技术找到这些数据的关系。随之而来的数据湖就产生了。
数据湖的概念首次于2010年被James Dixon在其博客帖子（Pentaho, Hadoop, and Data Lakes | James Dixon’s Blog）中提及 ：
如果将数据集市视为瓶装水的商店——经过清洁、包装和结构化以便于饮用——那么数据湖就是处于更自然状态的一大片水体。数据湖的内容从源头流入，填满湖，湖的各种用户可以来检查、潜入或取样。
维基百科对数据湖的定义是：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。
也就是说，数据湖中的数据在从源获取时不受数据结构的约束，在需要时应用“读取”模式来促进数据分析。数据湖的本质，是由“数据存储架构+数据处理工具”组成的解决方案，而不是某个单一独立产品。
数据湖的特征
数据湖具有以下特点：
- 容量大
数据湖汇聚吸收各个业务数据源流，容纳散落在各处的数据，理论上，存储空间巨大。 - 格式多
数据湖架构面向多数据源的信息存储，可以快速高效地采集、存储、处理大量来源不同、格式不同的原始数据，这其中包括文本、图片、视频、音频、网页等各类无序的非结构化数据，能把不同种类的数据汇聚存储在一起，并对汇聚后的数据进行管理，建立数据之间的关联关系，具有很强的兼容性。 - 处理速度快
数据湖技术能将各类原始数据快速转化为可以直接提取的、分析、使用的标准格式，统一优化数据结构并对数据进行分类存储，根据业务需求，对存储的数据进行快速的查询、挖掘、关联和处理，并实时传输给末端用户。 - 体系结构
由于Hadoop也能基于分布式文件系统来存储处理多类型数据，因此许多人认为Hadoop的工作机理就是数据湖的处理机制。当然，Hadoop基于其分布式、可横向扩展的文件系统架构，可以管理和处理海量数据，但是它无法提供数据湖所需要的复杂元数据管理功能，最直观的表现是，数据湖的体系结构表明数据湖是由多个组件构成的生态系统，而Hadoop仅仅提供了其中的部分组件功能。
数据仓库和数据湖的对比
| 数据仓库 | 数据湖 | |
| 数据 | 来自事务系统、运营数据库和业务线应用程序的关系数据 | 来自 IoT设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据 |
| 模式 | 写时模式，数据写入前已经定义好schema，更改schema成本较高 | 读时模式，数据在利用的时候再定义schema，灵活方便 |
| 使用思维 | 先有报表需求，根据报表确定数仓shcema，然后通过ETL过程将数据导入 | 并不需要根据需求来开发数据业务，数据集中存储，需要的时候再利用。保留了数据的完整性 |
| 存储容量 | 数据仓库对存储的数据更有选择性，一般比数据湖要小，但与传统数据库相比仍然很大 | 由于包含所有数据，通常是PB级别的 |
| 性价比 | 起步成本高，使用本地存储以获得最快查询结果 | 起步成本低，计算存储分离 |
| 产品形态 | 数据仓库可以是独立的标准化产品 | 数据湖则是一种架构，通常是围绕对象存储为“湖底座”的大数据管理方案组合 |
| 用户 | 结构化数据，使用非常方便，主要的使用对象是数据分析师、数据工程师、运营人员等等。 | 作为原始数据，非结构化数据的数据库，数据湖的主要使用对象是数据科学家。 |
从数据含金量来比，数据仓库里的数据价值密度更高一些，数据的抽取和Schema的设计，都有非常强的针对性，便于业务分析师迅速获取洞察结果，用与决策支持。
而数据湖更有一种“兜底”的感觉，甭管当下有用没有/或者暂时没想好怎么用，先保存着、沉淀着，将来想用的时候，尽管翻牌子就是了，反正都原汁原味的留存了下来。
（三）湖仓一体
数据湖虽然适合数据的存储，但又缺少一些关键功能，比如不支持事务、缺乏一致性/隔离性、不保证执行数据质量等，这样的短板决定了，让数据湖来承载读写访问、批处理、流作业是不现实的。而且，数据湖缺乏结构性，一旦没有被治理好，就会变成数据沼泽。
既然都是拿数据为业务服务，数据湖和数仓作为两大“数据集散地”，能不能彼此整合一下，让数据流动起来，少点重复建设呢？，于是，Databricks率先提出了湖仓一体（Data Lakehouse）的概念。
湖仓一体是一种结合了数据湖灵活性和数据仓库规范性优势的新范式，在基于数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。
Data Lakehouse的概念是由Databricks提出的，其联合创始人兼首席执行官 Ali Ghodsi 说：“从长远来看，所有数据仓库都将被纳入数据湖仓，这不会在一夜之间发生——这些东西会共存一段时间——但这个官方的世界纪录清楚地证明，在价格和性能上，数据湖仓完胜数据仓库。”
现在大多数企业都还没有用到湖仓一体的新架构，他们要么选择了数据湖方案，要么选择了数仓方案。但大方向之下，特别是随着 AI 的兴起，完全纯数仓的二维关系表已经无法承接半 / 非结构化数据的处理，AI 引擎不可能只跑在纯数仓模型上。所以湖仓一体一定是未来的发展趋势。
湖仓一体的特征
- 事务支持：Lakehouse可以处理多条不同的数据管道。这意味着它可以在不破坏数据完整性的前提下支持并发的读写事务。
- Schemas：数仓会在所有存储其上的数据上施加Schema，而数据湖则不会。Lakehouse的架构可以根据应用的需求为绝大多数的数据施加schema，使其标准化。
- 报表以及分析应用的支持：报表和分析应用都可以使用这一存储架构。Lakehouse里面所保存的数据经过了清理和整合的过程，它可以用来加速分析。同时相比于数仓，它能够保存更多的数据，数据的时效性也会更高，能显著提升报表的质量。
- 数据类型扩展：数仓仅可以支持结构化数据，而Lakehouse的结构可以支持更多不同类型的数据，包括文件、视频、音频和系统日志。
- 端到端的流式支持：Lakehouse可以支持流式分析，从而能够满足实时报表的需求，实时报表在现在越来越多的企业中重要性在逐渐提高。
- 计算存储分离：我们往往使用低成本硬件和集群化架构来实现数据湖，这样的架构提供了非常廉价的分离式存储。Lakehouse是构建在数据湖之上的，因此自然也采用了存算分离的架构，数据存储在一个集群中，而在另一个集群中进行处理。
开放性：Lakehouse在其构建中通常会使Iceberg，Hudi，Delta Lake等构建组件，首先这些组件是开源开放的，其次这些组件采用了Parquet，ORC这样开放兼容的存储格式作为下层的数据存储格
湖仓一体的优势
- 减少数据冗余：如果一个组织同时维护了一个数据湖和多个数据仓库，这无疑会带来数据冗余。在最好的情况下，这仅仅只会带来数据处理的不高效，但是在最差的情况下，它会导致数据不一致的情况出现。湖仓一体的结合，能够去除数据的重复性，真正做到了唯一。
- 降低存储成本：数据仓库和数据湖都是为了降低数据存储的成本。数据仓库往往是通过降低冗余，以及整合异构的数据源来做到降低成本。而数据湖则往往使用大数据文件系统和Spark在廉价的硬件上存储计算数据。湖仓一体架构的目标就是结合这些技术来最大力度降低成本。
- 拉通数据应用团队：数据科学倾向于与数据湖打交道，使用各种分析技术来处理未经加工的数据。而报表分析师们则倾向于使用整合后的数据，比如数据仓库或是数据集市。而在一个组织内，往往这两个团队之间没有太多的交集，但实际上他们之间的工作又有一定的重复和矛盾。而当使用湖仓一体架构后，两个团队可以在同一数据架构上进行工作，避免不必要的重复。
- 避免数据沼泽：在数据湖中，数据停滞是一个最为严重的问题，如果数据一直无人治理，那将很快变为数据沼泽。我们往往轻易的将数据丢入湖中，但缺乏有效的治理，长此以往，数据的时效性变得越来越难追溯。湖仓一体的引入，对于海量数据进行治理，能够更有效地帮助提升分析数据的时效性。
- 预防兼容风险：数据分析仍是一门兴起的技术，新的工具和技术每年仍在不停地出现中。一些技术可能只和数据湖兼容，而另一些则又可能只和数据仓库兼容。湖仓一体的架构意味着为两方面做准备。
智能湖仓
把数据湖和数据仓库集成起来只是第一步，还要把湖、仓以及所有其他数据处理服务组成统一且连续的整体，这就是Amazon Web Services提出的“智能湖仓”。
智能湖仓并非单一产品，它描述的是一种架构。
这套架构，以数据湖为中心，把数据湖作为中央存储库，再围绕数据湖建立专用“数据服务环”，环上的服务包括了数仓、机器学习、大数据处理、日志分析，甚至RDS和NOSQL服务等等。
大家“环湖而饲”，既可以直接操纵湖内数据，也可以从湖中摄取数据，还可以向湖中回注数据，同时环湖的服务彼此之间也可以轻松交换数据。
数据仓库、数据湖、湖仓一体对比
最后引用《DataFunCon 2021》大会上的一张图片总结数仓、数据湖和湖仓一体之间区别。
