系统设计:每月大量进口CSV

Question

我们有一个webapp，它将依赖每月来自外部供应商的大型CSV。当我说大的时候，我们看到的是大约6gb，所以几百万行。可能是2-5辆CSV。此webapp还允许用户输入、更正和标记/删除数据。从供应商的角度来看，数据的列数和清洁度不能得到保证。此外，数据可能重叠(我们不能在我们的webapp中显示重叠的数据)。

我一直在想多种方法来解决这个问题：

1. 按照匹配列标题的CSV将这些CSV加载到表中，然后创建我们所需的“视图”。

这个解决方案似乎是最容易实现和维护的，因为我们每个月都可以将CSV导入到CSV表中，这样就可以了。它似乎效率最低，数据完整性问题最多。而且，这里的景色会很复杂。

1. 每个月将这些CSV加载到我们自己的模式中，并根据我们自己的模式构建我们的webapp。

这个解决方案似乎很难实现和维护，因为当每月导入时，您将不得不运行您的导入，这可能会破坏您现有的数据。这将是最好的，您的can应用程序是您自己的模式，您可以“映射”到它。此外，CSV将包含使旧数据无效的数据，因此很难更新。如果您要走这个路线，您会使用Java/C#或SQL进行导入吗？Java/C#似乎是有意义的，这样我们就可以处理业务规则，但速度更慢.

1. 将CSV加载到每个CSV表中，并对其运行SQL查询，以创建与per应用程序需要的模型相匹配的per应用程序。

此解决方案遇到与视图解决方案相同的问题，但现在您的SQL查询非常复杂，您很难维护它们。如果外部供应商更改了模式，它可能会中断SQL查询，尽管在导入之前更改CSV以匹配导入程序会出现问题。

然后我们有以下问题：

1. 如果用户更新CSV填充的行，比如我们使用#2，这正是我所倾向的，那么当CSV出现时，我们如何保存该更新呢？
   1. 我们如何能够回滚CSV导入？如果我们认为CSV导入一个月是好的，而现在我们有大量的用户生成的数据给那个CSV呢？

似乎没有一个琐碎的解决方案，无论哪种方式，我都必须“接受”。我有遗漏什么吗？有人能找到或想出一个琐碎的解决方案吗？

Answer 1

"CSV“不是他们给你的合适的词。这是他们提供给你的格式，而且保证很弱。大多数人把不可靠和丢失数据的6GB CSV文件简单地称为“数据”，我认为这在这里更准确。你有一个供应商向你提供一些数据，你有责任以某种方式为你的客户提供服务。

每个月将这些CSV加载到我们自己的模式中，并根据我们自己的模式构建我们的webapp。

这看起来是最好的。您正在将业务逻辑应用于所提供的数据，以维护其完整性和性能。你的供应商向你提供很弱的担保，而你则为你的客户提供强有力的担保。他们给你的格式是一个长字符串。在任何一次技术面试中，如果他们要求建立对一个长字符串的持久访问，答案就是对其进行预处理，这就是您的建议。

您应该假设您的用户会要求提供更多关于如何与数据接口的功能。也许他们需要一个撤销按钮或审计日志，这两种日志都要求您拥有自己的专有(meta)-data。

将此与它们以清洁或功能格式(例如数据库)向您提供数据的情况进行对比。然后，您就会做出相同的决定，即自己拥有数据还是使用它们的格式，直到现在它们的格式才有更强的保证。

然后我们有以下问题：

这些都是好的、困难的问题，就像我说的，听起来您的公司正在为您的用户解决这些问题，是的，这些用例肯定鼓励使用您自己的模式。

从我的头顶上看，这似乎是一个版本控制问题，所以研究类似于“版本控制大数据”之类的问题。谷歌的一大热门：https://datascience.stackexchange.com/questions/5178/how-to-deal-with-version-control-of-large-amounts-of-binary-data

Answer 2

这在很大程度上取决于需求、“输入、更正和标记/删除数据”的确切含义，以及您对预处理和后处理的进一步要求。编辑是否按行进行？每一行都是完整的，还是该行中有不需要处理的块？完全手工操作，还是也有一些自动清理/预处理步骤？如何检测“重叠”？必须有一些标准来检测一行的标识。

您也没有说明随后在数据流中会出现什么。我想纠正数据本身是没有目的的，所以也需要考虑编辑完成后会发生什么:是否需要使用原始格式再次将数据写回CSV文件？它会在某个地方被储存/存档吗？还是会以完全不同的方式处理数据？

因此，一旦获得了这些总体需求，就应该创建一个数据模型/模式，该模型/模式完全支持所需的编辑和处理步骤，而不是更少。这可能在某种程度上是你的方法#2，但是

• 由于您提到了将来自不同月份的数据混合为一个问题，因此不需要集成它们--因此，每个月保持数据分开。拥有一个主表Datapool，其主键为"date“或"month"，可能是CSV文件名作为惟一属性，并将其他表创建为母版表的详细表。
• 建模您的用户和进程真正需要显示和编辑的部分数据；其余的数据可以保存在字符串列中。当你还不知道你是否需要的时候，不要把时间花在建模细节上。
• 确保您能够支持之后的所有步骤。了解这些需求将有助于您决定哪些数据必须保存，哪些数据可以忽略。

在创建数据模型时，请记住，数据可能不是您想要的质量。例如，可能不可能为编辑后应该唯一的每个属性设置所有“唯一”约束。

Answer 3

我们采用的解决方案是创建映射。该工具将抓取前n行数据，跳过任何看起来类似样板的数据，以便处理导入的人员能够看到数据和行标题的抽样以控制映射。

"CSV“模式由标题行(如果可用)和列数驱动。我们有一种方法将数据从CSV模式映射到应用程序模式。我们确实遇到了一些我们需要特别处理的事情：

• 所需列的默认值(在已知数据但不提供数据的情况下，所有记录都是相同的)
• 自定义日期格式识别(注意:当日期样本包括1/2/2018和1/3/2018时，很难检测哪个是月份，哪个是日期)

我肯定还有更多，但我离那个项目还有几年的路程。

此映射存储在数据库中，因此我们可以根据未来数据转储的头签名来查找它。它在处理数据格式方面有很大帮助。

处理过程包括数据读取和数据块写入数据库。这意味着阅读100行左右，在集合中准备它们，这样我们就可以更容易地消除噪音，然后将它们写在这个块中。当写入数据库时，它加快了数据导入速度，而不需要一次将所有内容都存储在内存中。

任何错误都被写入引用该文件的数据库记录中的CSV，这样我们就可以找出映射的错误所在(例如，月份和日期被反转，或者所需的列被稀疏填充)。CSV有行号、特定错误、导致问题的数据以及预期的目标列。

对您来说，更困难的问题是检测重复数据。只要您有高效的查询/搜索应用程序的数据存储，您就有以下几个选项：

• 将原始输入写入准备好的区域，然后作为单独的步骤进行后处理。
• 在进行过程中查询数据库。

折中之处在于，在将数据准备为已知模式时，第一个选项将以更快的速度吸收数据。允许您在映射实际可供使用之前对其进行分类。第二个选项将在一次传递中将您的数据准备就绪，但它可能需要10倍的处理时间。