数据分析之一：Superset升级与动态SQL

数据分析之二：Kylin环境构建，维度、度量的概念

数据分析之三：流式数据分析Kafka、Superset、Kylin

可用性定义

服务的质量最简单的度量指标就是可用性，所谓的可用性有很多定义，例如来自百度、维基等的定义等，也有同学将这个定义为可靠性，相关定义如下：

https://baike.baidu.com/item/%E9%AB%98%E5%8F%AF%E7%94%A8%E6%80%A7/909038?fr=aladdin

https://en.jinzhao.wiki/wiki/Availability

https://wiki.mbalib.com/wiki/%E5%8F%AF%E9%9D%A0%E6%80%A7

这里使用这个公式来定义服务的可用性度量指标：

可用性度量指标 = 实际可服务时间 / 应该服务时间

参考值表格

如何准确客观的定义这两个时间，并让服务与使用者都接受，时常会有一些争议，因为应该服务时间要不要直接按自然时间如年、季度、月，要不要排出一些非工作时间，法定可不服务时间，以及挂免战牌的时间；实际可服务时间，要不要就按有无客户反馈而来，还是应该有不间断的巡查来保障，或者要不要增加一些权重，毕竟忙闲不一样。

也正基于此，我们定义了一个简单的模式，避免发散，其余结合业务再去组合。

可用性度量指标 = 服务成功次数 / 总服务次数

基本思想

观察者模式用来评价服务可用性是成立的，所谓我见故我在，我之所见故而其在！当一物不为所有存在所感受到时，此物就不存在！有点啰嗦了，其实就是下图标注【不对外服务的服务，不应该存在】

服务犹若星辰，不对外服务的就不应该存在

另外我们简单抽象下模型，如下图，调用者到服务者都可以简单看作客户与服务两个角色，中间有连接通道。

基本调用关系模型

不管多么复杂的系统，最基本的组合单元就是Client-Cloud-Server。从Client调用Server，什么时间，调用耗时多少，成功与否......

基本的要素就是此五项，每一次调用都会生成此明细数据，然后基于此数据进行组合汇总，形成需要的报表。例如某服务的可用性，某调用关系的可用性，流量波动，调用链路错误原因汇总，故障服务错误原因汇总，耗时超过阀值的调用链路列表等。全景图如下，结合阀值对链路标记出状态，并结合链路对服务进行状态标记。

基本模型调用组合集群

考虑到数据分析对业务的影响要小，并确保一定的准实时性（分钟级别），所以每个节点会进行分钟级别的统计，然后结合节点的多寡进行分级逐层统计。

Agent按照机器节点分层部署，对每分钟产生的明细数据，做简单的汇总，形成如下记录：

时间【以分为粒度】+C+S+结果+次数+最大耗时+最小耗时+平均耗时

黑体部分为索引，计算步骤如下：

1、 将时间按照分钟为单位取模，形成T12、按照唯一记录标记 （T1+C+S+结果）对记录数量和时间进行汇总3、对上述记录，完善服务C的属性数据，例如IP地址；上报给GridV

GridV分为统计节点与中心，统计节点为分层计算提供分布式能力支持，中心进行数据的最后存储。中心还会基于服务的属性，进一步分发计算。随着对服务单元本身的定义逐渐清晰（服务归属关系，服务所在机器等），关于服务的定义属性会更多，更具体。数据也会按此进一步梳理汇总。

关于服务的定义如下：

动态的数据，动态的呈现，动态的策略，无为而为不为，迅乎其所不滞，天网恢恢！

实现方案

方案的设计需要每个节点支持每秒几十万次的上报，并对这些上报数据按照时间维度进行统计，一种开源的解决方案如下，可以相对比较广泛的支持各类终端的可用性上报，服务侧的上报。内部系统使用日志记录在本地，然后通过filebeat上报到kafka；远程系统则使用http协议上报给nginx，nginx记录日志，filebeat上报到kafka；然后kylin分析流式数据，按照设定的cube统计，最后通过superset呈现出报表。

一种开源实现