目标
我正在构建数据仓库，一般流程看起来像Nifi->Storage->ETL->Storage->Data Warehouse。
Data Lake的一般规则听起来像是在摄入阶段没有预处理。所有正在进行的处理都应该在ETL中进行，这样你就可以在原始&处理后的数据。
问题
源系统发送损坏的CSV文件。意味着除了标题和数据之外，前几行总是我们永远不会使用的自由格式元数据。只有一个表被损坏，损坏的CSV目前由单个Spark作业使用(让我们称之为X)。
问题
去除Nifi层的这两条线是一个好方法吗请参阅"解决方法"中的选项3。
解决方法
- 处理Spark作业
X中损坏的记录。IMHO，这是一种糟糕的方法，因为我们将来会在不同的工具上使用该文件(数据治理模式爬网程序，可能是ADLS/S3上的一些类似Athena/ADLA的引擎)。意味着损坏的记录处理逻辑应该在多个地方实现 - 修复ETL层上损坏的文件，并将其存储在"固定"层。所有正在进行的活动(ETL、数据治理、MPP引擎)将仅使用"固定"层，而不是"原始"层。这听起来像是一种开销，为单个CSV创建一个新层
- 在Nifi层修复(从CSV中删除前两个字符串)。意味着"原始"存储层将始终包含可读数据。IMHO，这很好，因为它很简单，并且处理逻辑在一个地方实现
首先，我认为你的问题很精彩，从你揭示心理过程的方式来看，我可以说你已经有了答案。
正如你提到的
Data Lake的一般规则听起来像是在摄入阶段没有预处理。
这是哲学的底线，所有的炒作都在这个容易过于简单化的想法上愈演愈烈。
如果我们检查AWS对什么是数据湖的定义。
数据湖是一个集中的存储库，允许您以任何规模存储所有结构化和非结构化数据。您可以按原样存储数据，而无需首先构建数据结构，并运行不同类型的分析——从仪表板和可视化到大数据处理、实时分析和机器学习，以指导更好的决策。
这是一个基本定义，但让我们将其用作"对权威的呼吁"。他们明确表示，您可以"按原样"存储数据。
- 我的第一个问题是："你可以"严格地说是"你应该"吗？。此外，他们还提到，它允许您"运行不同类型的分析——从仪表板和可视化到大数据处理"等
- 我的第二个问题是：如果数据实际上是故意不稳定的。。。把它扔在那里合法吗
在同一个链接中，下面一点，也说
数据湖架构的主要挑战是存储原始数据时不需要对内容进行监督。为了使数据可用，数据湖需要有定义的机制来编目和保护数据。如果没有这些元素，就无法找到数据，也无法信任数据，从而导致"数据沼泽"。满足更广泛受众的需求需要数据湖具有治理、语义一致性和访问控制。
总的来说，我的看法是，把所有东西都扔到那里，遵循"没有预处理"的规则，这是一种比教皇更信奉天主教的普遍尝试，或者可能是一种过于简化规则的普遍倾向。我相信"照原样"的想法"，它的力量更多地朝着不在注入中进行数据过滤或转换的方向发展，假设我们真的不知道未来所有可能的用例是什么，那么拥有原始数据是好的和可扩展的。但这并不意味着拥有我们知道已损坏的数据就是好的，我相信质量始终是数据的要求，在所有阶段都应该最不容易接近。
这让我想到了下一个想法：一个非常重复的想法是，数据湖允许读取模式(AWS、Intuit、IBM、O'Reilly)。因此，如果我们不想让每个可能想使用它的人的生活过于复杂，那么尽可能多地使用某种模式是有意义的，否则，我们可能会在某些情况下使它变得无用，因为使用它的开销可能会令人沮丧。事实上，奥在上面的一篇文章中称之为"阅读中模式的死亡"，正是谈到了缺乏治理所增加的复杂性。所以我想消除一些混乱将有助于数据湖的成功。
到目前为止，我认为我的立场对自己来说非常清楚——当我开始写回应的时候并没有那么清楚——但我会尽量用最新的参考资料来总结，那是我读过几次的一篇文章。早在2014年，这本书就在gartner.com的新闻发布室发表，名为《警惕数据湖谬误》。整篇文章很有趣，但我将重点介绍的这一部分
因此，数据湖具有巨大的风险。最重要的是，无法确定其他分析师或用户的数据质量或发现的谱系，这些分析师或用户以前在湖中使用相同的数据时发现了价值。根据其定义，数据湖接受任何数据，而无需监督或治理。如果没有描述性元数据和维护机制，数据湖就有可能变成数据沼泽。
我同意这一点。一开始很有趣。保存所有内容，看到你填充了S3桶，甚至在Athena或Presto中运行了一些查询，或者在许多gzip文件上运行了一些Spark作业，感觉我们正处于一个神奇的时代。但后来这个小污染来了，我们接受了它，有一天S3桶不是10而是100，小例外不是2而是20，太多的事情需要记住，事情变得越来越混乱。
最终，这是基于观点的。但我想说，有用的数据会让你未来的自己更快乐。
这么说，我会去你的选择：
-
处理Spark作业X中损坏的记录。你说了。那会恨你自己和你的团队，诅咒他们做一项可以避免的工作。
-
修复ETL层上损坏的文件，并将其存储在"固定"层。你说的，太夸张了。您将不断尝试删除第一层。事实上，我预测你最终会有一个生命周期策略，自动删除旧对象以节省成本。
-
看起来整洁而诚实。没有人能告诉你"这太疯狂了"。你唯一需要确保的是，你将删除的数据实际上与业务无关，而且在未来不会有你现在无法想象的用途。即使在这种情况下，我也会遵循一些安全的方法：
- 从Nifi层的CSV中删除前两个字符串，并将可读数据保存在"原始"存储层中
- 为了保护自己免受"我们没有看到这一点"的影响，保留一个元数据桶，在其中保存删除了这两行的简单文件，这样你就可以在未来访问它们，如果需要的话，你可以回复任何有不同意见的人，他们可以在未来说"你不应该删除它"。但我这么说是因为我无法想象这两条线是什么，也许这完全是夸大其词
就我个人而言，我喜欢数据湖，我喜欢每个系统背后的哲学，但我也喜欢逐一质疑一切。我在平面文件、json、csv中有很多数据，还有很多基于此的生产工作负载。但我的数据湖中最美丽的部分并不是纯粹的未处理数据，我们发现，进行第一次最小限度的清理非常强大，并且在可能的情况下，对于从根本上插入而不是更新的数据，还可以将其转换为Parquet或ORC，甚至可以快速压缩。我可以告诉你，我真的很喜欢使用这些数据，甚至可以直接对其进行查询。原始数据是的，但可用。
我喜欢公认答案中提供的哲学，但我想提供一个更具策略性的答案。。。
- 在火花读取上使用句柄"坏记录"选项，例如：
spark.read
.option("badRecordsPath", "/tmp/badRecordsPath")
.format("csv")
.load("/input/csvFile.csv")
参考"处理不良记录和文件">
参考"CSV文件">
您可以将其与模式选项.schema(customSchema)代码一起使用，以在作业的读取端获得一定级别的模式验证(以及更好的性能)。
若要在写入时执行架构检查，请执行看看DeltaLake开源项目，它有写强制和ACID事务的模式，以获得更高的可靠性。
Managed Delta Lake将允许您使用
OPTIMIZE命令Databricks Delta Lake Optimize命令对小文件进行垃圾打包- 由于ACID事务和bin打包，Spark Structured Streaming和Delta Lake非常好地合作，以继续Nifi正在执行的流数据采集