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

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

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




瓶颈在哪里?

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

这里有一个例子来帮助你理解。您有一个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多年的经验,这些努力是值得的。战略性的、可重复的性能和调优方法比战术的试错方法要有效得多。您还可以将学到的经验教训融入到您的过程中,并随着时间的推移进行改进。我希望本文能让您开始性能调优之旅,并祝您一切顺利。

相关文章
|
7月前
|
存储 调度 C++
16 倍性能提升,成本降低 98%! 解读 SLS 向量索引架构升级改造
大规模数据如何进行语义检索? 当前 SLS 已经支持一站式的语义检索功能,能够用于 RAG、Memory、语义聚类、多模态数据等各种场景的应用。本文分享了 SLS 在语义检索功能上,对模型推理和部署、构建流水线等流程的优化,最终带给用户更高性能和更低成本的针对大规模数据的语义索引功能。
581 61
|
9月前
|
存储 数据挖掘 BI
2-5 倍性能提升,30% 成本降低,阿里云 SelectDB 存算分离架构助力波司登集团实现降本增效
波司登集团升级大数据架构,采用阿里云数据库 SelectDB 版,实现资源隔离与弹性扩缩容,查询性能提升 2-5 倍,总体成本降低 30% 以上,效率提升 30%,助力销售旺季高效运营。
552 9
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
11月前
|
人工智能 API 数据安全/隐私保护
Apifox 与 Apipost 的 API 文档引擎对比:底层架构、性能与可扩展性分析
深入探索市场上两大主流API工具——Apifox和Apipost的文档能力时,发现了令人惊讶的差距。这不仅仅是功能多寡的问题,更关乎开发效率与团队协作的质变。
|
SQL 缓存 分布式计算
vivo 湖仓架构的性能提升之旅
聚焦 vivo 大数据多维分析面临的挑战、StarRocks 落地方案及应用收益。 在 **即席分析** 场景,StarRocks 使用占比达 70%,查询速度提升 3 倍,P50 耗时从 63.77 秒缩短至 22.30 秒,查询成功率接近 98%。 在 **敏捷 BI** 领域,StarRocks 已完成 25% 切换,月均查询成功数超 25 万,P90 查询时长缩短至 5 秒,相比 Presto 提升 75%。 在 **研发工具平台** 方面,StarRocks 支持准实时数据查询,数据可见性缩短至 3 分钟,查询加速使 P95 延迟降至 400 毫秒,开发效率提升 30%。
vivo 湖仓架构的性能提升之旅
|
8月前
|
存储 JSON 数据处理
ClkLog埋点与用户行为分析系统:架构升级与性能全面提升
随着越来越多企业在实际业务中使用 ClkLog,数据规模和分析需求也不断提升,部分用户日活已经超过10万,为了顺应这一趋势,ClkLog 秉持 “开放透明、持续演进”的理念,推出了迄今为止最重要的一次性能优化升级。新版本在大规模数据处理与复杂查询场景中,性能表现实现了跨越式提升。经过多轮研发与严格测试,新版本现已正式上线:在原有付费版 1.0 的基础上架构全面升级,并同步发布全新的 2.0 版本。为用户带来更强的性能与更广的适用场景。
|
11月前
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
|
11月前
|
存储 缓存 分布式计算
高内存场景必读!阿里云r7/r9i/r8y/r8i实例架构、性能、价格多维度对比
阿里云针对高性能需求场景,一般会在活动中推出内存型r7、内存型r9i、内存型r8y和内存型r8i这几款内存型实例规格的云服务器。相比于活动内的经济型e和通用算力型u1等实例规格,这些内存型实例在性能上更为强劲,尤其适合对内存和计算能力有较高要求的应用场景。这些实例规格的云服务器在处理器与内存的配比上大多为1:8,但它们在处理器架构、存储性能、网络能力以及安全特性等方面各有千秋,因此适用场景也各不相同。本文将为大家详细介绍内存型r7、r9i、r8y、r8i实例的性能、适用场景的区别以及选择参考。