实时文章采集(OracleLogminer研大数据实时采集的逻辑进行性能测试并分析)

　　实时文章采集(OracleLogminer研大数据实时采集的逻辑进行性能测试并分析)

　　前言

　　FlinkX是袋鼠云自研的大数据中间件，主要用于离线同步和实时采集功能。在实际应用中，这个数据同步采集的逻辑我们最需要关注的是它的支持能力和采集速度，这些是它最直观的指标。通过对其支持能力的性能测试，发现FlinkX的性能瓶颈，并进行针对性的优化，提升中间件的能力。

　　本文对FlinkX中实时采集的功能和Oracle Logminer数据实时采集的逻辑进行了性能测试和分析，并分享了测试过程中的测试点和测试方法。

　　1.测试目的

　　FlinkX Logminer的性能测试主要是检测FlinkX在Oracle Logminer数据采集到Kafka过程中各个阶段的性能，并输出性能测试指标测试数据供后期优化使用。检测 FlinkX 的性能瓶颈，引导并逐步提升 FlinkX 在大数据量或复杂情况下的处理能力。对于大数据中间件的测试，不仅要关注其功能层面，更要关注其性能层面。中间件的数据处理能力的效率直接影响到业务的稳定性、可用性、数据时效性和客户体验，这些是最重要的问题。

　　2. 测试对象介绍

　　

　　

　　2.1. FlinkX

　　FlinkX 是基于 Flink 的批流统一数据同步工具。不仅可以采集静态数据，还可以支持MySQL、HDFS等，将数据源A的数据同步到数据源B。还可以采集实时变化的数据，比如MySQL binlog、Oracle Logminer、Kafka等。在执行采集时，FlinkX分为两部分逻辑。一部分是从原创数据源读取的逻辑，比如在MySQL或者Logminer中读取数据，另一部分是处理后写入读取到的数据 对应数据源的逻辑，比如写入HDFS，写入Kafka因此，对于FlinkX的性能测试，我们往往分两部分进行，一是读测试，二是写测试。由于短板效应，某一点的短板可能导致整体采集的低效率。问题。

　　2.2. 登录矿工

　　Oracle 启动Logminer 后，所有对用户数据和数据字典的更改都会记录在Oracle Redo Log 中。通过Logminer对Redo Log的分析，可以得到所有的数据变化。经过分析，可以得到一些可以用于回滚的SQL语句，通常用于恢复数据库中某段数据的变化。

　　2.3. FlinkX实时采集逻辑

　　FlinkX常见的实时采集逻辑是先从源数据采集开始，经过数据处理后再写入目标数据源。比如本次测试中测试的FLinkX Logminer是来自Oracle的Logminer的FlinkX采集日志数据，处理日志数据后，将处理后的数据写入Kafka。FlinkX对Logminer的日志读取分为归档日志（ARCHIVE）读取和实时日志（ONLINE）读取。区别在于Redo Log中的数据是历史写入的归档数据还是实时写入的实时日志。图1-1。以此区分，我们将其分为两类进行测试，即存档数据和实时采集数据。

　　

　　

　　图1-1

　　3. 测试工具3.1. 测试工具介绍3.1.1. Arthas

　　Arthas 是阿里巴巴开源的 Java 诊断工具。其查看调用、调试、查看进程线程信息等功能对开发和测试有很大帮助。本次测试中，dashboard和thread主要用于查看进程线程的状态，profiler用于生成调用链接火焰图，定位被测对象的运行逻辑，调用采取的类或方法上更多的资源。

　　3.1.2. Grafana/Prometheus/EasyManager

　　Grafana 是一款优秀的开源数据可视化工具，常被用作测试中数据监控的显示面板工具。Prometheus 是 SoundCloud 开源的监控报警解决方案，用于存储服务器监控数据和时间序列。两者经常一起使用，通过一些exporter监控服务器资源或数据源状态，然后将数据存储在Prometheus中。Grafana 从 Prometheus 获取监控和存储的数据，并通过不同的监控面板显示给用户。方便测试人员更方便地对被测系统进行系统监控、数据分析和状态分析。

　　EasyManager是Digital Stack自主研发的运维工具。用于部署袋鼠云数字栈的各种应用。在本次测试中，我们主要借用了它的服务器资源监控功能，方便我们进行资源数据分析。这个也可以换。Grafana 监视器。

　　3.1.3. jstack

　　jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机中每个线程正在执行的方法栈的集合。生成线程快照的主要目的是定位线程中长时间停顿的原因，比如线程之间的死锁、死循环、外部资源请求导致的时间过长等。等待和等待的时间。当一个线程停滞时，可以通过jstack查看每个线程的调用栈，可以知道无响应的线程在后台在做什么，或者它在等待什么资源。

