2

客观的

我正在构建数据湖，一般流程看起来像 Nifi -> 存储 -> ETL -> 存储 -> 数据仓库。

Data Lake 的一般规则听起来像是在摄取阶段没有预处理。所有正在进行的处理都应在 ETL 进行，因此您对原始和处理过的数据有出处。

问题

源系统发送损坏的 CSV 文件。意味着除了标题和数据之外，第一行总是我们永远不会使用的自由格式元数据。只有单个表损坏，损坏的 CSV 目前由单个 Spark 作业使用（让我们称之为X）。

问题

在 Nifi 层删除这两条线是一个好方法吗？请参阅“解决方法”中的选项 3。

解决方法

  1. 处理 Spark 作业中损坏的记录X。恕我直言，这是一种不好的方法，因为我们将来会在不同的工具上使用该文件（数据治理模式爬虫，可能是一些 Athena/ADLA 类引擎而不是 ADLS/S3）。意味着应该在多个地方实现损坏的记录处理逻辑。
  2. 修复 ETL 层上损坏的文件并将它们存储在“修复”层。所有正在进行的活动（ETL、数据治理、MPP 引擎）仅适用于“固定”层，而不是“原始”层。这对我来说听起来像是一种开销，为单个 CSV 创建一个新层。
  3. 在 Nifi 层修复（从 CSV 中删除前两个字符串）。意味着“原始”存储层将始终包含可读数据。恕我直言，这很好，因为它很简单，并且处理逻辑在一个地方实现。
4

2 回答 2

1

首先，我认为您的问题很精彩，并且在您展示心理过程的方式中，我可以说您已经有了答案。

正如你提到的

Data Lake 的一般规则听起来像是在摄取阶段没有预处理。

这是哲学底线，所有的炒作都围绕着这个容易过度简化的想法。

如果我们检查AWS 对什么是数据湖的定义。

数据湖是一个集中式存储库，可让您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据，而无需首先构建数据，并运行不同类型的分析——从仪表板和可视化到大数据处理、实时分析和机器学习，以指导更好的决策。

这是一个基本定义，但让我们将其用作“诉诸权威”。他们清楚地说您可以“按原样”存储数据。

  1. 我的第一个问题是：“你可以”是否意味着“你应该”？此外，他们提到它允许您“运行不同类型的分析——从仪表板和可视化到大数据处理”等。
  2. 我的第二个问题是：如果数据在任何情况下故意不稳定......无论如何将其转储到那里是否合法？

在同一个链接，有点下面，也说

数据湖架构的主要挑战是原始数据的存储不受内容监督。为了使数据可用，数据湖需要定义机制来分类和保护数据。没有这些元素，就无法找到或信任数据，从而导致“数据沼泽”。满足更广泛受众的需求需要数据湖具有治理、语义一致性和访问控制。

总的来说，我的看法是，把所有东西都扔在那里以遵循“没有预处理”的规则，这是一种比教皇更天主教的普遍尝试，或者可能是一种过度简化规则的普遍趋势。我相信这个想法的“原样”，它的力量更多的是在不进行数据过滤或注入转换的方向上，假设我们真的不知道未来所有可能的用例是什么，所以拥有原始数据是好且可扩展。但这并不意味着拥有我们知道已损坏的数据是好的，我相信质量始终是数据的要求，并且在所有阶段至少应该是可访问的。

这让我想到了下一个想法：一个非常重复的想法是数据湖允许读取模式（AWS、Intuit、IBM、O'Reilly）。既然如此，尽可能多地保留某种模式的东西是有意义的，如果我们不想使每个可能想要使用它的人的生活过于复杂，否则，我们可能会在无用的情况下将其渲染为使用它的开销可能令人沮丧。实际上，上面的 O'Reilly 文章，名为“读取模式的死亡”，正是谈到了缺乏治理所增加的复杂性。所以我想消除一些混乱将有助于数据湖的成功。

到目前为止，我认为我的立场对我自己来说是非常清楚的——当我开始写回复时并没有那么多——但我会尝试用最新的参考资料来结束，那是一篇我读过几次的文章。早在 2014 年就在 gartner.com 的新闻发布室发表，名为《Beware of the Data Lake Fallacy》。整篇文章都很有趣，但我会强调这部分

因此，数据湖存在重大风险。最重要的是无法确定数据质量或其他分析师或用户的发现谱系，这些分析师或用户以前在使用湖中的相同数据时发现了价值。根据其定义，数据湖接受任何数据，无需监督或治理。如果没有描述性元数据和维护它的机制，数据湖就有变成数据沼泽的风险。

我同意这一点。一开始很有趣。保存所有内容，查看填充的 S3 存储桶，甚至在 Athena 或 Presto 中运行一些查询，或者在大量 gzip 文件上运行一些 Spark 作业，感觉我们正处于一个生活的神奇时刻。但随后这种小污染来了，并且我们接受它，有一天 S3 存储桶不是 10 而是 100，小例外不是 2 而是 20，要记住的事情太多，事情变得越来越混乱。

最终这是基于意见的。但我想说，可用的数据会让你未来的自己更快乐。

说这个，我会去你的选择：

  1. 处理 Spark 作业 X 中损坏的记录。您说过。那将是憎恨你自己和你的团队，诅咒他们做可以避免的工作。

  2. 修复 ETL 层上损坏的文件并将它们存储在“修复”层。你说的，开销太大了。您将不断尝试删除第一层。实际上，我预测您最终会采用生命周期策略来自动删除旧对象以节省成本。

  3. 看起来整洁而诚实。没有人能告诉你“这太疯狂了”。您唯一需要确保的是，实际上您将删除的数据与业务无关，并且将来没有您现在无法想象的可能用途。即使在这种情况下，我也会遵循一些安全的方法：

    • 在 Nifi 层从 CSV 中删除前两个字符串，并将可读数据保存在“原始”存储层中
    • 为了保护自己免受“我们没有看到这种情况发生”的情况，请保留一个元数据存储桶，您可以在其中保存删除了这 2 行的简单文件，以便您将来可以在需要时访问它们，并且您可以回复对于任何有不同意见的人，将来可以说“你不应该删除那个”。但我这么说是因为我无法想象这两行是什么，也许这完全是矫枉过正。

就个人而言，我喜欢数据湖，我喜欢每个系统背后的理念，但我也喜欢逐案质疑一切。我在平面文件、json、csv 中拥有大量数据，以及基于此的大量生产工作负载。但是我的数据湖最漂亮的部分并不是真正纯粹的未处理数据，我们发现进行第一次最小化清理非常强大，并且在可能的情况下 - 对于从根本上插入而不是更新的数据 - 也将其转换为 Parquet 或 ORC 和甚至用 snappy 压缩它。我可以告诉你，我真的很喜欢使用这些数据，甚至直接对它运行查询。原始数据是的，但可用。

于 2020-05-25T18:04:00.913 回答
1

我喜欢接受的答案中提供的哲学，但我想提供一个更具战术性的答案......

  • 在火花读取上使用句柄“坏记录”选项，例如：
spark.read
  .option("badRecordsPath", "/tmp/badRecordsPath")
  .format("csv")
  .load("/input/csvFile.csv")

参考“处理不良记录和文件”

参考“CSV 文件”

您可以将其与模式选项.schema(customSchema)代码一起使用，以便在作业的读取端也获得一定程度的模式验证（以及更好的性能）。

于 2020-05-31T00:01:30.723 回答