ETL设计:应该使用什么队列而不是SQL表并且仍然能够并行处理?

问题描述 投票:0回答:1

需要您的帮助来重新设计系统。我们有非常简单的ETL,但也很旧,现在当我们处理大量数据时,它变得非常缓慢且不灵活

第一个过程是收集器过程:

收集器过程-始终启动

  1. 收集器从队列中收集消息(rabbitMQ)
  2. 将消息属性(JSON格式)解析为java对象(例如,如果JSON包含'id'和'name'和'color'之类的字段,我们将创建一个具有int字段'id'和字符串字段'name'的Java对象,以及字符串字段'color')
  3. 解析后,将对象作为具有对象中所有属性的CSV行写入CSV文件中>]
  4. 我们发送确认并继续到队列中的下一条消息
  5. 处理工作流程-每小时发生一次

  1. 名为'Loader']的进程>使用SQL INFILE LOAD将所有CSV文件(收集器输出)加载到DB名为'Input']的数据库表中,所有新行的状态均为“未处理”。输入表就像这个设计中的队列
  2. 一个名为'Processor'的进程从表中读取所有状态为'未处理'的记录,将其转换为java对象,进行一些扩充,然后将记录插入另一个表为'输出'的表] >使用新字段,**每次迭代我们并行处理1000行-并对数据库插入使用JDBC批处理更新**。
  3. 此流程中的主要问题:

    该消息在现有流程中不灵活

-如果例如要向JSON消息中添加新属性(例如,还添加'city'),则还必须添加列'城市”(由于CSV文件“加载”),该表包含大量数据,并且每次消息更改时都无法添加列。

我的结论

该表不是此设计的正确选择。

我必须摆脱CSV编写并删除'Input'表,才能拥有一个灵活的系统,我想到也许使用队列而不是像KAFKA这样的表,并且可能使用诸如KAFKA流之类的工具进行充实。 -这将使我更加灵活,并且每次我想向消息中添加字段时都不需要在表中添加列我将无法像今天一样并行处理这个巨大的问题。

我可以使用什么代替表格来使我并行处理数据?

需要您的帮助来重新设计系统。我们有非常简单的ETL,但也很旧,现在当我们处理大量数据时,它变得非常缓慢且不灵活,第一个过程是...

是,使用Kafka可以改善这一点。

摄取

您当前编写CSV文件的过程可以发布到Kafka主题。根据您的要求和范围,可以替换RabbitMQ。

装载程序(可选)

您以初始格式]加载数据并写入数据库表的其他进程可以改为以所需格式发布到另一个Kafka主题。如果可以直接以处理器所需的格式编写,则可以省略此步骤。

处理器

您使用'Not handled' status的方式是将数据视为队列的方式,但这是由Kafka中的设计方法使用的,该设计使用log

(关系数据库建模为set )。

处理器订阅由加载程序或提取写入的消息。它将其转换为java对象,进行一些充实-但是可以将数据发布到新的output-topic上,而不是将结果插入到新表中。

而不是在batches中进行工作:“每次迭代我们都并行处理1000行-并且使用JDBC batchupdate进行DB插入”和Kafka并进行流处理,这是在连续的实时流中完成的-随着数据的到达。

模式可演化性

[例如,如果我想向json消息中添加新属性(例如,还添加'city'),我还必须在表中添加列“ city”(由于csv infile加载),表中包含大量数据量,并且每次消息更改时都无法添加列。

发布到Kafka主题时,可以使用Avro Schema解决此问题。

java design-patterns architecture bigdata etl
1个回答
0
投票

是,使用Kafka可以改善这一点。

摄取

© www.soinside.com 2019 - 2024. All rights reserved.