数据湖VS数据仓库之争？阿里提出大数据架构新概念：湖仓一体

1. 数据保持高速增长- 从5V核心要素看，大数据领域保持高速增长。阿里巴巴经济体，作为一个重度使用并着力发展大数据领域的公司，过去5年数据规模保持高速增长（年化60%-80%），增速在可见的未来继续保持。对于新兴企业，大数据领域增长超过年200%。
2. 大数据作为新的生产要素，得到广泛认可- 大数据领域价值定位的迁移，从“探索”到“普惠”，成为各个企业/政府的核心部门，并承担关键任务。还是以阿里巴巴为例，30%的员工直接提交大数据作业。随大数据普惠进入生产环境，可靠性、安全性、管控能力、易用性等企业级产品力增强。
3. 数据管理能力成为新的关注点- 数仓（中台）能力流行起来，如何用好数据成为企业的核心竞争力。
4. 引擎技术进入收敛期 - 随着Spark（通用计算）、Flink（流计算）、Hbase（KV）、Presto（交互分析）、ElasticSearch（搜索）、Kafka（数据总线）自从2010-2015年逐步占领开源生态，最近5年新引擎开源越来越少，但各引擎技术开始向纵深发展（更好的性能、生产级别的稳定性等）。
5. 平台技术演进出两个趋势，数据湖 VS 数据仓库- 两者均关注数据存储和管理（平台技术），但方向不同。

• 阶段一：数据库时代

• 阶段二：大数据技术的「探索期」

• 阶段三：大数据技术的「发展期」

• 阶段四：大数据技术「普及期」

• 开源 Hadoop 线，引擎、元数据、存储等基础部件的迭代更替进入相对稳态，大众对开源大数据技术的认知达到空前的水平。一方面，开放架构的便利带来了不错的市场份额，另一方面开放架构的松散则使开源方案在企业级能力构建上遇到瓶颈，尤其是数据安全、身份权限强管控、数据治理等方面，协同效率较差（如 Ranger 作为权限管控组件、Atlas 作为数据治理组件，跟今天的主流引擎竟然还无法做到全覆盖）。同时引擎自身的发展也对已有的开放架构提出了更多挑战，Delta Lake、Hudi 这样自闭环设计的出现使得一套存储、一套元数据、多种引擎协作的基础出现了某种程度的裂痕。
• 真正将数据湖概念推而广之的是AWS。AWS 构筑了一套以 S3 为中心化存储、Glue 为元数据服务，E-MapReduce、Athena 为引擎的开放协作式的产品解决方案。它的开放性和和开源体系类似，并在2019年推出Lake Formation 解决产品间的安全授信问题。虽然这套架构在企业级能力上和相对成熟的云数据仓库产品相去甚远，但对于开源技术体系的用户来说，架构相近理解容易，还是很有吸引力。AWS 之后，各个云厂商也纷纷跟进数据湖的概念，并在自己的云服务上提供类似的产品解决方案。
• 云厂商主推的数据仓库类产品则发展良好，数仓核心能力方面持续增强。性能、成本方面极大提升（MaxCompute 完成了核心引擎的全面升级和性能跳跃式发展，连续三年刷新 TPCx-BigBench 世界记录），数据管理能力空前增强（数据中台建模理论、智能数仓），企业级安全能力大为繁荣（同时支持基于 ACL 和基于规则等多种授权模型，列级别细粒度授权，可信计算，存储加密，数据脱敏等），在联邦计算方面也普遍做了增强，一定程度上开始将非数仓自身存储的数据纳入管理，和数据湖的边界日益模糊。

