TiDB 在茄子科技的應用實踐及演進

茄子科技（海外 SHAREit Group）是一家全球化互聯網科技公司，主要從事移動互聯網軟件研發與全球移動廣告變現解決方案、跨境支付解決方案等互聯網服務等業務。茄子快傳（SHAREit）是茄子科技旗下的代表產品， 是一款一站式數字娛樂內容與跨平臺資源分享平臺，累計安裝用戶數近 24 億。茄子科技作爲一家出海企業，已經在東南亞、南亞、中東以及非洲等地區，打造了多款工具和內容的應用，並且在 Google Play 的下載榜上常年名列前茅。

面向不同業態的數據庫選型

茄子科技的產品矩陣豐富，產品形態相對比較複雜，包括了工具、內容、遊戲、廣告、支付等。針對相對複雜的業務場景，根據不同的業務形態，我們做了不同的數據庫選型。目前，茄子科技使用的六款最主要的數據庫包括：

• 自研持久化 KV：特徵平臺、用戶畫像、行爲記錄等 

• Redis Cluster：業務緩存、session 信息等 

• Cassandra：內容庫 

• MySQL：Hue、Metadata、運營平臺等 

• ClickHouse：數據分析、實時報表 

• TiDB：用戶增長、APM 系統、雲賬單等

基於業務層面的痛點思考，我們在多個業務場景引入了 TiDB。

第一，茄子科技作爲一家出海企業引入了多家公有云作爲基礎設施，所以在數據庫的層面，要考慮業務在多雲架構下的業務適配、數據遷移、數據庫的兼容以及數據同步的問題。

第二，茄子有多款高流量的 APP 產品，業務呈現高速增長的態勢，傳統的 DRS 數據庫，比如 MySQL，因爲需要分庫分表，阻礙業務快速發展。

第三，Cassandra、HBase 等 NoSQL 數據庫，無法滿足分佈式事務，多表 join 等複雜場景。

第四，茄子科技的 APM（Application Performance Management）、Data Store 等系統，有一些是 HTAP 場景，同一份業務數據既有 OLTP 又有 OLAP 的需求，我們希望一套數據庫可以搞定。

引入 TiDB 之後，TiDB 在多個方面發揮出獨特優勢，幫助茄子科技打造可持續發展的數據庫生態：

• 利用 TiDB 的跨集羣遷移、數據同步的能力打造多雲架構下的業務擴展能力，滿足多雲架構下的業務架構設計。

• TiDB 提供自動水平彈性擴展的能力，做到業務無感知，解決分庫分表的問題。

• TiDB 高度兼容 MySQL，在大容量、高併發的場景下學習成本低、遷移成本低。

• 利用 TiDB HTAP 的能力，滿足業務在一份數據上的 OLTP 與 OLAP 的雙重需求。

TiDB 在 APM 場景的應用實踐

茄子科技的 APM（Application Performance Management）系統提供 APP 崩潰、性能等問題的監控、分析、看板、修復的一體化能力，用來支撐多款高增長的 APP 應用。這個系統的第一個特點就是信息量大，每天產生百億條的數據，需要保留 30 天；第二個特點是時效性要求比較高，針對一些比較棘手的情況，比如說崩潰以及嚴重的性能問題，如果時效性不能滿足的話會直接影響到用戶的體驗，甚至是產品的營收；第三個特點是需要打通工單系統，提供問題追蹤、修復的一體化能力；第四個特點是在 OLTP 事務場景的基礎上需要兼顧 OLAP 的分析場景。

首先分析一下早期 APM 的數據流轉，從 APP 數據上報到日誌收集，最後到 ClickHouse，整個數據流轉是一個類似批處理的流程，大概需要兩個多小時的時效性，整體時效性是很弱的，問題暴露不及時，會對用戶體驗產生影響。另外，這套系統裏面有 MySQL 和 ClickHouse 兩套數據庫，爲什麼這麼設計？因爲 ClickHouse 可以用來做數據的分析聚合，MySQL 主要是用來打造流程工單，同時有兩套數據庫在支撐，在成本上是比較高的。

再來看引入了 TiDB 之後的新版 APM 數據流轉，可以看到從 APP 的上報，到看板展示，到報警，再到流程工單，實現分鐘級的準實時看板展示和報警。這個部分主要是藉助了 TiDB 的 HTAP 能力，通過聚合分析向看板進行展示，向報警中心進行及時的報警。同時，利用 TiDB 的 OLTP 能力進行看板的行更新。所以，我們可以通過一套 TiDB 數據庫打通看板、監控、問題的追蹤和修復流程。

