摘要：作者客如云公司介紹客如云成立于年，是全球領(lǐng)先國內(nèi)最大的系統(tǒng)公司。目前面向餐飲零售等服務業(yè)商家，提供軟硬一體的新一代智能化前臺收銀等云服務，包括預訂排隊外賣點餐收銀會員管理進銷存等系統(tǒng)服務，并將數(shù)據(jù)實時傳達云端。

作者：客如云 BigData Infra?Team?

客如云成立于 2012 年，是全球領(lǐng)先、 國內(nèi)最大的 SaaS 系統(tǒng)公司。 目前面向餐飲、 零售等服務業(yè)商家， 提供軟硬一體的新一代智能化前臺、收銀等?SaaS 云服務，包括預訂、排隊、外賣、點餐、收銀、會員管理、進銷存等系統(tǒng)服務，并將數(shù)據(jù)實時傳達云端。我們是客如云的大數(shù)據(jù)基礎(chǔ)架構(gòu)組，負責公司的大數(shù)據(jù)架構(gòu)和建設工作，為公司提供大數(shù)據(jù)基礎(chǔ)數(shù)據(jù)服務。

隨著公司業(yè)務架構(gòu)越來越復雜，技術(shù)架構(gòu)組需要在服務器端與應用端盡可能的通過微服務化實現(xiàn)業(yè)務解耦，同時需要第三方熔斷服務機制來保證核心業(yè)務正常運行。數(shù)據(jù)庫層面，為了保證高并發(fā)的實時寫入、實時查詢、實時統(tǒng)計分析，我們針對地做了很多工作，比如對實時要求較高的服務走緩存、對大表進行分庫分表操作、對有冷熱屬性的大表進行歸檔、庫分離，雖然用大量人力資源解決了部分問題，但是同時也帶來了歷史數(shù)據(jù)訪問、跨庫分表操作、多維度查詢等問題。

大數(shù)據(jù)量下，MySQL 稍微復雜的查詢都會很慢，線上業(yè)務也存在單一復雜接口包含執(zhí)行幾十次?SQL的情況，部分核心交易大庫急需解決訪問性能。

3.?餐飲行業(yè)有明顯的業(yè)務訪問高峰時間，高峰期期間數(shù)據(jù)庫會出現(xiàn)高并發(fā)訪問，而有些業(yè)務，比如收銀，在高峰期出現(xiàn)任何?RDS?抖動都會嚴重影響業(yè)務和用戶體驗。

傳統(tǒng)的數(shù)倉業(yè)務往往有復雜的 T+1 的 ETL 過程，無法實時的對業(yè)務變化進行動態(tài)分析和及時決策。

大數(shù)據(jù)的 ODS（Operational Data Store） 以前選型的是 MongoDB，ODS 與支持?SaaS?服務的 RDS 進行數(shù)據(jù)同步。初期的設想是線上的復雜 SQL、分析 SQL，非核心業(yè)務?SQL?遷移到大數(shù)據(jù)的?ODS層。同時?ODS?也作為大數(shù)據(jù)的數(shù)據(jù)源，可以進行增量和全量的數(shù)據(jù)處理需求。但是由于使用的MongoDB，對業(yè)務有一定侵入，需要業(yè)務線修改相應查詢語句，而這點基本上遭到業(yè)務線的同學不同程度的抵制。同時目前大數(shù)據(jù)使用的是?Hadoop + Hive?存儲和訪問方案，業(yè)務線需要把歷史明細查詢遷移到 Hadoop ，然后通過 Impala、Spark SQL、Hive?SQL?進行查詢，而這三個產(chǎn)品在并發(fā)度稍微高的情況下，響應時間都會很慢，所以大數(shù)據(jù)組在提供明細查詢上就比較麻煩。?

同時更為棘手的是，面對客戶查詢服務（歷史細則、報表等），這類查詢的并發(fā)會更高，而且客戶對響應時間也更為敏感，我們首先將處理后的數(shù)據(jù)（歷史細則等）放在了?MongoDB?上（當時?TiDB 1.0?還沒有?GA ,不然就使用?TiDB?了），然后針對 OLAP 查詢使用了 Kylin ，先解決了明細查詢的問題。 但是由于業(yè)務很復雜, 數(shù)據(jù)變更非常頻繁，一條數(shù)據(jù)最少也會經(jīng)過五六次變更操作。報表展現(xiàn)的不僅是當天數(shù)據(jù)，涉及到掛賬、跨天營業(yè)、不結(jié)賬、預定等復雜狀況，生產(chǎn)數(shù)據(jù)的生命周期往往會超過一個月以上。所以當前的?OLAP?解決方案還有痛點，所以后續(xù)我們要把 OLAP 查詢移植一部分到 TiDB 上面去，來減輕 Kylin 的壓力并且支持更加靈活的查詢需求，這個目前還在論證當中。?

