好屌妞-这里只有精品,2018高清国产一区二区三区,91美女秘片黄在线观看

MySQL到TiDB：Hive Metastore橫向擴展之路

一、背景

大數(shù)據(jù)元數(shù)據(jù)服務(wù)Hive Metastore Service（以下簡稱HMS），存儲著數(shù)據(jù)倉庫中所依賴的所有元數(shù)據(jù)并提供相應(yīng)的查詢服務(wù)，使得計算引擎（Hive、Spark、Presto）能在海量數(shù)據(jù)中準(zhǔn)確訪問到需要訪問的具體數(shù)據(jù)，其在離線數(shù)倉的穩(wěn)定構(gòu)建上扮演著舉足輕重的角色。vivo離線數(shù)倉的Hadoop集群基于CDH 5.14.4版本構(gòu)建，HMS的版本選擇跟隨CDH大版本，當(dāng)前使用版本為1.1.0-cdh5.14.4。

vivo在HMS底層存儲架構(gòu)未升級前使用的是MySQL存儲引擎，但隨著vivo業(yè)務(wù)發(fā)展，數(shù)據(jù)爆炸式增長，存儲的元數(shù)據(jù)也相應(yīng)的增長到億級別（PARTITION_PARAMS：8.1億、

PARTITION_KEY_VALS：3.5億、PARTITIONS：1.4億），在如此大量的數(shù)據(jù)基數(shù)下，我們團隊經(jīng)常面臨機器資源的性能瓶頸，往往用戶多并發(fā)的去查詢某些大分區(qū)表（50w+分區(qū)），機器資源的使用率就會被打滿，從而導(dǎo)致元數(shù)據(jù)查詢超時，嚴(yán)重時甚至整個HMS集群不可用，此時恢復(fù)手段只能暫時停服所有HMS節(jié)點，直到MySQL機器負(fù)載降下來后在逐步恢復(fù)服務(wù)。為此，針對當(dāng)前MySQL方案存在的嚴(yán)重性能瓶頸，HMS急需一套完善的橫向擴展方案來解決當(dāng)前燃眉之急。

二、橫向擴展技術(shù)方案選型

為解決HMS的性能問題，我們團隊對HMS橫向擴展方案做了大量的調(diào)研工作，總體下來業(yè)內(nèi)在HMS的橫向擴展思路上主要分為對MySQL進行拆庫擴展或用高性能的分布式引擎替代MySQL。在第一種思路上做的比較成熟的方案有Hotels.com公司開源的Waggle Dance，實現(xiàn)了一個跨集群的Hive Metastore代理網(wǎng)關(guān)，他允許用戶同時訪問多個集群的數(shù)據(jù)，這些集群可以部署在不同的平臺上，特別是云平臺。第二種思路當(dāng)前主流的做法是用分布式存儲引擎TiDB替換傳統(tǒng)的MySQL引擎，在Hive社區(qū)中有不少公司對hive 2.x接入TiDB做了大量的測試并應(yīng)用到生產(chǎn)中（詳情點擊）。

2.1 Waggle Dance

Waggle-dance向用戶提供統(tǒng)一的入口，將來自Metastore客戶端的請求路由到底層對應(yīng)的Metastore服務(wù)，同時向用戶隱藏了底層的Metastore分布，從而在邏輯層面整合了多個Metastore的Hive庫表信息。Waggle-dance實現(xiàn)了Metastore的Thrift API，客戶端無需改動，對用戶來說，Waggle-dance就是一個Metastore。其整體架構(gòu)如下：

MySQL到TiDB：Hive Metastore橫向擴展之路

從Waggle-dance的架構(gòu)中最突出的特性是其采用了多個不同的MySQL實例分擔(dān)了原單MySQL實例的壓力，除此之外其還有如下優(yōu)勢：

