MySQL數(shù)據(jù)分析怎么解決

本篇內(nèi)容主要講解“MySQL數(shù)據(jù)分析怎么解決”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MySQL數(shù)據(jù)分析怎么解決”吧!

作為最為流行的開源數(shù)據(jù)庫，MYSQL正成為越來越多企業(yè)的選擇。MySQL數(shù)據(jù)庫大量應(yīng)用在各種業(yè)務(wù)系統(tǒng)，除了在線業(yè)務(wù)邏輯的讀寫，還會有一些額外的數(shù)據(jù)分析需求，如BI報表、可視化大屏、大數(shù)據(jù)應(yīng)用等。但受限于MySQL架構(gòu)等問題，在面對數(shù)據(jù)分析場景時，其往往力不從心。

針對這種情況，業(yè)內(nèi)有很多種解決方案。這里特推薦一種新的方式 — 數(shù)據(jù)湖分析，在面對低成本場景時是個不錯的選擇。在展開正式內(nèi)容之前，對數(shù)據(jù)湖這個還較為陌生的概念做個簡單介紹。

數(shù)據(jù)湖，是一種Serverless化的交互式聯(lián)邦查詢服務(wù)。使用標準SQL即可分析與集成對象存儲(OSS)、數(shù)據(jù)庫(PostgreSQL/MySQL等)、NoSQL(TableStore等)數(shù)據(jù)源的數(shù)據(jù)。

01.  方案背景

•  需求場景一

MySQL數(shù)據(jù)庫大量應(yīng)用在各種業(yè)務(wù)系統(tǒng)，除了在線業(yè)務(wù)邏輯的讀寫，還會有一些額外的數(shù)據(jù)分析需求，如BI報表、可視化大屏、大數(shù)據(jù)應(yīng)用等。隨著業(yè)務(wù)的發(fā)展，單機MySQL數(shù)據(jù)庫達到一定的數(shù)據(jù)量后，直接使用MySQL做數(shù)據(jù)分析性能比較差，而且會影響在線業(yè)務(wù)的讀寫性能。這種情況下就需要尋求新的數(shù)據(jù)分析方案。

•  需求場景二

MySQL中的數(shù)據(jù)需要和日志數(shù)據(jù)做聯(lián)合分析，這種場景下有些公司會使用開源的大數(shù)據(jù)系統(tǒng)（如Hive，Hadoop，Spark等）搭建數(shù)據(jù)倉庫，這個方法雖然能解決問題，但它所需的人力成本和服務(wù)器等資源成本卻是最高的。如何才能低成本的把MySQL與其他系統(tǒng)的數(shù)據(jù)做聯(lián)合分析？

•  需求場景三

當MySQL中數(shù)據(jù)量超過單機性能后，為了保證在線業(yè)務(wù)性能，DBA通常會采用分庫分表技術(shù)，將一個數(shù)據(jù)庫中的單張表數(shù)據(jù)拆分到多個數(shù)據(jù)庫的多張表中。由于一個邏輯表被拆成多張表，這時候如果要進行數(shù)據(jù)分析，將會變得十分復雜。需要新的分析方案來解決。

02.  案評估因素

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

1.成本因素

這里談到的成本，是個綜合的概念，不單指經(jīng)濟成本，還包括時間、人力、風險成本等。用戶做方案選擇時，要考慮綜合的“性價比”。

2.能力因素

能力維度包括兩個方面，即功能和性能。功能上，方案是否提供了完備的分析能力及擴展能力。性能上，是否滿足用戶的對時效性、并行性的要求，特別是在海量規(guī)模下。

3.可維護性

好的產(chǎn)品，應(yīng)該是提供良好的可維護性。用戶可通過很簡潔的方式使用它。當出現(xiàn)問題的時候，也可以很容易排查解決。

4.易用性

產(chǎn)品自身應(yīng)具有良好的易用性。用戶只需要很低的門檻即可使用到數(shù)據(jù)分析服務(wù)。

