基于”有限状态机模型“的链路分析设计

背景介绍

• 为什么会有这一篇文章？
  • 在笔者过去几年的数据分析系统的开发中，接触了大量的订单维度的不同状态流转情况下的数据分析，在最近的实战中，发现可以跳出业务系统，在高阶的抽象层面，落地一套东西，这一套设计和业务无关，说白了，任何业务的单据的不同状态流转的多维分析，都可以用这一套思路落地，如果对你有用，最好，如果无用，就当抛砖引玉了
• 什么是数据分析的模型？
  • 数据分析的模型，在我看来是数据分析的最高阶的抽象，可能不是java中的object，可能不是db中的表，但是在无形之中指导者我们的系统设计
  • 笔者在做系统设计的时候，觉得事件+有限状态机，能够解决大部分的业务单据不同状态流转的问题，遂在原先系统设计的基础上做了抽象，如果你也遇到类似的问题，可以参考，基于这个可以做很多事情
  • 已有的模型有哪些，这里做几个简单的介绍
    • 漏斗模型
      • 例如一个典型的购物路径，用户可能经历下面几个环节
      • 商品详情页浏览，添加商品进入购物车，购物车点击结算，进入订单确认页面进行确定，跳到付款页面进行付款
      • 这些过程中，是比较典型的一个漏斗的模型，在向下走的过程中，用户肯定越来越少
    • 事件模型
      • 使用的比较多的一个模型，什么事件？已经发生的一件事情
      • 比较典型的，例如登陆事件，浏览事件
      • 基于这个事件数据，可以做多个维度的分析，最简单的是统一一天的用户数以及页面浏览数
    • 路径分析模型
      • 顺着刚才的事件模型向下走，用户在浏览特定网站的时候，会从一个页面跳转到另外一个页面，如此反复
      • 在做精细化网站分析的时候，需要了解用户的路径，方便网站本身做优化以及升级
  • 基于上面的描述，我们一步一步的走向优先状态机模型的链路分析

关于事件

• 什么是事件驱动？
  • 所谓事件，表示已经发生的一件事，然后这件事件驱动后面的流程，在系统架构中，EDA更多的是异步化，通过消息来包装事件，之后做事情，例如“订单付款事件”，这个事件发生之后，广播出来，物流的系统要根据付款事件去发货，广告的系统要根据付款来结算广告费用等等(纯YY，如果业务不对，请指正哈哈)；
  • 谁在什么时间在那里做了什么事情
  • 具体落地到各个系统中的时候，可能有取舍或者个性化，例如where，有个设计可能是业务的类型，有的可能是地域信息；
• 比较典型的一个事件的案例？
  • 这里copy一下神策分析网站上的事件的抽象定义
  • 谁在什么时间在哪里用那种方式做了什么事情
  • Who：即参与这个事件的用户是谁
  • When：即这个事件发生的实际时间
  • Where：即事件发生的地点，更多是区域信息的记录
  • How：即用户从事这个事件的方式。这个概念就比较广了，包括用户使用的设备、使用的浏览器、使用的APP版本、操作系统版本、进入的渠道、跳转过来时的referer等
  • What：描述用户所做的这个事件的具体内容，这个可能根据不同的业务有不用的形式，可以通过几个核心的属性来描述清楚一件事

抽象层面看状态机

• 什么是状态机？
  • 有限状态机（Finite-state machine）是一个非常有用的模型，可以模拟世界上大部分事物
  • 特征一：状态总数（state）是有限的
  • 特征二：任一时刻，只处在一种状态之中
  • 特征三：某种条件下，会从一种状态转变（transition）到另一种状态

能够做的事情

• 多维度的分析
  • 处于特定事件状态的单据的数量，例如状态为“完成发货事件”，则处于发货事件的订单数量是多少
  • 处于特定事件状态的单据，超过特定时间的数量，例如状态为“付款事件”，则会有一种场景，就是超时未付款的数量
  • 状态之间流转，例如A状态到B状态，平均用时多久，这样时效类的就能获得到了，例如“创建订单”到“支付订单”的数据，我们能够得到平均付款时间等
• 举例说明整个过程
  • 我们的数据是这样的形式
  • 计算逻辑可以采用storm的的流式计算来搞定
  • 计算的结果存储在在线的DB中，对外提供查询服务

介绍一下Storm的作者的lambda的架构

• 什么是lamdba架构？
  • 一套方法论，说白了就是一套概念，但是在系统架构设计的时候，有非常大的借鉴意义
• 这套架构的必选条件
  • 对于硬件的问题以及人为失误的高容错性
  • 支持用户多维度的查询以及更新，且保证性能
  • 线性扩展性，也就是当出现瓶颈的时候，能够通过增加机器来实现
  • 在系统维护以及添加新功能上良好的扩展性
• 通过最高层阶看lamdba架构
  • Batch 层，做两件事情
    • 管理整体的数据集合，不可变行级别的数据进行追加，类似离线的数据仓库
    • 对于查询的需求做一些预加工
  • Server 层
    • 对于Batch Views和Real timeView的查询的服务提供者
  • Speed 层
    • 针对流动的实时数据，做多维度的加工处理

这套东西有啥用？

• 单独从一个订单维度看，似乎没啥意义
• 但是如果从事件存储维度做抽象，计算过程统一
• 这样，任何单据的状态事件变更，都可以在这套计算体系落地了
• 例如采购单、交易订单、物流单、支付订单等等