用戶側(cè)可以沿用Metastore客戶端的用法，配置多臺Waggle-dance的連接，在當(dāng)前Waggle-dance連接服務(wù)不可用的時候切換到其他的Waggle-dance服務(wù)上。
Waggle-dance只需幾秒即可啟動，加上其無狀態(tài)服務(wù)的特性，使得Waggle-dance具備高效的動態(tài)伸縮性，可以在業(yè)務(wù)高峰期快速上線新的服務(wù)節(jié)點分散壓力，在低峰期下線部分服務(wù)節(jié)點釋放資源。
Waggle-dance作為一個網(wǎng)關(guān)服務(wù)，除了路由功能外，還支持后續(xù)的定制化開發(fā)和差異化部署，平臺可根據(jù)需要添加諸如鑒權(quán)、防火墻過濾等功能。

2.2 TiDB

TiDB 是 PingCAP 公司自主設(shè)計、研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，是一款同時支持在線事務(wù)處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式數(shù)據(jù)庫產(chǎn)品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數(shù)據(jù)庫、兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性。在TiDB 4.x版本中，其性能及穩(wěn)定性較與之前版本得到了很大的提升并滿足HMS的元數(shù)據(jù)查詢性能需求。故我們對TiDB也做了相應(yīng)的調(diào)研及測試。結(jié)合HMS及大數(shù)據(jù)生態(tài)，采用TiDB作為元數(shù)據(jù)存儲整體的部署架構(gòu)如下：

MySQL到TiDB：Hive Metastore橫向擴展之路

由于TiDB本身具有水平擴展能力，擴展后能均分查詢壓力，該特性就是我們解決HMS查詢性能瓶頸的大殺器。除此外該架構(gòu)還有如下優(yōu)勢：

用戶無需任何改動；HMS側(cè)面沒有任何改動，只是其依賴的底層存儲發(fā)生變化。
不破壞數(shù)據(jù)的完整性，無需將數(shù)據(jù)拆分多個實例來分擔(dān)壓力，對HMS來說其就是一個完整、獨立的數(shù)據(jù)庫。
除引入TiDB作為存儲引擎外，不需要額外的其他服務(wù)支撐整個架構(gòu)的運行。

2.3 TiDB和Waggle Dance對比

前面內(nèi)容對Waggle-dance方案和TiDB方案做了簡單的介紹及優(yōu)勢總結(jié)，以下列舉了這兩個方案在多個維度的對比：

MySQL到TiDB：Hive Metastore橫向擴展之路

通過上述多個維度的對比，TiDB方案在性能表現(xiàn)、水平擴展、運維復(fù)雜度及機器成本上都優(yōu)于waggle-dance方案，故我們線上選擇了前者進行上線應(yīng)用。

三、TiDB上線方案

選擇TiDB引擎替代原MySQL存儲引擎，由于TiDB與MySQL之間不能做雙主架構(gòu)，在切換過程中HMS服務(wù)須完全停服后并重新啟動切換至TiDB，為保障切換過程順利及后面若有重大問題發(fā)生能及時回滾，在切換前做了如下數(shù)據(jù)同步架構(gòu)以保障切換前MySQL與TiDB數(shù)據(jù)一致以及切換后仍有MySQL兜底。

MySQL到TiDB：Hive Metastore橫向擴展之路

在上述架構(gòu)中，切換前唯一可寫入的數(shù)據(jù)源只有源數(shù)據(jù)庫主庫，其他所有TiDB、MySQL節(jié)點都為只讀狀態(tài)，當(dāng)且僅當(dāng)所有HMS節(jié)點停服后，MySQL源數(shù)據(jù)庫從庫及TiDB源數(shù)據(jù)庫主庫的數(shù)據(jù)同步最大時間戳與源數(shù)據(jù)庫主庫一致時，TiDB源數(shù)據(jù)庫主庫才開放可寫入權(quán)限，并在修改HMS底層存儲連接串后逐一拉起HMS服務(wù)。

在上述架構(gòu)完成后，即可開始具體的切換流程，切換整體流程如下：

MySQL到TiDB：Hive Metastore橫向擴展之路

其中在保障源MySQL與TiDB數(shù)據(jù)正常同步前，需要對TiDB做以下配置：

tidb_skip_isolation_level_check需要配置為1 ，否則啟動HMS存在MetaException異常。
tidb_txn_mode需配置為pessimistic ，提升事務(wù)一致性強度。
事務(wù)大小限制設(shè)置為3G，可根據(jù)自己業(yè)務(wù)實際情況進行調(diào)整。
連接限制設(shè)置為最大3000 ，可根據(jù)自己業(yè)務(wù)實際情況進行調(diào)整。

