TiQuery：All Diagnosis in SQL | TiDB Hackathon 優秀項目分享

本文做者是來自 TiNiuB 隊的黃夢龍同窗，他們的項目 TiQuery 在本屆 TiDB Hackathon 2018 中得到了三等獎。 TiQuery 能夠蒐集診斷集羣問題所須要的信息，包括集羣拓撲，Region 分佈，配置，各類系統信息，整理成結構化的數據，並在 TiDB 中支持直接使用 SQL 語言進行查詢，開發和運維人員能夠在 SQL 環境方便高效地進行問題診斷。

「距離 Hackathon 結束已經一個多星期了，感受心情仍是沒有從激情中平復過來。不過因爲我讀書少，這時候好像只能感慨一句，黑客馬拉松真是太好玩了……」

組隊和選題

組隊的過程有些崎嶇，過程不細表，總之最後咱們湊成了 4 人團隊：

我（menglong）和阿毛哥是 PingCAP 內部員工，我在 TiKV 團隊，目前主要是負責 PD 部分的。阿毛哥是 TiDB 組的開發，同時也是 Go 語言圈的大佬。

曉峯（ID 米麒麟）是大數據圈的網紅，可能不少人都在各類社區或各類微信羣偶遇過，另外他的公司其實也是上線了 TiDB 集羣的客戶之一。

胡爭來自小米，是 HBase 的 committer，在分佈式系統方面有豐富的經驗，Hackathon 的過程當中還順便給 TiKV 集羣的全局備份方案提了幾個很好的建議，也是不得不服……他還有另一個身份，是咱們 TiKV 組員大妹子的老公，大妹子回老家休產假了因而只得派家眷來代爲過個癮。

咱們大約從一週以前開始討論選題的事情，咱們全部人都是第一次參加 Hackathon，也沒什麼選題的經驗，通過微信語音長時間的頭腦風暴，先後大約提了有五六個方案，最終敲定了 TiQuery 這個方案。 方案的主要靈感是來自 facebook 的開源項目 osquery，它能把系統的各類信息（CPU，內存，文件，掛載，設備，網絡鏈接，crontab，ulimit，iptable，等等等等）整理成結構化數據並支持以 SQL 的方式進行查詢。固然它是一個單機的，咱們須要作個 proxy 把集羣中全部節點的數據收集在一塊兒，放在 TiDB 裏供用戶查詢。再考慮 TiDB 產品生態的實際狀況，咱們還能夠蒐集 region 分佈，配置，日誌，metrics 等診斷所須要信息統一到 SQL 接口裏，這樣就升級成了一套完整的診斷工具。

最後選 TiQuery 這個方案主要考慮了這幾點：

• 不須要寫前端。咱們幾個雖說平時或多或少寫過點前端，可是畢竟手生，短期可能很難搞出酷炫的效果，並且還有翻車的風險。過後證實這個揚長避短的思路無疑是正確的，最後拿到名次的 6 個團隊只有 2 個是重點在可視化這塊的，並且呈現出來的效果以咱們的水平應該難以企及。

• 不容易翻車。由於有 facebook/osquery 這個強力項目作後盾，基本上不存在翻車的可能。作完 osquery 後，計劃的其餘部分能夠到時候根據狀況決定要不要作，能夠說是既穩又浪。

• 實用性強。咱們在平常幫助用戶排查問題的時候，常常須要在 SQL / 日誌 / Grafana / pd-ctl / tidb-ctl / ssh 各類工具來回切換蒐集各類信息。甚至有時候沒法直接訪問用戶的環境，須要一步一步向用戶說明如何去排查，在交流上花費了大量沒必要要的時間和精力。因此 TiQuery 這個項目解決的是切實存在的痛點，聽聞已經有客戶準備在生產集羣中把 TiQuery 上線，也是很好的佐證。

比勝過程

Day1

比賽第一天。早上 10 點踩着點來到公司，在前臺簡單簽了到領了周邊，轉身進入辦公區域，一瞬間就被撲面而來的熱烈的氣氛給感染到了。日常安靜空曠的工做空間此時已經是濟濟一堂，各路大神有的圍在一塊兒探討方案，有的已經打開電腦開始攻克技術難題，還有很多相互網上熟識已久的網友們在熱情地打着招呼。

