ACM通信
为什么“数据湖”实际上是“数据沼泽”
最近我经常听到这样的说法:“我计划把我所有的数据放入一个数据湖，这样我的员工就可以对这个潜在的信息宝库进行分析。”这一观点也被一些在Hadoop生态系统中销售产品的供应商所推崇。不幸的是，它有一个严重的缺陷，我在这篇文章中用我在麻省理工学院的一个同事的数据(大部分是伪造的)说明了这个缺陷。
考虑两个包含雇员数据的非常简单的数据源。第一个数据源有表单的记录:
雇员(姓名、工资、爱好、年龄、城市、州)
而第二个包含的数据布局为:
个人(p-id，工资，地址，生日，出生年份，点赞)
来自第一个数据集的一个示例记录可能是:
(Sam Madden, 4000美元，{自行车，狗}，36岁，剑桥，马萨诸塞州)
第二个数据集中的一个例子可能是:
Samuel E. Madden, 5000美元，Newton Ma。1985年10月4日，骑自行车)
第一个合理的步骤是将这些记录组装到一个单独的位置，以便进行后续处理。这摄取步骤是一个的第一阶段数据管理处理过程包含以下组件:
摄取:必须按照上面所述的方式组装数据源。
数据转换: address字段必须分解为其组成部分city和state。同样，“年龄”必须从“出生年份”和“生日”计算。
模式集成。p-id和name的意思是一样的，这个事实必须被确定。类似的语句适用于记录中的其他属性，以及转换后的字段。
数据清理．山姆·马登的两份薪水是不同的数字。其中一个或两个都可能是错误的。或者，两者都可能是正确的;例如，一个可以是包括咨询费在内的工资总额，而另一个可以代表个人的W-2工资。同样，Sam也只能有一个年龄。因此，一个(或两个)数据源具有不正确的信息。
实体整合．必须确定山姆·马登的两份记录是同一个人的，而不是两个不同的人。然后，必须将两个记录合并到一个复合记录中。在这个过程中，需要对Sam的爱好做出决定(通常称为合并规则)。例如，“bike”和“bicycle”是一样的东西吗?
有几条评论是显而易见的。数据管理是一个迭代的过程。在应用了其中一些步骤之后，回过头来重复其他一些步骤可能是有意义的。例如，实体合并可能会揭示Sam的工资和年龄问题。因此，需要进一步的数据清理。实际上，数据管理是一个包含一些回溯的处理步骤的工作流。
其次，一些数据管理步骤将需要人工参与。期望自动系统完成全部工作是不合理的。此外，在许多环境中，需要专家提供必要的人类判断。例如，基因组数据的整合需要一个熟练的生物学家，而不能通过普通的人群来源技术来完成。
第三，真实世界的数据通常非常肮脏。坊间证据表明，防火墙内高达10%的企业数据是不正确的。因此，任何认为他的麻烦在他摄入了他的数据源之后就结束了的人都是可悲的错误。剩下的四个步骤将是非常昂贵的。
实际上，与其他四个步骤相比，摄入阶段是微不足道的。因此，在未经策划的“数据沼泽”中摄取数据只是数据整合的冰山一角。要把沼泽变成数据湖，还需要投入大量的努力。
这个故事的寓意是“不要低估数据管理的难度”。如果您这样做了，您将重新审视一条老路，即20世纪90年代企业在数据仓库方面的经验。当时流行的策略是将面向客户的数据集合到数据仓库中。然后，业务分析师可以使用结果来确定客户行为，并做出更好的销售决策。当时的平均数据仓库项目超出预算2倍，延迟2倍，因为数据管理问题被低估了。不要重复那个特别的错误。
评论
凯伦·洛佩兹
从最初的1和0被扔到数据存储的粪坑里开始，这些数据格式和含义的挑战就一直伴随着我们。
我们在一个又一个项目中看到了对数据质量的过度自信。尽管这些人在完成当前数据库设计时做出了同样糟糕的选择，但我还是看到了这一点。有某种设计健忘症或阻塞，导致专业人员相信每个其他数据源都有良好的设计、可靠的数据管理和易于理解的数据沿袭。尽管他们自己的设计与数据可用性(年龄、工资)相悖。
我们在每个项目中都在重复过去的失败，因为我们很少教授数据原理，很少为数据质量努力进行预算和计划，也很少让数据专业人员敢于“放慢项目进度”，以理解和为我们的解决方案构建可靠的数据组件。
我们工作的环境中，构建应用程序的方式是深刻的数据痴呆和疾病感失认症。对于我们这些从事数据管理职业的人来说，看到其他专业人士对他们所处理的数据了解得更少，或者根本不关心数据是否可用，这是令人恼火的。当然，有些人害怕限制数据的想法，但可以肯定的是，即使是新开发人员也可以看到捕获的不是年龄，而是出生日期(以及理解年龄所需的其他部分)的权衡。
原始系统需要时间、预算和资源来确保数据在写入时不被损坏。这种情况很少发生，随后会造成各种不必要的成本、风险和伤害。如果我们真的是专业人士，我们会解决这个问题。
卡西迪艾伦
不能超过几行代码!
显示所有2评论