乐趣区

关于大数据:用户行为分析模型实践一-路径分析模型

jiezi

一、需要背景

在互联网数据化经营实际中，有一类数据分析利用是互联网行业所独有的——路径分析。路径分析利用是对特定页面的上下游进行可视化展现并剖析用户在应用产品时的门路散布状况。比方：当用户应用某 APP 时，是怎么从【首页】进入【详情页】的，用户从【首页】别离进入【详情页】、【播放页】、【下载页】的比例是怎么的，以及能够帮忙咱们剖析用户来到的节点是什么。

在场景对应到具体的技术方案设计上，咱们将拜访数据依据 session 划分，挖掘出用户频繁拜访的门路；性能上容许用户即时查看所选节点相干门路，反对用户自定义设置门路的终点或起点，并反对依照业务新增用户 / 沉闷用户查看不同指标人群在同一条行为门路上的转化后果剖析，满足精细化剖析的需要。

1.1 利用场景

通常用户在须要进行路径分析的场景时关注的次要问题：

  • 按转换率从高至低排列在 APP 内用户的次要门路是什么；
  • 用户在来到料想的门路后，理论走向是什么？
  • 不同特色的用户行为门路有什么差别？

通过一个理论的业务场景咱们能够看下路径分析模型是如何解决此类问题的；

【业务场景】

剖析“沉闷用户”达到指标落地页 [小视频页] 的次要行为门路（日数据量为十亿级，要求计算结果产出工夫 1s 左右）

【用户操作】

  1. 抉择起始 / 完结页面，增加筛选条件“用户”；
  2. 抉择类型“拜访次数”/“会话次数”；
  3. 点击查问，即时产出后果。

二、基本概念

在进行具体的数据模型和工程架构设计前，先介绍一些根底概念，帮忙大家更好的了解本文。

2.1 路径分析

路径分析是罕用的数据挖据办法之一，次要用于剖析用户在应用产品时的门路散布状况，挖掘出用户的频繁拜访门路。与漏斗性能一样，路径分析会摸索用户在您的网站或利用上勾留的过程中采取的各项步骤，但路径分析可随机对多条门路进行钻研，而不仅仅是剖析一条事后设定的门路。

2.2 Session 和 Session Time

不同于 WEB 利用中的 Session，在数据分析中的 Session 会话，是指在指定的时间段外在网站上产生的一系列互动。本模型中的 Session Time 的含意是，当两个行为间隔时间超过 Session Time，咱们便认为这两个行为不属于同一条门路。

2.3 桑基图

桑基图（Sankey diagram），即桑基能量分流图，也叫桑基能量均衡图。它是一种特定类型的流程图，图中延长的分支的宽度对应数据流量的大小。如图 4.1- 1 所示，每条边示意上一节点到该节点的流量。一个残缺的桑基图包含以下几个内容：节点数据及节点转化率（下图红框局部）、边数据及边转化率（下图黑框局部）。转化率的计算详见【3.5. 转化率计算】。

2.4 邻接表

结构桑基图能够简化为一个图的压缩存储问题。图通常由几个局部组成：

  • 边（edge）
  • 点（vertex）
  • 权重（weight）
  • 度（degree）

本模型中，咱们采纳邻接表进行存储。邻接表是一种罕用的图压缩存储构造，借助链表来保留图中的节点和边而疏忽各节点之间不存在的边，从而对矩阵进行压缩。邻接表的结构如下：

（a）中，左侧为顶点节点，蕴含顶点数据及指向第一条边的指针；右侧为边节点，蕴含该边的权重、出入度等边信息以及指向下一条边的指针。一个残缺的邻接表相似于 Hashmap 的构造，如图 (b)，左侧是一个程序表，保留的是(a) 中的边节点；每个边节点对应一个链表存储与该节点相连接的边。页面门路模型中，为了适应模型的须要，咱们对顶点节点和边节点构造做了革新，详情请见【4.1】节。

2.5  树的剪枝

剪枝是树的结构中一个重要的步骤，指删去一些不重要的节点来升高计算或搜寻的复杂度。页面门路模型中，咱们在剪枝环节对原始数据结构的树进行修整，去掉不符合条件的分支，来保障树中每条根节点到叶节点门路的完整性。

2.6 PV 和 SV