　　3.1.4. 甲骨文 AWR

　　AWR是Oracle 10g版本之后引入的新特性，全称是Automatic Workload Repository。它是Oracle提供的性能采集和分析工具，是Oracle性能调优的强大工具。它可以提供一段时间内整个系统的资源使用情况报告。

　　3.1.5. FlinkX BenchMark

　　基于JMH BenchMark框架，拆解FlinkX采集的每一步都是基于模仿FlinkX处理逻辑编写的性能测试工具。主要用于这个FlinkX Logminer采集性能测试执行工具。

　　3.2. 测试机器配置

　　中央处理器

　　内存

　　用

　　32C

　　64G

　　性能测试环境Hadoop集群节点一

　　32C

　　64G

　　性能测试环境Hadoop集群节点二

　　32C

　　64G

　　性能测试环境Hadoop集群节点三

　　32C

　　64G

　　性能测试环境 Oracle 数据源

　　16C

　　32G

　　性能测试环境执行端

　　4. 测试策略和重点

　　本次测试开始前，先梳理一下FlinkX的采集的逻辑，因为FlinkX对Logminer采集的处理主要是读取归档日志/实时日志，然后处理数据，然后写入数据针对不同的数据源，那么我们将整体逻辑拆分为归档日志处理（日志读取、数据处理）和实时采集（日志读取、数据处理、写入其他数据源）。对于归档日志处理，我们将其分为归档日志读取、归档数据处理、整体端到端（全链接）。我们分别测试几种不同的逻辑，看看哪一步需要很长时间。对于这一步的处理逻辑，我们将进行具体分析。对于实时采集部分，我们主要测试从Redo Log读取数据到写入Kafka的延迟，

　　对于上述测试内容，我们需要注意测试过程中归档日志的读取、处理速度、耗时。实时采集，数据从写入Oracle到采集到Kafka的延迟。这些是主要的输出测试指标。同时我们还需要关注采集端（Oracle）的资源占用，应用本身（FlinkX）的资源占用，线程情况，以及写端（Kafka）的监控情况。

　　对于Oracle端，需要注意是否有慢SQL，因为FlinkX会先执行SQL从Oracle Logminer获取Redo Log信息，然后这些SQL是否可以优化，是否有过长耗时的情况，这个需要注意。然后是数据库的负载情况。看Oracle整体空闲情况，资源是否充分利用，hard analysis的次数是否过高，是否有一些阻塞的情况。

　　对于FlinkX，我们需要关注应用本身的资源占用情况，通过Arthas分析JVM资源分配是否合理，调用环节中哪些类和方法占用资源过多，耗时长。通过jstack分析线程，看看有没有卡住、锁等。

　　对于写入端，我们主要关注不同条件下写入速度是否有影响，高差是否有波动。

　　5. 测试过程

　　一、首先我们需要启动Oracle Logminer并将日志大小设置为521M。打开Oracle Logminer和设置日志组大小的方法这里不再赘述，大家可以自己通过搜索引擎搜索。

　　二、根据我们的测试用例，分别执行归档日志部分和实时采集部分的测试用例。测试示例如图 5-1 所示：

　　

　　图 5-1

　　性能测试的测试用例设计需要保证单变量原则，方便比较。比如在本次测试中，根据不同的变量将测试用例划分为不同的类型，分别对监控表/日志大小/字段数的测试结果进行分析影响。

　　对于归档日志部分的测试，总体逻辑是先构造归档日志，然后通过FlinkX BenchMark模拟FlinkX来测试这部分归档日志。然后我们需要通过一些测试数据的工具，或者存储过程函数，将大量的测试数据插入到测试表中。然后通过SQL查询，注意生成的归档日志大小达到指定的数量级。比如我的测试用例是2G/20G/40G/80G，数据表的个数是10个，那么我需要同时写数据到10个表，生成的归档日志达到我需要的大小后停止数据写入。然后使用 FlinkX BenchMark 工具读取这些归档日志的指定 SCN 位置，对测试进行处理，并记录测试数据。当然，我们需要注意一些监控数据，

　　对于实时采集部分的测试，总体逻辑是FlinkX实时采集来自Logminer的数据，Oracle实时写入数据，FlinkX处理后写入Kafka，测试写入Oracle的数据和写入数据进入Kafka的延迟时间。我的逻辑是创建一个Oracle Logminer to Kafka实时采集 FlinkX任务并运行它，同时使用数据创建工具向Oracle写入数据，这样前半部分是完成，边读边写，然后实时采集任务将数据写入Kafka后，由于Kafka在写入数据时会有时间戳，因此使用FlinkX BenchMark获取Kafka中数据的时间戳即可计算数据延迟时间。

