我眼中的分布式系统可观测性

位于 M87 中央的特大质量黑洞示意图（© EHT Collaboration）
今天的文章我想从这张模糊的照片提及。相信很多小伙伴对这张照片并不陌生，这是去年人类第一次拍摄的 M87 中央黑洞的照片，从1915年，爱因斯坦提出相对论预言黑洞的存在到 2019 年我们终于第一次「看到」了黑洞的样子，中心整整相隔了 100 多年，这对于人类熟悉黑洞乃至熟悉宇宙都是一个里程碑式的事件。人类是一个感性的动物，所谓「一图胜千言」很多时候一张图传达的信息凌驾千言万语。关于黑洞我不想展开太多，今天我们聊聊「望远镜」。

前几天，在 TiDB 4.0 的开辟分支中，我们引入了一个新功能叫做：Key Visualizer（下面简称 KeyViz），提及来这个小工具也并不复杂，就是用差别颜色的方框来表现整个数据库的差别位置数据访问频度和流量。一开始我们只是仅仅将它定位为一个给 DBA 用来办理数据库热点题目的调优辅助小工具，但是从昨晚开始我就不停在把玩这个小东西，突然觉得它对于分布式数据库来说背后的意义远不及此。在 CNCF 对 Cloud Native 的定义中，有一条叫做「Observability」，通用的翻译叫系统的「可观测性」。过去我不停苦于探求一个例子说明什么叫做一个「可观测」的系统，在 KeyViz 这个项目上，我找到了对这点绝佳的体现。举几个直观的小例子。你知道 TPC-C 测试「长」什么样子吗？请看下图：

KeyViz 给 TPC-C 拍摄的「照片」图中横轴是时间，纵轴是数据的分布，左半部分是数据导入的过程，有零散的亮点，可以看到写入分散到多个区块；右边密集的色块是测试在运行时系统的及时读写状态，越暗表示流量越小，越亮表示流量越高。从密集的色块我们能够看得出来，workload 根本分布匀称，但是大概有两处是明显偏亮的区域，其中靠近最上方，有一个特别明显的局部访问热点（最亮的那条线）。第二个例子，你见过 Sysbench 测试 「长」什么样子吗？看看下面。

左边比力密集的豁亮黄块部分，是导入数据阶段；右半段明暗相间的部分是在进行 oltp_point_select 测试，因为选取的模式是 uniform 模式，并且导入的时候是 32 线程 32 张测试表，可以看到的数据和分布和访问都比力匀称。如果你看懂了上面两个小例子，下面是一个小作业：这是我们模拟的一个现实用户的生产环境的照片，这个用户的系统遇到了一些瓶颈，你能看出题目吗？

上面几个小例子是让大家对 KeyViz 有个感性的熟悉，在介绍这个东西背后的意义之前，我想先介绍一下 TiDB 这类典范的分布式数据库的系统架构，方便大家更好的理解。

一个典范的分布式数据库的数据分布策略分布式数据库，顾名思义，数据一定是分散在差别机器上的。对于一张表的数据，我们会在逻辑上切分成若干个连续的区间，将这些区间内的数据分给差别的机器存储，不管是写入照旧读取，只需要知道目标数据属于哪个区间，就可以直接到那个机器上进行访问。然后加上对每一个区间的数据在物理上做多副本冗余，实现高可用。如下图所示，Region 在 TiDB 的内部就是一个个连续的数据区间。

和很多分布式数据库不太一样的是，我们的 Region 的巨细比力小（默认 96MB) ，别的数据的分布并不是静态的，而是动态的，Region 会像细胞一样分裂/合并，也会在差别机器之间移动进行动态的负载平衡。

如今回头看这个计划，照旧觉得无比的简洁和优雅。对用户而言再也不消去思索怎么分库，怎么分表，数据在最底层的细胞就像有生命一样繁衍和迁徙。

然后题目就来了，对于这样的数据库而言，有没有一种办法能够直观地描述系统的运行时状态？我怎么知道它是不是「生病」了？我能不能推测这个系统的未来？我能不能发现未知的风险？过去，不管是业务开辟者照旧 DBA，衡量一个数据库的状态，来来回回就是几个指标，QPS 、TPS、查询时间、机器负载（CPU、网络、磁盘），但很多时候就像是盲人摸象一样对于系统的全局我们是不清楚的。再加上在一个分布式的架构下，很多时候，我们可能会被海量的数字蒙蔽了双眼。一些有履历的 DBA 大概可以通过自己的履历，从多个指标里模糊构建出业务全局状态，但是到底这个履历每每是不可描述的，这就是为什么一些老运维、老 DBA 那么值钱的原因，但是我以为这种做事方式是很难 scale 的。CT 、B 超、核磁共振，这些当代化的手段极大地促进了当代医学的发展，因为我们第一次能「看见」我们身体的内部状态，从而才能得出精确的判断。在计算机的世界道理也是相通的，最好通过某些工具让人清晰地「看见」系统运行的健康状态、帮助诊断病灶，从而降低履历门槛和不确定性。过去也常常有朋友问我：“你说我这个业务适不适合使用 TiDB？”这时我们只能问，你的 QPS 多少 TPS 多少，数据量多少？读写比？典范查询？数据分布怎么样？表结构是什么呀？等等一连串的灵魂拷问，而且很多术语都非常专业，不是在这个行业摸爬滚打很久的老司机可能都搞不太清楚。而且有些信息可能是敏感的，也不方便共享。所以「预判 TiDB 到底适不适合某项业务」就成了一个玄学题目，这个题目困扰了我很久，很多时候也只能凭个人感觉和履历。着实这个题目也并不是 TiDB 特有，尤其是近来几年，几乎所有当代的分布式系统，都或多或少有类似的题目。在过去，一个物理机器的状态确实可以通过几个监控指标描述，但是随着我们的系统越来越复杂，我们的观测对象正渐渐的从「Infrastructure」转到「应用」，观察行为本身从「Monitoring（监控）」到「Observability（观测）」。固然看上去这两者只是笔墨上的差别，但是请仔细思索背后的含义。关于这个话题，我很喜欢引用下面这张图：

