Spark 中的合并数据模式答案

【问题标题】：Merge data pattern in SparkSpark 中的合并数据模式
【发布时间】：2017-08-19 11:41:17
【问题描述】：

我在 hdfs 中有大约 6TB 的数据，分区为 hdfs://products/yyyy/mm/dd/hh 让我们称之为dataset1。我每天的数据大小约为 5GB，我们称之为 dataset2，我需要根据连接条件将其插入/更新到 6TB。

我正在努力完成的任务如下

我需要使用 Spark 来实现这一点，我的问题是，每天读取 6TB 以查找存在于 5GB 大小文件中的客户 ID 是否会高效。

您能否建议使用 Spark 的替代合并模式？

【问题讨论】：

【解决方案1】：

像这样的“大数据”用例的架构可以成为一本书的主题。

事实上，它已经--大数据 由 Nathan Marz，以前的 Twitter。详细了解他的 Lambda 架构here。

在一个非常高、过于简单的层面上，这个想法是将所有原始数据（事实来源）放入“批处理层”（例如 HDFS），运行分析（例如使用 Spark）将“批处理视图”（本质上是数据的索引）预计算到“服务层”中，然后通过运行分析、创建视图并最终在“速度层”中处理新数据将这些数据与批处理层和服务层合并。

这似乎是您应该根据自己的情况考虑的那种架构。

基于流而不是批处理的更简单的方法是 Jay Kreps 的 Kappa Architecture，他是 LinkedIn 的前成员。我实际上更喜欢 Kappa 架构，但如果您没有实时数据流，则不适用。

我认为您应该阅读 Nathan 的书并非常仔细地阅读每天到达速度层的最新数据如何与包含可追溯到“时间开始”的数据的服务层和批处理层合并。我提到的资源中的案例研究应该可以帮助您以适合您业务的方式进行设置。

【讨论】：

我喜欢不可变主数据的想法。但是批处理视图处理仍然会在每次批处理运行时处理所有数据，我可以想象随着逻辑变得更加复杂，执行将需要很长时间。我仍然会问同样的问题，是否应该在 Spark 中使用优雅的 Merge 模式来合并批处理数据中的数据？
你误解了架构。批处理层不会每次都处理所有数据。批处理层和服务层基本上将使用您当前拥有的所有数据运行一次。然后所有 新数据 将由速度层处理，并且有一个过程获取新数据和索引并将新增量与批处理中的数据合并，服务层。我知道这很复杂，但如果 Lambda 架构缓慢且效率低下，显然它不会有一本书和众多实现。
让我们举一个具体的例子。我有 6TB 文件，其属性包括 EventDate、TransactionType、BalanceBeforeAdjustment、Final Balance。我每天收到大约 5GB 大小的文件，其中包含新记录以及对现有记录的更新。我可以在 Merge Key 上对 New 和 Batch 数据进行分区，以减少 Spark 需要处理的数据量。但我需要处理这些数据，进一步应用分析函数，与其他数据连接，最后生成最终用户可以理解的事实表。事实表也需要增量加载。