PV 即 Page View，拜访次数，本模型中指的是一段时间内拜访的次数；SV 即 Session View，会话次数，本模型中指呈现过该拜访门路的会话数。如，有门路一：A → B → C → D → A → B 和门路二：A → B → D，那么，A → B 的 PV 为 2 +1=3，SV 为 1 +1=2。

 三、数据模型设计

本节将介绍数据模型的设计，包含数据流向、门路划分、ps/sv 计算以及最终失去的桑基图中门路的转化率计算。

3.1 整体数据流向

数据来源于对立的数据仓库，通过 Spark 计算后写入 Clickhouse，并用 Hive 进行冷备份。数据流向图见图 3.1-1。

图 3.1-1

3.2  技术选型

Clickhouse 不是本文的重点，在此不详细描述，仅简要阐明抉择 Clickhouse 的起因。

抉择的起因是在于，Clickhouse 是列式存储，速度极快。看下数据量级和查问速度（截止到本文撰写的日期）：

图 3.2-1

最初失去的千亿数据查问速度是这样，

图 3.2-2

3.3 数据建模

3.3.1 获取页面信息，划分 session

页面门路模型基于各种事件 id 切割获取到对应的页面 id，来进行页面路径分析。Session 的概念可见第 2.2 节，这里不再赘述。目前咱们应用更加灵便的 Session 划分，使得用户能够查问到在各种工夫粒度（5,10,15,30,60 分钟）的 Session 会话下，用户的页面转化信息。

假如有用户 a 和用户 b，a 用户当天产生的行为事件别离为 E1, E2, E3… , 对应的页面别离为 P1, P2, P3…，事件产生的工夫别离为 T1, T2, T3…，选定的 session 距离为 tg。如图所示 T4-T3>tg，所以 P1,P2,P3 被划分到了第一个 Session，P4,P5 被划分到了第二个 Session，同理 P6 及前面的页面也被划分到了新的 Session。

伪代码实现如下：

def splitPageSessions(timeSeq: Seq[Long], events: Seq[String], interval: Int)
                     (implicit separator: String): Array[Array[Array[String]]] = {
  // 参数中的 events 是事件汇合，timeSeq 是相应的事件产生工夫的汇合
  if (events.contains(separator))
    throw new IllegalArgumentException("Separator should't be in events.")
  if (events.length != timeSeq.length)
    throw new Exception("Events and timeSeq not in equal length.")
  val timeBuf = ArrayBuffer[String](timeSeq.head.toString) // 存储含有 session 分隔标识的工夫汇合
  val eventBuf = ArrayBuffer[String](events.head) // 存储含有 session 分隔标识的事件汇合
  if (timeSeq.length >= 2) {
    events.indices.tail.foreach { i =>
      if (timeSeq(i) - timeSeq(i - 1) > interval * 60000) { // 如果两个事件的产生工夫距离超过设置的工夫距离，则增加分隔符作为前面划分 session 的标识
        timeBuf += separator;
        eventBuf += separator
      }
      timeBuf += timeSeq(i).toString;
      eventBuf += events(i)
    }
  }
  val tb = timeBuf.mkString(",").split(s",\\$separator,").map(_.split(",")) // 把汇合通过标识符划分成为各个 session 下的工夫汇合
  val eb = eventBuf.mkString(",").split(s",\\$separator,").map(_.split(",")) // 把汇合通过标识符划分成为各个 session 下的事件汇合
  tb.zip(eb).map(t => Array(t._1, t._2)) // 把 session 中的事件和产生工夫对应 zip 到一起，并把元组批改成数组类型，不便后续解决
}

3.3.2 相邻页面去重

不同的事件可能对应同一页面，邻近的雷同页面须要被过滤掉，所以划分 session 之后须要做的就是相邻页面去重。

图 3.3-2

相邻页面去重后失去的后果是这样

图 3.3-3

3.3.3 获取每个页面的前 / 后四级页面

而后对上述数据进行窗口函数剖析，获取每个 session 中每个页面的前后四级页面，其中 sid 是依据用户标识 ID 和 session 号拼接而成，比方，针对上述的用户 a 的第一个 session 0 会生成如下的 7 条记录，图中的 page 列为以后页面，空页面用 - 1 示意

图 3.3-4

计算剩下的，会失去一共 7 +7+6+4+5=29 条记录。失去全副记录如下

3.3.4 统计正负向门路的 pv/sv

