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 项目如果真要在严肃的生产环境上线，还有许多工作要做：