利用 TiKV 打造分佈式 KV 系統

大家知道 TiKV 是 TiDB 的存儲層，同時也是一個 Key-Value 數據庫，接下來談談茄子科技基於 TiKV 打造分佈式 KV 系統的歷程。茄子科技主要是提供工具和內容產品，產生的數據量非常大，KV 產品需要爲兩類場景做支撐：一類是數據的實時產生，對於 Redis，需要實時的寫入；另一類是針對用戶畫像和特徵引擎，將離線產生的大批量數據快速地加載到在線的 KV 存儲，爲在線業務提供快速的訪問，即 Bulk Load 能力，實際業務中需要大概每小時 TB 級的吞吐量。

下圖是茄子科技之前基於 RocksDB 自研的分佈式 KV，這個系統同時滿足上述的兩類對 KV 的需求。圖中左邊展示的架構主要是實時寫入能力的實現，數據先從 SDK 到網絡協議層，然後到拓撲層，再到數據結構的映射層，最後到 RocksDB。右邊是 Bulk Load 批量導入的流程。大家可能有一個疑問，爲什麼左邊實時的寫入流程不能滿足小時級 TB 數據導入？主要原因有兩點：一是因爲 RocksDB 的寫放大，尤其在大型場景下，LuaDB 寫放大是非常嚴重的。另一點是受限於單塊盤的網絡帶寬，導致了單機負載或者單機存儲是有限的。右邊整個批量導入的能力是怎麼實現的？它是通過 Spark 把 Parquet 進行數據解析、預分片以及 SST 生成，把 SST 上傳到 LuaDB 的存儲節點，最後通過 ingest & compact 統一加載到 KV 層，供在線的業務進行訪問，單機吞吐每秒鐘可以達到百兆。

茄子科技既然已經自研了基於 RocksDB 的分佈式 KV，爲什麼還要用到 TiKV ？首先在技術層面，雖然自研分佈式 KV 在生產已經運行了兩年多的時間，支撐了上百 TB 的數據，但是有些技術問題，比如自動彈性升縮、強一致性、事務和大 key 等支持上還需要進一步投入研發。第二，在人才層面針對高質量數據庫人才儲備還有一定的欠缺。經過多次調研以及和 TiKV 研發同學的溝通，發現我們的需求和痛點與 TiKV 的產品規劃是不謀而合的，這就促使了我們積極地擁抱 TiKV。我們藉助 TiKV 可以在技術上打造存儲與計算分離的 KV 產品。第三，TiKV 擁有活躍的開源社區，我們可以藉助社區的力量共同打磨產品。

下圖中的架構是茄子科技基於 TiKV 打造的一款分佈式 KV。左側部分主要是解決數據實時寫入的一個流程，從 SDK 到網絡存儲，到數據計算，最後到 TiKV 的存儲引擎。我們重點的研究方向是右側部分整個 Bulk Load 能力的研發，與自研的分佈式 KV 的不同，我們把整個 SST 的生成流程放在 TiKV 內部去做，這樣做的原因是可以最大化地減少 Spark 部分的代碼開發和維護成本，提升易用性。

以下兩張表是基於 TiKV 的 Bulk Load 能力進行實際測試的結果。上面這張表是在 E5 CPU，40 個 vcore，磁盤使用 NVMe 的情況下，最大可以達到 256 兆的單機吞吐。下邊這張表是我們在進行 Bulk Load 的同時對 online reading 部分進行壓測，可以看到 Latency 響應時間的抖動是非常小的，不管是 P99 還是 P99.99 ，都是處在一個比較穩定的狀態。這個測試結果是一個 Demo 的驗證，相信後續經過我們的優化，不管是存儲吞吐還是響應延遲，都會有質的提升。

Bulk Load 的能力是我們和 TiKV 的研發同學一起，共同協作開發、共同演進的。我們相信開放的力量，在不遠的某個時刻，我們會把整個架構，包括測試數據都會放到 GitHub 上公開，如果大家有相應的需求可以關注一下。

💡 本文根據茄子科技存儲負責人閆林林在【PingCAP DevCon 2021】上的演講整理而成。掃描下方二維碼查看全部視頻回放和 PPT。點擊閱讀原文查看本篇演講實況。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rsEdwXgGob4AmUB3e9Z64A