作為最為流行的開源資料庫，MYSQL正成為越來越多企業的選擇。MySQL資料庫大量應用在各種業務系統，除了線上業務邏輯的讀寫，還會有一些額外的資料分析需求，如BI報表、視覺化大屏、大資料應用等。但受限於MySQL架構等問題，在面對資料分析場景時，其往往力不從心。針對這種情況，業內有很多種解決方案。這裡特推薦一種新的方式 — 資料湖分析，在面對低成本場景時是個不錯的選擇。在展開正式內容之前，對資料湖這個還較為陌生的概念做個簡單介紹。資料湖，是一種Serverless化的互動式聯邦查詢服務。使用標準SQL即可分析與整合物件儲存(OSS)、資料庫(PostgreSQL/MySQL等)、NoSQL(TableStore等)資料來源的資料。https://cn.aliyun.com/product/datalakeanalytics?aly_as=bX_ZThXyu

方案背景需求場景一

MySQL資料庫大量應用在各種業務系統，除了線上業務邏輯的讀寫，還會有一些額外的資料分析需求，如BI報表、視覺化大屏、大資料應用等。隨著業務的發展，單機MySQL資料庫達到一定的資料量後，直接使用MySQL做資料分析效能比較差，而且會影響線上業務的讀寫效能。這種情況下就需要尋求新的資料分析方案。

需求場景二

MySQL中的資料需要和日誌資料做聯合分析，這種場景下有些公司會使用開源的大資料系統（如Hive，Hadoop，Spark等）搭建資料倉庫，這個方法雖然能解決問題，但它所需的人力成本和伺服器等資源成本卻是最高的。如何才能低成本的把MySQL與其他系統的資料做聯合分析？

需求場景三

當MySQL中資料量超過單機效能後，為了保證線上業務效能，DBA通常會採用分庫分表技術，將一個數據庫中的單張表資料拆分到多個數據庫的多張表中。由於一個邏輯表被拆成多張表，這時候如果要進行資料分析，將會變得十分複雜。需要新的分析方案來解決。

方案評估因素

MySQL分析場景中，如果要解決上述三個場景問題，主要考慮的因素有哪些？如果有多種解決方案，應該如何選擇？可以參考以下幾個關鍵因素。

成本因素這裡談到的成本，是個綜合的概念，不單指經濟成本，還包括時間、人力、風險成本等。使用者做方案選擇時，要考慮綜合的“價效比”。能力因素能力維度包括兩個方面，即功能和效能。功能上，方案是否提供了完備的分析能力及擴充套件能力。效能上，是否滿足使用者的對時效性、並行性的要求，特別是在海量規模下。可維護性好的產品，應該是提供良好的可維護性。使用者可透過很簡潔的方式使用它。當出現問題的時候，也可以很容易排查解決。易用性產品自身應具有良好的易用性。使用者只需要很低的門檻即可使用到資料分析服務。方案選擇

針對MySQL資料的分析場景，有多種解決方案，包括直接在MySQL只讀例項上分析、自建開源資料倉庫和資料湖構建方案。下面讓我們詳細看看這些方案的優缺點。

基於MySQL只讀例項分析

透過額外購買伺服器搭建MySQL只讀備庫例項，然後基於只讀例項做資料分析。這個方案的優缺點：

缺點：功能無法滿足需求場景二和場景三，即使針對需求場景一，當資料量增大時（參考下文TPC-H 10G SQL耗時），基於只讀例項的分析效能較弱。優點：方案簡單，能防止對線上業務產生影響；易用性、相容性好。自建開源資料倉庫

使用開源大資料系統（如Hive，Hadoop，Spark等）搭建資料倉庫，然後同步MySQL資料到資料倉庫，再基於Spark或Hive進行資料分析。

缺點：易用性差：開源大資料系統使用門檻比較高，需要專門的大資料工程師來操作和運維；此外Sqoop同步不支援表結構變更，增加和刪除列都會導致同步失敗。成本最高：另外還需要額外購買伺服器搭建系統，增加了硬體成本，這個方案整體成本最高。優點：能解決需求場景一和二的問題，分析效能較好。資料湖構建方案

