TiDB在特來電的探索

TiDB在特來電的探索html

1、  爲何研究TiDBsql

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

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

  • 隨着基於大數據分析計算的深刻應用,使用sql進行分析的需求愈來愈旺盛,但目前已經上線的大數據集羣對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.運維

2、  TiDB介紹機器學習

a)       簡介分佈式

    TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啓發而設計的開源分佈式 HTAP 數據庫,結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL,支持無限的水平擴展,具有強一致性和高可用性。TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景,更復雜的 OLAP 分析能夠經過 TiSpark 項目來完成。

b)       總體架構

 

 

  • TiDB Server

   TiDB Server 負責接收 SQL 請求,處理 SQL 相關的邏輯,並經過 PD 找到存儲計算所需數據的 TiKV 地址,與 TiKV 交互獲取數據,最終返回結果。 TiDB Server 是無狀態的,其自己並不存儲數據,只負責計算,能夠無限水平擴展,能夠經過負載均衡組件(如LVS、HAProxy 或 F5)對外提供統一的接入地址。

  • PD Server

 Placement Driver (簡稱 PD) 是整個集羣的管理模塊,其主要工做有三個: 一是存儲集羣的元信息(某個 Key 存儲在哪一個 TiKV 節點);二是對 TiKV 集羣進行調度和負載均衡(如數據的遷移、Raft group leader 的遷移等);三是分配全局惟一且遞增的事務 ID。

  • TiKV Server

   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

  • TiSpark 深度整合了 Spark Catalyst 引擎, 能夠對計算提供精確的控制,使 Spark 可以高效的讀取 TiKV 中的數據,提供索引支持以實現高速的點查。
  • 經過多種計算下推減小 Spark SQL 須要處理的數據大小,以加速查詢;利用 TiDB 的內建的統計信息選擇更優的查詢計劃。
  • 從數據集羣的角度看,TiSpark + TiDB 可讓用戶無需進行脆弱和難以維護的 ETL,直接在同一個平臺進行事務和分析兩種工做,簡化了系統架構和運維。
  • 除此以外,用戶藉助 TiSpark 項目能夠在 TiDB 上使用 Spark 生態圈提供的多種工具進行數據處理。例如使用 TiSpark 進行數據分析和 ETL;使用 TiKV 做爲機器學習的數據源;藉助調度系統產生定時報表等等。

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

相關文章
相關標籤/搜索