取 page 和 page\_id\_previous1, page\_id\_previous2, page\_id\_previous3 ,page\_id\_previous4 失去负向五级门路（path\_direction 为 2），取 page 和 page\_id\_next1, page\_id\_next2, page\_id\_next3, page\_id\_next4 失去正向五级门路（path\_direction 为 1），别离计算门路的 pv 和 sv（依照 sid 去重），失去如下数据 dfSessions，

间接看下面的数据可能比拟茫然，所以这里拆出两条数据示例，第一条后果数据

图 3.3-4

这是一条正向的（path_direction 为 1）门路后果数据，在下图中就是从左到右的门路，对应的两个门路如下

图 3.3-5

第二条后果数据

图 3.3-6

也是一条正向的门路后果数据，其中 pv 为 2，对应的两个门路如下，sv 为 1 的起因是这两条门路的 sid 统一，都是用户 a 在 S1 会话中产生的门路

图 3.3-7

3.3.5 统计计算各级门路的 pv/sv

而后依据 dfSessions 数据，依照 page\_id\_lv1 分组计算 pv 和 sv 的和，失去一级门路的 pv 和 sv，一级门路非凡地会把 path_direction 设置为 0

而后相似地别离计算二三四五级门路的 pv 和 sv，合并所有后果失去如下

3.4 数据写入

通过 Spark 剖析计算的后果数据须要写入 Clickhouse 来线上服务，写入 Hive 来作为数据冷备份，能够进行 Clickhouse 的数据恢复。

Clickhouse 表应用的是分布式（Distributed）表构造，分布式表自身不存储任何数据，而是作为数据分片的通明代理，主动路由到数据到集群中的各个节点，所以分布式表引擎须要配合其余数据表引擎一起应用。用户路径分析模型的表数据被存储在集群的各个分片中，分片形式应用随机分片，在这里波及到了 Clickhouse 的数据写入，咱们开展解说下。

有对于这一点，在模型初期咱们应用的是写分布式表的形式来写入数据，具体的写入流程如下所示：

  1. 客户端和集群中的 A 节点建设 jdbc 连贯，并通过 HTTP 的 POST 申请写入数据；
  2. A 分片在收到数据之后会做两件事件，第一，依据分片规定划分数据，第二，将属于以后分片的数据写入本人的本地表；
  3. A 分片将属于远端分片的数据以分区为单位，写入目录下长期 bin 文件，命名规定如：/database@host:port/[increase_num].bin；
  4. A 分片尝试和远端分片建设连贯；
  5. 会有另一组监听工作监听下面产生的长期 bin 文件，并将这些数据发送到远端分片，每份数据单线程发送；
  6. 远端分片接收数据并且写入本地表；
  7. A 分片确认实现写入。

通过以上过程能够看出，Distributed 表负责所有分片的数据写入工作，所以建设 jdbc 连贯的节点的出入流量会峰值极高，会产生以下几个问题：

  1. 单台节点的负载过高，次要体现在内存、网卡出入流量和 TCP 连贯期待数量等，机器衰弱水平很差；
  2. 当业务增长后更多的模型会接入 Clickhouse 做 OLAP，意味着更大的数据量，以以后的形式来持续写入的必然会造成单台机器宕机，在以后没有做高可用的情况下，单台机器的宕机会造成整个集群的不可用；
  3. 后续肯定会做 ck 集群的高可用，应用可靠性更高的 ReplicatedMergeTree，应用这种引擎在写入数据的时候，也会因为写分布式表而呈现数据不统一的状况。

针对于此数据端做了 DNS 轮询写本地表的革新，通过革新之后：

  • 用于 JDBC 连贯的机器的 TCP 连贯期待数由 90 降落到 25，升高了 72% 以上；
  • 用于 JDBC 连贯的机器的入流量峰值由 645M/ s 升高到 76M/s，升高了 88% 以上；
  • 用于 JDBC 连贯的机器因散发数据而造成的出流量约为 92M/s，革新后这部分出流量清零。

另外，在 Distributed 表负责向远端分片写入数据的时候，有异步写和同步写两种形式，异步写的话会在 Distributed 表写完本地分片之后就会返回写入胜利信息，如果是同步写，会在所有分片都写入实现才返回胜利信息，默认的状况是异步写，咱们能够通过批改参数来管制同步写的期待超时工夫。