基於阿里雲資料湖分析構建方案，它能完美的解決低成本分析MySQL資料的需求。

優點：方便易用：使用一鍵建倉可以很輕鬆把整個資料庫同步到資料湖。分析能力強：資料湖分析（Data Lake Analytics）與MySQL體驗完全相同，資料量增加對分析效能幾乎沒有影響。成本極低：不需要購買伺服器，按查詢量計費，無查詢不收費；無維護成本。對源庫影響：資料分析對線上業務無影響。資料湖構建方案評測資料及技術原理

接下來讓我們詳細看一下資料湖構建方案的評測資料和技術原理。

低成本高效能低成本

下面是成本的對比，額外購買一臺高效能RDS（MySQL資料庫）包月費用需2344元；以TPC-H 10G為例，如果每天執行一次TPC-H的22條SQL，使用DLA一個月的費用只需要26.64元，平均每天不到1元。只需1%的成本就能獲取高效能的分析；此外DLA的列式儲存消耗只需要3G，而原生Mysql的儲存可能消耗約20G。

高效能

資料湖構建把資料從源資料庫同步後，使用列式+壓縮的方式儲存，以TPC-H 10G的資料為例，儲存在MySQL將消耗大約20G儲存，但使用列式+壓縮方式儲存只消耗約3G儲存。使用阿里雲資料湖分析（DLA）分析，能以極低的成本獲得高效的分析，再次以TPC-H 10G的資料為例，TPC-H的22條SQL在DLA執行耗時平均為5.5s，在MySQL中平均耗時為345.5s，且有4條SQL跑不出來，下圖TPC-H 10G 22條SQL在MySQL和DLA的耗時對比。

易用性支援豐富資料來源

阿里雲資料湖分析構建方案，支援豐富的資料來源，包括自建的MySQL、SQLServer、PostgreSQL、Oracle、雲資料庫RDS、PolarDB、ADB等。與傳統的資料倉庫相比，它的設計目標是"簡單"，讓使用者透過簡單的配置就能實現資料同步到DLA，真正實現"一鍵"建倉。

自動同步保持資料一致

資料湖構建支援自動同步更新的資料，也能自動同步包括建立表，刪除表，新增列、修改列、刪除列等元資料操作。在分庫分表的場景中，資料湖構建能把一張分佈在多個數據庫的邏輯表合併到一張表中，實現基於一張表做資料分析。此外資料湖構建支援同步的表數量無上限限制。

增量構建

資料湖分析（DLA）團隊正在研發資料湖增量構建以支援增量模式同步源庫資料，能完全消除對源庫產生的影響；並且能大大提升資料分析的時效性。增量構建將於近期釋出上線，敬請期待。

對源庫影響

基於資料湖分析查詢對源庫完全無影響；在資料湖從源庫同步資料時，對源庫的影響也保證在10%以內。下圖是資料湖構建針對不同規格源資料庫的CPU消耗：隨著機器規格增大，連線數會自動增加，最終源庫的平均CPU消耗都在10%以內。

為了儘量減低同步對源資料庫的影響，資料湖構建做了大量的最佳化。包括：

資料湖構建會自動根據源資料庫的機器規格，動態調整連線數，能保證對源資料庫的壓力在10%以內。在併發同步一張表時，優先選擇索引列做切分，透過索引快速定位一段資料範圍，減小同步對源資料庫的影響。資料湖構建預設選擇業務低谷做資料同步，防止影響線上業務。

最終實現對源庫的壓力幾乎可以忽略。如果使用者希望加快同步速度，也可以手動增加連線數加快同步速度。

阿里雲資料湖實踐

如果你希望試用資料湖分析構建MySQL低成本分析，只需要以下步驟即可開通試用。（文件詳見https://datalakeanalytics.console.aliyun.com/cn-hangzhou/solutions）1、登入Data Lake Analytics管理控制檯。在頁面左上角，選擇DLA所在地域。2、在左側導航欄單擊解決方案。在解決方案頁面，單擊一鍵建倉中的進入嚮導。3、根據頁面提示，進行引數配置。

4、完成上述引數配置後，單擊建立，就可以開始使用資料湖愉快的分析了。