三、具体区别
1. 数据仓库 VS 数据湖
相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们一致认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比，数据湖缺乏结构性，而且更灵活，并且提供了更高的敏捷性。值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。
2. 数据仓库 VS 数据中台
数据仓库和传统的数据平台，其出发点为一个支撑性的技术系统，即一定要先考虑我具有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理；而数据中台的第一出发点不是数据而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。
在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT结构转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。
3. 总结
根据以上数据仓库、数据湖和数据中台的概念论述和对比，我们进行如下总结：
- 数据中台、数据仓库和数据湖没有直接的关系；
- 数据中台、数据仓库和数据湖在某个维度上为业务产生价值的形式有不同的侧重；
- 数据中台是企业级的逻辑概念，体现企业数据向业务价值转化的能力，为业务提供服务的主要方式是数据 API；
- 数据仓库是一个相对具体的功能概念，是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表；
- 数据中台距离业务更近，能够更快速的响应业务和应用开发需求，从而为业务提供速度更快的服务；
- 数据仓库是为了支持管理决策分析，而数据中台则是将数据服务化之后提供给业务系统，不仅限于分析型场景，也适用于交易型场景；
- 数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。
四、湖仓一体
有人说“湖仓一体成为下一站灯塔，数仓、数据湖架构即将退出群聊”。
2020年，大数据DataBricks公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，此概念一出各路云厂商纷纷跟进。
Data Lakehouse（湖仓一体）是新出现的一种数据架构，它同时吸收了数据仓库和数据湖的优势，数据分析师和数据科学家可以在同一个数据存储中对数据进行操作，同时它也能为公司进行数据治理带来更多的便利性。
1. 目前数据存储的方案
一直以来，我们都在使用两种数据存储方式来架构数据：
- 数据仓库：主要存储的是以关系型数据库组织起来的结构化数据。数据通过转换、整合以及清理，并导入到目标表中。在数仓中，数据存储的结构与其定义的schema是强匹配的。
- 数据湖：存储任何类型的数据，包括像图片、文档这样的非结构化数据。数据湖通常更大，其存储成本也更为廉价。存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上。相反的是，数据的拥有者通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上。
现在许多的公司往往同时会搭建数仓、数据湖这两种存储架构，一个大的数仓和多个小的数据湖。这样，数据在这两种存储中就会有一定的冗余。
2. Data Lakehouse（湖仓一体）
Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。
下面详细解释下：
湖仓一体（Data Lakehouse）：
依据DataBricks公司对Lakehouse 的定义：一种结合了数据湖和数据仓库优势的新范式，解决了数据湖的局限性。Lakehouse 使用新的系统设计：直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。
解释拓展：
湖仓一体，简单理解就是把面向企业的数据仓库技术与数据湖存储技术相结合，为企业提供一个统一的、可共享的数据底座。
避免传统的数据湖、数据仓库之间的数据移动，将原始数据、加工清洗数据、模型化数据，共同存储于一体化的“湖仓”中，既能面向业务实现高并发、精准化、高性能的历史数据、实时数据的查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。
湖仓一体方案的出现，帮助企业构建起全新的、融合的数据平台。通过对机器学习和AI算法的支持，实现数据湖+数据仓库的闭环，提升业务的效率。数据湖和数据仓库的能力充分结合，形成互补，同时对接上层多样化的计算生态。
Lakehouse有如下关键特性：
- 事物支持：Lakehouse 在企业级应用中，许多数据管道通常会同时读取和写入数据。通常多方同时使用 SQL 读取或写入数据，Lakehouse 保证支持ACID事务的一致性。
- 模式实施和治理：Lakehouse 应该有一种支持模式实施和演变的方法，支持 DW 模式规范，例如 star /snowflake-schemas。该系统应该能够推理数据完整性，并且应该具有健壮的治理和审核机制。
- BI支持：Lakehouse 可以直接在源数据上使用BI工具。这样可以减少陈旧度和等待时间，提高新近度，并且降低必须在数据湖和仓库中操作两个数据副本的成本。
- 存储与计算分离：事实上，这意味着存储和计算使用单独的群集，因此这些系统能够扩展到更多并发用户和更大数据量。一些现代数据仓库也具有这种属性。
- 兼容性：Lakehouse 使用的存储格式是开放式和标准化的，例如 Parquet，并且它提供了多种 API，包括机器学习和 Python/R 库，因此各种工具和引擎都可以直接有效地访问数据。
- 支持从非结构化数据到结构化数据的多种数据类型：Lakehouse 可用于存储，优化，分析和访问许多新数据应用程序所需的数据类型，包括图像，视频，音频，半结构化数据和文本。
- 支持各种工作场景：包括数据科学，机器学习和 SQL 分析。这些可能依赖于多种工具来支持的工作场景，它们都依赖于相同的数据存储库。
- 端到端流式任务：实时报告是许多企业的日常需要。对流处理的支持消除了对专门服务于实时数据应用程序的单独系统的需求。
上面这张图是DataBricks给出的架构演化参考图。
我们可以看到，传统的数仓目标非常明确，适用于将各业务数据源合并后，进行商务BI分析和报表。随着企业需要处理的数据类型越来越多，包括客户行为，IoT，图片，视频等， 数据规模也成指数增加。
数据湖技术被引入，并用于承担通用数据存储和处理平台的作用，数据湖由于其分布式存储和计算能力的特点，也可以更好的支持机器学习计算， 在数据湖时代，我们通常可以看到DataLake和Data Warehouse还是会同时存在的。
随着大数据时代的到来，是不是有可能让大数据技术可以取代传统数仓，形成一个统一的数据处理架构，湖仓一体的概念被提出，并由DataBricks和云厂商们在进行快速的推演和实践。
