摘要：阿毛哥是組的開發，同時也是語言圈的大佬。阿毛哥那邊計劃是魔改一版，來達成特定表的數據從遠程服務加載這個需求。下午的我們排在最后出場，由胡爭出場演示。略有遺憾的是當時胡爭可能是過于激動，關于具體有哪些實用場景沒有細說。

本文作者是來自 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 上線，也是很好的佐證。

比賽第一天。早上 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 在技術難點上痛不欲生。當時我們就感覺勝券在握了，簡單商量了一下就各自回家休息。

第二天早上過來先是又轉了一圈探查敵情，當時腦海里就冒出來“龜兔賽跑”的故事。

幾個可視化的項目，昨天晚上走之前還幾乎是白板一片，一夜之間就酷炫到沒朋友了，尤其是鳳凰隊，真給人一種山雞變鳳凰的感覺。還有 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 這個項目吧。

首先明確一點，它不是要替換掉已有的查日志，看 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

期待大家來共同完善！