TiDB在特來電的探索html
1、 爲何研究TiDBsql
特來電大數據平臺經過開源與自研相結合的方式,目前已經上線多套集羣知足不一樣的業務需求.目前在大數據存儲和計算方面主要使用了Hbase、Elasticsearch、Druid、Spark、Flink.大數據技術可謂是百花齊放,百花齊放 百家爭鳴,不一樣的技術都有針對性的場景.結合實際狀況,選擇合適的技術不是一件容易的事情.數據庫
隨着接入大數據平臺的核心業務的增長,伴咱們在OLAP上主要遇到如下痛點問題.緩存
大數據技術發展迅速,咱們也一直但願採用新的技術能夠解決咱們以上問題,咱們關注到目前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.運維
2、 TiDB介紹機器學習
a) 簡介分佈式
TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啓發而設計的開源分佈式 HTAP 數據庫,結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL,支持無限的水平擴展,具有強一致性和高可用性。TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景,更復雜的 OLAP 分析能夠經過 TiSpark 項目來完成。
b) 總體架構
TiDB Server 負責接收 SQL 請求,處理 SQL 相關的邏輯,並經過 PD 找到存儲計算所需數據的 TiKV 地址,與 TiKV 交互獲取數據,最終返回結果。 TiDB Server 是無狀態的,其自己並不存儲數據,只負責計算,能夠無限水平擴展,能夠經過負載均衡組件(如LVS、HAProxy 或 F5)對外提供統一的接入地址。
Placement Driver (簡稱 PD) 是整個集羣的管理模塊,其主要工做有三個: 一是存儲集羣的元信息(某個 Key 存儲在哪一個 TiKV 節點);二是對 TiKV 集羣進行調度和負載均衡(如數據的遷移、Raft group leader 的遷移等);三是分配全局惟一且遞增的事務 ID。
TiKV Server 負責存儲數據,從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region,每一個 Region 負責存儲一個 Key Range (從 StartKey 到 EndKey 的左閉右開區間)的數據,每一個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft 協議作複製,保持數據的一致性和容災。副本以 Region 爲單位進行管理,不一樣節點上的多個 Region 構成一個 Raft Group,互爲副本。數據在多個 TiKV 之間的負載均衡由 PD 調度,這裏也是以 Region 爲單位進行調度。
² 核心特性
p 高度兼容 MySQL --無需修改代碼便可從 MySQL 輕鬆遷移至 TiDB
p 水平彈性擴展 --輕鬆應對高併發、海量數據場景
p 分佈式事務 -- TiDB 100% 支持標準的 ACID 事務
p 高可用 --基於 Raft 的多數派選舉協議能夠提供金融級的 100% 數據強一致性保證
p 一站式 HTAP 解決方案 --一份存儲同時處理 OLTP & OLAP,無需傳統繁瑣的 ETL 過程。
其中涉及到的分佈式存儲和分佈式計算,你們能夠參考TIDB的官方網站.在這裏就再也不進行論述.
c) TiSpark
在處理大型複雜的計算時,PingCAP 結合上圖說的Tikv 以及目前大數據生態的Spark,提供了另一個開源產品TiSpark.不得不說這是一個巧妙的設計,充分利用瞭如今企業已有的Spark 集羣的資源,不須要另外在新建集羣.TiSpark 架構以及核心原理簡單描述以下
圖2
3、 目前的應用狀況
因爲不少用戶已經部署了生產系統,咱們沒有在測試上再次投入比較大的精力,通過了簡單的性能測試之後,搭建了咱們的第一個TIDB集羣,嘗試在咱們的業務上進行使用.目前主要用於咱們的離線計算,以及部分即系查詢場景,後續根據使用狀況,主鍵調整咱們的集羣規模以及增長咱們的線上應用.
l 目前的集羣配置
圖3
l 規劃的應用架構
基於TiDB 咱們規劃了完整的數據流處理邏輯,從數據接入到數據展示,因爲TIDB 高度兼容MySql,所以在數據源接入和UI展示就有不少成熟的工具可使用,好比Flume、Grafana、Saiku 等.
l 應用簡介
² 充電功率的分時統計
每一個用戶使用特來電的充電樁進行充電時,車輛的BMS數據、充電樁數據、環境溫度等數據是實時的保存到大數據庫中。咱們基於保存的用戶充電數據,須要按照必定的時間展現全國的充電功率 好比展現過去一天,全國的充電功率變化曲線,每隔15分鐘或者30分鐘進行一次彙總。隨着咱們業務規模的增長,此場景的計算也逐步進行了更新換代.
目前咱們單表數據量接近20億,天天的增量接近800萬左右.使用tidb後,在進行離線計算分析時,咱們的業務邏輯轉成了直接在咱們的離線計算平臺經過sql的方式進行定義和維護,極大的提升了維護效率,同時計算速度也獲得了大幅提高.
² 充電過程分析
上面咱們講了,咱們已經有了充電過程當中的寶貴的海量數據,如何讓數據發揮價值,咱們基於充電數據進行充電過程的分析就是其中的一個方式,好比分析不一樣的車型在不一樣的環境(天然、電池等)下,充電的最大電壓和電流的變化狀況,以及咱們充電樁的需求功率知足率等.
針對海量的歷史數據計算咱們使用了TiSpark進行計算,直接使用了咱們現有的spark集羣,在使用spark進行計算時,因爲分配的資源比較少,時間多一些,後來和tidb技術人員交流了解到,提高配置和調整部分參數後,性能還會提高很多。這個場景中咱們充分利用了tidb和tispark 進行協同工做,知足了咱們的業務需求。
4、 總結及問題
² 最佳應用場景
結合咱們的線上驗證,咱們認爲使用tidb,主要有如下幾個優點
p Sql支持度相對於現有的集羣支持度較好,靈活性和功能性大大加強
p 能夠進行表之間的join運算,下降了構造寬邊的複雜度以及所以帶來的維護成本
p 歷史數據方便修改
p 高度兼容Mysql 生態下對應的成熟軟件較多(開發工具、展示、數據接入)
p 基於索引的sql性能在離線計算上基本能夠知足咱們需求,在即系查詢上最適合海量數據下進行多維度的精確查詢,相似與「萬里挑一」的場景.
p 使用TiSpark 進行復雜的離線計算,充分利用了現有的集羣,數據存儲作到了一份,同時也下降了運維成本
² 目前的定位
結合咱們的實際現狀,現階段咱們主要用於進行離線計算和部分即系查詢的場景,後期隨着應用的深刻,咱們逐步考慮增長更多的應用以及部分oltp場景.
² 發現的問題
在進行線上驗證的時候,咱們也發現了目前幾個問題
p TiDB在高併發下海量數據的聚合查詢時,性能須要提高
p 因爲TiDB 目前尚未充分利用查詢緩存,同一個連續屢次執行時,執行效率沒有變化
p 目前發現部分即系查詢場景在數據量增長時,性能有所降低,聯合TiDB技術人員診斷後(做爲開源產品,TIDB的技術支持很給力),肯定是因爲目前沒有采用SSD硬盤致使,考慮到目前的應用還比較少,後續應用豐富後,考慮SSD