我也很快找到 TiNiuB 隊的根據地，短暫寒暄後就進入了工做狀態。根據以前商量的分工，我主要負責把 PD 相關的數據轉成 table 的形式。由於對 Go 語言和 PD 的接口都很熟悉，很快就把 TiQuery 的大致框架給擼出來了，PD 相關的數據源也依次給整理出來了。

阿毛哥那邊計劃是魔改一版 TiDB，來達成特定表的數據從遠程服務加載這個需求。原本咱們想的是須要 hack 一下 physical plan，或者實現一個新的 storage 什麼的，想一想還有些複雜。到他具體作的時候猛然發現 InformationSchema 這個神奇的存在，簡單介紹下，InformationSchema 包含了 TiDB 中一系列特殊的表，它們的數據是直接從內存中撈來的，不須要通過 physical plan，也不須要走 storage。因此咱們仿照 InformationSchema 的方式處理一下就好了，只不過數據是從 TiQuery 獲取而不是直接在內存裏。

兩邊寫完以後咱們很快進行了簡單的聯調，直接就經過測試了。看到 「SELECT * FROM pd_store」跑出結果後你們不禁地一陣歡呼。不得不說，當不須要考慮異常錯誤處理，不須要寫測試，不須要 review 的時候寫代碼的效率是真高……

中午咱們在園區的「那家小館」吃午飯。這裏有個小插曲，胡爭早了爲了方便進園區把大妹子的員工卡給帶來了，咱們一合計估摸她休假以前應該卡里還留了很多錢，便決定飽餐一頓後強行用她的卡買單。等到告終帳的時候才發現卡里只給留了 8 分錢……最後只好我掏了卡，並暗地裏下決心好歹得拿個獎回來，否則偷雞不成還蝕把米，與此同時不由爲胡爭將來漫長的婚姻生活捏了把汗。

下午咱們加入了 osquery-agent 服務負責從不一樣節點蒐集上報系統信息，並用腳本把 osquery 的全部 schema 轉成了 MySQL 兼容的形式導入進 TiDB。跑通後簡單的試玩了下，基本上能按預期的方式運行，可是實用性方面有一些不足。隨後咱們主要從這幾個方面進行優化：

• 增長集羣拓撲結構的信息。osquery-agent 變身成 tiquery-agent，除了 wrap osquery 以外還上報節點所運行的全部服務信息。

• 引入 psutil 庫，tiquery-agent 支持查詢針對單個服務更精確的 CPU，內存等信息。

• 調研 prometheus 轉成 table 的可行性，這個咱們發現短期不太好作，就放棄了。

其餘同步在作的事情包括用 ansible 部署了一套測試集羣，開始作演示用的 slides，梳理 TiQuery 能提供的功能整理一個有說服力的 user story。期間我還客串了下導師的角色，支持了幾個涉及到 PD 的項目。

到了晚上，測試集羣上已經能徹底順暢地跑起來了，slides 基本上完成，演示要用的查詢也都準備好了。霸哥（導師團成員韓飛，人稱 SQL 小王子）幫咱們手寫了一個複雜的 4 表 JOIN，一鼓作氣，你們紛紛表示向大佬低頭。

23 點左右，我又去整個賽場溜達了一圈，發現比較有競爭力的幾個項目要麼還在埋頭苦幹，要麼就是 block 在技術難點上痛不欲生。當時咱們就感受勝券在握了，簡單商量了一下就各自回家休息。

Day2

次日早上過來先是又轉了一圈探查敵情，當時腦海裏就冒出來「龜兔賽跑」的故事。

幾個可視化的項目，昨天晚上走以前還幾乎是白板一片，一晚上之間就酷炫到沒朋友了，尤爲是鳳凰隊，真給人一種山雞變鳳凰的感受。還有 TiBoys，昨天我琢磨着項目太宏大，鐵定無法搞出來的，早上去一看，readme 裏的 todo list 已經基本上全給勾上了，很難想像這一晚上他們經歷了什麼……

咱們當天其實就沒作什麼事情了，就整理了下項目文檔什麼的，還找了個馬里奧的圖片 ps 了下。