A data lake is a system or repository of datastored in its natural/raw format,usually object blobsor files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analyticsand machine learning. A data lake can include structured datafrom relational databases(rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data(emails, documents, PDFs) and binary data(images, audio, video). A data lake can be established "on premises" (within an organization's data centers) or "in the cloud" (using cloud services from vendors such as Amazon, Google and Microsoft).A data swamp is a deteriorated and unmanaged data lake that is either inaccessible to its intended users or is providing little value.

数据湖是指使用大型二进制对象或文件这样的自然格式储存数据的系统。它通常把所有的企业数据统一存储，既包括源系统中的原始副本，也包括转换后的数据，比如那些用于报表, 可视化, 数据分析和机器学习的数据。数据湖可以包括关系数据库的结构化数据(行与列)、半结构化的数据(CSV，日志，XML, JSON)，非结构化数据 (电子邮件、文件、PDF)和 二进制数据(图像、音频、视频)。储存数据湖的方式包括 Apache Hadoop分布式文件系统， Azure 数据湖或亚马逊云 Lake Formation云存储服务，以及诸如 Alluxio 虚拟数据湖之类的解决方案。数据沼泽是一个劣化的数据湖，用户无法访问，或是没什么价值。

A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

1. 统一的存储系统
2. 存储原始数据
3. 丰富的计算模型/范式
4. 数据湖与上云无关

• 帮助用户摆脱原生HDFS系统运维困难的问题。HDFS系统运维有两个困难：1）存储系统相比计算引擎更高的稳定性要求和更高的运维风险 2）与计算混布在一起，带来的扩展弹性问题。存储计算分离架构帮助用户解耦存储，并交由云厂商统一运维管理，解决了稳定性和运维问题。
• 分离后的存储系统可以独立扩展，不再需要与计算耦合，可降低整体成本
• 当用户采用数据湖架构之后，客观上也帮助客户完成了存储统一化（解决多个HDFS数据孤岛的问题）

In computing, a data warehouse (DW or DWH), also known as an enterprise data warehouse (EDW), is a system used for reportingand data analysis, and is considered a core component of business intelligence.DWs are central repositories of integrated data from one or more disparate sources. Extract, transform, load(ETL) and extract, load, transform(E-LT) are the two main approaches used to build a data warehouse system.

在计算机领域，数据仓库（英语：data warehouse，也称为企业数据仓库）是用于报告和数据分析的系统，被认为是商业智能的核心组件。数据仓库是来自一个或多个不同源的集成数据的中央存储库。数据仓库将当前和历史数据存储在一起，用于为整个企业的员工创建分析报告。比较学术的解释是，数据仓库由数据仓库之父W.H.Inmon于1990年提出，主要功能乃是将组织透过信息系统之在线交易处理(OLTP)经年累月所累积的大量数据，透过数据仓库理论所特有的数据存储架构，作一有系统的分析整理，以利各种分析方法如在线分析处理(OLAP)、数据挖掘(Data Mining)之进行，并进而支持如决策支持系统(DSS)、主管信息系统(EIS)之创建，帮助决策者能快速有效的自大量数据中，分析出有价值的信息，以利决策拟定及快速回应外在环境变动，帮助建构商业智能(BI)。

1. 内置的存储系统，数据通过抽象的方式提供（例如采用Table或者View），不暴露文件系统。
2. 数据需要清洗和转化，通常采用ETL/ELT方式
3. 强调建模和数据管理，供商业智能决策

1. 引擎深度理解数据，存储和计算可做深度优化
2. 数据全生命周期管理，完善的血缘体系
3. 细粒度的数据管理和治理
4. 完善的元数据管理能力，易于构建企业级数据中台

1. 当企业处于初创阶段，数据从产生到消费还需要一个创新探索的阶段才能逐渐沉淀下来，那么用于支撑这类业务的大数据系统，灵活性就更加重要，数据湖的架构更适用。
2. 当企业逐渐成熟起来，已经沉淀为一系列数据处理流程，问题开始转化为数据规模不断增长，处理数据的成本不断增加，参与数据流程的人员、部门不断增多，那么用于支撑这类业务的大数据系统，成长性的好坏就决定了业务能够发展多远。数据仓库的架构更适用。

• 2017年Redshift推出Redshift Spectrum，支持Redsift数仓用户访问S3数据湖的数据。
• 2018年阿里云MaxCompute推出外表能力，支持访问包括OSS/OTS/RDS数据库在内的多种外部存储。

• 2011年，Hadoop开源体系公司Hortonworks开始了Apache Atlas和Ranger两个开源项目的开发，分别对应数据血缘追踪和数据权限安全两个数仓核心能力。但两个项目发展并不算顺利，直到 2017 年才完成孵化，时至今日，在社区和工业界的部署都还远远不够活跃。核心原因数据湖与生俱来的灵活性。例如Ranger作为数据权限安全统一管理的组件，天然要求所有引擎均适配它才能保证没有安全漏洞，但对于数据湖中强调灵活的引擎，尤其是新引擎来说，会优先实现功能、场景，而不是把对接Ranger作为第一优先级的目标，使得Ranger在数据湖上的位置一直很尴尬。
• 2018年，Nexflix开源了内部增强版本的元数据服务系统Iceberg，提供包括MVCC（多版本并发控制）在内的增强数仓能力，但因为开源HMS已经成为事实标准，开源版本的Iceberg作为插件方式兼容并配合HMS，数仓管理能力大打折扣。
• 2018-2019年，Uber和Databricks相继推出了Apache Hudi和DeltaLake，推出增量文件格式用以支持Update/Insert、事务等数据仓库功能。新功能带来文件格式以及组织形式的改变，打破了数据湖原有多套引擎之间关于共用存储的简单约定。为此，Hudi为了维持兼容性，不得不发明了诸如 Copy-On-Write、Merge-On-Read 两种表，Snapshot Query、Incremental Query、Read Optimized Query 三种查询类型，并给出了一个支持矩阵（如图10），极大提升了使用的复杂度。

1. 湖和仓的数据/元数据无缝打通，且不需要用户人工干预
2. 湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作
3. 数据湖与数据仓库的数据，系统负责自动caching/moving，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化

• MaxCompute全新自创PrivateAccess网络连通技术，在遵循云虚拟网络安全标准的前提下，实现多租户模式下特定用户作业定向与IDC/ECS/EMR Hadoop集群网络整体打通能力，具有低延迟、高独享带宽的特点。
• 经过快速简单的开通、安全配置步骤即可将数据湖和购买的 MaxCompute数仓相连通。

• MaxCompute实现湖仓一体化的元数据管理，通过DB元数据一键映射技术，实现数据湖和MaxCompute数仓的元数据无缝打通。MaxCompute通过向用户开放创建external project的形式，将数据湖HiveMetaStore中的整个database直接映射为MaxCompute的project，对Hive Database的改动会实时反应在这个project中，并可以在MaxCompute侧随时通过这个project进行访问、计算其中的数据。与此同时，阿里云EMR数据湖解决方案也将推出Data Lake Formation，MaxCompute湖仓一体方案也会支持对该数据湖中的统一元数据服务的一键映射能力。MaxCompute侧对external project的各种操作，也会实时反应在Hive侧，真正实现数据仓库和数据湖之间的无缝联动，完全不需要类似联邦查询方案里的元数据人工干预步骤。
• MaxCompute实现湖仓一体化的存储访问层，不仅支持内置优化的存储系统，也无缝的支持外部存储系统。既支持HDFS数据湖，也支持OSS云存储数据湖，可读写各种开源文件格式。

• 数据湖里的Hive DataBase映射为MaxCompute external project，和普通project别无二致，同样享受MaxCompute数仓里的数据开发、追踪和管理功能。基于DataWorks强大的数据开发/管理/治理能力，提供统一的湖仓开发体验，降低两套系统的管理成本。
• MaxCompute高度兼容Hive/Spark，支持一套任务可以在湖仓两套体系中灵活无缝的运行。
• 同时，MaxCompute也提供高效的数据通道接口，可以让数据湖中的Hadoop生态引擎直接访问，提升了数仓的开放性。

• 湖仓一体需要用户根据自身资产使用情况将数据在湖和仓之间进行合理的分层和存储，以最大化湖和仓的优势。MaxCompute开发了一套智能cache技术，根据对历史任务的分析来识别数据冷热度，从而自动利用闲时带宽将数据湖中的热数据以高效文件格式cache在数据仓库中，进一步加速数据仓库的后续数据加工流程。不仅解决了湖仓之间的带宽瓶颈问题，也达到了无须用户参与即可实现数据分层管理/治理以及性能加速的目的。

• 案例背景

• 核心痛点

1. 安排专人专项负责训练数据同步，工作量巨大
2. 训练数据体量大，导致耗时多，无法满足实时训练的要求
3. 新写SQL数据处理query，无法复用Hive SQL原有query

• 解决方案

• 案例价值

• 不仅融合了数据湖和数据仓库的优势，在灵活性和效率上找到最佳平衡，还快速构建了一套统一的AI计算中台，极大提升该机器学习平台团队的业务支撑能力。无须进行数据搬迁和作业迁移，即可将一套作业无缝灵活调度在MaxCompute集群和EMR集群中。
• SQL数据处理任务被广泛运行到MaxCompute集群，性能有明显提升。基于阿里巴巴PAI丰富且强大的算法能力，封装出多种贴近业务场景的算法服务，满足更多的业务需求。
• MaxCompute云原生的弹性资源和EMR集群资源形成互补，两套体系之间进行资源的削峰填谷，不仅减少作业排队，且降低整体成本。