第一件事，我认为您的问题很出色，以您揭示心理过程的方式，我可以说您已经有了答案。

您提到的

Data Lake的一般规则听起来像在摄取阶段不进行任何预处理。

这是哲学上的底线，所有在这种容易简化的想法上的炒作都在增长。

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

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

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

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中删除前两个字符串，并将可读数据保存在“原始”存储层中
   • 为了保护自己免受“我们看不到这种情况的发生”的影响，请保留一个元数据存储桶，在其中保存删除了这两行的简单文件，以便将来在需要时可以访问它们，并且您可以回覆任何有不同意见的人，将来他们可以说“您不应该删除它”。但是我之所以这样说，是因为我无法想象这两行是什么，也许这完全是过分的了。

就个人而言，我喜欢数据湖，也喜欢每个系统背后的理念，但我也想逐案地询问所有问题。我在平面文件，json，csv和基于此的大量生产工作量中有大量数据。但是，我的数据湖中最美丽的部分并不是真正未经处理的数据，我们发现进行第一次最小限度的清理非常强大，并且在可能的情况下（对于具有基本插入而不是更新的数据），还可以将其转换为Parquet或ORC，甚至压缩它。而且我可以告诉您，我真的很喜欢使用这些数据，甚至可以直接对它运行查询。原始数据是，但可用。

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

• 在火花读取中使用处理“不良记录”选项，例如：

spark.read
  .option("badRecordsPath","/tmp/badRecordsPath")
  .format("csv")
  .load("/input/csvFile.csv")

Reference "Handling bad records and files"

Reference "CSV files"

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

• 要在写入时执行模式检查，请使用 看看Delta Lake open source project，它具有关于写入强制和ACID事务的架构，以提高可靠性。

• Managed Delta Lake将使您可以使用OPTIMIZE命令Databricks Delta Lake Optimize command

  来打包您的小文件
  • 由于采用了ACID事务处理和装箱，Spark Structured Streaming和Delta Lake可以很好地配合以继续Nifi正在执行的流数据采集。