03.  方案選擇

針對MySQL數(shù)據(jù)的分析場景，有多種解決方案，包括直接在MySQL只讀實例上分析、自建開源數(shù)據(jù)倉庫和數(shù)據(jù)湖構(gòu)建方案。下面讓我們詳細看看這些方案的優(yōu)缺點。

基于MySQL只讀實例分析

通過額外購買服務(wù)器搭建MySQL只讀備庫實例，然后基于只讀實例做數(shù)據(jù)分析。這個方案的優(yōu)缺點：

缺點：

•  功能不能無法滿足需求場景二和場景三，即使針對需求場景一，當數(shù)據(jù)量增大時（參考下文TPC-H 10G SQL耗時），基于只讀實例的分析性能會非常差。

•  成本較高：額外購買的只讀實例成本也比較高。

優(yōu)點：

•  方案簡單，能防止對在線業(yè)務(wù)產(chǎn)生影響；易用性、兼容性好。

自建開源數(shù)據(jù)倉庫

使用開源大數(shù)據(jù)系統(tǒng)（如Hive，Hadoop，Spark等）搭建數(shù)據(jù)倉庫，然后同步MySQL數(shù)據(jù)到數(shù)據(jù)倉庫，再基于Spark或Hive進行數(shù)據(jù)分析。

缺點：

•  易用性差：開源大數(shù)據(jù)系統(tǒng)使用門檻比較高，需要專門的大數(shù)據(jù)工程師來操作和運維；此外Sqoop同步不支持表結(jié)構(gòu)變更，增加和刪除列都會導致同步失敗。

•  成本最高：另外還需要額外購買服務(wù)器搭建系統(tǒng)，增加了硬件成本，這個方案整體成本最高。

優(yōu)點：

•  能解決需求場景一和二的問題，分析性能較好。

分析型數(shù)據(jù)庫

使用開源或商用的分析型數(shù)據(jù)庫，通過數(shù)據(jù)同步工具完成數(shù)據(jù)同步，再基于SQL進行數(shù)據(jù)分析。

缺點：

•  可維護性差，需要專門運維人員。

•  成本較高，需額外購買資源。

優(yōu)點：

•  滿足海量規(guī)模的數(shù)據(jù)分析

數(shù)據(jù)湖構(gòu)建方案

基于阿里云數(shù)據(jù)湖分析構(gòu)建方案，它能完美的解決低成本分析MySQL數(shù)據(jù)的需求。

優(yōu)點：

•  方便易用：使用一鍵建倉可以很輕松把整個數(shù)據(jù)庫同步到數(shù)據(jù)湖。

•  分析能力強：數(shù)據(jù)湖分析（Data Lake Analytics）與MySQL體驗完全相同，數(shù)據(jù)量增加對分析性能幾乎沒有影響。

•  成本極低：不需要購買服務(wù)器，按查詢量計費，無查詢不收費；無維護成本。

•  對源庫影響：數(shù)據(jù)分析對在線業(yè)務(wù)無影響。

04.  數(shù)據(jù)湖構(gòu)建方案評測數(shù)據(jù)及技術(shù)原理

接下來讓我們詳細看一下數(shù)據(jù)湖構(gòu)建方案的評測數(shù)據(jù)和技術(shù)原理。

低成本高性能

•  低成本

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

•  高性能

數(shù)據(jù)湖構(gòu)建把數(shù)據(jù)從源數(shù)據(jù)庫同步后，使用列式+壓縮的方式存儲，以TPC-H 10G的數(shù)據(jù)為例，存儲在MySQL將消耗大約20G存儲，但使用列式+壓縮方式存儲只消耗約3G存儲。

使用阿里云數(shù)據(jù)湖分析（DLA）分析，能以極低的成本獲得高效的分析，再次以TPC-H 10G的數(shù)據(jù)為例，TPC-H的22條SQL在DLA執(zhí)行耗時平均為5.5s，在MySQL中平均耗時為345.5s，且有4條SQL跑不出來。

