TiDB 在特來電的實踐

背景介紹

特來電新能源有限公司是創業板第一股特銳德（300001）的全資子公司，主要從事新能源汽車充電網的建設、運營及互聯網的增值服務。特來電顛覆了傳統充電樁的模式，世界獨創了電動汽車羣智能充電系統，得到 336 項技術專利，以「無樁充電、無電插頭、羣管羣控、模塊結構、主動防禦、柔性充電」的特色引領世界新能源汽車充電的發展，系統的鑑定結論爲：「產品世界獨創、技術水平國際領先。主動柔性充電對電池壽命能夠延長 30% 左右，電池充電的安全性能夠提高 100 倍以上。」

特來電採用互聯網思惟，依靠國際領先的汽車羣智能充電技術和系統，創新電動汽車充電商業模式，建設全國最大的汽車充電網，經過大系統賣電、大平臺賣車、大共享租車、大數據修車、大支付金融、大客戶電商，打造讓客戶滿意、政府放心的中國最大汽車充電網生態公司，引領充電網、車聯網、互聯網「三網融合」的新能源互聯網。

爲何研究 TiDB

特來電大數據平臺經過開源與自研相結合的方式，目前已經上線多套集羣知足不一樣的業務需求。目前在大數據存儲和計算方面主要使用了 HBase、Elasticsearch、Druid、Spark、Flink。大數據技術可謂是百花齊放、百家爭鳴，不一樣的技術都有針對性的場景。結合實際狀況，選擇合適的技術不是一件容易的事情。

隨着接入大數據平臺的核心業務的增長，咱們在 OLAP 上主要遇到如下痛點問題：

• 隨着基於大數據分析計算的深刻應用，使用 SQL 進行分析的需求愈來愈旺盛，但目前已經上線的大數據集羣（ HBase、Elasticsearch、Druid、Spark、Flink）對 SQL 的支持度都比較弱。
• 目前進入大數據集羣的數據主要以寬表方式進行，致使在數據歸集和後期基礎數據放生變化時應用成本較高。
• 數據倉庫業務有些仍是基於複雜的 T+1 模式的 ETL 過程，延時較高，不能實時的反映業務變化。
• 因爲每一個大數據集羣主要針對特定的場景，數據重複存儲的狀況較多，這就形成了存儲成本的增長，同時也會致使數據的不一致性。
• 目前進入 HDFS / Druid / ES 的數據，在歷史數據更新時，成本較高，靈活性下降。

大數據技術發展迅速，咱們也一直但願採用新的技術能夠解決咱們以上問題，咱們關注到目前 NewSQL 技術已經有落地產品，而且很多企業在使用，因此決定在咱們平臺內嘗試引入 NewSQL 技術解決咱們的痛點問題。

咱們先了解一下 NewSQL。

圖 1 數據庫發展史

如圖 1 所示，數據庫的發展經歷了 RDBMS、NoSQL 以及如今的 NewSQL，每種不一樣的技術都有對應的產品，每種數據庫的技術背後，都有典型的理論支撐。2003 年 Google GFS 開創了分佈式文件系統、2006 年的 BigTable 論文催生了 Hadoop 生態，在 2012 年的 Spanner 和 2013 年的 F1 論文發表後，被業界認爲指明瞭將來關係型數據庫的發展。

隨着大數據技術的發展，實際上 SQL 和 NoSQL 的界限逐漸模糊，好比如今 HBase  之上有 Phoenix，HiveSQL，SparkSQL 等，也有一些觀點認爲 NewSQL = SQL + NoSQL。不一樣的技術都有各自的最佳適應場景，Spanner 和 F1 被認爲是第一個 NewSQL 在生產環境提供服務的分佈式系統技術，基於該理念的開源產品主要爲 CockroachDB、TiDB。結合社區活躍度以及相關案例、技術支持，咱們決定 NewSQL  技術上引入 TiDB。

TiDB 介紹

TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啓發而設計的開源分佈式 HTAP 數據庫，結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具有強一致性和高可用性。

圖 2 TiDB 架構圖

TiDB 具備如下核心特性：

• 高度兼容 MySQL —— 無需修改代碼便可從 MySQL 輕鬆遷移至 TiDB
• 水平彈性擴展 —— 輕鬆應對高併發、海量數據場景
• 分佈式事務 —— TiDB 100% 支持標準的 ACID 事務
• 高可用 —— 基於 Raft 的多數派選舉協議能夠提供金融級的 100% 數據強一致性保證
• 一站式 HTAP 解決方案 —— 一份存儲同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程

其中涉及到的分佈式存儲和分佈式計算，你們能夠參考 TiDB 的官方網站，在這裏就再也不進行論述。

在處理大型複雜的計算時，PingCAP 結合上圖說的 TiKV 以及目前大數據生態的 Spark，提供了另一個開源產品 TiSpark。不得不說這是一個巧妙的設計，充分利用瞭如今企業已有的 Spark 集羣的資源，不須要另外再新建集羣。TiSpark 架構以及核心原理簡單描述以下：

