TiDB 在二維火餐飲管理實時報表中的實踐

二維火 SaaS 平台介紹

二維火作為餐飲商家管理標準化服務提供商，幫助商家節省經營成本、提升服務效果是我們的使命。在商家日常生產中，上游系統產生了很多數據，包括供應鏈採購系統（Support），門店收銀系統（POS），食客排隊系統（Queueing），智能廚房顯示系統（KDS），電子菜譜系統等（E-Menu）， 一個實時、精準、可多維度分析的報表系統能充分利用這些數據，支持商家對經營決策進行優化，極大提升商家工作效率。主要服務於以下場景：

• 收銀員交接班需要通過收銀軟體、財務報表進行多維度對賬，來保障收銀員一天的辛苦勞動。
• 商家運營人員需要時段性監控每個門店的經營狀況，並通過監控數據實時調整運營策略。
• 中小型店老闆解放自我，不再需要時時刻刻呆在門店裡，也能從原料變化到收入波動進行實時把控。
• 大型門店連鎖更有專門的指揮中心，實時了解每個門店的經營狀況，實現一體化管理。

二維火各類報表界面：

二維火實時報表的業務約束

• 要求實時或者准實時，數據延遲不超過 3 秒。
• 數據量大、數據增速快，報表結果查詢需要在 500 ms 之內返回結果。
• 查詢維度多，查詢條件複雜，涉及十幾個業務表，上百個維度匯總查詢。

隨著業務範圍擴大以及功能擴展，實時報表業務不光承擔了報表業務，業務方同時希望這是一個數據實時、可多維度查詢分析的數據平台工具，為業務進行各種數據支持。

二維火數據的特殊場景

• 商家門店連鎖關係不是固定的，A 門店數據今天屬於 AA 連鎖，明天可能會變成 BB 連鎖。
• 數據展現多人多面，許可權不同展現結果不同。
• 數據變更非常頻繁，一條數據最少也會經過五六次變更操作。
• 實時報表展現的不僅是當天數據，涉及到掛帳、垮天營業、不結賬等複雜狀況，生產數據的生命周期往往會超過一個月以上。

如果用 MySQL 作為報表存儲引擎的話，一個門店所屬連鎖總部變更，相當於分庫的路由值產生了變化，意味著需要對這家店的數據進行全量遷移，這是個災難性的事情，我們希望連鎖只是個屬性，而不用受到 Sharding Key 的制約導致的一地雞毛。

開始的解決方案

我們的業務數據是構建在 MySQL 之上，按照業務和商家維度進行分庫。利用 Otter 訂閱業務數據，進行數據整理歸併到 Apache Solr[1] 中，輸出分析、統計報表所需要的數據。然而隨著業務的快速發展以及客戶定製化需求不斷增加，Solr 的瓶頸從一張白紙慢慢地被填充。

• 不斷的添加檢索維度，需要不停的對索引進行 Full Build，Solr 的 Full Build 成本慢慢地高成了一座大山。
• 為保障數據精準，Solr 的 Full Build 必須隔段時間操作一次。
• 隨著業務蓬勃發展，數據更新頻率越來越高、範圍時間內更新的數據條數越來越多，面對 Solr GC 這個問題，我們對數據更新做了窗口控制，一條數據的更新延遲到了 10 秒鐘。
• Solr 的故障恢復時間過長，嚴重影響業務可用性。
• Solr 很好，但是對於要求能靈活定製、數據即時、維度複雜的報表業務來說，他還不夠好。

引入 TiDB

在引入 TiDB 之前，我們也評估和使用過 Greenplum，但是發現並發實時寫入的性能無法滿足我們的業務承載，在機緣巧合之下認識了 TiDB 同學們，經過了一段時間熟悉、測試和研究之後，我們意識到 TiDB 就是我們想要的產品，於是就開始在實際環境中使用 TiDB 來構建實時報表系統。

特別要讚美下 TiDB 的軟體太棒了，國內開源軟體無出其右，天然的高可用，本身減少了很多運維工作，Ansible 多節點、多組件一鍵部署，業務無感知滾動升級，特別是把監控也嵌合到軟體本身里，讓我們追蹤、定位問題異常清晰明了，大大縮減了排查成本。

當然 TiDB 的優點很多：

• 首先解決了繁瑣的分庫分表以及無限水平擴展問題，並且能保證事務特性。
• 其次故障自恢復，計算、存儲全無單點。
• 還有 TiDB 在做 DDL 操作時候，基本不影響業務使用，這個對我們經常調整表結構的業務來說，大大加快了迭代速度，在線 DDL 不再是一件奢侈的事情。
• TiDB 通過下推到存儲節點進行並行計算等技術，在數據量大、同時不影響寫入的情況下，能非常好的滿足各種統計查詢響應時間要求。

總之，TiDB 很好的解決了我們之前在實時報表碰到了各種痛點，讓我們終於不用為業務方的每項決策和用戶的需求而絞盡腦汁和痛苦不堪。

TiDB 集群總體配置如下：2*TiDB、3*TiKV、3*PD

TiDB 使用體驗

我們基於 TiDB 的實時報表系統穩定運行了一個多月，目前實時報表承載的日數據更新量在一億以上，高峰時期 TiDB 寫入 QPS 高於 4000，百級讀 QPS ，讀流量基本上是統計類 SQL， 比較複雜，最多包含十幾張表的關聯查詢。TiDB 不管從性能、容量還是高可用性以及可運維性來說，完全超出了我們的預期。TiDB 讓我們的業務開發回到了業務本質，讓簡單的再簡單，開發不需要再拆東牆補西牆忙於數據爆髮帶來的各種手忙腳亂。

整體資料庫架構圖：

在 TiDB 使用中的幾點注意事項

一些注意事項，TiDB 的官方文檔寫的非常詳細全面了，這裡我再畫蛇添足幾點個人覺得非常重要的幾項：

• TiDB 對 IO 操作的延遲有一定的要求，所以一定要本地 SSD 盤。我們一開始在一個集群中使用了雲SSD 盤，發現性能抖動非常厲害，特別是擴容縮容會導致業務基本不可用。
• 刪除大數據的時候，用小數據多批量方式操作，我們現在每批次是小於 1000 條進行刪除。
• 在大批量數據導入後，務必先操作 analyze table${table_name}。
• TiDB 開發非常活躍，版本迭代非常快，升級的時候先在非生產環境演練下業務，特別是一些複雜SQL 的場景。

後續計劃

在接入一個業務實時報表後，我們對 TiDB 越來越了解，後續我們計劃對 TiDB 進行推廣使用，具體包括：

• 把公司所有實時報表以及統計結果都逐漸遷移到 TiDB 中。
• 對業務進行分類，大表、多表關聯的複雜場景準備開始使用 TiSpark，結合現有 TiDB，會大大簡化目前整個數據產品、架構，同時大大解放運維。
• 中期會考慮將 OLTP 的業務遷入到 TiDB。

最終通過 TiDB 構造成一個同時兼容分析型和事務型（HTAP）的統一資料庫平台。

? 作者介紹：二維火架構運維負責人 火燒 （花名）