「集成架构」Talend ETL 性能调优宝典

作为Talend的客户成功架构师,我花了大量时间帮助客户优化他们的数据集成任务——不管是在Talend数据集成平台还是大数据平台上。虽然大多数时候开发人员都有一个健壮的解决方案工具包来处理不同的性能调优场景,但我注意到一个常见的模式是,没有定义良好的策略来解决性能问题的根本原因。有时没有策略会修复一些直接的问题,但从长远来看,相同的性能问题会重新出现,因为原始设计中的核心问题没有得到解决。这就是为什么我建议客户使用结构化方法来调优数据集成任务的性能。拥有策略的一个关键好处是它是可重复的——不管您的数据集成任务是做什么,它们是多么简单还是多么复杂,以及作为集成的一部分而移动的数据量。

「集成架构」Talend ETL 性能调优宝典


「集成架构」Talend ETL 性能调优宝典


「集成架构」Talend ETL 性能调优宝典


瓶颈在哪里?

性能调优策略的第一步是确定瓶颈的来源。在设计的各个步骤中可能存在瓶颈。我们的目标不是同时解决所有的瓶颈,而是一次解决一个瓶颈。策略是首先确定最大的瓶颈,找出产生瓶颈的根本原因,找到解决方案并实现它。一旦实现了解决方案,我们就寻找下一个最大的瓶颈并解决它。我们不断迭代所有的瓶颈,直到找到最优的解决方案。

这里有一个例子来帮助你理解。您有一个Talend数据集成标准作业,它从Oracle OLTP数据库中读取数据,在tMap中进行转换,并将其加载到Netezza数据仓库中。

如果这个任务没有达到你的性能要求,我的建议是把这个任务分成三个不同的部分:

  • 从Oracle

  • 在Talend中进行转换

  • 写信给Netezza

上面列出的一个或多个任务可能会导致您的进程变慢。我们的目标是一次解决一个问题。找出瓶颈的一个简单方法是创建三个测试Talend作业来复制一个Talend作业的功能。大概是这样的:

1.作业1 -从Oracle读取:该作业将使用tOracleInput从Oracle读取,并使用tFileOutputDelimited写入到Talend作业服务器的本地文件系统中的一个文件。运行此作业并捕获吞吐量(行/秒)。如果吞吐量数字看起来不合理,那么来自Oracle source的查询就是瓶颈之一。

2. 作业2 -转换:使用tFileInputDelimited读取作业1中创建的文件,应用tMap转换,然后使用tFileOutputDelimited将另一个文件写到相同的本地文件系统中。吞吐量数字看起来如何?与作业1相比,它们是快得多还是慢得多,还是一样?

3.向Netezza写入:读取在Job2中创建的文件,并将其加载到Netezza数据库中,然后查看吞吐量。它们与工作1和工作2相比如何?

在运行这些作业时,您需要注意以下几点:

  • 首先,这些测试作业应该对本地文件系统进行读写操作——这是为了确保消除任何可能的网络延迟。

  • 第二件事—吞吐量(读取/转换/写入数据的速率)—是比运行时间更准确的性能度量。我们的目标是减少运行时间,并通过在数据集成管道的每个阶段增加吞吐量来解决这个问题。

让我们假设这是运行我们的测试的结果:

Job

Description

Throughput

Job 1

Read from Oracle

20000 rows/sec

Job 2

tMap transformation

30000 rows/sec

Job 3

Write to Netezza

250 rows/sec

基于上面的场景,我们可以很容易地指出Netezza是我们场景中的瓶颈,因为它具有最低的吞吐量*。

如果结果如下所示,我们可以得出这样的结论:从Oracle读取和从Netezza写入都存在瓶颈,我们需要同时解决这两个问题*。

Job

Description

Throughput

Job 1

Read from Oracle

500 rows/sec

Job 2

tMap transformation

30000 rows/sec

Job 3

