对大数据提供服务的数据方案有两种：
- 数仓+数集
- 数据湖+数据治理(以华为为代表的数据湖解决方案）
- 手撕数据湖
维基百科上定义，数据湖（Data Lake）是一个以原始格式存储数据的存储库或系
统。它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储
结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON
），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视
频）这个概念出来，第一时间跳脚的就是搞大数据的这批人，这不就是HDFS或者数仓的ODS层吗？！
图1： 数据湖与数据治理
按照这个架构的理解，数据湖就是个旧酒新瓶. 我们再看一个图
图2： 数据湖-逻辑概念
到这里依然会有人骂，这跟用HDFS作为数据湖没有什么本质区别啊，五十步笑百步。第二点，HDFS的作用在哪里？ 早期看到包括微软等诸多公司对维基的数据湖概念并没有直接采纳，因为落地性不强，而直接采用上图的逻辑层数据湖，必须充分借助数据治理的来讲故事。
再看第三个图：
图3 数据湖
这个图既满足了维基的数据湖定义，又为数据湖引擎埋下了打下了基础。
以上的各种解释，我们都很难得到一个满意的答案。 实际上，是我们进入了一个误区，我们一定要拿数据湖和已经存在且被广泛接受的数仓架构对比，且单独对一个数据湖概念进行抨击，而数据湖本身是为了一套解决方案而生，这套方案能够弥补数仓ETL提供数据服务的不足
- 数据治理与数据仓库都尝试建立数据标准
数据治理的数据质量和数仓的逻辑建模都是在尝试 建立数据标准。 早期数据治理和数据湖双生的时候，多数人对数据治理的理解是基于HDFS，所以理解数据治理是基于大数据平台的数据治理； 而如果按照我们图2，图3的理解，数据治理是对整个业务体系的治理。
数据治理也明显补充了数据仓库的不足，如数据血缘，数据共享等，且把大数据平台的监控，ETL调度集到一个共同的 平台。
数据治理的概念随着各大厂商共同探索，也逐渐发现数据治理与数仓变得不可分割，且是一个公司级别的战略问题，参考《华为数据之道》
数据治理平台kylo（现在自己定位为数据湖管理平台），在数据治理方面表达的非常清晰。
- 数据湖引擎
数据湖的解决方案是如何对外提供服务的？华为有过自己的探索，然而有另一种完全不用的思路-数据湖引擎逐渐进入人们的视野，典型代表是dremio，且数据湖引擎逐渐被接受。 我司（方正证券）进行了充分调研，做了大量POC之后，国内首家投入使用，并给dremio企业提供了大量的改进意见。 我个人也认同该思路，因为对于 业务人员使用数据是一个相对数仓更快速的通道。
共同看下数据湖引擎的思路：
图4 ： dremio的数据服务架构
- ETL到 ELT
传统ETL的思路是数据经过清洗转换到数据仓库，然后根据主题分为不同的数据集市提供服务。 就目前而言，在大数据处理方面依然是最具影响力，且认可度最高的一种方案，但依然不能满足实际生产中的一些业务场景，比如数据分析人员无法清晰的描述数据模型，而数据开发人员对业务的理解不够透彻，如图5
图5：建立数据集市需要面对的问题
图5这种场景在多数情况下还是能被接受，有一些探索性，科研性的场景，快速，临时，以分析为主，甚至在探索初期都无法确定一定要什么数据。我们为这种场景建立ETL简直是灾难性的。
数据湖引擎的解决方案在探索性场景就非常适配，我们能直接访问源数据，在基于SQL的反复探索性查询后，建立一个主题，包含多个VDS，然后沉淀为一个数据集市。 这样的数据集市更贴近业务，更精准匹配需求。
ELT在这里是怎么表现的呢，如图6：
图6：ELT
ELT 在先探查所需要业务数据，然后把数据加载到PDS（物理数据集）的存储系统（这个存储系统可以是hdfs，可以是云），进一步建立面向业务的表结构，我们把这种表结构叫做VDS（虚拟数据集）。
- 总结《云原生数据中台》中对数据湖与数据仓库的理解更直接
6.1 数据湖是什么
数据湖目前市场最主流的两种声音：
- 与数仓的ODS在一个位置，基于云或者分布式存储，包含了从源数据库采集而来的数据
- 数据湖是一个逻辑概念，包含了多类数据库，并且数据可以被数据湖解决方案使用
第一种解释更具有生命力，在dremio等多个数据湖解决方案中被使用。
6.2 理解数据湖解决方案
- 数据湖+数据湖引擎（或者数据治理+大数据组件） 是一种数据服务解决方案
- 数据数仓+数据集市 是一种数据解决方案
我们也看到，两种解决方案各有优劣，那有没有可能探索出一种取得双方优势的方案， 有！ 湖仓一体
最后提一嘴，国内有一家对基于dremio优化的版本，叫beelink，修复了dremio糟糕的执行计划， 性价比更高
