<input id="0qass"><u id="0qass"></u></input>
  • <input id="0qass"><u id="0qass"></u></input>
  • <menu id="0qass"><u id="0qass"></u></menu>

    海外直播軟件 Bigo 的 TiDB 4.0 線上實踐

    作者介紹:徐嘉埥,Bigo DBA,TUG 華南區大使。

    Bigo 于 2014 年成立,是一家高速發展的科技公司。Bigo 基于強大的音視頻處理技術、全球音視頻實時傳輸技術、人工智能技術、CDN 技術,推出了一系列音視頻類社交及內容產品,包括 Bigo Live、Likee、imo、Hello 語音等,在全球已擁有近 4 億月活用戶,產品及服務已覆蓋超過 150 個國家和地區。

    TiDB 4.0 在 Bigo 的使用情況

    我們在今年年初開始使用 TiDB 4.0 測試版本,在測試的時候搭建了一個測試環境的集群,它始終會跟隨著 TiDB 的最新版本迭代,所以我們前不久也迅速升級到了 4.0 GA 版。

    對于 TiDB 在生產環境的上線,我們非常勇敢,也是非常大膽的部署了 2 套生產環境集群,這兩個集群規模不算非常大,更多的是偏分析類的業務。一套是網絡監控的分析,特點是數據量增長大,且 SQL 偏分析類,同時對響應時間由一定要求;還有一套是做大數據的下游存儲,大數據分析后的數據提供線上的實時服務來使用,單表數據量通常也不小,大多是運營類的后臺匯總業務。我們使用了 TiUP 進行集群部署,這也是官方相對比較推薦的部署方式,簡單來說 TiUP 這個部署的方式比之前的 TiDB Ansible 好很多,解決了我們一大部分的問題。

    另外,我們使用 TiDB 4.0 更多的組件和功能,包括 Pump、TiFlash 等等。由于 Bigo 的業務覆蓋全球,所以我們希望在全球各個大洲(或者說各個大區)都能夠部署上自己的服務,而服務的跨大洲延遲,對于一部分業務來說是不可接受的,因此我們會通過 Pump 之類同步的方式,來進行各洲之間的數據同步。關于 TiFlash,稍后我會花更多篇幅分享實踐經驗,熟悉我的 TiDB 社區伙伴們應該都知道,我總在各個場合夸“TiFlash 是真的香”。

    我們為什么會使用 TiDB 4.0?

    一方面業務上有新的需求,通常作為 DBA 我們會盡量去滿足業務的需求。

    比如 TiDB 4.0 支持通過字符集排序規則來控制大小寫是否敏感,在此之前我們是沒有辦法控制的,所以說經常有業務同學向我們吐槽說你們 TiDB 的服務部署了之后,字符級的排序就跟“假”的一樣,當然確實之前好像也是假的,因為沒有辦法控制。

    還有一些電商、金融平臺會使用悲觀事務,而 TiDB 4.0 實現了 悲觀事務,對于業務來說不需要那么關注一致性或者說數據沖突之類的問題了。

    另一方面是運維方面的需求。

    我們現在使用 TiUP 的包管理的方式來部署 TiDB,包括升級迭代,之前我們用的是 TiDB Ansible,需要做授權認證等一系列的工作,而且它通過 playground 也沒有那么靈活。而 TiUP 做得更好的一點就是它更靈活,它的包管理機制不需要每一次授權都需要找最底層的 SaaS 團隊讓他們去開一些權限,會減輕更多的交互。而且我們可以通過 TiUP 來查看真個集群的狀況。

    還有就是備份功能,我們很多核心業務一直想在 TiDB 上做一些嘗試,但是由于之前只能通過 Mydumper 或者磁盤快照等等,可能對 DBA 運維上不那么友好的方式去進行備份,現在 TiDB 4.0 已經有了非常完善的備份功能,因此我們會盡一切可能地去推動 TiDB 4.0 在更多業務中上線。

    當然最重要、最核心的理由是 TiFlash。TiFlash 從架構上來看,在 KV 旁邊多了一個列存的副本,這個副本當然也通過 MVCC 之類的可以做一致性的讀取,更重要的它是一個列存。

    按照我們之前的理解,我們會把線上或者我們會把所有的請求分為 OLTP 和 OLAP 這兩類,那些灌輸的知識都會告訴我們,線上實時的業務請求都是 OLTP 的請求,大數據的匯總都是 OLAP 的請求,但是我們真真正正的去想一想,真實的線上業務場景的請求真的只有 OLTP 嗎?或者說所有經過大數據匯總的數據真的只有 OLAP 的查詢嗎?其實未必。很多業務場景上會有一些運營類的需求,會有實時報表類的查詢。如果說我們用以往大數據的那一套東西,通常會是一個 T+1 或 T+N 的時間,做不到實時。但是線上業務需要去管理平臺做匯總類的查詢,有時候就直接把它扔到了線上TP 類的存儲上去,當然有的業務會通過改索引、進行數據異構來做。但現在 TiFlash 給了我們另一種選擇,就是通過增加一個新的列存副本來解決實時分析的場景。

    在上圖的右下角,我列了一個 SQL(處理了一些敏感信息),大家可以看到這個 SQL 有 100 多行,它有一堆的表和 groupby,還有一些條件,在上面還做了 SUM 計算。這個是實時業務的請求,通常放在線上的 MySQL 上或者放在只有 TiKV 引擎的 TiDB 上,可能要跑到分鐘級甚至更多。在這個業務上面我們直接勇敢嘗試了 TiFlash,事實證明直接使用 TiFlash 的引擎,我們可以把這樣的請求直接降到 50 秒左右,這對于業務會更加友好,并且它的數據是實時的,因為 TiFlash 的每一個 Region 都是通過 TiKV 的 Region 來進行同步,并通過 Raft 保證一致性。

    除此之外,TiDB 本身還可以和我們已有的大數據進行結合,通過 TiSpark 來直接打到下面的引擎層,包括 TiKV 和 TiFlash。

    當然做了這樣的優化以后,業務方通常還會看著我們說:DBA 大佬們能不能再給力一點?于是我們向 PinpCAP 技術團隊尋求了一些幫助。是不是可以再給力一點呢?答案是可以的。

    在 TiDB 4.0 GA 版本里,TiFlash 增加了兩個新的算子,它可以把更多算子進行下推,同時把更多 Region 進行合并,也就是說多了兩個相應的優化參數,這兩個優化參數雖然默認是關閉的,但是我們可以通過設置將它打開,打開以后提升效果會非常明顯,至少在我們的測試中提升了一倍以上,從原來的 25 秒穩定在了 11 秒到 12 秒。這樣下來的話,實際上已經和線上的實時查詢差距并不大了,也就是說我們擁有了非常實時的線上分析能力。

    所以現在我們的業務會傾向于選擇 TiFlash,而不是選擇通過大數據的那一套數據的導入和導出,因為我所有的大數據導入、導出涉及數據管道的鏈路相對比較長,并且缺乏來回的校驗,這也是我們在最終選擇引擎的時候選擇 TiFlash 的原因。

    總的來說,Bigo 整個線上業務的所有的 TiDB 4.0 集群,都會至少配備一個 TiFlash 的副本。對于 DBA 來說,穩定性很重要,而 TiFlash 帶來的保證是:至少不會變得更差,即使 TiFlash 的副本掛了,在沒有其他 TiFlash 副本的情況下我們也同樣可以把算子打到 TiKV 上。這就是我們作為 DBA 去選擇 TiDB 4.0 以及選擇 TiFlash 的重要原因。

    基于 TiDB 4.0 我們還會做什么?

    1. 對于同步場景的 TiCDC 嘗試

    我們的業務會有一個多點同步的問題,在多個大洲都有寫入。多點同步的問題我們最開始是使用 Pump+Drainer 的方式,但因為我們會有一些多點寫入的問題,所以還需要做一些去重之類的改造工作。而現在 Pump+Drainer 本身的部署還有一些可用性的問題,而且資源消耗也比較大,還會產生一些我們并不希望產生的中間 binlog,所以我們試圖通過新的 TiCDC 數據同步工具來進行多個 TiDB 以及多個不同數據源之間的同步,我們可能還會再做一些自己的開發,包括解決沖突、數據之間的合并等等。

    2. 基于 PD 的服務發現

    因為整個 TiDB 很多業務部署架構是把 TiKV 和 TiFlash 作為引擎層的部署,TiDB Server 層或者是一個無狀態的服務,大部分的業務會接在無狀態的服務之上,再加一層類似于 proxy 之類的東西進行轉發,以達到負載均衡。這個方法并沒有非常優雅,比如將它上接上了容器以后,可能通過容器的彈性擴縮容以及其他的方式來做,就會出現 proxy 無法及時的感知到后端的變化的情況。

    一個比較好的方面是 PD 基于 etcd 的一些接口,我們可以直接拿來用,然后從中發現可用的 TiDB 節點,當進行彈性擴容的時候,比如一波流量高峰來臨的時候,彈性擴容一個無狀態的 TiDB 會非???#xff0c;這時 PD 會迅速的發現那個 DB,我們就可以直接從 Client 端發現那個服務,直接把流量打過去。這樣可以更快讓一個擴容出來的服務快速上線,而這對于業務來說并不需要更多的改造。如果通過傳統的方式,我們可能需要當擴容出來的 DB 真真正正的注冊到服務以后,還需要再次在 proxy 中進行重新注冊,就會拖慢了整個流程。

    3. 基于 Dashboard 的更多的探索

    下圖是實際上是 TiDB Dashboard 的一張熱點圖:

    作為一個 DBA,有的時候也會和業務產生一些“對立”的情況,比如業務同學:我沒有做請求,我沒有任何變化,我的數據沒有熱點、很均勻。但現在我們有了 TiDB Dashboard 以后,我們可以自己看到這個數據是「長什么樣」的了。這個熱點圖橫向是時間軸、縱向是各個數據的分區、分片,可以看到這個數據在某個時間、在各個分片上的量。如果再遇到當業務同學說“我的數據沒有熱點、我的數據完全均勻、我的數據非常 ok”的時候,DBA 就可以拿出一張這樣的熱點圖來,明確指出哪個數據有熱點、哪個數據有變化,業務上是不是有什么樣的數據的傾向、或者有什么樣的數據的變化導致了熱點的產生。

    很多時候業務同學也并不完全能夠掌控自己的數據和變化趨勢,有了這樣一份“完全的數據快照”會給我們的工作帶來巨大的便利。當然 Dashboard 同時帶來了更多好處,比如說它更好地檢查到慢查詢,提供了檢查各種日志的方式,我們甚至可以在 Dashboard 上面去一鍵抓取 Perf 火焰圖,然后通過火焰圖來分析當前的集群究竟問題出在什么地方。

    多乐彩