数据湖的热还没褪去，湖仓一体就被炒起来了，有人问要不要入局湖仓一体，我的观点：先把自家的数据湖玩明白了再说吧，事实上，大多数的数据湖用得名不副实，更别提湖仓一体了。
为什么这么说呢？
判断一个技术对自己有没有用，我还是喜欢追溯下技术的源头，很多技术被产品化后，夹杂了太多的私货。
在说明我的观点之前，先做一个数据技术的穿越，从数据库、数据仓库、数据湖再到湖仓一体。
1、简单可用阶段：数据库（DataBase）
早在1980年代初中期，是没有专门面向数据分析场景的产品。当时还是以面向事务交易场景为主，数据分析仅作为附带提供的场景。主要是面对管理层提供固定报表，满足宏观管理决策。作为底层数据库，通过标准SQL提供数据分析能力。
这一架构在面对数据分析场景的缺点很明显，集成水平低，扩展性差，很难支持大规模数据分析，性能也无法满足需求。这也催生专门解决数据分析的产品出现，即后面出现的数据仓库。
2、 规范标准阶段：数仓（Data Warehouse）
到了1980年代中后期，为解决数据库面对数据分析的不足，孕育出新一类产品数据仓库。让我们先来看下数据仓库的定义，数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策和信息的全局共享。
上图是数据仓库的应用架构，从中可见其做了若干阶段划分，简单可分为数据集成（装载）、数据加工（ETL）、数据汇聚、数据展示及挖掘。数据经过这一过程，被抽取到数据仓库中，并严格按照预先定义的模式被装载进来，经过多层加工形成数据集市，并最终提供给终端应用或进一步供挖掘使用，主要场景包括编制报表、发布下游数据集市(Data Marts)，以及支持自助式商业智能等。
在技术实现上，主流采用MPP无共享存储架构，基于标准X86服务器，可实现数百节点的扩展。其对外提供标准的SQL能力和ACID特性，整体计算性能可在一定程度上随节点扩展可提升。
当然，随着数据在企业内角色愈发重要，对其分析的要求不断提高，例如，随着数据规模扩大，对数据承载能力（容量、算力）的要求也不断增大，数仓架构的扩展能力面临考验，规模的扩展会面临大量资源的投入，但硬件资源缺乏弹性，会导致高峰时资源不足，低谷时资源闲置浪费问题。针对数据类型，也不再局限于结构化数据，更多半结构化、非结构化数据需要被利用起来，传统的数据仓库架构面临诸多的挑战，只能扩展上百节点的MPP架构快撑不住了。
3.、开放自由阶段：数据湖（Data Lake）
相比于数据仓库，数据湖是一种不断演进中、可扩展的大数据存储、处理、分析的基础设施。它就像一个大型仓库，可以存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据，数据湖通常更大，存储成本也更为廉价，结合先进的数据科学与机器学习技术，能提供预测分析、推荐模型等能力。
数据仓库中，数据存储的结构与其定义的schema是强匹配的，也就是先建模再使用，简单点说，数据仓库就像是一个大型图书馆，里面的数据需要按照规范放好，你可以按照类别找到想要的信息，存储在仓库中都是结构化数据，可以直接消费。
而数据湖存储其中的数据不需要满足特定的schema，数据湖也不会尝试去将特定的schema施行其上，任何格式的数据都可以扔进数据湖。数据使用通常会在读取数据的时候解析schema（schema-on-read），当处理相应的数据时，将转换施加其上，也就是说，数据湖对于入湖的数据不做任何规范和约束，只有在于使用时才定义存储格式以便分析使用。
下面这张图形象的表达了数据仓库和数据湖的区别，数据仓库有点像“计划经济”，而数据湖则是“市场经济”。
基于以上的特点，业界一般都会认为数据仓库成长性较好，适合于成熟规模型企业使用，因为规范化讲究的是一个规模效益。数据湖灵活性较好，更适用于初创型企业使用，如下图所示：
可以看到，数据湖和数据仓库都有各自的优势和不足，但不难发现，二者在某些层面是非常互补的，于是乎，2020年，大数据DataBricks公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一。
此概念一出各路云厂商纷纷跟进，2021年，这个概念爬上了Gartner曲线，在国内火了起来，各种湖仓一体的产品也冒出来了，无论是国外的，阿里的，华为的，开源的等等。
无论是数据湖，还是湖仓一体，看起来都很美好，不可否认它们代表了一种技术趋势，但这些老外传过来的东西，其宣扬的那些特性，对你的企业真的有用吗？
“不要说湖仓一体了，就连数据湖技术，大多企业也没怎么玩明白，即使你已经拥有了它。” 这是我当前给出的答案。
为什么要这么说？
2年前自己去参加一个展会，有人在那介绍数据湖的产品，我就问讲解员数据湖相对数据仓库带来了什么增益价值？能否举个让人信服的例子？然后讲解员巴拉巴拉的说了几个例子，我问这不是传统数据仓库干的事情吗？然后他就说，这是hadoop，它就是数据湖。
Hadoop就是数据湖？
有人解释国外习惯把hadoop叫做数据湖，而我们国内一般叫做大数据平台，虽然名字不一样，但其实说得是同一回事，因此其实我们早就一步走上了技术巅峰，可能连我们自己都不知道呢？
不知道什么时候开始，很多企业的PPT里开始把大数据平台改称了数据湖，也许数据湖这个名字比较通俗易懂吧，老板们也喜欢用，似乎是一瞬间，大家的大数据平台一下全部升级成为了数据湖。
遗憾的是，虽然大多企业的hadoop从技术角度来讲可以叫作数据湖，但从业务的角度讲，只是披着数据湖外衣的更大型的数据仓库而已。
大多企业从来没有像谷歌、互联网大厂一样发挥出过hadoop蕴含的数据湖的那些独特价值，比如将非结构化数据，结构化数据，半结构化数据全部扔到hdfs上统一管理，然后数据科学家能够所见即所得的进行分析使用。
事实上，大多企业只是把hadoop的hive当成了一个能处理海量数据的廉价数据仓库，用以替代跑不动的可能还贵得要死的MPP，但我们还在用MPP时代使用数据仓库的方式使用着数据湖，从来没有变更过，好比我虽然买了一辆具备自动驾驶的汽车但从来没有使用过自动驾驶功能一样。
下面这张表说明了一切，你可以看看数据湖相对数据仓库的11个方面的不同，然后想想咱家的hadoop数据湖跟这里提到的数据湖是不是同一个物种？
那么，造成这种现象的深层次原因是什么呢？
我想主要跟使用者的背景和业务有关，跟技术无关。
第一是原生数据的问题。数据湖缘起互联网，强调从非结构化数据中挖掘价值，比如谷歌使用MR计算引擎来处理非结构化的网页，而现在使用Hadoop的企业大多可是传统行业，本身没有什么非结构化数据，或者利用非结构化数据的业务驱动还不够，大家只是希望利用数据湖的分布式计算框架来提升海量结构化数据的处理能力，这让数据湖丧失了独特价值。
第二是生产关系的问题。虽然不少企业拥有各种类型的数据，但要汇聚这些数据到统一数据湖首先得打破数据孤岛，这对很多企业是巨大的挑战，因为企业数据治理体系不是那么容易建立。
理论上讲，一个公司有搞综合的，有搞财务的，有搞人力的，也有搞供应链的，不可能不需要保存和使用非结构化数据，但现实情况是，即使企业有了数据湖，很多领域对各种非结构数据的存储和处理其实还在用竖井的方式解决，比如构建独立的文档库，大家并没有什么入湖共享的意识。
前段时间我写过一篇数据编织的文章，提到获取完整的元数据是数据编织的前提，但如果连连接各个数据源的元数据权力都没有，谈何数据编织，而数据湖的困境也是一样的。
下面这张图体现出数据湖是一个生态，但生态的打造不是在一个空地上挖一个池子就可以的。
有人说数据湖的核心问题是数据太多缺乏治理导致变成了数据沼泽，我说你太杞人忧天了，数据湖的核心问题是湖水太少了，数据治理首先要解决的是有没有水、能不能把水引进来的问题。
第三是数据应用的问题。数据湖的最大推动者是亚马逊等一众互联网大厂，这些互联网的数字原生企业，其本身的数字化水平是非常高的，面对激烈的市场竞争，早就不再满足于数据仓库那种按部就班的单一数据的供给模式，互联网大厂的数据科学家具备足够的能力从数据湖中获取原始数据、解析数据、处理数据直到挖掘数据，所见即所得是数据科学家探索数据所需要的。
但在传统企业里，数据分析师能够基于数据仓库提供的结构化数据进行自助取数、分析和挖掘已经是非常牛逼了，大多还是处于被动的数据供给模式，数据湖所倡导的灵活性对他们来说是没有什么意义的，这是由企业的性质和所处的阶段决定的。
由此可以看到，数据湖相对数据仓库拥有的那些独特优势，无论是对于非结构数据的存储处理还是分析的灵活性等等，在大多企业是没有条件执行的，或者说没有足够的业务驱动力，大多企业的使用者眼里只有支持SQL的HIVE数据仓库，数据湖对他们来讲就是更大号的数据仓库，比如企业90%的数据都是以HIVE表的形式存在的，所有的需求都不需要用到数据湖的独特技术。
现在，hadoop这种数据湖技术已经逐步不能满足互联网大厂的要求了，因为hadoop实时性太差，无法满足数据湖“对于业务系统中的数据都会存储一份“一模一样”的完整拷贝”的保真性要求。
这意味着数据写入数据湖的时候要保证ACID，要高效支持upsert /delete历史数据，要能容忍数据频繁导入文件系统上产生的大量的小文件，显然hadoop这种数据湖技术不够看了，在这种背景下，Delta、iceberg和hudi等新技术逐渐冒出来了，但它们到底是属于数据仓库的升级，还是属于数据湖的升级，那就见仁见智了，我们既可以说数据仓库需要支撑实时数据，也可以说数据湖需要确保所有的数据能及时的扔进数据湖且跟原系统一模一样。
但脱离了hadoop体系的新数据湖技术，大多企业估计也很难买单，一方面实时技术有很多替代品，即使不是那么完美，另一方面也有保护原有投资的需要。
明白了这一点，我们再回过头来分析湖仓一体，自然会得到你需要的答案，我不否认湖仓一体是很好的技术，代表了某种趋势，但回到每个企业每个个体，我们还是要回到业务原点去思考问题，虽然技术可以适当领先业务半步，但步子不要一下子迈得太大，还得因地制宜，诸如阿里提供的湖仓一体解决方案应该也有市场，因为能解决异构数据平台的数据共享和同步问题，至少能保护企业的原有投资，但卖点不在湖仓一体本身。
最后一句话总结：数据仓库永不过时，数据湖任重而道远，湖仓一体就先让子弹飞一会儿吧。
