本文作者是來自 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 主幹）

最後，專案的地址在

https://github.com/TiNiuB/tiquery

期待大家來共同完善！