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…

期待你们来共同完善！