下圖TPC-H 10G 22條SQL在MySQL和DLA的耗時對比。

易用性

•  支持豐富數(shù)據(jù)源

阿里云數(shù)據(jù)湖分析構(gòu)建方案，支持豐富的數(shù)據(jù)源，包括自建的MySQL、SQLServer、PostgreSQL、Oracle、云數(shù)據(jù)庫RDS、PolarDB、ADB等。與傳統(tǒng)的數(shù)據(jù)倉庫相比，它的設(shè)計目標是"簡單"，讓用戶通過簡單的配置就能實現(xiàn)數(shù)據(jù)同步到DLA，真正實現(xiàn)"一鍵"建倉。

•  自動同步保持數(shù)據(jù)一致

數(shù)據(jù)湖構(gòu)建支持自動同步更新的數(shù)據(jù)，也能自動同步包括創(chuàng)建表，刪除表，新增列、修改列、刪除列等元數(shù)據(jù)操作。在分庫分表的場景中，數(shù)據(jù)湖構(gòu)建能把一張分布在多個數(shù)據(jù)庫的邏輯表合并到一張表中，實現(xiàn)基于一張表做數(shù)據(jù)分析。此外數(shù)據(jù)湖構(gòu)建支持同步的表數(shù)量無上限限制。

•  增量構(gòu)建

數(shù)據(jù)湖分析（DLA）團隊正在研發(fā)數(shù)據(jù)湖增量構(gòu)建以支持增量模式同步源庫數(shù)據(jù)，能完全消除對源庫產(chǎn)生的影響；并且能大大提升數(shù)據(jù)分析的時效性。增量構(gòu)建將于近期發(fā)布上線，敬請期待。

•  對源庫影響

基于數(shù)據(jù)湖分析查詢對源庫完全無影響；在數(shù)據(jù)湖從源庫同步數(shù)據(jù)時，對源庫的影響也保證在10%以內(nèi)。下圖是數(shù)據(jù)湖構(gòu)建針對不同規(guī)格源數(shù)據(jù)庫的CPU消耗：隨著機器規(guī)格增大，連接數(shù)會自動增加，最終源庫的平均CPU消耗都在10%以內(nèi)。

為了盡量減低同步對源數(shù)據(jù)庫的影響，數(shù)據(jù)湖構(gòu)建做了大量的優(yōu)化。包括：

•  數(shù)據(jù)湖構(gòu)建會自動根據(jù)源數(shù)據(jù)庫的機器規(guī)格，動態(tài)調(diào)整連接數(shù)，能保證對源數(shù)據(jù)庫的壓力在10%以內(nèi)。

•  在并發(fā)同步一張表時，優(yōu)先選擇索引列做切分，通過索引快速定位一段數(shù)據(jù)范圍，減小同步對源數(shù)據(jù)庫的影響。

•  數(shù)據(jù)湖構(gòu)建默認選擇業(yè)務(wù)低谷做數(shù)據(jù)同步，防止影響線上業(yè)務(wù)。

最終實現(xiàn)對源庫的壓力幾乎可以忽略。如果用戶希望加快同步速度，也可以手動增加連接數(shù)加快同步速度。

05.  阿里云數(shù)據(jù)湖實踐

如果你希望試用數(shù)據(jù)湖分析構(gòu)建MySQL低成本分析，只需要以下步驟即可開通試用。

1、登錄Data Lake Analytics管理控制臺。在頁面左上角，選擇DLA所在地域。（https://datalakeanalytics.console.aliyun.com）

2、在左側(cè)導航欄單擊解決方案。在解決方案頁面，單擊一鍵建倉中的進入向?qū)А?/p>

3、根據(jù)頁面提示，進行參數(shù)配置。

4、完成上述參數(shù)配置后，單擊創(chuàng)建，就可以開始使用數(shù)據(jù)湖愉快的分析了。

到此，相信大家對“MySQL數(shù)據(jù)分析怎么解決”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！