圖 3 TiSpark 架構圖

TiSpark 深度整合了 Spark Catalyst 引擎， 能夠對計算提供精確的控制，使 Spark 可以高效的讀取 TiKV 中的數據，提供索引支持以實現高速的點查。

經過多種計算下推減小 Spark SQL 須要處理的數據大小，以加速查詢；利用 TiDB 的內建的統計信息選擇更優的查詢計劃。

從數據集羣的角度看，TiSpark + TiDB 可讓用戶無需進行脆弱和難以維護的 ETL，直接在同一個平臺進行事務和分析兩種工做，簡化了系統架構和運維。

除此以外，用戶藉助 TiSpark 項目能夠在 TiDB 上使用 Spark 生態圈提供的多種工具進行數據處理。例如使用 TiSpark 進行數據分析和 ETL；使用 TiKV 做爲機器學習的數據源；藉助調度系統產生定時報表等等。

目前的應用狀況

因爲不少用戶已經部署了生產系統，咱們沒有在測試上再次投入比較大的精力，通過了簡單的性能測試之後，搭建了咱們的第一個 TiDB 集羣，嘗試在咱們的業務上進行使用。目前主要用於咱們的離線計算，以及部分即系查詢場景，後續根據使用狀況，逐漸調整咱們的集羣規模以及增長咱們的線上應用。

1. 目前的集羣配置

圖 4 集羣配置清單

2. 規劃的應用架構

圖 5 引入 TiDB 之後的應用架構圖

基於 TiDB 咱們規劃了完整的數據流處理邏輯，從數據接入到數據展示，因爲 TiDB 高度兼容 MySQL，所以在數據源接入和 UI 展示就有不少成熟的工具可使用，好比 Flume、Grafana、Saiku 等。

3. 應用簡介

a. 充電功率的分時統計

每一個用戶使用特來電的充電樁進行充電時，車輛的 BMS 數據、充電樁數據、環境溫度等數據是實時的保存到大數據庫中。咱們基於採集的用戶充電數據，須要按照必定的時間展現全國的充電功率 好比展現過去一天，全國的充電功率變化曲線，每隔 15 分鐘或者 30 分鐘進行一次彙總。隨着咱們業務規模的增長，此場景的計算也逐步進行了更新換代。

圖 6 充電功率的分時統計

目前咱們單表數據量接近 20 億，天天的增量接近 800 萬左右。使用 TiDB 後，在進行離線計算分析時，咱們的業務邏輯轉成了直接在咱們的離線計算平臺經過 SQL 的方式進行定義和維護，極大的提升了維護效率，同時計算速度也獲得了大幅提高。

b. 充電過程分析

上面咱們講了，咱們已經有了充電過程當中的寶貴的海量數據，如何讓數據發揮價值，咱們基於充電數據進行充電過程的分析就是其中的一個方式，好比分析不一樣的車型在不一樣的環境（環境溫度、電池特性）下，充電的最大電壓和電流的變化狀況，以及咱們充電樁的需求功率知足度等。

圖 7 充電過程分析

針對海量的歷史數據計算咱們使用了 TiSpark 進行計算，直接使用了咱們現有的 Spark 集羣，在使用 Spark 進行計算時，一開始因爲不熟悉 TiSpark，分配的資源比較少，耗時多一些。後來和 TiDB 技術人員交流了解到最佳實踐，提高配置和調整部分參數後，性能提高很多。這個場景中咱們充分利用了 TiDB 和 TiSpark 進行協同工做，知足了咱們的業務需求。

總結及問題

1. 最佳應用場景

結合咱們的線上驗證，咱們認爲使用 TiDB，主要有如下幾個優點：

• SQL 支持度相對於現有的集羣支持度較好，靈活性和功能性大大加強。
• 能夠進行表之間的 join 運算，下降了構造寬邊的複雜度以及所以帶來的維護成本。
• 歷史數據方便修改。
• 高度兼容 MySQL 生態下對應的成熟軟件較多（開發工具、展示、數據接入）。
• 基於索引的 SQL 性能在離線計算上基本能夠知足咱們需求，在即席查詢上最適合海量數據下進行多維度的精確查詢，相似與 「萬里挑一」 的場景。
• 使用 TiSpark 進行復雜的離線計算，充分利用了現有的集羣，數據存儲作到了一份，同時也下降了運維成本。

2. 目前的定位

結合咱們的實際現狀，現階段咱們主要用於進行離線計算和部分即席查詢的場景，後期隨着應用的深刻，咱們逐步考慮增長更多的應用以及部分 OLTP 場景。

做者介紹：潘博存，特來電大數據技術研發部架構師，具備 10 多年平臺軟件設計開發經驗，現專一於大數據領域快速讀寫方向。