我们这些数据和分析从业者当然听过这个词，当我们开始与客户讨论大数据解决方案时，谈话自然转向了对数据湖的讨论。但是，我经常发现客户要么没有听说过这个词，要么没有很好地理解它的含义。
数据仓库
维基百科，将数据仓库定义为：
“...来自一个或多个不同来源的综合数据的中央存储库。他们存储当前和历史数据，并用于创建高级管理报告的趋势报告，如年度和季度比较。“
这是一个非常高层次的定义，它描述了数据仓库的目的，但没有解释如何达到目的。
我会继续添加一个数据仓库有以下属性：
- 它代表了由主题领域组织的业务的抽象图片。
- 这是高度转变和结构。
- 在定义使用数据之前，数据不会被加载到数据仓库中。
- 它通常遵循诸如Ralph Kimball和Bill Inmon所定义的方法。
数据湖
Pentaho首席技术官詹姆斯·迪克森（James Dixon）通常被称为“数据湖”（data lake）。他描述了一个类似于一瓶水的数据集市（数据仓库的一个子集）...“清理，打包和结构化以便于消费”，而数据湖更像是一个自然状态的水体。数据从流（源系统）流向湖。用户可以进入湖泊进行检查，采样或潜水。
现代数据架构中的数据湖这也是一个相当不精确的定义。我们来添加一个数据湖的一些特定属性：
- 所有数据都从源系统加载。没有数据被拒绝。
- 数据以未转换或几乎未转换的状态存储在叶级。
- 数据被转换，模式被应用来满足分析的需要。
接下来，我们将重点介绍数据湖的五个关键区别以及它们与数据仓库方法的对比。
1. Data Lakes保留所有数据
在开发数据仓库的过程中，花费大量时间分析数据源，了解业务流程和分析数据。其结果是设计用于报告的高度结构化的数据模型。这个过程的很大一部分包括决定要包含哪些数据，而不包括在仓库中。一般来说，如果数据不是用来回答特定的问题或在一个定义的报告中，它可能被排除在仓库之外。这通常是为了简化数据模型，并节省昂贵的磁盘存储上的空间，用于提高数据仓库的性能。
相比之下，数据湖保留所有数据。不仅仅是今天正在使用的数据，还有可能使用的数据，甚至可能永远不会被使用的数据。数据也一直保存下来，以便我们能及时回到任何一点做分析。
这种方法成为可能，因为数据湖的硬件通常与用于数据仓库的硬件大不相同。商品，现成的服务器与便宜的存储相结合，使数据湖扩展到TB级和PB级相当经济。
2.数据湖支持所有数据类型
数据仓库一般由从事务系统中提取的数据组成，并由定量度量和描述它们的属性组成。Web服务器日志，传感器数据，社交网络活动，文本和图像等非传统数据源在很大程度上被忽略。这些数据类型的新用途不断被发现，但是消耗和存储它们可能是昂贵和困难的。
数据湖方法包含这些非传统的数据类型。在数据湖中，我们保留所有数据而不管源和结构。我们保持它的原始形式，只有在我们准备好使用它时，我们才会改变它。这种方法被称为“读取模式”与数据仓库中使用的“写入模式”方法。
3.数据湖支持所有用户
在大多数组织中，80％或更多的用户是“运营”的。他们希望获得他们的报告，查看他们的关键绩效指标，或者每天在电子表格中对同一组数据进行分组。数据仓库通常是这些用户的理想选择，因为它结构合理，易于使用和理解，并且专门用于回答他们的问题。
接下来的10％左右，对数据做更多的分析。他们使用数据仓库作为数据源，但往往回溯到源系统，以获取未包含在仓库中的数据，有时从组织外部获取数据。他们最喜欢的工具是电子表格，他们创建新的报告，通常分布在整个组织。数据仓库是他们的数据源，但是他们经常超出界限
最后，最后几个百分比的用户做了深入的分析。他们可能会根据研究创建全新的数据源。他们混合了许多不同类型的数据，并提出了全新的问题来回答。这些用户可能会使用数据仓库，但往往会忽略它，因为他们通常被控超越其能力。这些用户包括数据科学家，他们可能会使用先进的分析工具和功能，如统计分析和预测建模。
数据湖方法同样支持所有这些用户。数据科学家可以前往湖泊，利用他们所需要的大量不同的数据集，而其他用户则可以使用更为结构化的数据视图来提供数据。
4.数据湖适应变化
关于数据仓库的主要抱怨之一是需要多长时间来改变它们。在开发过程中花费了相当多的时间来获得仓库的结构。一个好的仓库设计可以适应变化，但是由于数据加载过程的复杂性以及为使分析和报告容易进行而做的工作，这些变化将必然消耗一些开发人员资源并花费一些时间。
许多业务问题都迫不及待地让数据仓库团队调整系统来回答问题。自助服务商业智能的概念引发了日益增长的对更快答案的需求。
另一方面，在数据湖中，由于所有数据都是以原始形式存储的，并且总是可以被需要的人访问，所以用户有权超越仓库结构以新颖的方式探索数据并回答问题在他们的步伐。
如果一个探索的结果被证明是有用的，并且有一个重复的愿望，那么可以应用一个更正式的模式，并且可以开发自动化和可重用性来帮助将结果扩展到更广泛的观众。如果确定结果不是有用的，则可以丢弃该结果，并且没有对数据结构进行改变，也没有消耗开发资源。
5.数据湖提供更快的洞察力
这最后一个区别实际上是其他四个的结果。因为数据湖泊包含了所有的数据和数据类型，因为它使用户能够在数据被转换，清理和结构化之前访问数据，使得用户能够比传统的数据仓库方法更快地获得结果。
但是，这种对数据的早期访问是有代价的。通常由数据仓库开发团队完成的工作可能无法完成分析所需的部分或全部数据源。这让驾驶座位的用户可以根据需要探索和使用数据，但上述第一层业务用户可能不希望这样做。他们还只是想要他们的报告和关键绩效指标。
在数据湖中，这些操作报告消费者将利用数据库中的数据的更加结构化的视图，类似于以前在数据仓库中的数据。不同之处在于，这些视图主要是作为元数据存在于湖泊中的数据之上，而不是物理上需要开发者改变的刚性表格。
我应该选择哪种方法？
这是一个困难的问题。如果你已经建立了完善的数据仓库，我当然不主张把所有的工作都放在窗口上，从头开始。但是，像许多其他数据仓库一样，您可能会遇到我所描述的一些问题。如果是这种情况，您可以选择在仓库的旁边实施一个数据湖。仓库可以像以往一样继续经营，您可以用新的数据源开始填充您的湖泊。您还可以将其用于您的仓库数据的归档存储库，以便实际使其保持可用状态，从而为用户提供比以前更多的数据访问权限。随着仓库的老化，您可能会考虑将其移至数据湖，否则您可能会继续提供混合方法。
如果您刚刚开始构建集中式数据平台，我强烈建议您考虑两种方法。
那么技术呢？
我故意没有提到任何具体的技术。数据湖这个词已经成为像Hadoop这样的大数据技术的代名词，而数据仓库仍然与关系数据库平台保持一致。我这篇文章的目标是突出两种数据管理方法的差异，而不是强调一个特定的技术。然而事实是，上述技术方法的一致并不是巧合。关系数据库技术是数据仓库应用的理想选择，因为它们在高速查询结构数据方面表现优异。
另一方面，Hadoop生态系统非常适用于数据湖方法，因为它可以非常容易地适应和扩展非常大的卷，并且可以处理任何数据类型或结构。但是，另外，Hadoop还可以通过将结构化视图应用于原始数据来支持数据仓库场景。正是这种灵活性使Hadoop能够擅长向所有业务用户层提供数据和洞察力。
未来该何去何从？
两个阵营的技术不断发展。
关系数据库软件在软件和硬件方面不断发展和进步，专门用于使数据仓库更快，更具可扩展性和更可靠。
Hadoop生态系统正被看到前所未有的采用，而且它是由社区支持的开源项目的集合，这意味着开发和进步的速度比传统软件快得多。
Hadoop对开源软件和商品硬件的依赖使得从成本和功能的角度来看，如果您正在评估一个新的数据平台，或者正在计划替换或升级一个遗留系统，那么它就非常有吸引力。