此外在開啟sentry服務(wù)狀態(tài)下，需確認(rèn)sentry元數(shù)據(jù)中NOTIFICATION_ID的值是否落后于HMS元數(shù)據(jù)庫中NOTIFICATION_SEQUENCE表中的NEXT_EVENT_ID值，若落后需將后者替換為前者的值，否則可能會發(fā)生建表或創(chuàng)建分區(qū)超時異常。

以下為TiDB方案在在不同維度上的表現(xiàn)：

在對HQL的兼容性上TiDB方案完全兼容線上所有引擎對元數(shù)據(jù)的查詢，不存在語法兼容問題，對HQL語法兼容度達100%
在性能表現(xiàn)上查詢類接口平均耗時優(yōu)于MySQL，性能整體提升15%；建表耗時降低了80%，且支持更高的并發(fā)，TiDB性能表現(xiàn)不差于MySQL
在機器資源使用情況上整體磁盤使用率在10%以下；在沒有熱點數(shù)據(jù)訪問的情況下，CPU平均使用率在12%；CPU.WAIT.IO平均值在0.025%以下;集群不存在資源使用瓶頸。
在可擴展性上TiDB支持一鍵水平擴縮容，且內(nèi)部實現(xiàn)查詢均衡算法，在數(shù)據(jù)達到均衡的情況下各節(jié)點可平攤查詢壓力。
在容災(zāi)性上TiDB Binlog技術(shù)可穩(wěn)定支撐TiDB與MySQL及TiDB之間的數(shù)據(jù)同步，實現(xiàn)完整的數(shù)據(jù)備份及可回退選擇。
在服務(wù)高可用性上TiDB可選擇LVS或HaProxy等服務(wù)實現(xiàn)負(fù)載均衡及故障轉(zhuǎn)移。

以下為上線后HMS主要API接口調(diào)用耗時情況統(tǒng)計：

MySQL到TiDB：Hive Metastore橫向擴展之路圖片

（左右滑動，查看更多···）

四、問題及解決方案

4.1 在模擬TiDB回滾至MySQL過程中出現(xiàn)主鍵沖突問題

在TiDB數(shù)據(jù)增長3倍后，切換回MySQL出現(xiàn)主鍵重復(fù)異常，具體日志內(nèi)容如下：

MySQL到TiDB：Hive Metastore橫向擴展之路

產(chǎn)生該問題的主要原因為每個 TiDB 節(jié)點在分配主鍵ID時，都申請一段 ID 作為緩存，用完之后再去取下一段，而不是每次分配都向存儲節(jié)點申請。這意味著，TiDB的AUTO_INCREMENT自增值在單節(jié)點上能保證單調(diào)遞增，但在多個節(jié)點下則可能會存在劇烈跳躍。因此，在多節(jié)點下，TiDB的AUTO_INCREMENT自增值從全局來看，并非絕對單調(diào)遞增的，也即并非絕對有序的，從而導(dǎo)致Metastore庫里的SEQUENCE_TABLE表記錄的值不是對應(yīng)表的最大值。

造成主鍵沖突的主要原因是SEQUENCE_TABLE表記錄的值不為元數(shù)據(jù)中實際的最大值，若存在該情況在切換回MySQL后就有可能生成已存在的主鍵導(dǎo)致初見沖突異常，此時只需將SEQUENCE_TABLE里的記錄值設(shè)置當(dāng)前實際表中的最大值即可。

4.2 PARTITION_KEY_VALS的索引取舍

在使用MySQL引擎中，我們收集了部分慢查詢?nèi)罩荆擃惒樵冎饕遣樵兎謪^(qū)表的分區(qū)，類似如下SQL：