def splitPageSessions(timeSeq: Seq[Long], events: Seq[String], interval: Int)
                     (implicit separator: String): Array[Array[Array[String]]] = {
  // 参数中的 events 是事件汇合，timeSeq 是相应的事件产生工夫的汇合
  if (events.contains(separator))
    throw new IllegalArgumentException("Separator should't be in events.")
  if (events.length != timeSeq.length)
    throw new Exception("Events and timeSeq not in equal length.")
  val timeBuf = ArrayBuffer[String](timeSeq.head.toString) // 存储含有 session 分隔标识的工夫汇合
  val eventBuf = ArrayBuffer[String](events.head) // 存储含有 session 分隔标识的事件汇合
  if (timeSeq.length >= 2) {
    events.indices.tail.foreach { i =>
      if (timeSeq(i) - timeSeq(i - 1) > interval * 60000) { // 如果两个事件的产生工夫距离超过设置的工夫距离，则增加分隔符作为前面划分 session 的标识
        timeBuf += separator;
        eventBuf += separator
      }
      timeBuf += timeSeq(i).toString;
      eventBuf += events(i)
    }
  }
  val tb = timeBuf.mkString(",").split(s",\\$separator,").map(_.split(",")) // 把汇合通过标识符划分成为各个 session 下的工夫汇合
  val eb = eventBuf.mkString(",").split(s",\\$separator,").map(_.split(",")) // 把汇合通过标识符划分成为各个 session 下的事件汇合
  tb.zip(eb).map(t => Array(t._1, t._2)) // 把 session 中的事件和产生工夫对应 zip 到一起，并把元组批改成数组类型，不便后续解决
}

3.5 转化率计算

在前端页面抉择相应的维度，选中起始页面：

后端会在 Clickhouse 中查问，

  • 选定节点深度（node\_depth）为 1 和一级页面（page\_id_lv1）是选定页面的数据，失去一级页面及其 sv/pv，
  • 选定节点深度（node\_depth）为 2 和一级页面（page\_id_lv1）是选定页面的数据，依照 sv/pv 倒序取前 10，失去二级页面及其 sv/pv，
  • 选定节点深度（node\_depth）为 2 和一级页面（page\_id_lv1）是选定页面的数据，依照 sv/pv 倒序取前 20，失去三级页面及其 sv/pv，
  • 选定节点深度（node\_depth）为 2 和一级页面（page\_id_lv1）是选定页面的数据，依照 sv/pv 倒序取前 30，失去四级页面及其 sv/pv，
  • 选定节点深度（node\_depth）为 2 和一级页面（page\_id_lv1）是选定页面的数据，依照 sv/pv 倒序取前 50，失去五级页面及其 sv/pv，

转化率计算规定：

页面转化率：

假如有门路 A-B-C，A-D-C，A-B-D-C，其中 ABCD 别离是四个不同页面

计算三级页面 C 的转化率：

(所有节点深度为 3 的门路中三级页面是 C 的门路的 pv/sv 和)÷(一级页面的 pv/sv) 

门路转化率

假如有 A -B-C，A-D-C，A-B-D-C，其中 ABCD 别离是四个不同页面

计算 A -B- C 门路中 B - C 的转化率：

(A-B- C 这条门路的 pv/sv)÷(所有节点深度为 3 的门路中二级页面是 B 的门路的 pv/sv 和)

 四、工程端架构设计

本节将解说工程端的解决架构，包含几个方面：桑基图的结构、门路合并以及转化率计算、剪枝。

4.1 桑基图的结构

从上述原型图能够看到，咱们须要结构桑基图，对于工程端而言就是须要结构带权门路树。

简化一下上图，就能够将需要转化为结构带权树的邻接表。如下左图就是咱们的邻接表设计。左侧程序列表存储的是各个节点（Vertex），蕴含节点名称（name）、节点代码（code）等节点信息和一个指向边（Edge）列表的指针；每个节点（Vertex）指向一个边（Edge）链表，每条边保留的是以后边的权重、端点信息以及指向同节点下一条边的指针。

图 4.1-2

图 4.1-3 

图 4.1- 2 就是咱们在模型中应用到的邻接表。这里在 2.4 中形容的邻接表上做了一些改变。在咱们的桑基图中，不同层级会呈现雷同名称不同转化率的节点，这些节点作为门路的一环，并不能依照名称被看作反复节点，不形成环路。如果整个桑基图用一个邻接表示意，那么这类节点将被当作雷同节点，使得图像当中呈现环路。因而，咱们将桑基图依照层级划分，每两级用一个邻接表示意，如图 4.1-2，Level 1 示意层级 1 的节点和指向层级 2 的边、Level 2 示意层级 2 的节点指向层级 3 的边，以此类推。

