Kibana 图形试玩 | 多突出各原因占比

Posted 2021-07-02 三疯白帽笔记

小目标：2021-02-25 开始日拱三年七百篇 #72/720，迭代三疯白帽笔记，入门白帽。

1. 日拱学习

• 地铁看书：「金庸作品集」6594/26907。

• 技术学习：ES 核心技术与实战课程 13/100。

2. 日拱技术

日拱鸽了两天。周五去聚餐，想着周末补，结果周末除了踢球遛猫，都在王者峡谷度过了。昨天周一状态不好，又鸽了。

最近几天都在分析一个打点数据，完善了下打点协议和开关控制的设计。

ES 分析层面，在 Kibana 里动手调配了下 Visualize 和 Dashboard，整体上感觉这种可视化的分析还凑活。

有了图形，有些维度分析，就立马直观了。而且这种图形是可以保存的。当前问题分析期间一直受用，后续分析就很高效。

另外这几天也一直在用 ES 做查询分析，但总感觉 ES 查询的结果展现方式太呆板了，没有 mysql 那种二维表看着方便。去找插件，也没找到这种格式化结果类型的插件。

ES 的 MySQL 基础版，用了下，其实也不太好用。发愁。

这几天了解到 ClickHouse，初步了解了下，这种 OLAP 的库，做了针对性优化，性能特表高，貌似兼容 MySQL 语法也不错。后续我们尝试下 ClickHouse。

3. 日拱唠嗑

跟人一起探讨分析一件事时，最好各自把自己对各种原因所占比例给说明一下。这样会更清晰。

观察到很多同学沟通时，只是各自说出觉得有哪些原因，而没说出各原因的比例。最终虽然对原因种类基本达成共识，但其实各自认为的原因配比，可能是天壤之别。

这也是沟通同步信息时，造成伪和谐的重要原因之一。

所以，我一般会说 A 原因占 30% 左右，B 原因 70% 左右。

后来看剧时也发现了，一些剧里高段位的也会这么沟通事情。不过大佬用的几成几成，例如 A 原因占三成，B 原因占七成。

哈哈，这个叫法更通俗易懂，接地气。