#以下查詢?yōu)椴樵內(nèi)壏謪^(qū)表模板，且每級分區(qū)都有過來條件
SELECT PARTITIONS.PART_ID
FROM PARTITIONS
  INNER JOIN TBLS
  ON PARTITIONS.TBL_ID = TBLS.TBL_ID
    AND TBLS.TBL_NAME = '${TABLE_NAME}'
  INNER JOIN DBS
  ON TBLS.DB_ID = DBS.DB_ID
    AND DBS.NAME = '${DB_NAME}'
  INNER JOIN PARTITION_KEY_VALS FILTER0
  ON FILTER0.PART_ID = PARTITIONS.PART_ID
    AND FILTER0.INTEGER_IDX = ${INDEX1}
  INNER JOIN PARTITION_KEY_VALS FILTER1
  ON FILTER1.PART_ID = PARTITIONS.PART_ID
    AND FILTER1.INTEGER_IDX = ${INDEX2}
  INNER JOIN PARTITION_KEY_VALS FILTER2
  ON FILTER2.PART_ID = PARTITIONS.PART_ID
    AND FILTER2.INTEGER_IDX = ${INDEX3}
WHERE FILTER0.PART_KEY_VAL = '${PART_KEY}'
  AND CASE 
    WHEN FILTER1.PART_KEY_VAL <> '__HIVE_DEFAULT_PARTITION__' THEN CAST(FILTER1.PART_KEY_VAL AS decimal(21, 0))
    ELSE NULL
  END = 10
  AND FILTER2.PART_KEY_VAL = '068';

在測試中通過控制并發(fā)重放該類型的SQL，隨著并發(fā)的增加，各個API的平均耗時也會增長，且重放的SQL查詢耗時隨著并發(fā)的增加查詢平均耗時達到100s以上，雖然TiDB及HMS在壓測期間沒有出現(xiàn)任何異常，但顯然這種查詢效率會讓用戶很難接受。DBA分析該查詢沒有選擇合適的索引導(dǎo)致查詢走了全表掃描，建議對PARTITION_KEY_VALS的PARTITION_KEY_VAL字段添加了額外的索引以加速查詢，最終該類型的查詢得到了極大的優(yōu)化，即使加大并發(fā)到100的情況下平均耗時在500ms內(nèi)，對此我們曾嘗試對PARTITION_KEY_VALS添加上述索引操作。

但在線上實際的查詢中，那些沒有產(chǎn)生慢查詢的分區(qū)查詢操作其實都是按天分區(qū)的進行一級分區(qū)查詢的，其SQL類似如下：

SELECT "PARTITIONS"."PART_ID"
FROM "PARTITIONS"
  INNER JOIN "TBLS"
  ON "PARTITIONS"."TBL_ID" = "TBLS"."TBL_ID"
    AND "TBLS"."TBL_NAME" = 'tb1'
  INNER JOIN "DBS"
  ON "TBLS"."DB_ID" = "DBS"."DB_ID"
    AND "DBS"."NAME" = 'db1'
  INNER JOIN "PARTITION_KEY_VALS" "FILTER0"
  ON "FILTER0"."PART_ID" = "PARTITIONS"."PART_ID"
    AND "FILTER0"."INTEGER_IDX" = 0
  INNER JOIN "PARTITION_KEY_VALS" "FILTER1"
  ON "FILTER1"."PART_ID" = "PARTITIONS"."PART_ID"
    AND "FILTER1"."INTEGER_IDX" = 1
WHERE "FILTER0"."PART_KEY_VAL" = '2021-12-28'
  AND CASE 
    WHEN "FILTER1"."PART_KEY_VAL" <> '__HIVE_DEFAULT_PARTITION__' THEN CAST("FILTER1"."PART_KEY_VAL" AS decimal(21, 0))
    ELSE NULL
  END = 10;

由于對PARTITION_KEY_VALS的PARTITION_KEY_VAL字段添加了索引做查詢優(yōu)化，會導(dǎo)致該類查詢生成的執(zhí)行計劃中同樣會使用idx_PART_KEY_VAL索引進行數(shù)據(jù)掃描，該執(zhí)行計劃如下：

MySQL到TiDB：Hive Metastore橫向擴展之路

添加的idx_PART_KEY_VAL索引在該字段的具有相同值的數(shù)據(jù)較少時，使用該索引能檢索較少的數(shù)據(jù)提升查詢效率。在hive中的表一級分區(qū)基本是按天進行分區(qū)的，據(jù)統(tǒng)計每天天分區(qū)的增量為26w左右，如果使用idx_PART_KEY_VAL索引，按這個數(shù)值計算，查詢條件為day>=2021-12-21 and day<2021-12-26的查詢需要檢索將近160w條數(shù)據(jù)，這顯然不是一個很好的執(zhí)行計劃。

