数据湖是近几年数据领域经常提到的一个热词，在国内外大厂迅速普及传播。
第一次看到数据湖这个概念的时候，我想：“又拿什么新概念来忽悠我？”
先大致解释一下什么是数据湖。
数据湖作为一个集中的存储库，可以在其中存储任意规模的所有结构化和非结构化数据。在数据湖中，可以存储数据，不需要对其进行结构化，就可以运行不同类型的分析。
再形象点说，如果说数仓里是瓶装的水——是打包好的、方便取用的；
那么数据湖里面就是原生态的水——它是未经处理的。数据湖中的水从源头流入湖中，各种用户都可以来湖里获取、蒸馏提纯这些水，也就是数据。
但数据湖真的如想象中那么美好，能帮助企业彻底解决数据难题吗？
数据湖技术门槛较高，标准化水平却不高
数据湖有六个特点：保真性、灵活性、可管理、可分析、可追溯、可存储。特点多了，一方面可以说是功能强大，另一方面也说明了技术复杂性，让我们很难清晰判定什么样的平台才有资格叫做数据湖。
就拿保真性来说，其是这么描述的：“数据湖中对于业务系统中的数据都会存储一份“一模一样”的完整拷贝。与数据仓库不同的地方在于，数据湖中必须要保存一份原始数据，无论是数据格式、数据模式、数据内容都不能被修改，要原样保存。
那么，原系统的实时数据如何保真到数据湖呢？
这个技术就复杂了，比如数据写入数据湖的时候要保证ACID，要高效支持upsert /delete历史数据，要能容忍数据频繁导入文件系统上产生的大量的小文件（显然HDFS就不行了）。
Delta、iceberg和hudi等开源数据湖就是一些特定技术解决方案，但很多企业连hadoop生态还没搞通搞透呢，又搞出这么多技术，而且还没有统一标准，的确令人头大。
然后国内的大厂又基于开源的数据湖技术搞出了自己的数据湖，无论是腾讯的基于iceberg的Flink+Iceberg 企业级实时数据湖，还是阿里的基于hudi的湖仓一体，真是乱花渐欲迷人眼啊，但这个时候大多企业估计连数据湖还没整明白吧。
数据湖替换成本较大，无法保护原有的投资
从保护企业的固有资产投资的角度来讲，如果你已经建设了大数据平台，现在选择数据湖并不是明智之举，当然新建另当别说。
在我们刚建设完成hadoop大数据平台后，面临的质疑声是很多的，因为业务人员并没有看到什么显性的价值，因此花了巨大的代价去建设基于Hadoop的数据管理体系，包括端到端的一体化工具链等等。
对于大多数企业来讲，Hadoop周边生态体系的建设比hadoop建设本身更为重要，大家都聚焦到了如何让大数据平台发挥出应有的价值上来，这是好事情，而且完成hadoop大数据平台建设也不过4-5年，从保护投资的角度讲，这是理性的，不能这山望着那山高。
况且，Hadoop某种程度算是刚需，因为不采用它，海量数据根本处理不了，当然这种刚需也仅是针对拥有PB级别数据的企业来讲的，而数据湖显然还不是，它的技术缘起于解决某些特定场景，反正我想好了老半天，都没找到必需使用它的理由。
数据湖是数库技术的升级，但不具备不可替代性
老板问我：“我们到底要不要数据湖？” 我说：“场景太少，即使需要，也有替代方案，虽然不是很完满！”
数据湖有一种典型的应用场景，就是需要实时写海量数据进数据库然后能实时分析统计，很多大屏都需要用到这个技术，我想诸如Flink+Iceberg 等数据湖技术引擎肯定是比较完美的解决方案。
此图仅用来展示，是用FineReport制作
但我安排几个技术人员一周也搞定了，采用的是Flink+HTAP，虽然加载速度、查询速度并不是毫秒级，但对于大多数场景够用。
数据湖专业人士会跳出来说这个方案有很多问题，比如HTAP无法支持多种存储引擎和计算引擎等等，但在这个场景下，不会追求通用的技术方案，而是尽量选择符合企业技术现状、性价比更高的方式。
数据湖总结下来有六大技术特点，包括（1）同时支持流批处理（2）支持数据更新（3）支持事务（ACID）（4）可扩展的元数据（5）支持多种存储引擎（6）支持多种计算引擎等等。
对于大多数企业，如果要为这些技术去找特定应用场景，并不是很好找，不信你找找看，即使找到了，估计用到其中的1-2个技术能力就可以了，而满足1-2个条件的肯定有其他的替代品。
总之，“没有强大的数据处理能力就别用数据湖”，即使要采用数据湖，也要注意实施难度，因为数据湖为了达成那六种技术能力，需要用到一种存储中间件，对下统一对接各种存储，对上统一对接各种技术引擎，这实在是太折腾了。
源：大鱼的数据人生