Data Lake：修复 Ingestion 与 ETL 上损坏的文件
Data Lake: fix corrupted files on Ingestion vs ETL
Objective
我正在构建数据湖，一般流程看起来像 Nifi -> 存储 -> ETL -> 存储 -> 数据仓库。
Data Lake 的一般规则在摄取阶段似乎没有 pre-processing。所有正在进行的处理都应该在 ETL 中进行，因此您可以了解原始数据和已处理数据的来源。
问题
源系统发送损坏的 CSV 文件。意味着除了 header 和数据之外，第一行总是我们永远不会使用的自由格式元数据。只有单个 table 已损坏，损坏的 CSV 目前由单个 Spark 作业使用（我们称之为 X）。
问题
移除 Nifi 层的那两条线是一种好方法吗？ 请参阅 "Workarounds" 处的选项 3。
解决方法
- 处理 Spark 作业中损坏的记录
X。恕我直言，这是一种糟糕的方法，因为我们将来会在不同的工具中使用该文件（数据治理模式爬虫，也许 Athena/ADLA-like 引擎超过 ADLS/S3）。意味着应该在多个地方实施损坏的记录处理逻辑。
- 修复ETL层损坏的文件并将它们存储在"fixed"层。所有正在进行的活动（ETL、数据治理、MPP 引擎）将仅适用于 "fixed" 层，而不是 "raw" 层。这对我来说听起来是一种开销，为单个 CSV 创建一个新层。
- 在 Nifi 层修复（从 CSV 中删除前两个字符串）。意味着 "raw" 存储层将始终包含可读数据。恕我直言，这很好，因为它很简单并且处理逻辑在一个地方实现。
首先，我认为你的问题很精彩，从你揭示心理过程的方式来看，我可以说你已经有了答案。
如你所说
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.
这是一个基本定义，但让我们将其用作"appeal to authority"。他们说得很清楚，你可以存储数据"as-is"。
- 我的第一个问题是："you can" 是严格意义上的 "you should" 吗？此外，他们提到它允许您 "run different types of analytics—from dashboards and visualizations to big data processing"，等等
- 我的第二个问题是：如果数据在已知情况下实际上是不稳定的……无论如何将它转储到那里是否合法？
同上link，下面一点，也说
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.
总的来说，我看待它的方式是，将所有东西都扔在那里以遵循 "no preprocessing, is a general attempt of being more catholic than the pope, or maybe a general tendency to oversimplify the rules. I believe that the idea of " 原样”的规则，并且它的力量更多地体现在不进行数据过滤或转换的方向上在注入中，假设我们真的不知道未来所有可能的用例是什么，所以拥有原始数据是好的和可扩展的。但这并不意味着拥有我们知道已损坏的数据是好的，我相信质量始终是对数据的要求，并且在所有阶段至少应该是可访问的。
这让我想到了下一个想法：一个反复出现的想法是数据湖允许读取模式 (AWS, Intuit, IBM, O'Reilly)。因此，如果我们不想让可能想要使用它的每个人的生活过于复杂，那么尽可能多地保留某种模式的东西是有意义的，否则，我们可能会在某些情况下使它变得无用使用它的开销可能令人沮丧。实际上，上面那篇名为 "the death of schema on read" 的 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 中进行一些查询，或者 运行 一些 Spark 作业处理大量 gzip 文件，感觉我们正处于生活的神奇时刻。但后来这个小污染来了，我们接受了它，有一天 S3 桶不是 10，而是 100，小异常不是 2，而是 20，需要记住的事情太多，事情变得越来越混乱。
最终这是基于意见的。但我会说可用的数据会让你未来的自己更快乐。
说到这里，我会去你的选项：
处理 Spark 作业 X 中损坏的记录。你说的。那就是讨厌你自己和你的团队，诅咒他们去做本可以避免的工作。
修复ETL层损坏的文件并将它们存储在"fixed"层。你说了算，开销太大了。您将不断地尝试删除第一层。实际上，我预测您最终会采用生命周期策略来自动删除旧对象以节省成本。
看起来干净利落。没人能告诉你"that is crazy"。您唯一需要确定的是，您要删除的数据实际上与业务无关，并且没有您现在无法想象的未来用途。即使在这种情况下，我也会采取一些安全的方法：
- 在Nifi层去掉CSV的前两个字符串，将可读数据保存在"raw"存储层
- 为了保护自己免受 "we didn't see this coming" 的影响，请保留一个元数据存储桶，您可以在其中保存删除了这两行的简单文件，以便将来需要时可以访问它们，并且您可以以后有不同意见的可以回复一下"you shouldn't have deleted that"。但我这么说是因为我无法想象那两条线是什么，也许这完全是矫枉过正。
就个人而言，我喜欢数据湖，我喜欢每个系统背后的哲学，但我也喜欢逐案质疑一切。我在平面文件、json、csv 和基于这些的大量生产工作负载中有大量数据。但是我的数据湖中最美丽的部分并不是真正纯粹的未处理数据，我们发现进行第一次最小清理非常强大，并且在可能的情况下 - 对于基本上是插入而不是更新的数据 - 也将其转换为 Parquet 或 ORC 和甚至用 snappy 压缩它。我可以告诉你，我真的很喜欢使用这些数据，甚至 运行 直接查询它。原始数据是的，但可用。
我喜欢接受的答案中提供的理念，但我想提供更具战术性的答案...
- 在 spark read 上使用 handle 'bad records' 选项，例如：
spark.read
.option("badRecordsPath", "/tmp/badRecordsPath")
.format("csv")
.load("/input/csvFile.csv")
Reference "Handling bad records and files"
您可以将其与架构选项 .schema(customSchema) 代码一起使用，以在作业的读取端获得一定程度的架构验证（以及更好的性能）。
要在写入时执行架构检查，请执行
查看 Delta Lake open source project，它具有关于写入执行和 ACID 事务的模式以提高可靠性。
Managed Delta Lake 让您可以使用 OPTIMIZE 命令 Databricks Delta Lake Optimize command
对您的小文件进行 bin 打包
- 由于 ACID 事务和装箱，Spark Structured Streaming 和 Delta Lake 可以很好地协同工作以继续 Nifi 正在执行的流数据采集。
Objective
我正在构建数据湖，一般流程看起来像 Nifi -> 存储 -> ETL -> 存储 -> 数据仓库。
Data Lake 的一般规则在摄取阶段似乎没有 pre-processing。所有正在进行的处理都应该在 ETL 中进行，因此您可以了解原始数据和已处理数据的来源。
问题
源系统发送损坏的 CSV 文件。意味着除了 header 和数据之外，第一行总是我们永远不会使用的自由格式元数据。只有单个 table 已损坏，损坏的 CSV 目前由单个 Spark 作业使用（我们称之为 X）。
问题
移除 Nifi 层的那两条线是一种好方法吗？ 请参阅 "Workarounds" 处的选项 3。
解决方法
- 处理 Spark 作业中损坏的记录
X。恕我直言，这是一种糟糕的方法，因为我们将来会在不同的工具中使用该文件（数据治理模式爬虫，也许 Athena/ADLA-like 引擎超过 ADLS/S3）。意味着应该在多个地方实施损坏的记录处理逻辑。 - 修复ETL层损坏的文件并将它们存储在"fixed"层。所有正在进行的活动（ETL、数据治理、MPP 引擎）将仅适用于 "fixed" 层，而不是 "raw" 层。这对我来说听起来是一种开销，为单个 CSV 创建一个新层。
- 在 Nifi 层修复（从 CSV 中删除前两个字符串）。意味着 "raw" 存储层将始终包含可读数据。恕我直言，这很好，因为它很简单并且处理逻辑在一个地方实现。
首先，我认为你的问题很精彩，从你揭示心理过程的方式来看，我可以说你已经有了答案。
如你所说
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.
这是一个基本定义，但让我们将其用作"appeal to authority"。他们说得很清楚，你可以存储数据"as-is"。
- 我的第一个问题是："you can" 是严格意义上的 "you should" 吗？此外，他们提到它允许您 "run different types of analytics—from dashboards and visualizations to big data processing"，等等
- 我的第二个问题是：如果数据在已知情况下实际上是不稳定的……无论如何将它转储到那里是否合法？
同上link，下面一点，也说
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.
总的来说，我看待它的方式是，将所有东西都扔在那里以遵循 "no preprocessing, is a general attempt of being more catholic than the pope, or maybe a general tendency to oversimplify the rules. I believe that the idea of " 原样”的规则，并且它的力量更多地体现在不进行数据过滤或转换的方向上在注入中，假设我们真的不知道未来所有可能的用例是什么，所以拥有原始数据是好的和可扩展的。但这并不意味着拥有我们知道已损坏的数据是好的，我相信质量始终是对数据的要求，并且在所有阶段至少应该是可访问的。
这让我想到了下一个想法：一个反复出现的想法是数据湖允许读取模式 (AWS, Intuit, IBM, O'Reilly)。因此，如果我们不想让可能想要使用它的每个人的生活过于复杂，那么尽可能多地保留某种模式的东西是有意义的，否则，我们可能会在某些情况下使它变得无用使用它的开销可能令人沮丧。实际上，上面那篇名为 "the death of schema on read" 的 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 中进行一些查询，或者 运行 一些 Spark 作业处理大量 gzip 文件，感觉我们正处于生活的神奇时刻。但后来这个小污染来了，我们接受了它，有一天 S3 桶不是 10，而是 100，小异常不是 2，而是 20，需要记住的事情太多，事情变得越来越混乱。
最终这是基于意见的。但我会说可用的数据会让你未来的自己更快乐。
说到这里，我会去你的选项：
处理 Spark 作业 X 中损坏的记录。你说的。那就是讨厌你自己和你的团队，诅咒他们去做本可以避免的工作。
修复ETL层损坏的文件并将它们存储在"fixed"层。你说了算，开销太大了。您将不断地尝试删除第一层。实际上，我预测您最终会采用生命周期策略来自动删除旧对象以节省成本。
看起来干净利落。没人能告诉你"that is crazy"。您唯一需要确定的是，您要删除的数据实际上与业务无关，并且没有您现在无法想象的未来用途。即使在这种情况下，我也会采取一些安全的方法：
- 在Nifi层去掉CSV的前两个字符串，将可读数据保存在"raw"存储层
- 为了保护自己免受 "we didn't see this coming" 的影响，请保留一个元数据存储桶，您可以在其中保存删除了这两行的简单文件，以便将来需要时可以访问它们，并且您可以以后有不同意见的可以回复一下"you shouldn't have deleted that"。但我这么说是因为我无法想象那两条线是什么，也许这完全是矫枉过正。
就个人而言，我喜欢数据湖，我喜欢每个系统背后的哲学，但我也喜欢逐案质疑一切。我在平面文件、json、csv 和基于这些的大量生产工作负载中有大量数据。但是我的数据湖中最美丽的部分并不是真正纯粹的未处理数据，我们发现进行第一次最小清理非常强大，并且在可能的情况下 - 对于基本上是插入而不是更新的数据 - 也将其转换为 Parquet 或 ORC 和甚至用 snappy 压缩它。我可以告诉你，我真的很喜欢使用这些数据，甚至 运行 直接查询它。原始数据是的，但可用。
我喜欢接受的答案中提供的理念，但我想提供更具战术性的答案...
- 在 spark read 上使用 handle 'bad records' 选项，例如：
spark.read
.option("badRecordsPath", "/tmp/badRecordsPath")
.format("csv")
.load("/input/csvFile.csv")
Reference "Handling bad records and files"
您可以将其与架构选项 .schema(customSchema) 代码一起使用，以在作业的读取端获得一定程度的架构验证（以及更好的性能）。
要在写入时执行架构检查，请执行 查看 Delta Lake open source project，它具有关于写入执行和 ACID 事务的模式以提高可靠性。
Managed Delta Lake 让您可以使用
对您的小文件进行 bin 打包OPTIMIZE命令 Databricks Delta Lake Optimize command- 由于 ACID 事务和装箱，Spark Structured Streaming 和 Delta Lake 可以很好地协同工作以继续 Nifi 正在执行的流数据采集。