architecture - 数据湖 : fix corrupted files on Ingestion vs ETL

Question

客观的

我正在构建数据湖，一般流程看起来像 Nifi -> Storage -> ETL -> Storage -> Data Warehouse。

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

问题

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

题

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

解决方法

处理 Spark 作业中损坏的记录 X .恕我直言，这是不好的方法，因为我们将来会在不同的工具中使用该文件(数据治理模式爬虫，也许是 ADLS/S3 上的一些类似 Athena/ADLA 的引擎)。意味着应在多个地方实现损坏的记录处理逻辑。

在 ETL 层修复损坏的文件并将它们存储在“固定”层。所有正在进行的事件(ETL、数据治理、MPP 引擎)将仅适用于“固定”层，而不是“原始”层。这对我来说听起来像是一种开销，为单个 CSV 创建一个新层。

在 Nifi 层修复(从 CSV 中删除前两个字符串)。意味着“原始”存储层将始终包含可读数据。恕我直言，这很好，因为它很简单，并且处理逻辑在一个地方实现。

Answer 1

首先，我认为你的问题很精彩，从你揭露心理过程的方式来看，我可以说你已经有了答案。

正如你提到的

The general rule for Data Lake sounds like no pre-processing on the ingestion stage.

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

如果我们检查 AWS of what is a data lake 的定义.

A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.

这是一个基本定义，但让我们将其用作“对权威的呼吁”。他们明确表示您可以“按原样”存储数据。

我的第一个问题是:“你可以”是不是严格意义上的“你应该”？此外，他们提到它允许您“运行不同类型的分析——从仪表板和可视化到大数据处理”等。

我的第二个问题是:如果数据在任何情况下都故意不稳定……无论如何将其转储到那里是否合法？

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

The main challenge with a data lake architecture is that raw data is stored with no oversight of the contents. For a data lake to make data usable, it needs to have defined mechanisms to catalog, and secure data. Without these elements, data cannot be found, or trusted resulting in a “data swamp." Meeting the needs of wider audiences require data lakes to have governance, semantic consistency, and access controls.

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

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

到目前为止，我认为我的立场对自己来说非常明确——当我开始写回复时并没有那么多——但我会尝试用最新的引用资料来结束，那是我读了几次的文章。早在2014年就发表在gartner.com'新闻室，名为“ Beware of the Data Lake Fallacy”。整篇文章很有趣，但我会重点介绍这一部分

Data lakes, therefore, carry substantial risks. The most important is the inability to determine data quality or the lineage of findings by other analysts or users that have found value, previously, in using the same data in the lake. By its definition, a data lake accepts any data, without oversight or governance. Without descriptive metadata and a mechanism to maintain it, the data lake risks turning into a data swamp.

我同意这一点。一开始很有趣。保存所有内容，看到您填充了 S3 存储桶，甚至在 Athena 或 Presto 中运行一些查询，或者在大量 gzip 文件上运行一些 Spark 作业，并感觉我们正处于一个美好的生活时代。但是这个小污染来了，并且我们接受它，总有一天 S3 存储桶不是 10 而是 100，小异常(exception)不是 2 而是 20，要记住的事情太多，事情变得越来越困惑。

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

说到这里，我会去你的选择:

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

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

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

在Nifi层从CSV中删除前两个字符串，并将可读数据保存在“原始”存储层

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

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