前言

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. Logminer

Oracle在開啟Logminer後，所有對使用者資料和資料字典的改變都記錄在Oracle的Redo Log中，通過Logminer分析Redo Log，可以獲得資料變化的所有內容。分析後可以得到一些可以用於回滾的SQL語句，常用於恢復資料庫中某一段的資料變化。

2.3. FlinkX實時採集邏輯

FlinkX常見的實時採集邏輯，都是先從源資料採集，經過資料處理後再寫入目標資料來源。例如本次測試的FLinkX Logminer，就是FlinkX從Oracle的Logminer中採集日誌資料，經過對日誌資料的處理後，將處理後的資料寫入kafka。FlinkX對於Logminer的日誌讀取分為歸檔日誌（ARCHIVE）的讀取和實時日誌(ONLINE)的讀取，區別在於Redo Log內的資料是歷史寫入的歸檔資料，還是實時寫入的實時日誌如圖1-1。以此區別，我們劃分成兩大類進行測試，分別是歸檔資料和實時採集資料。

圖1-1

3. 測試工具

3.1. 測試工具介紹

3.1.1. Arthas

Arthas 是一款Alibaba開源的Java診斷工具，其檢視呼叫，debug，檢視程式執行緒資訊等功能對於開發測試均有巨大的幫助。在本次測試中，主要運用其中的dashboard，thread來檢視程式執行緒狀態，以及使用profiler生成呼叫鏈路火焰圖，定位被測物件執行邏輯中，呼叫佔用資源較多的類或者方法。

3.1.2. Grafana/Prometheus/EasyManager

Grafana是一款優秀的開源資料視覺化工具，在測試中常用作資料監控的展示皮膚工具。Prometheus則是由 SoundCloud 開源監控告警解決方案，用於儲存伺服器監控資料以及時間序列。二者經常配合在一起使用，通過一些exporter來監控伺服器資源或者資料來源狀態然後將資料儲存在Prometheus中，Grafana從Prometheus中獲取監控儲存的資料通過不同的監控皮膚展示給使用者。方便測試人員更便捷的對被測系統進行系統監控，資料分析，狀態分析。

EasyManager是數棧自研的運維利器，用於部署袋鼠雲數棧的各種應用，在本次測試中我們主要借用其伺服器資源監控的功能，方便我們進行資源資料分析，這個也可以替換運用Grafana進行監控。

3.1.3. jstack

jstack 用於生成java虛擬機器當前時刻的執行緒快照。執行緒快照是當前java虛擬機器內每一條執行緒正在執行的方法堆疊的集合，生成執行緒快照的主要目的是定位執行緒出現長時間停頓的原因，如執行緒間死鎖、死迴圈、請求外部資源導致的長時間等待等。 執行緒出現停頓的時候通過jstack來檢視各個執行緒的呼叫堆疊，就可以知道沒有響應的執行緒到底在後臺做什麼事情，或者等待什麼資源。

3.1.4. Oracle AWR

AWR 是 Oracle 10g 版本之後推出的新特性， 全稱叫Automatic Workload Repository-自動負載資訊庫。它是一種Oracle提供的效能收集和分析工具，是進行Oracle效能調優的利器。它能提供一個時間段內整個系統資源使用情況的報告。

3.1.5. FlinkX BenchMark

基於JMH BenchMark框架，拆解FlinkX採集過程中的每步動作，基於每一步模仿FlinkX處理邏輯編寫的效能測試工具。主要用於本次FlinkX Logminer採集的效能測試執行工具。

3.2. 測試機器配置

4. 測試策略&關注點

本次測試開始前，先將FlinkX的採集邏輯進行梳理，因為FlinkX對於Logminer採集的流程主要是歸檔日誌/實時日誌讀取，然後資料處理，再將資料寫入到不同的資料來源，那麼我們便將整體的邏輯拆分為歸檔日誌處理（日誌讀取，資料處理）和實時採集（日誌讀取，資料處理，寫入其他資料來源）兩塊。對於歸檔日誌處理我們劃分為歸檔日誌讀取，歸檔資料處理以及整體的端到端（全鏈路）幾個內容，針對幾個不同的邏輯分別進行測試，看耗時較長的在哪一步，針對這一步的處理邏輯我們再進行具體分析。對於實時採集部分，我們主要是測試資料從Redo Log中讀取到寫入kafka的延遲情況，結合歸檔日誌處理部分的測試內容，來分析實時採集的延遲原因，以及延遲情況。