　　三、在测试过程中，需要关注各种监控数据，比如服务器资源、应用线程情况、数据源监控信息等。如果出现异常情况，比如高抖动CPU占用、线程一直在等待、数据源读写异常等，需要及时排查，通过jstack抓取栈的快照信息，分析是否有问题等。同时，在测试过程中，需要使用Arthas生成稳定运行时的火焰图，方便后续的数据分析。

　　四、 测试数据分析，通过测试过程中的数据监控情况，测试结果，各种测试用例的对比，分析本次测试中性能问题的定位，以及优化方案。

　　五、 输出测试报告和开发检查，确定后续优化方向和优化方案。

　　接下来我们分析具体用例的具体流程。

　　6. 数据分析

　　借用归档日志部分的测试用例，我们来看一下整个过程。本文文章使用归档日志20G大小，监控一张表进行分析。

　　

　　首先，在执行测试的过程中，我们需要观察测试执行端（FlinkX BenchMark）对拆分后的每个部分（日志读取/数据处理/全链接）的资源占用情况。这里我汇总了链路的监控状态来分析，先查看CPU和内存的使用情况。从图6-1我们可以发现，整体资源占用比较稳定，没有出现异常的急剧增减，基本是在一定区间内来回的小抖动。这种情况一般不会出现异常，但是如果出现较大的峰谷，则需要查看是否有问题。

　　

　　图 6-1

　　测试执行机共16C32G配置。从图6-2可以看出，Java进程占用资源不多，CPU资源使用不均衡。然后我们暂时推测问题不大，也没有异常情况。

　　

　　图 6-2

　　然后我们看一下Oracle数据源的监控，如图6-3所示。数据源的机器系统资源占用不多，但有明显的高峰和低谷。判断可能是有一些SQL消耗的资源比较多。执行时占用资源较多，执行后释放资源。这种SQL可能是慢SQL，需要我们捞出来看看。

　　

　　图 6-3

　　通过top命令，如图6-4所示，我们还可以看到oracle占用资源较多，我们来看看占用CPU较多的SQL的执行情况

　　

　　图 6-4

　　SELECT     scn,     timestamp,     operation,     operation_code

,     seg_owner,     table_name,     sql_redo,     sql_undo,

 xidusn,     xidslt,     xidsqn,     row_id,     rollback,     c

sf FROM     v$logmnr_contents WHERE     scn > :1       AND scn <

 :2    and ( ((SEG_OWNER=&#39;ORACLE&#39; and TABLE_NAME=&#39;YUNCHUAN_LOGMI

NER01&#39;)) and OPERATION_CODE in (&#39;1&#39;,&#39;3&#39;,&#39;2&#39;)  or OPERATION_CODE

= 7 )

　　分析这一段SQL，我们可以发现，这其实是一条钓鱼Redo Log的SQL，所以消耗的CPU比较多，可以理解。属于普通的SQL，但是如果这条SQL还有优化的空间，我们可以稍后再看。.

　　经过以上简单的分析，我们基本可以断定，在运行过程中没有明显影响FlinkX性能的异常情况。然后我们需要进一步分析逻辑，看看具体的线程情况。这时候就需要用到jstack和Arthas了。

　　我们使用jstack和Arthas在操作过程中捕获执行端的调用栈信息进行分析。这里涉及到一些敏感信息，图中没有显示。通过jstack和Arthas抓取火焰图，我们可以分析出在整体调用中，FlinkX在读取日志后的数据处理部分花费了大量时间。在梳理出具体的类之后，我们可以把它作为一个优化方向来开发。借助火焰图和堆栈信息，它还可以帮助开发并更快地定位特定问题点。

　　至此，单个用例的分析到此结束。接下来需要完成其他测试用例，然后进行对比分析，看看不同变量之间是否存在关系。测试后，我们取不同日志大小的数据处理时间，绘制成折线图，如图6-5所示。我们会发现整体时间消耗随着日志大小的增加几乎是线性的。数据越大，耗时越长。，这与我们之前的分析是一致的。

　　

　　图 6-5

　　7. 收益

　　在以往的功能测试中，测试人员很少关注组件的性能，基本保证功能可以用，就算没问题。但是这次对于FlinkX Logminer实时采集的性能测试，让我们实时分析一下FlinkX的性能瓶颈采集，FlinkX在性能方面还有优化的空间，我们会需要具体优化的开发方向与开发同步，排期进行迭代优化。后来，我们针对性能瓶颈开发了定向优化。我们可以发现，经过这次优化后，FlinkX的实时采集性能提升了20%，原来的同步时间几乎减少了一半。

　　来自“ITPUB博客”，链接：，如需转载请注明出处，否则将追究法律责任。