感觉有用。
URL：https://blog.csdn.net/yunqiinsight/article/details/109025690
数据湖 VS 数据仓库
综上，数据仓库和数据湖，是大数据架构的两种设计取向。两者在设计的根本分歧点是对包括存储系统访问、权限管理、建模要求等方面的把控。
数据湖优先的设计，通过开放底层文件存储，给数据入湖带来了最大的灵活性。进入数据湖的数据可以是结构化的，也可以是半结构化的，甚至可以是完全非结构化的原始日志。另外，开放存储给上层的引擎也带来了更多的灵活度，各种引擎可以根据自己针对的场景随意读写数据湖中存储的数据，而只需要遵循相当宽松的兼容性约定（这样的松散约定当然会有隐患，后文会提到）。但同时，文件系统直接访问使得很多更高阶的功能很难实现，例如，细粒度（小于文件粒度）的权限管理、统一化的文件管理和读写接口升级也十分困难（需要完成每一个访问文件的引擎升级，才算升级完毕）。
而数据仓库优先的设计，更加关注的是数据使用效率、大规模下的数据管理、安全/合规这样的企业级成长性需求。数据经过统一但开放的服务接口进入数据仓库，数据通常预先定义 schema，用户通过数据服务接口或者计算引擎访问分布式存储系统中的文件。数据仓库优先的设计通过抽象数据访问接口/权限管理/数据本身，来换取更高的性能（无论是存储还是计算）、闭环的安全体系、数据治理的能力等，这些能力对于企业长远的大数据使用都至关重要，我们称之为成长性。
下图是针对大数据技术栈，分别比较数据湖和数据仓库各自的取舍。
图8. 数据湖和数据仓库在技术栈上的对比
灵活性和成长性，对于处于不同时期的企业来说，重要性不同。
1、当企业处于初创阶段，数据从产生到消费还需要一个创新探索的阶段才能逐渐沉淀下来，那么用于支撑这类业务的大数据系统，灵活性就更加重要，数据湖的架构更适用。
2、当企业逐渐成熟起来，已经沉淀为一系列数据处理流程，问题开始转化为数据规模不断增长，处理数据的成本不断增加，参与数据流程的人员、部门不断增多，那么用于支撑这类业务的大数据系统，成长性的好坏就决定了业务能够发展多远。数据仓库的架构更适用。
本文有观察到，相当一部分企业（尤其是新兴的互联网行业）从零开始架构的大数据技术栈，正是伴随开源 Hadoop 体系的流行，经历了这样一个从探索创新到成熟建模的过程。在这个过程中，因为数据湖架构太过灵活而缺少对数据监管、控制和必要的治理手段，导致运维成本不断增加、数据治理效率降低，企业落入了『数据沼泽』的境地，即数据湖中汇聚了太多的数据，反而很难高效率的提炼真正有价值的那部分。最后只有迁移到数据仓库优先设计的大数据平台，才解决了业务成长到一定规模后所出现的运维、成本、数据治理等问题。
下一代演进方向：湖仓一体
经过对数据湖和数据仓库的深入阐述和比较，本文认为数据湖和数据仓库作为大数据系统的两条不同演进路线，有各自特有的优势和局限性。数据湖和数据仓库一个面向初创用户友好，一个成长性更佳。对企业来说，数据湖和数据仓库是否必须是一个二选一的选择题？是否能有一种方案同时兼顾数据湖的灵活性和云数据仓库的成长性，将二者有效结合起来为用户实现更低的总体拥有成本？
将数仓和数据湖融合在一起也是业界近年的趋势，多个产品和项目都做过对应的尝试：
1、数仓支持数据湖访问
· 2017年Redshift推出Redshift Spectrum，支持Redsift数仓用户访问S3数据湖的数据。
· 2018年阿里云MaxCompute推出外表能力，支持访问包括OSS/OTS/RDS数据库在内的多种外部存储。
但是无论是 Redshift Spectrum 还是 MaxCompute 的外部表，仍旧需要用户在数仓中通过创建外部表来将数据湖的开放存储路径纳入数仓的概念体系——由于一个单纯的开放式存储并不能自描述其数据本身的变化，因此为这些数据创建外部表、添加分区（本质上是为数据湖中的数据建立 schema）无法完全自动化（需要人工或者定期触发 Alter table add partition 或 msck）。这对于低频临时查询尚能接受，对于生产使用来说，未免有些复杂。
2、数据湖支持数仓能力
· 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），极大提升了使用的复杂度。
图10. Hudi Support Matrix（来自网络）
而DeltaLake则选择了保证以Spark为主要支持引擎的体验，相对牺牲对其他主流引擎的兼容性。这对其他引擎访问数据湖中的Delta数据造成了诸多的限制和使用不便。例如Presto要使用DeltaLake表，需要先用Spark创建manifest文件，再根据manifest创建外部表，同时还要注意manifest文件的更新问题；而Hive要使用DeltaLake表限制更多，不仅会造成元数据层面的混乱，甚至不能写表。
上述在数据湖架构上建立数仓的若干尝试并不成功，这表明数仓和数据湖有本质的区别，在数据湖体系上很难建成完善的数仓。数据湖与数据仓库两者很难直接合并成一套系统，因此作者团队，开始基于融合两者的思路进行探索。所以我们提出下一代的大数据技术演进方向：湖仓一体，即打通数据仓库和数据湖两套体系，让数据和计算在湖和仓之间自由流动，从而构建一个完整的有机的大数据技术生态体系。
我们认为，构建湖仓一体需要解决三个关键问题：
1、湖和仓的数据/元数据无缝打通，且不需要用户人工干预
2、湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作
3、数据湖与数据仓库的数据，系统负责自动caching/moving，系统可以根据自动的规则决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化