4.2 门路的定义

首先，咱们先回顾一下桑基图：

察看上图能够发现，咱们须要计算四个数据：每个节点的 pv/sv、每个节点的转化率、节点间的 pv/sv、节点间的转化率。那么上面咱们给出这几个数据的定义：

  • 节点 pv/sv = 以后节点在以后档次中的 pv/sv 总和
  • 节点转化率 = (节点 pv/sv) / (门路起始节点 pv/sv)
  • 节点间 pv/sv = 上一级节点流向以后节点的 pv/sv
  • 节点间转化率 = (节点间 pv/sv) / (上一级节点 pv/sv)

再来看下存储在 Clickhouse 中的门路数据。先来看看表构造：

(`node_depth` Int8 COMMENT '节点深度，共 5 个层级深度，枚举值 1 -2-3-4-5' CODEC(T64, LZ4HC(0)),
  `page_id_lv1` String COMMENT '一级页面，起始页面' CODEC(LZ4HC(0)),
  `page_id_lv2` String COMMENT '二级页面' CODEC(LZ4HC(0)),
  `page_id_lv3` String COMMENT '三级页面' CODEC(LZ4HC(0)),
  `page_id_lv4` String COMMENT '四级页面' CODEC(LZ4HC(0)),
  `page_id_lv5` String COMMENT '五级页面' CODEC(LZ4HC(0))
)

上述为门路表中比拟重要的几个字段，别离示意节点深度和各级节点。表中的数据蕴含了残缺门路和两头门路。残缺门路指的是：门路从终点到退出、从终点达到指定起点，超出 5 层的门路当作 5 层门路来解决。两头门路是指数据计算过程中产生的两头数据，并不能作为一条残缺的门路。

门路数据：

（1）残缺门路

（2）不残缺门路

那么咱们须要从数据中筛选出残缺门路，并将门路数据组织成树状构造。

4.3 设计实现

4.3.1 整体框架

后端整体实现思路很明确，次要步骤就是读取数据、结构邻接表和剪枝。那么要怎么实现残缺 / 非残缺门路的筛选呢？咱们通过 service 层剪枝来过滤掉不残缺的门路。以下是形容整个流程的伪代码：

// 1-1: 分层读取原始数据
// 1-1-1: 分层结构 Clickhouse Sql
    for(int depth = 1; depth <= MAX_DEPTH; depth ++){sql.append(select records where node_depth = depth)
    }
// 1-1-2: 读取数据
    clickPool.getClient();
    records = clickPool.getResponse(sql);
// 2-1: 获取节点之间的父子、子父关系（双向 edge 结构）findFatherAndSonRelation(records);
    findSonAndFathRelation(records);
// 3-1: 剪枝
// 3-1-1: 革除孤立节点
    for(int depth = 2; depth <= MAX_DEPTH; depth ++){while(hasNode()){node = getNode();
            if node does not have father in level depth-1:
                cut out node;
        }
    }
// 3-1-2: 过滤不残缺门路
    for(int depth = MAX_DEPTH - 1; depth >= 1; depth --){cut out this path;}
// 3-2: 结构邻接表
    while(node.hasNext()){
        sumVal = calculate the sum of pv/sv of this node until this level;
        edgeDetails = get the details of edges connected to this node and the end point connected to the edges;
        sortEdgesByEndPoint(edgeDetails);
        path = new Path(sumVal, edgeDetails);
    }

4.3.2 Clickhouse 连接池

页面门路中咱们引入了 ClickHouse，其特点在这里不再赘述。咱们应用一个简略的 Http 连接池连贯 ClickHouse Server。连接池构造如下：

4.3.3 数据读取

如 2 中形容的，咱们须要读取数据中的残缺门路。

(
  `node_depth` Int8 COMMENT '节点深度，枚举值',
  `page_id_lv1` String COMMENT '一级页面，起始页面',
  `page_id_lv2` String COMMENT '二级页面',
  `page_id_lv3` String COMMENT '三级页面',
  `page_id_lv4` String COMMENT '四级页面',
  `page_id_lv5` String COMMENT '五级页面',
  `val` Int64 COMMENT '全量数据 value'
)