同時，我們發(fā)現(xiàn) TiDB 有一個子項目 TiSpark， TiSpark 是建立在 Spark 引擎之上，Spark 在機器學習領(lǐng)域里有諸如?MLlib?等諸多成熟的項目，算法工程師們使用 TiSpark 去操作?TiDB?的門檻非常低，同時也會大大提升算法工程師們的效率。我們可以使用 TiSpark 做 ETL，這樣我們就能做到批處理和實時數(shù)倉，再結(jié)合 CarbonData 可以做到非常靈活的業(yè)務分析和數(shù)據(jù)支持，后期根據(jù)情況來決定是否可以把一部分 Hive 的數(shù)據(jù)放在 TiDB 上。

新老框架如下圖：

阿里云服務器：

TiDB / PD：3?臺 i1 型 機器，16c 64g ；

TiKV?：5?臺 i2 型機器，16c 128g， 1.8T*2 每臺機器部署兩個?KV；

監(jiān)控機一臺。

目前我們將線上?RDS?中三個庫的數(shù)據(jù)通過?Binlog?同步到?TiDB?，高峰期?QPS?23k 左右，接入了業(yè)務端部分查詢服務；未來我們會將更多?RDS?庫數(shù)據(jù)同步過來，并交付給更多業(yè)務組使用。因為 TiDB 是新上項目，之前的業(yè)務線也沒有線上 SQL 遷移的經(jīng)歷，所以在寫入性能上也沒有歷史數(shù)據(jù)對比。

（1）查詢一個索引后的數(shù)字列，返回?10?條記錄，測試索引查詢的性能。

（2）查詢兩個索引后的數(shù)字列，返回?10?條記錄（每條記錄只返回?10?字節(jié)左右的?2?個小字段）的性能，這個測的是返回小數(shù)據(jù)量以及多一個查詢條件對性能的影響。

（3）查詢一個索引后的數(shù)字列，按照另一個索引的日期字段排序（索引建立的時候是倒序，排序也是倒序），并且 Skip 100 條記錄后返回?10?條記錄的性能，這個測的是 Skip 和 Order 對性能的影響。

（4）查詢?100?條記錄的性能（沒有排序，沒有條件），這個測的是大數(shù)據(jù)量的查詢結(jié)果對性能的影響。

（5）TiDB?對比?MySQL?復雜 SQL 執(zhí)行速率：

Table 1 ?TiDB?數(shù)據(jù)量?5?千萬，MySQL數(shù)據(jù)量?2.5?千萬；

Table 2 ?TiDB?數(shù)據(jù)量?5?千萬，MySQL數(shù)據(jù)量?2.5?千萬；

Table 3 ?TiDB?數(shù)據(jù)量?5?千萬，MySQL數(shù)據(jù)量?2.5?千萬。

a. 對應 SQL：

SELECT sum(p.exempt_amount) exempt_amount FROM table1 p JOIN table2 c ONp.relate_id=c.id? AND p.is_paid = 1

andp.shop_identy in(BBBBB)??

andp.brand_identy=AAAAA

andp.is_paid=1 AND p.status_flag=1 AND p.payment_type!=8??????????????

WHEREc.brand_identy = AAAAA

ANDc.shop_identy in(BBBBB)??????????????????????????????

ANDc.trade_type in(1,3,4,2,5)??????????????????????????

ANDc.recycle_status=1????????

AND c.trade_statusIN (4,5,10)????????

ANDp.payment_time BETWEEN "2017-08-11 16:56:19" AND "2018-01-13 00:00:22"????????

ANDc.status_flag = 1????????

ANDc.trade_pay_status in(3,5)????????????????????

AND c.delivery_type in(1,2,3,4,15)

?b. 對應 SQL：

SELECT sum(c.sale_amount)tradeAmount,sum(c.privilege_amount)?privilege_amount,sum(c.trade_amount)totalTradeAmount,sum(c.trade_amount_before) tradeAmountBefore????????

FROM (SELECTc.sale_amount,c.privilege_amount,c.trade_amount,c.trade_amount_before????????

FROM table1p????????

JOIN table2c ON p.relate_id=c.id????????????????????????????????

andp.shop_identy in(BBBBB)??????????????????

andp.brand_identy=AAAAA

andp.is_paid=1 AND p.status_flag=1 AND p.payment_type!=8??????????????

and? c.brand_identy = AAAAA

ANDc.shop_identy in(BBBBB)????????????????????????????????

ANDc.trade_type in(1,3,4,2,5)????????????????????????????

ANDc.recycle_status=1???????? AND c.trade_statusIN (4,5,10)????????

ANDp.payment_time BETWEEN "2017-07-31 17:38:55" AND "2018-01-13 00:00:26"????????

ANDc.status_flag = 1????????

ANDc.trade_pay_status in(3,5)??????????????????????

ANDc.delivery_type in(1,2,3,4,15)??????????????????????????????????

ANDp.payment_type not in(4,5,6,8,9,10,11,12)????????

GROUP BY p.relate_id??) c