下午的 Demo 咱們排在最後出場，由胡爭出場演示。整個過程出奇地順暢，評委的疑問也順暢的解答了，其實咱們的項目自己比較簡單，要作的事情一兩句話就能說清楚。略有遺憾的是當時胡爭多是過於激動，關於 TiQuery 具體有哪些實用場景沒有細說。

最後咱們在衆多優秀的做品中殺出重圍，僥倖拿到了三等獎，第一次參賽的你們都很興奮，晚上天然是又出去好好腐敗了一把，並相約之後再找機會參加相似的活動……

感想和總結

我本人喜歡跑步，也參加過屢次馬拉松賽，其實馬拉松賽不只在於競技，也不只在於堅持跑完那 42km，更重要的是它是一大羣有共同愛好的人聚在一塊兒的一次狂歡。從這個角度看，「黑客馬拉松」真的是很是貼切的一個名字。在這裏我想感謝 PingCAP 和志願者們的精心組織，提供了這麼好的一個機會讓你們有機會互相欣賞，切磋，交流，學習。

經過此次比賽我也積攢了一些經驗，或者說下次參加 Hackathon 會去考慮的一些點吧，在這裏分享出來供你們探討：

THINK BIG。咱們在選方案的時候特別怕想複雜了到時候作不出來而後翻車，實際上在 Hackathon 比賽時爆發出的潛能會遠超本身的想象，結果就是咱們迅速就完工了後面其實無所事事……能夠簡單針對編程速度算下帳：不用考慮異常處理，效率 x2，不用寫單元測試，效率 x3，不用 code review，效率 x2，不用考慮優雅設計先後兼容，效率 x2，全天 24 小時工做，效率 x3（根據貴司具體狀況可調整爲 x2），再加上是幾我的一塊兒作的，粗略算下來 24 小時內足以作完平時須要幾個月才能完成的事情，所以咱們設計方案時能夠儘管往大了想。

SHOW OFF ALL。比賽以前咱們就已經意識到 Demo 展現環節很是關鍵，可是惋惜這塊仍是作得不夠好，有些花力氣作了的功能最終沒有最後在 Demo 時展示出來，從此參加相似的比賽時會更加註意這一點。

TiQuery 項目及其將來

最後再花一些篇幅來推廣下 TiQuery 這個項目吧。

首先明確一點，它不是要替換掉已有的查日誌，看 metrics，調用 PD API 等現有的診斷問題手段，而是提供一種新的途徑和可能，即直接使用 SQL 語言，而且這種途徑在不少場景下會更方便甚至是變不可能爲可能。

好比咱們日常定位一個慢 SQL，可能須要先在 SQL 環境中確認有問題的語句，而後去日誌中找出響應時間長的 Region，隨後使用 pd-ctl 去查詢 Region 的信息，而後再根據 leader 所在的 TiKV ID 查詢到對應 TiKV 所在的節點，而後再 ssh 登陸到對應的節點查詢關鍵線程的 CPU 佔用狀況……

若是部署了 TiQuery，以上操做均可以在 SQL 環境中搞定，不用各類工具來回切換，並且經過 SQL 的關聯查詢功能，以上整個流程甚至只須要一條語句。

再好比，客戶的環境可能對訪問某些資源有限制，好比沒有權限 ssh 登陸對應的服務器，防火牆的緣由沒法查看 Grafana，這時 TiQuery 就能幫且咱們拿到本來拿不到的信息。還有的時候，咱們沒法直接鏈接客戶的集羣，只能遠程指導客戶去診斷問題，這種狀況下不用去費力教會客戶用各類工具了，直接扔過去一條 SQL，豈不美哉。

另外，SQL 做爲一門標準化的查詢語言，在易用性方面有着自然的優點，不只方便不瞭解 TiDB 的 DBA 快速上手，其餘外部系統也能方便地對接（好比外部監控報警系統）。

固然了，TiQuery 項目若是真要在嚴肅的生產環境上線，還有許多工做要作：

• 完善異常處理，重構，文檔的完善

• 更多 schema 支持，包括日誌文件，prometheus metrics 等

• tidb-ansible 集成，包括部署 tiquery-agent 服務，配置生成，安裝 osquery 等

• TiDB 支持外部數據源加載數據（這個特性在 Hackathon 其餘項目也有各自的實現，期待能合入 TiDB 主幹）

最後，項目的地址在

github.com/TiNiuB/tiqu…

期待你們來共同完善！