Write to Netezza

250 rows/sec

*在我上面的简单用例中,我假设整个管道的行长度不变,也就是说,如果我们从Oracle读取10列,同样的10列通过转换和写作业传递。然而,在实际场景中,我们确实需要添加或删除列作为管道的一部分,我们需要选择吞吐量的替代度量,比如MBs/sec。

让我们消除这些瓶颈

在前一节中,我讨论了确定瓶颈的“位置”。在本节中,我们将对如何消除不同类型的瓶颈进行总结。

源的瓶颈

如果源是关系数据库,则可以与数据库管理员合作,以确保根据最佳查询计划优化和执行查询。它们还可以提供优化器提示来提高查询的吞吐量。它们还应该能够为具有GROUP BY或ORDER BY子句的查询添加新索引。

对于Oracle和其他一些数据库,Talend允许您在t输入组件中配置游标大小。游标大小定义了结果集的获取大小。一旦从数据库中检索到结果集,就将其存储在内存中,以便更快地处理。理想的大小由您的数据集和需求定义。您还可以与数据库管理员一起增加网络数据包的大小,从而允许在同一时间通过网络传输更大的数据包。

对于非常大的读操作,使用多个具有非重叠where子句的t输入组件将并行读分区创建为多个子作业。选择为where子句建立索引的列——这将使数据能够在多次读取之间均匀分布。通过在作业属性中启用“多线程执行”,每个子作业都可以并行运行

对于存储在网络共享存储上的文件源,请确保运行Talend作业服务器的服务器与承载文件的文件系统之间没有网络延迟。理想情况下,文件系统应该专门用于存储和管理数据集成任务的文件。在我的一次任务中,存储源文件的文件系统与邮件服务器备份共享—因此,当运行夜间邮件备份时,我们对文件系统的读取将显著减慢。与存储架构师一起消除所有这些瓶颈。

目标的瓶颈

大多数现代关系数据库支持批量加载。使用散装装载器,Talend绕过数据库日志,从而提高了性能。对于某些数据库,我们还提供了使用带有外部加载器的命名管道的选项。这消除了将中间文件写入磁盘的需要。

有时在加载之前删除索引和键约束有助于提高性能。您可以在成功完成加载之后重新创建索引和约束

对于更新,将数据库索引放在与在t输出组件中定义为键的列相同的列上将提高性能

对于网络共享存储上的文件目标,请遵循上面关于存储在网络共享存储上的源文件的指导原则

转换瓶颈

通过消除管道中不必要的行和列来减少Talend正在处理的数据量。可以通过使用tFilterRows和tFilterColumns组件来实现这一点

对于一些内存密集型组件,如tMap和tSortRow, Talend提供了将中间结果存储在磁盘上的选项。建议使用作业服务器本地的快速磁盘。这减少了在数据量增长时添加更多内存的需求。

有时,转换瓶颈的出现是因为一个试图同时做许多事情的大型单片作业。将如此大的作业分解为更高效的数据处理小作业。

有一些额外的优化技术解决瓶颈在工作层面上(如并行化,英语教学,内存优化等)不讨论这个博客的一部分,但你可以找到他们的信息和其他技术工作Talend的设计模式和最佳实践——第1部分、第2部分,第3部分和第4部分。

结论

成功地优化作业以获得最佳性能的关键因素是识别和消除瓶颈。性能调优的第一步是确定瓶颈的来源。是的,它确实涉及到创造额外的测试工作。但不要气馁,你必须付出额外的努力和时间来建立这些。根据我20多年的经验,这些努力是值得的。战略性的、可重复的性能和调优方法比战术的试错方法要有效得多。您还可以将学到的经验教训融入到您的过程中,并随着时间的推移进行改进。我希望本文能让您开始性能调优之旅,并祝您一切顺利。

上一篇:美团数据仓库的演进


下一篇:大数据ETL之Kettle基本理论与安装部署