若執(zhí)行計劃不走idx_PART_KEY_VAL索引，TiDB可通過dbs、tbls檢索出所有關(guān)聯(lián)partition數(shù)據(jù)，在根據(jù)part_id和過濾條件掃描PARTITION_KEY_VALS數(shù)據(jù)并返回。此類執(zhí)行計劃掃描的數(shù)據(jù)量和需要查詢的表的分區(qū)總量有關(guān)，如果該表只有少數(shù)的分區(qū)，則查詢能夠迅速響應(yīng)，但如果查詢的表有上百萬的分區(qū)，則該類執(zhí)行計劃對于該類查詢不是最優(yōu)解。

MySQL到TiDB：Hive Metastore橫向擴展之路

針對不同執(zhí)行計劃的特性，整理了以下對比點：

MySQL到TiDB：Hive Metastore橫向擴展之路

在實際生產(chǎn)中元數(shù)據(jù)基本都是按天分區(qū)為主，每天增長大概有26w左右，且范圍查詢的使用場景較多，使用idx_PART_KEY_VAL索引查詢的執(zhí)行計劃不太適合線上場景，故該索引需不適合添加到線上環(huán)境。

4.3 TiDB內(nèi)存突增導(dǎo)致宕機問題

在剛上線TiDB服務(wù)初期，曾數(shù)次面臨TiDB內(nèi)存溢出的問題，每次出現(xiàn)的時間都隨機不確定，出現(xiàn)的時候內(nèi)存突增幾乎在一瞬間，若期間TiDB的內(nèi)存抗住了突增量，突增部分內(nèi)存釋放在很長時間都不會得到釋放，最終對HMS服務(wù)穩(wěn)定性帶來抖動。

MySQL到TiDB：Hive Metastore橫向擴展之路

通過和TiDB開發(fā)、DBA聯(lián)合分析下，確認(rèn)TiDB內(nèi)存飆高的原因為用戶在使用Dashboard功能分析慢查詢引起；在分析慢查詢過程中，TiDB需要加載本地所有的slow-query日志到內(nèi)存，如果這些日志過大，則會造成TiDB內(nèi)存突增，此外，如果在分析期間，用戶點擊了取消按鈕，則有可能會造成TiDB的內(nèi)存泄漏。針對該問題制定如下解決方案：

使用大內(nèi)存機器替換原小內(nèi)存機器，避免分析慢查詢時內(nèi)存不夠
調(diào)大慢查詢閾值為3s，減少日志產(chǎn)生
定時mv慢查詢?nèi)罩镜絺浞菽夸?/li>

4.4 locate函數(shù)查詢不走索引導(dǎo)致TiKV負(fù)異常

在HMS中存在部分通過JDO的方式去獲取分區(qū)的查詢，該類查詢的過濾條件中用locate函數(shù)過濾PART_NAME數(shù)據(jù)，在TiDB中通過函數(shù)作用在字段中是不會觸發(fā)索引查詢的，所以在該類查詢會加載對應(yīng)表的所有數(shù)據(jù)到TiDB端計算過濾，TiKV則需不斷掃描全表并傳輸數(shù)據(jù)到TiDB段，從而導(dǎo)致TiKV負(fù)載異常。

MySQL到TiDB：Hive Metastore橫向擴展之路

然而上述的查詢條件可以通過like方式去實現(xiàn)，通過使用like語法，查詢可以成功使用到PARTITIONS表的UNIQUEPARTITION索引過濾，進而在TiKV端進行索引過濾降低負(fù)載。

MySQL到TiDB：Hive Metastore橫向擴展之路

通過實現(xiàn)將locate函數(shù)查詢轉(zhuǎn)換為like語法查詢，有效降低了TiKV端的負(fù)載情況。在HMS端完成變更后，TiKV的CPU使用率降低了將近一倍，由于在KV端進行索引過濾，相應(yīng)的io使用率有所上升，但網(wǎng)絡(luò)傳輸則有明顯的下降，由平均1G降低到200M左右。

