一個接口查詢關聯了十幾張表，響應速度太慢？怎么辦？

作者：追逐仰望星空 2020-04-08 20:10:47

一個接口查詢關聯了十幾張表，響應速度太慢？怎么辦？我們選擇了“通過 ETL 提前進行數據整合”的方案。

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

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

什么是 ETL

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

ETL 是三個單詞的縮寫：

從這三個單詞基本可以了解 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 中，對外提供查詢服務；這樣可以將多表關聯查詢，變成了單表查詢。

一個接口查詢關聯了十幾張表，響應速度太慢？怎么辦？

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

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

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

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

不管什么類型的數據庫，這種“吐數據”的方案，對于基礎設施的要求都比較高，并且對原有系統有一定的侵入性；所以我們采用了對原有系統侵入性更小的方案：主動抽數據。

1. 優點

2. 缺點

責任編輯：龐桂玉來源：今日頭條