数据湖的简单解释

数据湖轻松地收集数据：管他什么样的数据，我先把它存到我的库里面，不清洗，不过滤，直接存，数据水分很大，所以叫数据湖，要使用数据的时候再去编程解析到我定义好的数据库表里面。而数据仓库，就是提前建好数据库的表结构，把数据处理好之后，再存入，所以数据仓库不能轻松收集数据。

从数据中发掘更多价值：数据仓库和数据市场由于只使用数据中的部分属性（字段少，内容少），所以只能回答一些事先定义好的问题；而数据湖存储所有最原始、最细节的数据，所以可以回答更多的问题。并且数据湖允许组织中的各种角色通过自助分析工具，对数据进行分析，以及利用AI、机器学习的技术，从数据中发掘更多的价值。

消除数据孤岛：数据湖中汇集了来自各个系统中的数据，这就消除了数据孤岛问题。

具有更好的扩展性和敏捷性：数据湖可以利用分布式文件系统来存储数据，因此具有很高的扩展能力。开源技术的使用还降低了存储成本。数据湖的结构没那么严格，因此天生具有更高的灵活性，从而提高了敏捷性。（这句可以不要，数据湖会增加存储成本，因为数据水分大）实际上是数据项目前期，可能不知道这些数据能做什么。所以先全面的存下来，后面再做开发扩展。

 

数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。 但是在实际项目中，其实我们更希望各专业系统上报的数据越清晰越好。

简单一点： 数据湖就是存储乱七八糟的原始数据的地方。

 

数据湖的实现遇到了哪些问题？
数据湖刚提出来时，只是一个朴素的理念。而从理念变成一个可以落地的系统，就面临着许多不得不考虑的现实问题：
首先，把所有原始数据都存储下来的想法，要基于一个前提，就是存储成本很低。而今数据产生的速度越来越快、产生的量越来越大的情况下，把所有原始数据，不分价值大小，都存储下来，这个成本在经济上能不能接受，可能需要打一个问号。
其次，数据湖中存放这各类最原始的明细数据，包括交易数据、用户数据等敏感数据，这些数据的安全怎么保证？用户访问的权限如何控制？
再次，湖中的数据怎么治理？谁对数据的质量、数据的定义、数据的变更负责？如何确保数据的定义、业务规则的一致性？
数据湖的理念很好，但是它现在还缺乏像数据仓库那样，有一整套方法论为基础，有一系列具有可操作性的工具和生态为支撑。正因如此，目前把Hadoop用来对特定的、高价值的数据进行处理，构建数据仓库的模式，取得了较多的成功；而用来落实数据湖理念的模式，遭遇了一系列的失败。这里，总结一些典型的数据湖失败的原因：
数据沼泽：当越来越多的数据接入到数据湖中，但是却没有有效的方法跟踪这些数据，数据沼泽就发生了。在这种失败中，人们把所有东西都放在HDFS中，期望以后可以发掘些什么，可没多久他们就忘那里有什么。
数据泥团：各种各样的新数据接入进数据湖中，它们的组织形式、质量都不一样。 由于缺乏用于检查，清理和重组数据的自助服务工具，使得这些数据很难创造价值。
缺乏自助分析工具：由于缺乏好用的自助分析工具，直接对数据湖中的数据分析很困难。一般都是数据工程师或开发人员创建一个整理后的小部分数据集，把这些数据集交付给更广泛的用户，以便他们使用熟悉的工具进行数据分析。这限制了更广泛的人参与到探索大数据中，降低了数据湖的价值。
缺乏建模的方法论和工具：在数据湖中，似乎每一项工作都得从头开始，因为以前的项目产生的数据几乎没有办法重用。 其实，我们骂数据仓库很难变化以适应新需求，这其中有个原因就是它花很多时间来对数据进行建模，而正是有了这些建模，使得数据可以共享和重用。数据湖也需要为数据建模，不然每次分析师都得从头开始。
缺少数据安全管理：通常的想法是每个人都可以访问所有数据，但这是行不通的。企业对自己的数据是有保护本能的，最终一定是需要数据安全管理的。
一个数据湖搞定一切：大家都对能在一个库中存储所有数据的想法很兴奋。然而，数据湖之外总会有新的存储库，很难把他们全都消灭掉。 其实，大多数公司所需的，是可以对多种存储库联合访问功能。是不是在一个地方存储，并不是那么重要。

 

 

 

所以，综上所述：

我们应该建立更有含金量的数据湖。