MySQL到TiDB：Hive Metastore橫向擴展之路

除TiKV負(fù)載有明顯的降低，TiDB的整體性能也得到明顯的提升，各項操作耗時呈量級降低。以下整理了TiDB增刪改查的天平均耗時情況：

MySQL到TiDB：Hive Metastore橫向擴展之路

4.5 get_all_functions優(yōu)化

隨著hive udf的不斷增長，HMS的get_all_functions api平均耗時增長的也越來越久，平均在40-90s，而該api在hive shell中首次執(zhí)行查詢操作時會被調(diào)用注冊所有的udf，過長的耗時會影響用戶對hive引擎的使用體驗，例如執(zhí)行簡單的show database需要等待一分鐘甚至更久才能返回結(jié)果。

MySQL到TiDB：Hive Metastore橫向擴展之路

導(dǎo)致該api耗時嚴(yán)重的主要原因是HMS通過JDO方式獲取所有的Function，在獲取所有的udf時后臺會遍歷每條func去關(guān)聯(lián)DBS、FUNC_RU兩個表，獲取性能極低。而使用directSQL的方式去獲取所有udf數(shù)據(jù)，響應(yīng)耗時都在1秒以內(nèi)完成，性能提升相當(dāng)明顯。以下為directSQL的SQL實現(xiàn)邏輯：

select FUNCS.FUNC_NAME,
  DBS.NAME,
  FUNCS.CLASS_NAME,
  FUNCS.OWNER_NAME,
  FUNCS.OWNER_TYPE,
  FUNCS.CREATE_TIME,
  FUNCS.FUNC_TYPE,
  FUNC_RU.RESOURCE_URI,
  FUNC_RU.RESOURCE_TYPE
from FUNCS
left join FUNC_RU on FUNCS.FUNC_ID = FUNC_RU.FUNC_ID
left join DBS on FUNCS.DB_ID = DBS.DB_ID

五、總結(jié)

我們從2021年7月份開始對TiDB進行調(diào)研，在經(jīng)歷數(shù)個月的測試于同年11月末將MySQL引擎切換到TiDB。由于前期測試主要集中在兼容性和性能測試上，忽略了TiDB自身可能潛在的問題，在上線初期經(jīng)歷了數(shù)次因慢查詢?nèi)罩緦iDB內(nèi)存打爆的情況，在這特別感謝我們的DBA團隊、平臺運營團隊及TiDB官方團隊幫忙分析、解決問題，得以避免該問題的再次發(fā)生；與此同時，由于當(dāng)前HMS使用的版本較低，加上大數(shù)據(jù)的組件在不斷的升級演進，我們也需要去兼容升級帶來的變動，如HDFS升級到3.x后對EC文件讀取的支持，SPARK獲取分區(qū)避免全表掃描改造等；此外由于TiDB的latin字符集支持中文字符的寫入，該特性會導(dǎo)致用戶誤寫入錯誤的中文分區(qū)，對于此類型數(shù)據(jù)無法通過現(xiàn)有API進行刪除，還需要在應(yīng)用層去禁止該類型錯誤分區(qū)寫入，避免無用數(shù)據(jù)累積。

經(jīng)歷了一年多的實際生產(chǎn)環(huán)境檢驗，TiDB內(nèi)存整體使用在10%以內(nèi)，TiKV CPU使用平穩(wěn)，使用峰值均在30核內(nèi)，暫不存在系統(tǒng)瓶頸；HMS服務(wù)的穩(wěn)定性整體可控，關(guān)鍵API性能指標(biāo)滿足業(yè)務(wù)的實際需求，為業(yè)務(wù)的增長提供可靠支持。在未來三年內(nèi)，我們將保持該架構(gòu)去支撐整個大數(shù)據(jù)平臺組件的穩(wěn)定運行，期間我們也將持續(xù)關(guān)注行業(yè)內(nèi)的變動，吸收更多優(yōu)秀經(jīng)驗應(yīng)用到我們的生產(chǎn)環(huán)境中來，包括但不限于對性能更好的高版本TiDB嘗試，HMS的性能優(yōu)化案例。