對於以上測試內容，我們在測試過程中需要關注歸檔日誌的讀取，處理速度，耗時。實時採集時，資料從寫入到Oracle到採集到Kafka的延遲情況。這些是主要產出的測試指標，同時我們也需要關注應用在測試的過程中對於採集端（Oracle）的資源佔用，應用本身（FlinkX）的資源佔用，執行緒情況，寫入端（Kafka）的監控情況。

對於Oracle端，我們需要關注是否存在慢SQL，因為FlinkX會先執行SQL從Oracle Logminer中獲取Redo Log的資訊，那麼這些SQL是否可以進行優化，是否有耗時過長的情況，這個需要關注。然後是資料庫的負載情況，看一下整體Oracle的空閒情況，是否充分利用資源，以及硬解析次數是否過高，是否存在一些阻塞的情況。

對於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到Kafka實時採集的FlinkX任務並執行，同時使用造資料工具同時對Oracle寫入資料，這樣就完成了前半部分，一邊寫一邊讀，然後實時採集任務將資料寫入Kafka後，因為Kafka在寫入資料時會帶有時間戳，通過FlinkX BenchMark去Kafka內取資料的時間標記，計算資料的延遲時間。

三、在測試過程中，需要關注各項監控資料，例如伺服器的資源，應用的執行緒情況，資料來源的監控資訊。如果出現異常情況，例如抖動較大的CPU佔用，一直處於等待狀態的執行緒，資料來源的讀取寫入異常等等情況，要及時排查，通過jstack撈一下堆疊的快照資訊，分析是否存在問題等。同時在測試過程中，需要使用Arthas生成穩定執行期間的火焰圖，方便後續進行資料分析。

四、測試資料分析，通過在測試過程中的資料監控情況，測試結果，各條測試用例對比，分析本次測試中，效能問題所在位置，以及優化方案等。

五、輸出測試報告與開發核對，確定後續優化方向及優化方案。

接下來我們拿具體用例具體流程分析。

6. 資料分析

借用歸檔日誌部分的測試用例我們來看整個過程，本篇文章採用歸檔日誌20G大小，監聽1張表這一條來分析。

首先在執行測試的過程中，對於拆分後的每一部分（日誌讀取/資料處理/整鏈路）我們都需要觀察測試執行端（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='ORACLE' and TABLE_NAME='YUNCHUAN_LOGMI
NER01')) and OPERATION_CODE in ('1','3','2')  or OPERATION_CODE
= 7 )

分析這段SQL，我們可以發現，這其實是一段撈Redo Log日誌的SQL，那麼其耗CPU較多，就可以理解了，屬於正常SQL，但是這個SQL有沒有優化的空間我們可以後續再看看。

經過上面的簡單分析，我們基本可以得出在執行過程中，FlinkX是沒有什麼明顯影響效能的異常情況存在的。那麼我們就需要進一步對邏輯進行分析，看一下具體的執行緒情況，這時候就需要用到jstack和Arthas了。

我們通過jstack和Arthas將執行過程中，執行端的呼叫堆疊資訊抓取出來進行分析，這裡涉及到一些敏感資訊就不上圖了。通過jstack和Arthas抓取火焰圖我們可以分析出整體呼叫中，FlinkX在日誌讀取後的資料處理部分耗時較多，梳理出來具體的類後就可以提給開發作為優化方向了。配合火焰圖和堆疊資訊，也能更快的幫助開發定位具體問題點。

到此，單個用例執行的分析就到此為止了，接下來就需要完成其他測試用例，然後進行對比分析，看不同的變數間是否存在關係。我們把測試完後不同日誌大小的資料處理時間拿出來，畫成折線圖，如圖6-5，會發現整體的耗時隨日誌大小的增加幾乎呈線性關係，資料越大，耗時越長，跟我們之前的分析是一致的。

圖6-5

7. 收益

在以往的功能測試中，測試人員很少關注元件效能方面的情況，基本上保證功能可用就算ok了。但是這一次針對FlinkX Logminer實時採集的效能測試，讓我們分析出了FlinkX在實時採集中的效能瓶頸，FlinkX在效能方面還存在有優化的空間，我們將具體需要優化的方向同步到開發，排進迭代進行優化。在之後開發在針對效能瓶頸點有方向的優化，我們回測可以發現，經過本次的優化提升了FlinkX實時採集效能的20%，幾乎縮短原先同步所花費一半的時間，可以說在業務的穩定性，可用性，資料的及時性上跨進了一大步，整體是十分有意義的。