DataLake（翻译） - Martin Fowler 2015.02.05

原文地址：

https://martinfowler.com/bliki/DataLake.html

译文如下：

Data Lake 是近十年出现的一个术语，用于描述大数据世界中数据根系管道的重要组成部分。其主题思想是为一个组织中任何人可能需要分析的所有原始数据提供一个存储。通常，人们使用Hadoop来处理湖中的数据，但这个概念不局限于Hadoop。

当我听到要将要分析的所有数据汇总到一起时，我立即想到了数据仓库（和数据集市）。但是，数据湖和数据仓库之间存在重大区别。数据湖以数据源提供的任何形式存储原始数据。没有关于数据 schema 的任何假设，每个数据源都可以使用喜欢的任何 schema . 数据的消费者根据自己的目的来理解和使用数据。

这是重要的一步， 由于 schema 的问题，很多数据仓库计划并未走的很远。数据仓库倾向于采用满足所有分析需求的单一 schema 概念，但是我认为，除了最小的组织外，单一的统一数据模型对于任何其他组织都是不切实际的。为了对一个稍微复杂的域建模，您需要多个 BoundedContext, 每个BoundContext 具有自己的数据模型。用分析术语来说，您需要每个分析用户受益股对他们正在进行的分析有意义的模型。通过切换到仅存储原始数据，也将建模的责任切换到数据分析师身上。

数据仓库的另一个问题来源是数据质量保证。试图获得权威的单一数据来源，需要对不同系统如何获取和使用数据进行大量分析。系统A 可能适合某些数据，而系统B可能适合其他数据。您遇到的规则是，系统A适用于较新的订单，而系统B适用于一个月或更早的订单，除非涉及退货。除此之外，数据质量通常是一个主观的问题，不同的分析对数据质量问题的容忍度不同，甚至对什么是优质质量的概念也不同。

这引起了对数据湖的普遍批评 - 它是数据质量差异很大的数据垃圾场，最好叫做数据沼泽。 这个批评既正确又无关紧要。新分析的热门标题是“数据科学家”。尽管这是一个被滥用的标题，但其中许多人确实具有扎实的科学背景。任何认真的科学家都知道数据质量问题。考虑一下您可能认为简单的事 - 分析温度随时间的变化。您必须考虑到某些气象站搬迁，会以多种方式影响读数，由于设备问题引起的异常，传感器无法正常工作的丢失时段。尽管已经有了很多复杂的统计技术来解决数据质量问题，但科学家们仍然对数据质量持怀疑态度，并习惯于处理有问题的数据。因此，对于他们来说，数据之所以重要，是因为他们可以使用原始数据，并且可以故意考虑应用使之有意义的技术，而不是某种可能带来更大危害的不透明的数据清除机制。

数据仓库通常不仅会清理数据，还会将数据聚合成一种易于分析的形式。但是科学家们也倾向于反对这一观点，因为聚合意味着丢失数据。数据湖应包含所有数据，因为您不知道今天或者几年后人们会发现有价值的东西。

我的一位同事最近的一个例子中说明了这种想法：我们正在尝试将自动预测模型域公司交易经理进行的手动预测进行比较。为此，我们决定对已有的数据（几年的旧数据）进行训练，并将预测结果与经理们预测的作比较。由于我们现在知道正确的结果，因此这应该是个公平的准确性测试。当我们开始执行此操作时，我们发现经理的预测似乎太可怕了，甚至短短两周之内建立的模型也能将其粉碎。我们甚至怀疑这种出色的表现太好了，难以置信。经过大量的测试和挖掘，我们发现与这些经理预测相关的时间戳是错误的，某些月末处理报告对他们进行了修改。简而言之，数据仓库中的这些值是无用的。我们担心我们无法进行这种比较。经过更多的挖掘，我们发现这些报告已存储，因此我们可以提取当时的实际预测（我们再次粉碎了他们，虽然花了好几个月的时间）。

这些原始数据的复杂性意味着可以将数据整理成更易于管理的结构（并减少了可观的数据量）。数据湖不应该被直接访问。因为这些数据是原始数据，所以您需要大量的工作去理解它们。您有相对较少的人在数据湖工作，因为它们发现了该湖中通常有用的数据视图，因此他们可以创建许多数据集市，每个数据集市都具有针对单个有限上下文的特定模型。然后大量下游用户可以将这些湖案集市视为该背景下的权威来源。

到目前为止，我们已经将数据湖描述为在整个企业中集成数据的奇异点，但是我需要提醒着不是它原来的意图。这个术语 James Dixon 在2010 年提出的，当时他的确打算将一个数据湖用作单个数据源，而多个数据湖将形成一个“水花园”。尽管其原始表述是那样，现在的普遍用法是认为数据湖结合了多数据源。

您应该将数据湖用作分析目的，而不是用作操作系统之间的协作。当操作系统之间进行写作时， 他们应该通过为此目的而设计的服务来实现此目的，例如 RESTful HTTP 调用或异步消息传递。湖太复杂，无法拖网进行业务交流。对湖泊的分析可能会导致新的运营沟通路线，但这些路线应直接构建而不是通过湖泊构建。

重要的是，放入湖中的所有数据都应有明确的来源和时间。 每个数据项都应该清楚地跟踪它来自哪个系统以及何时生成数据。 因此，数据湖包含历史记录。 这可能是因为将Domain 事件 写入湖中，与事件数据源系统自然契合。 但是它也可能来自将当前状态定期转储到湖中的系统-这种方法在源系统没有任何临时功能但您需要对其数据进行临时分析时非常有用。 这样做的结果是，放入湖泊的数据是不可变的，一次观察结果一旦完成就无法删除（尽管以后可能会反驳），您可能会遇到矛盾的观察结果。

数据湖是无模式的，它取决于源系统来决定使用哪种 schema ,并由消费者确定如何处理造成的混乱。此外，数据源系统可以自由地任意更改奇流入数据的schema, 而消费者必须再次应对。显然，我们希望此类更改尽可能减少破坏性，但科学家更喜欢混乱的数据而不是丢失的数据。

数据湖将变得非常大，并且许多存储都围绕大型无模式结构的概念而来，这就是Hadoop和HDFS通常是人们用于数据湖的技术的原因。 湖岸市场的重要任务之一是减少您需要处理的数据量，以使大数据分析不必处理大量数据。

Data Lakes 对大量原始数据的需求引起了关于隐私和安全的尴尬问题。Datensparsamkei（Datensparsamkei是一个德语单词，很难翻译成英语，它是一种如何捕获数据和存储数据的态度 - 只处理我们需要的数据）的原理与数据科学家现在要捕获所有数据的愿望紧密相关。数据湖为“疯子”（crackers）制造了一个诱人的目标他们可能喜欢将感兴趣的部分吸入公共海洋。 将湖泊的直接访问限制在一个小型数据科学小组中可能会减少这种威胁，但是并不能避免该小组保持负责数据的隐私的问题。