背景介紹
特來電新能源有限公司是創業板第一股特銳德（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 所示，資料庫的發展經歷了 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，支援無限的水平擴充套件，具備強一致性和高可用性。
TiDB 具有以下核心特性：
-
高度相容 MySQL —— 無需修改程式碼即可從 MySQL 輕鬆遷移至 TiDB
-
水平彈性擴充套件 —— 輕鬆應對高併發、海量資料場景
-
分散式事務 —— TiDB 100% 支援標準的 ACID 事務
-
高可用 —— 基於 Raft 的多數派選舉協議可以提供金融級的 100% 資料強一致性保證
-
一站式 HTAP 解決方案 —— 一份儲存同時處理 OLTP & OLAP，無需傳統繁瑣的 ETL 過程
其中涉及到的分散式儲存和分散式計算，大家可以參考 TiDB 的官方網站，在這裡就不再進行論述。
在處理大型複雜的計算時，PingCAP 結合上圖說的 TiKV 以及目前大資料生態的 Spark，提供了另外一個開源產品 TiSpark。不得不說這是一個巧妙的設計，充分利用了現在企業已有的 Spark 叢集的資源，不需要另外再新建叢集。TiSpark 架構以及核心原理簡單描述如下：
TiSpark 深度整合了 Spark Catalyst 引擎， 可以對計算提供精確的控制，使 Spark 能夠高效的讀取 TiKV 中的資料，提供索引支援以實現高速的點查。
通過多種計算下推減少 Spark SQL 需要處理的資料大小，以加速查詢；利用 TiDB 的內建的統計資訊選擇更優的查詢計劃。
從資料叢集的角度看，TiSpark + TiDB 可以讓使用者無需進行脆弱和難以維護的 ETL，直接在同一個平臺進行事務和分析兩種工作，簡化了系統架構和運維。
除此之外，使用者藉助 TiSpark 專案可以在 TiDB 上使用 Spark 生態圈提供的多種工具進行資料處理。例如使用 TiSpark 進行資料分析和 ETL；使用 TiKV 作為機器學習的資料來源；藉助排程系統產生定時報表等等。
目前的應用情況
由於很多使用者已經部署了生產系統，我們沒有在測試上再次投入比較大的精力，經過了簡單的效能測試以後，搭建了我們的第一個 TiDB 叢集，嘗試在我們的業務上進行使用。目前主要用於我們的離線計算，以及部分即系查詢場景，後續根據使用情況，逐漸調整我們的叢集規模以及增加我們的線上應用。
1. 目前的叢集配置
2. 規劃的應用架構
基於 TiDB 我們規劃了完整的資料流處理邏輯，從資料接入到資料展現，由於 TiDB 高度相容 MySQL，因此在資料來源接入和 UI 展現就有很多成熟的工具可以使用，比如 Flume、Grafana、Saiku 等。
3. 應用簡介
a. 充電功率的分時統計
每個使用者使用特來電的充電樁進行充電時，車輛的 BMS 資料、充電樁資料、環境溫度等資料是實時的儲存到大資料庫中。我們基於採集的使用者充電資料，需要按照一定的時間展示全國的充電功率 比如展示過去一天，全國的充電功率變化曲線，每隔 15 分鐘或者 30 分鐘進行一次彙總。隨著我們業務規模的增加，此場景的計算也逐步進行了更新換代。
目前我們單表資料量接近 20 億，每天的增量接近 800 萬左右。使用 TiDB 後，在進行離線計算分析時，我們的業務邏輯轉成了直接在我們的離線計算平臺通過 SQL 的方式進行定義和維護，極大的提高了維護效率，同時計算速度也得到了大幅提升。
b. 充電過程分析
上面我們講了，我們已經有了充電過程中的寶貴的海量資料，如何讓資料發揮價值，我們基於充電資料進行充電過程的分析就是其中的一個方式，比如分析不同的車型在不同的環境（環境溫度、電池特性）下，充電的最大電壓和電流的變化情況，以及我們充電樁的需求功率滿足度等。
針對海量的歷史資料計算我們使用了 TiSpark 進行計算，直接使用了我們現有的 Spark 叢集，在使用 Spark 進行計算時，一開始由於不熟悉 TiSpark，分配的資源比較少，耗時多一些。後來和 TiDB 技術人員交流了解到最佳實踐，提升配置和調整部分引數後，效能提升不少。這個場景中我們充分利用了 TiDB 和 TiSpark 進行協同工作，滿足了我們的業務需求。
總結及問題
1. 最佳應用場景
結合我們的線上驗證，我們認為使用 TiDB，主要有以下幾個優勢：
-
SQL 支援度相對於現有的叢集支援度較好，靈活性和功能性大大增強。
-
可以進行表之間的 join 運算，降低了構造寬邊的複雜度以及因此帶來的維護成本。
-
歷史資料方便修改。
-
高度相容 MySQL 生態下對應的成熟軟體較多（開發工具、展現、資料接入）。
-
基於索引的 SQL 效能在離線計算上基本可以滿足我們需求，在即席查詢上最適合海量資料下進行多維度的精確查詢，類似與 “萬里挑一” 的場景。
-
使用 TiSpark 進行復雜的離線計算，充分利用了現有的叢集，資料儲存做到了一份，同時也降低了運維成本。
2. 目前的定位
結合我們的實際現狀，現階段我們主要用於進行離線計算和部分即席查詢的場景，後期隨著應用的深入，我們逐步考慮增加更多的應用以及部分 OLTP 場景。
作者介紹：潘博存，特來電大資料技術研發部架構師，具有 10 多年平臺軟體設計開發經驗，現專注於大資料領域快速讀寫方向。