一個接口查詢關聯了十幾張表,響應速度太慢?怎麼辦?

  1. <strong>
  2. <strong>
  3. <strong>
一個接口查詢關聯了十幾張表,響應速度太慢?怎麼辦?

不知道開發的同學有沒有遇到過類似這樣的需求:

  • 相同類型的數據在多個系統中,如果要得到全部的信息,就要連續調多個系統的接口;
  • 業務複雜,一個需求需要關聯幾張表甚至幾十張表才能得到想要的結果;
  • 系統做了分庫分表,但是需要統計所有的數據。

那麼此類需求要如何滿足呢?我們選擇了“通過 ETL 提前進行數據整合”的方案。

什麼是 ETL

說到ETL,很多開發夥伴可能會有些陌生,更多的時候 ETL 是用在大數據、數據分析的相關崗位;我也是在近幾年的工作過程中才接觸到ETL的,現在的項目比較依賴 ETL,可以說是項目中重要的一部分。

ETL 是三個單詞的縮寫:

  • Extraction:抽取、提取;就是把數據從數據庫裡面取出來;
  • Transformation:轉換;包括但不限於:數據篩選校驗、數據關聯、數據內容及結構的修改、運算、統計等等;
  • Loading:加載;將處理後的數據保存到目標數據庫。

從這三個單詞基本可以瞭解 ETL 的作用:將各個業務系統的數據,通過抽取、清洗、轉換之後,將加工後的數據落地到數據庫中(數據倉庫);在這個過程中,ETL 可以將分散、零亂、標準不統一的數據整合到一起。

一個接口查詢關聯了十幾張表,響應速度太慢?怎麼辦?

使用場景

我接觸過的項目,使用 ETL 工具的場景有這個幾種:

1. 報表、BI系統:

在公司建設的初期,業務比較少,系統也比較少,一臺數據庫就搞定了;隨著公司業務的增加,業務系統被拆成很多系統;隨著數據量的繼續增加,單個系統的數據增加到一定程度的時候,也做了分庫分表;

這時候領導、業務人員在用數據做分析的時候,數據來源可能是多個系統的多張表,這時候企圖通過一個複雜的 SQL 跑出來結果就很困難了;通常公司會建立一個數據倉庫,通過 ETL 工具把數據抽取到數據倉庫中,再做數據的擬合和展示。

2. 跨系統的數據加工或查詢:

我們現在所在公司,業務系統有幾百個,由於業務流程比較複雜,前端系統在做業務操作的時候,在正式提交交易之前,有很多業務校驗;

比如要查詢客戶在 X 系統的交易歷史,在 Y 系統的交易歷史,在 Z 系統的交易歷史;那麼就需要分別調用 X、Y、Z 系統的接口,這個對前端系統很不友好,那麼通常的解決方案是什麼?

  • A 方案:做一箇中間服務,中間服務去調用 X、Y、Z 系統的接口,客戶端直接調用這個中間服務;這種方案只是把前端要做的事情,轉移到了中間服務;
  • B 方案:整合 X、Y、Z 三個系統,建服務中臺;這種方法很好,但是極為難,對於很多公司來說,別說把 X、Y、Z 三個系統整合成一箇中臺系統,就是其中一個系統本身進行重構,都是非常困難的;
  • C 方案:把 X、Y、Z 三個系統中需要的數據,通過 ETL 抽取加工到一個數據倉庫中,對外提供服務;這個系統最大的好處是在不改造 X、Y、Z 三個系統的前提下,又可以實現跨系統的查詢。

我們在 C 方案的基礎上又往前做了一步,就是將落地後的數據又做了一次加工,將需要跨表關聯的數據,提前關聯好存入 MongoDB 中,對外提供查詢服務;這樣可以將多表關聯查詢,變成了單表查詢。

一個接口查詢關聯了十幾張表,響應速度太慢?怎麼辦?

吐數據 VS 抽數據

接上文中第二個例子中的 C 方案,有些同學可能會有個疑問:數據抽取,需要抽取哪些數據呢?為什麼不讓這些系統把數據吐出來呢?

答案也簡單,“有的時候,數據不一定能吐出來”。

MySQL 數據庫往外吐數據有比較成熟的中間件,比如 Canal,它可以通過監聽 Mysql 的 binlog 日誌來獲取數據,binlog 設置為 row 模式,能夠獲取到每一條新增、刪除、修改的日誌,同時還能獲取到修改前後的數據;

其他商用數據庫,比如 Oracle、DB2 等,我也查閱過相關的資料,也是有觸發器機制,可以當數據發生變化的時候通知出來,比如調用一段程序,將數據發送到消息隊列中,再由其他程序監聽消息隊列做後續處理。

不管什麼類型的數據庫,這種“吐數據”的方案,對於基礎設施的要求都比較高,並且對原有系統有一定的侵入性;所以我們採用了對原有系統侵入性更小的方案:主動抽數據。

ETL 方案的優缺點

1. 優點

  • 侵入性較低,數據源系統只需要開通數據庫的訪問權限即可,為保證數據抽取對業務的影響,通常是訪問源系統的備庫,並且單獨設置一個只讀權限的數據庫用戶;
  • 支持不同類型數據源的數據抽取,比如源庫有 Mysql、DB2、Oracle,通過 ETL 也可以輕鬆搞定;
  • 數據整合,將不同業務系統的相同數據整合在一起,比如有些系統 M/F 表示男女,有些系統 1/0 表示男女,ETL 在抽取加工後轉換成統一的編碼;

2. 缺點

  • 比較致命的一個缺點,就是數據抽取和加工有一定的延遲,需要根據業務場景進行評估,是否接受這個延遲;
  • 可能會受到源庫表結構變化的影響;
  • 如果源庫中的表沒有時間戳,或者時間戳不準確,那麼增量抽取就變得很困難;
  • 需要招聘 ETL 開發崗,從我目前的經驗看,不是特別好招。


作者:會點代碼的大叔
原文鏈接:https://juejin.im/post/5e4258c86fb9a07c964589cb


分享到:


相關文章: