数据湖很美好，但并不被需要 by 大鱼先生
数据湖是现在的一个热点，在大厂迅速普及，可在传统企业却不愠不火，有点冰火两重天的意思，为什么？
为了更好的理解这篇文章，建议大家可以先读读我这篇普及数据湖的文章《到底什么是数据湖？全面解读数据湖的缘起、特征、技术、案例和趋势》。
1、数据湖容易望文生义，导致雷声大雨点小
在我第一次接触数据湖的时候，就望文生义：“什么？把所有东西乱七八糟都扔到一个地方，这也叫一种技术？应该叫数据沼泽吧”，相信很多做数据仓库的朋友第一次听到这个名词，会跟我有同样的反应。
有一次参加合作伙伴大会，正好有展示数据湖的，然后我就问讲解员：“这个数据湖有什么特点？” 然后讲解员跟我说了一堆数据仓库的东西，核心意思就是汇聚数据。然后我问：“这个跟数据仓库又有什么区别？” 讲解员又扒拉了老半天，我就知道其实他也不知道。
数据湖这个概念在大厂的节奏下莫名其妙的飞起来了，有一天公司同事给我发了一段老大要讲的话，里面提到了数据湖，问我们是否已经有数据湖了，老大的报告里提数据湖是不是合适？
我赶紧到网上查了数据湖的来龙去脉，发现hadoop算是一种数据湖的形式，但当初建hadoop的时候，可没人说这是数据湖啊。数据湖显然不是简单的数据收容箱，技术内涵远不是hadoop所能囊括的，心里就慌得一比，不知道它到底能给企业带来什么增值价值。
由于数据湖的概念大家混淆不清，很容易眉毛胡子一把抓的说成就是将所有数据汇聚在一个地方的简单技术，大多数老板会认为自己建设的大数据平台就是数据湖，如果都是这种认知，那的确没有再建设的必要了。
大厂想普及数据湖，传统企业岿然不动，显然跟概念没讲清楚有一定关系，同样是数据归集和整合，数据湖相较于数据仓库，境界显然要高很多，但到底高在哪里？想想我这个搞数据技术10多年的人都对其一脸懵逼，更何况一般的人？
2、数据湖技术门槛较高，标准化水平却不高
数据湖有六个特点：保真性、灵活性、可管理、可分析、可追溯、可存储，特点多了，一方面可以说是功能强大，另一方面也说明了技术复杂性，让我们很难清晰判定什么样的平台才有资格叫作数据湖。
就拿保真性来说，其是这么描述的：“数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不应该被修改。在这方面，数据湖强调的是对于业务数据“原汁原味”的保存。同时，数据湖应该能够存储任意类型/格式的数据，包括结构化、半结构化和非结构化数据。”
那么，原系统的实时数据如何保真到数据湖呢？
这个技术就复杂了，比如数据写入数据湖的时候要保证ACID，要高效支持upsert /delete历史数据，要能容忍数据频繁导入文件系统上产生的大量的小文件（显然HDFS就不行了）。
Delta、iceberg和hudi等开源数据湖就是一些特定技术解决方案，但传统企业连hadoop生态还没搞通搞透呢，又搞出这么多技术，而且还没有统一标准，的确令人头大。
然后国内的大厂又基于开源的数据湖技术搞出了自己的数据湖，无论是腾讯的基于iceberg的Flink+Iceberg 企业级实时数据湖，还是阿里的基于hudi的湖仓一体，真是乱花渐欲迷人眼啊，但这个时候大多企业估计连数据湖还没整明白吧。
3、数据湖理念比较超前，大规模普及尚需时日
10多年前自助BI就已经提出来了，包括自助取数，自助报表等等，其核心理念是业务人员能基于自助BI的产品自己操控数据，从而提升业务响应速度。但10多年过去了，现在的传统企业有多少比例的业务人员能够自己取数分析？
客观来讲，比10多年前有进步，但自助BI对于大多数企业的业务人员仍然是奢侈品一样的存在，一方面受限于企业的数字化水平，另一方面也受限于企业的数据文化，也许，只有等这一代的业务人员退休了，自助BI才能占据主流。
自助BI的数据模型好歹还是数据仓库预先生成的，但数据湖就更加激进了，从数据采集、建模、挖掘到分析，所有工作都需要业务人员基于数据湖提供的工具来完成，因为数据湖倡导者认为只有这样才能更快捷的响应市场需求。
如果说数据仓库分层建模是计划经济的话，那数据湖就是一种市场经济了，如果说自助BI是产品层面的创新，那数据湖就是全新升级版了，是对传统数据仓库服务模式的一种颠覆。
数据湖的始作俑者是亚马逊，我不知道这个企业自己有多少人在用，但人家企业的数字化水平高是肯定的，国内的大厂也差不多吧，但对于大多数企业来讲，数据湖倡导的理念实在是有点超前。
20多年前，数据仓库是很多巨无霸企业的技术狂欢，但当时的业务人员根本不知道建这个玩意有什么价值，也许我们还要再等10-20年，才能真正领悟数据湖的真谛，历史，总是在不停的重复吧。
4、数据湖是数库技术的升级，但不具备不可替代性
老板问我：“我们到底要不要数据湖？” 我说：“场景太少，即使需要，也有替代方案，虽然不是很完满！”
数据湖有一种典型的应用场景，就是需要实时写海量数据进数据库然后能实时分析统计，很多大屏都需要用到这个技术，我想诸如Flink+Iceberg 等数据湖技术引擎肯定是比较完美的解决方案。
但我安排几个技术人员一周也搞定了，采用的是Flink+HTAP，虽然加载速度、查询速度并不是毫秒级，但对于大多数场景够用。
数据湖专业人士会跳出来说这个方案有很多问题，比如HTAP无法支持多种存储引擎和计算引擎等等，但在这个场景下，不会追求通用的技术方案，而是尽量选择符合企业技术现状、性价比更高的方式。
数据湖总结下来有六大技术特点，包括（1）同时支持流批处理（2）支持数据更新（3）支持事务（ACID）（4）可扩展的元数据（5）支持多种存储引擎（6）支持多种计算引擎等等。
对于大多数企业，如果要为这些技术去找特定应用场景，并不是很好找，不信你找找看，即使找到了，估计用到其中的1-2个技术能力就可以了，而满足1-2个条件的肯定有其他的替代品。
5、数据湖替换成本较大，无法保护原有的投资
从保护企业的固有资产投资的角度来讲，如果你已经建设了大数据平台，现在选择数据湖并不是明智之举，当然新建另当别说。
在我们刚建设完成hadoop大数据平台后，面临的质疑声是很多的，因为业务人员并没有看到什么显性的价值，因此花了巨大的代价去建设基于Hadoop的数据管理体系，包括端到端的一体化工具链等等。
对于大多数企业来讲，要用好Hadoop，Hadoop周边生态体系的建设比hadoop建设本身更为重要，大家都聚焦到了如何让大数据平台发挥出应有的价值上来，这是好事情，而且完成hadoop大数据平台建设也不过4-5年，从保护投资的角度讲，这是理性的，不能这山望着那山高。
况且，Hadoop某种程度算是刚需，因为不采用它，海量数据根本处理不了，当然这种刚需也仅是针对拥有PB级别数据的企业来讲的，而数据湖显然还不是，它的技术缘起于解决某些特定场景，反正我想好了老半天，都没找到必需使用它的理由。
最后，即使要采用数据湖，实施的难度不小，因为数据湖为了达成那六种技术能力，需要用到一种存储中间件，对下统一对接各种存储，对上统一对接各种技术引擎，这实在是太折腾了。
当然也许我说得都是错的，那5年后再回过头来看吧。