小编近期接触了一些小工程，发现很多机构都是以数据湖当成服务底层来用，同时整体工程规划中又严重缺失各类数据辅助管理中间工具的支撑。这样一来，这些机构所搭建的工程就极有可能变成为面子工程。在未来的延续性，实时性，时效性，有效性，扩展性等方面都会产生巨大的缺陷，从而造成了项目资源的不可控、不可管、不可扩等一些列问题，最终容易导致整个工程昙花一现。
那么，脱离了数据仓库和数据管理工具之后，仅使用数据湖的弊端有哪些呢？下面进行讲解：
数据湖本身是一个中心化的存储，能够存储任意规模的结构化与非结构化数据。可以把数据湖理解成是一个“垃圾堆”，做得好的就可以理解为是一个做了垃圾分类的垃圾堆。
数据湖相比数据仓库确实也有很多的优势，但大多是在理想状态下的，一旦执行依然会有很多技术问题会产生。
（一）数据湖的数据并不会真正做到实时出来。
在业务环境中，在缺少ETL管理工具和主数据管理能力的条件下，如果把所有数据都放到数据湖里，那么从数据湖直接调用数据的过程可能比原来数据仓库更慢，因为从数据湖中提取出来的数据，依然要经过清洗实现标准化后才能更好的利用。长远来看，具体数据湖直接调用数据能否达到需求的低时延效果，还要根据具体应用场景来进行判断。
（二）把所有的原始数据都放到数据湖，可能会提升数据的使用难度。
对于很多机构而言，业务内容丰富，操作系统繁杂，数据使用者往往期望所有的数据都能平民化，就像数据仓库提供的那种经过了精心处理的数据，能够轻松调度和使用来实现对业务的指导。
如果是数据湖提供的原始化数据，其本身是很复杂的，数据专家进行理解和处理时或许难度适中，但大多数的普通程序员能否消化、理解并利用这些数据，将会是一个巨大的空洞。
（三）数据治理问题。
数据仓库里的数据是经过整理、清晰易懂的。但数据湖的概念是不经处理直接进行堆砌，那么数据湖就有可能会变成“数据沼泽”，筛选难度会变大。
当然，数据湖的优势就是数据可以先作为资产存放起来，问题就在于如何把这些数据在业务中利用起来。当部署了数据湖之后，数据治理问题将会接踵而至，比如从数据湖到数据资产，如何将数据进行分流、资产数据如何进行整理等。
综上所述，行业流行了一个全新理念——湖仓一体。
简单理解，就是当前很多机构对于数据湖的落地实践，基本上也是顶着数据湖的名号，做的是传统数仓的事情，只是会增加文档图片、物联网数据等传统数仓不包含的内容。常见传统的笨办法是一个数据湖，加上多个数据仓库，以及其他的专用系统，例如流、时间序列、图形和图像数据库等。这种架构的复杂性，将会带来运维的难题，因为技术人员始终需要在不同系统之间移动或复制数据。更重要的是，数据的传输引入了延迟，不能提高数据的时效性，所以这种产品架构会让小编本人也感觉非常的不适。我们详细看看湖仓一体应该的形态是什么样的，如下：
湖仓一体是一种新型开放式架构，将数据湖和数据仓库的优势充分结合，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能。
湖仓一体具有以下关键特征：
事务支持：在机构中，数据往往要为业务系统提供并发的读取和写入。对事务的ACID支持，可确保数据并发访问的一致性、正确性，尤其是在SQL的访问模式下。
数据的模型化和数据治理：湖仓一体可以支持各类数据模型的实现和转变，支持DW模式架构，例如星型模型、雪花模型等。该系统应当保证数据完整性，并且具有健全的治理和审计机制。
BI支持：湖仓一体支持直接在源数据上使用BI工具，这样可以加快分析效率，降低数据延时。另外相比于在数据湖和数据仓库中分别操作两个副本的方式，更具成本优势。
存算分离：存算分离的架构，也使得系统能够扩展到更大规模的并发能力和数据容量。（一些新型的数据仓库已经采用了这种架构）
开放性：采用开放、标准化的存储格式（例如Parquet等），提供丰富的API支持，因此，各种工具和引擎（包括机器学习和Python / R库）可以高效地对数据进行直接访问。
支持多种数据类型（结构化、非结构化）：Lakehouse可为许多应用程序提供数据的入库、转换、分析和访问。数据类型包括图像、视频、音频、半结构化数据和文本等。
支持各种工作负载：支持包括数据科学、机器学习、SQL查询、分析等多种负载类型。这些工作负载可能需要多种工具来支持，但它们都由同一个数据库来支撑。
端到端流：实时报表已经成为企业中的常态化需求，实现了对流的支持后，不再像以往一样，为实时数据服务构建专用的系统。
相比数据湖，湖仓一体 架构能够支撑联机交易和联机分析的场景，弥补了如Hadoop架构构建数据湖的重大不足。
相比数据仓库，湖仓一体作为支持联机处理的统一数据底座，数据可以实时入库，实时分析，无需异步写入另一个数据库再进行分析处理，可大大降低数据处理的成本。