?c. 對應?SQL：

SELECT SUM(if(pay_mode_id=-5 or pay_mode_id = -6,0,IFNULL(pi.face_amount, 0) - IFNULL(pi.useful_amount, 0) -IFNULL(pi.change_amount, 0))) redundant

FROM table2c

JOIN? table1 p?ON c.id = p.relate_id AND c.brand_identy=p.brand_identy????????

JOIN table3pi ON pi.payment_id=p.id AND pi.pay_status in (3,5,10)

AND? pi.brand_identy=p.brand_identy ANDpi.pay_mode_id!=-23????????????????????????????????

andp.shop_identy in(BBBBB)??????????????????

andp.brand_identy=AAAAA

andp.is_paid=1 AND p.status_flag=1 AND p.payment_type!=8??????????????

WHEREc.brand_identy = AAAAA

ANDc.shop_identy in(BBBBB)??????????????????????????????

ANDc.trade_type in(1,3,4,2,5)??????????????????????????

ANDc.recycle_status=1????????

AND c.trade_statusIN (4,5,10)????????

ANDp.payment_time BETWEEN "2017-07-31 17:38:55" AND "2018-01-13 00:00:26"????????

ANDc.status_flag = 1????????

ANDc.trade_pay_status in(3,5)????????????????????

AND c.delivery_type in(1,2,3,4,15)

d.?對應?SQL：

SELECT? t.id tradeId,sum(t.trade_amount - t.trade_amount_before) AS roundAmount,? sum(-p.exempt_amount) AS exemptAmount

FROM table2t

LEFT JOINtable1 p ON p.relate_id = t.id

LEFT JOINtable3 pi ON pi.payment_id = p.id

WHEREt.brand_identy =AAAAA AND t.trade_status IN (4,5,10)

ANDt.trade_pay_status IN (3,4,5,6,8)? ANDp.payment_type IN (1,2)

ANDpi.pay_mode_id !=-23? ANDp.is_paid=1? AND? t.status_flag=1

AND t.shop_identy IN(<123個商戶號碼>)

GROUP BY t.id

e. 對應?SQL：

SELECT? t.id tradeId,??

sum(t.trade_amount- t.trade_amount_before) AS roundAmount,

sum(-p.exempt_amount)AS exemptAmount

FROM table2t

?JOIN table1 p ON t.id = p.relate_id

WHERE? t.brand_identy = AAAA

ANDt.trade_status IN(4,5,10)

ANDt.trade_pay_status IN (3,4,5,6,8)??

ANDp.is_paid=1? AND? t.status_flag=1

group by t.id ;

（6）OLTP 對比測試結(jié)果：

（7）簡單測試結(jié)論：

不管是索引查詢、分頁查詢、線上業(yè)務級的負載查詢，大數(shù)據(jù)量下 TiDB 的性能都比 MySQL 更強；

TiDB 整體性能表現(xiàn)滿足我們業(yè)務的需求。

目前線上已經(jīng)存儲超過?6?個月的數(shù)據(jù)，總數(shù)據(jù)量幾 T，支持線上的查詢和分析需求，很多一般復雜度 OLAP 查詢都能夠在秒級返回結(jié)果。TiSpark?我們也調(diào)試通過，準備移植一些支持?OLAP?的?ETL?應用做到實時 ETL。目前?TiDB?生產(chǎn)還有很多優(yōu)化的空間，比如系統(tǒng)參數(shù)，SQL?的使用姿勢，索引的設計等等。

已經(jīng)有一個交易量很大業(yè)務部門在向我們了解 TiDB，有可能要使用 TiDB 作為線上交易系統(tǒng)；

后續(xù)大數(shù)據(jù)也會使用 TiSpark 來做 OLAP 查詢和數(shù)據(jù)處理，同時也可能會作為 Kylin 的數(shù)據(jù)源；

可以預見將來不管是 OLTP，還是 OLAP 場景，TiDB 都會在客如云發(fā)揮越來越重要的作用。

感謝?TiDB?的廠商的人員給予了我們巨大的支持，希望我們能夠提供給?TiDB?一些有意義的信息和建議，在 TiDB 成長的路上添磚加瓦。

延展閱讀
TiDB 在二維火餐飲管理實時報表中的實踐
TiDB 在餓了么歸檔環(huán)境的應用
TiDB 助力一面數(shù)據(jù)實現(xiàn)消費領(lǐng)域的決策分析平臺