上图坐标描述了我们对系统的理解程度和可网络信息之间的关系。在 X 轴的右侧（Known Knows 和 Known Unknowns）这些称为确定性的已知和未知，图中也给出了相对应的例子，这些信息通常是最基础的普适的事实，也就是在系统上线之前我们一定就能想到，一定能够监控起来的（CPU Load、内存、TPS、QPS 之类的指标），我们过去已有的大多数运维监控都是围绕这些确定的东西。但是有一些环境是这些基础信息很难描述和衡量的，比方这个坐标的左上角：Unknown Knowns，用通俗的话来说，叫做「假设」。举个数据库的例子：有履历的架构师在计划一个基于分布式数据库的应用时，通常不会将表的主键设成自增主键，会尽可能的用 UUID 或者其他方式打散数据，这样在即使有突发写入压力的时候，系统也能很好的扩展。注意在这个例子中，着实「假设」的事情（写入压力突然增大）并没有发生，如果在日常压力不大，数据量不多的环境下，即使使用自增主键，从已有的基础监控中，可能也很难看出任何题目。但是到出事的时候，这个计划失误就会酿成 Unknown Unkowns（意外），这是任何人都不想看到的。有履历的架构师能通过种种的蛛丝马迹证实自己的推测，也从无数次翻车的 Post-mortem 中将 Unknown Unknowns 的范围变小。但是更合理的做法是通过技术手段描绘系统更全面的状态。在 Cloud Native 和微服务的世界里，近来几年一个行业的大趋势是将「系统的可观测性」放在一个更高的位置（监控只是可观测性的一个子集），这是有道理的。

回到数据库的世界，TiDB KeyViz 的意义在于，就像上面提到的，这个工具不仅仅是一个监控工具，而且它能以一个非常低门槛且形象的方式让架构师具象化的看到自己对于业务的「假设」是否符合预期，这些「假设」不一定是能够通过监控反映的，以获得对业务更深刻的 Insight。照旧说回上面那个主键的小例子。对于两种差别的主键计划，KeyViz 这边是怎么表现的呢？看看下面两张图，是不是非常一目了然？

所以如今如果有朋友问我，“这个业务适不适合 TiDB？”我只需要通过录制线上流量，或者搭建一个从集群，只需要把 KeyViz 的图给我看一眼，我甚至都不需要压力测试就能判断这个业务是否适合，而且即使不适合，我也能正确的给出修改建议，因为 KeyViz 的图对我的「假设」的可解释性有了很强的支持。我们不妨在此基础上再放飞一下想象力，为什么人类能够一眼就从这图片中理解这些信息，这说明这些图形背后有模式，有模式我们就可以识别——想象一下，如果所有的 TiDB 用户，都使用 KeyViz 将自己的系统具象化后分享出来（着实这些图片已经高度抽象，已经不具有任何的业务机密信息），我们是不是可以通过机器学习，挖掘背后更深层次的价值？AI 能不能通过这种形式更加理解我们的业务？

最后，我想以我最喜欢的科幻小说《三体：黑暗森林》中的一段话结束这篇文章，大抵是面壁人希恩斯在冬眠后被妻子唤醒后的一个场景：
……与此同时，希恩斯感觉到围绕着他们的白雾发生了变化，雾被粗化了，显然是对某一局部进行了放大。他这时发现所谓的雾着实是由无数发光的小微粒构成的，那月光般的光亮是由这些小微粒自身发出的，而不是对外界光源的散射。放大在继续，小微粒都酿成了闪亮的星星。希恩斯所看到的，并不是地球上的那种星空，他仿佛置身于银河系的焦点，星星密密麻麻，几乎没有给黑夜留出清闲。


“每一颗星星就是一个神经元。”山杉惠子说，一千亿颗星星构成的星海给他们的身躯镀上了银边。

延展阅读
TiDB 4.0 新特性前瞻（一）拍个 CT 诊断集群热点题目

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！