在上述表构造中能够看到，写入数据库的门路曾经是通过一级筛选，深度≤5 的门路。咱们须要在此基础上再将残缺门路和不残缺门路辨别开，依据须要依据 node\_depth 和 page\_id_lvn 来判断是否为残缺门路并计算每个节点的 value。

残缺门路判断条件：

  • node\_depth=n, page\_id\_lvn=pageId (n < MAX\_DEPTH)
  • node\_depth=n, page\_id\_lvn=pageId || page\_id\_lvn=EXIT\_NODE (n = MAX_DEPTH)

残缺门路的条件咱们曾经晓得了，那么读取门路时有两种计划。计划一：间接根据上述条件进行筛选来获取残缺门路，因为 Clickhouse 及后端性能的限度，取数时必须 limit；计划二：逐层读取，能够计算全量数据，然而无奈保障取出精确数量的门路。

通过观察发现，数据中会存在反复门路，并且假如有两条门路：

A → B → C → D → EXIT_NODE

A → B → E → D → EXIT_NODE

当有以上两条门路时，须要计算每个节点的 value。而在理论数据中，咱们只能通过不残缺门路来获取以后节点的 value。因而，计划一不实用。

那么计划二就能够通过以下伪代码逐层读取：

for(depth = 1; depth <= MAX_DEPTH; depth++){
    select
        node_depth as nodeDepth,
        ...,
        sum(sv) as val
    from
        table_name
    where
        ...
        AND (toInt16OrNull(pageId1) = 45)
        AND (node_depth = depth)
        ...
    group by
        node_depth,
        pageId1,
        pageId2,
        ...
    ORDER BY
        ...
    LIMIT
        ...
}

读取出的数据如下：

那么，node1\_A\_val = 10+20，node2\_B\_val = 9+15 以此类推。

4.3.4 剪枝

依据 4.3.3，在取数阶段咱们会分层取出所有原始数据，而原始数据中蕴含了残缺和非残缺门路。如下图是间接依据原始数据结构的树（原始树）。依照咱们对残缺门路的定义：门路深度达到 5 且完结节点为退出或其它节点；门路深度未达到 5 且完结节点为退出。可见，图中标红的局部（node4\_lv1 → node3\_lv2）是一条不残缺门路。

另外，原始树中还会呈现孤立节点（绿色节点 node4\_lv2）。这是因为在取数阶段，咱们会对数据进行分层排序再取出，这样一来无奈保障每层数据的关联性。因而，node4\_lv2 节点在 lv2 层排序靠前，而其前驱、后继节点排序靠后无奈选中，从而导致孤立节点产生。

图 4.3-3

因而，在咱们取出原始数据集后，还须要进行过滤能力获取咱们真正须要的门路。

在模型中，咱们通过剪枝来实现这一过滤操作。

// 革除孤立节点
    for(int depth = 2; depth <= MAX_DEPTH; depth ++){while(hasNode()){node = getNode();
            if node does not have any father and son: // [1]
                cut out node;
        }
    }
// 过滤不残缺门路
    for(int depth = MAX_DEPTH - 1; depth >= 1; depth --){cut out this path; // [2]
    }

在前述的步骤中，咱们曾经获取了双向 edge 列表（父子关系和子父关系列表）。因而在上述伪代码 [1] 中，借助 edge 列表即可疾速查找以后节点的前驱和后继，从而判断以后节点是否为孤立节点。

同样，咱们利用 edge 列表对不残缺门路进行裁剪。对于不残缺门路，剪枝时只须要关怀深度有余 MAX\_DEPTH 且最初节点不为 EXIT\_NODE 的门路。那么在上述伪代码 [2] 中，咱们只须要判断以后层的节点是否存在程序边（父子关系）即可，若不存在，则革除以后节点。

 五、写在最初

基于平台化查问中查问工夫短、须要可视化的要求，并联合现有的存储计算资源以及具体需要，咱们在实现中将门路数据进行枚举后分为两次进行合并，第一次是同一天内对雷同门路进行合并，第二次是在日期区间内对门路进行汇总。本文心愿能为路径分析提供参考，在应用时还需联合各业务本身的个性进行正当设计，更好地服务于业务。

计划中波及到的 Clickhouse 在这里不具体介绍，感兴趣的同学能够去深刻理解，欢送和笔者一起探讨学习。

作者：vivo 互联网大数据团队

退出移动版