一、背景

漏斗分析是常见数据分析的一种，通过分析用户在网站的行为，帮助运营人员分析一个多步骤过程中每一步的转化与流失情况。比如定义一次电商活动（指定时间范围比如最长30天）中用户行为：访问网站 -> 到达商品推荐页 → 查看商品 → 生成订单，统计用户从访问网站到下订单完成转化的数据就自然地形成了一个漏斗。

通过上述描述得出几个关键词：

• 用户行为有序分析
• 有转化时间范围（30天）
• 用户访问数（会话数）和用户数（去重后的用户基数）

同时作为分析产品的话，挑战点就是如何能够基于用户自定义先后访问顺序的情况下秒级分析出各层漏斗的情况。

本文提出一种基于Druid来实现的方案，该方案具有满足需求的前提下实现成本小的优点。

二、技术方案

有序漏斗分析问题，本质上为了解决在海量数据上根据自定义条件做搜索匹配的问题，那么思路的方向如何设计合理的数据存储结构和更有的匹配查询方式。

做OLAP数据分析思路有两类

1. 基于明细统计查询的方案：满足查询灵活性，但是大数据量下聚合统计分析类查询性能不佳。
2. 预聚合方案：满足查询性能要求，但是查询不灵活、业务需要开发聚合数据逻辑，方案复杂（ETL层较重）。

基于Druid的方案：

• 兼顾查询灵活性与性能、较少的开发成本，维度（查询时组合） + 聚合指标（提前指定）。
• 分布式架构（高可用、伸缩性），自动rollup预聚合（业务开发简单、只需导入原始记录）+ 高压缩比 + bitmap倒排索引。

分析用户的行为，首先是需要把同一个用户（user_id）的所有行为整理在一起，并且考虑到有访问量的指标，那么还需要基于网页session会话（session_id）做数据聚合。

第一步：数据清洗（ETL）

根据会话ID按访问时间把所有网页数据聚合在一起，数据表如下：

其中的关键是把所有页面的path拼接在一起用空格分割，目的是为了做漏斗匹配。这里可能大家会有疑问假如量很大怎么办？这里有两个处理：1. 相邻的两个路径若是相同则合并比如用户同一个页面刷新上报了两次/1 /1那么在ETL的时候这里合并为一个/1；2. 一个session的时长是30分钟，若是极端情况下一个用户每秒都是访问合1800秒，按平均一个路径100byte来算也才180kb左右的大小。

第二步：清洗后的数据入Druid供查询

原始入druid的数据就是上述一行session数据，其中session_time作为时间维度供筛选，host、path_list作为普通维度供查询过滤，session_id和user_id当做metrc算统计值，session_id因为在ETL的时候已经去重了，所以用longSum统计指标即可，而user_id则考虑用hyperUnique（Hyperloglog算法）求基数。

数据schema设计

{
  "type" : "index_hadoop",
  "spec" : {
    "ioConfig" : {
      "type" : "hadoop",
      "inputSpec" : {
        "type" : "static",
        "paths" : ""
      }
    },
    "dataSchema" : {
      "dataSource" : "",
      "granularitySpec" : {
        "type" : "uniform",
        "segmentGranularity" : {"type":"period","period":"P1D","timeZone":"Asia/Shanghai"},
        "queryGranularity" : {"type":"period","period":"P1D","timeZone":"Asia/Shanghai"},
        "intervals" : []
      },
      "parser" : {
        "type" : "string",
        "parseSpec" : {
          "format" : "json",
          "dimensionsSpec" : {
            "dimensions": [
              "host",
              "path"
            ]
          },
          "timestampSpec" : {
            "format" : "auto",
            "column" : "time"
          }
        }
      },
      "metricsSpec": [
        {
          "name": "count",
          "type": "count"
        },
        { 
          "type" : "hyperUnique",
          "name" : "qidianid",
          "fieldName" : "qidianid",
          "round" : true
        }
      ]
    },
    "tuningConfig" : {
      "type" : "hadoop",
      "partitionsSpec" : {
        "type" : "hashed",
        "targetPartitionSize" : 5000000
      },
      "indexSpec" : {
        "bitmap" : { "type" : "roaring"},
        "dimensionCompression":"LZ4",
        "metricCompression" : "LZ4",
        "longEncoding" : "auto"
      }
    }
  }
}

三、具体实践

查询语句示例

{
  "queryType": "timeseries",
  "dataSource": {
    "type": "table",
    "name": "web_funnel"
  },
  "intervals": {
    "type": "intervals",
    "intervals": ["2018-03-19T00:00:00+08:00/2018-04-19T00:00:00+08:00"]
  },
  "filter": {
    "type": "selector",
    "dimension": "host",
    "value": "qidian.qq.com"
  },
  "granularity": {"type": "all"},
  "aggregations": [
    {
      "type" : "filtered",
      "filter" : {
        "type" : "like",
        "dimension" : "path",
        "pattern": "/%",
        "escape": null,
        "extractionFn": null
      },
      "aggregator" : {"type": "longSum", "name": "1", "fieldName": "count"}
    },
    {
      "type" : "filtered",
      "filter" : {
        "type" : "like",
        "dimension" : "path",
        "pattern": "/ %/index.html%",
        "escape": null,
        "extractionFn": null
      },
      "aggregator" : {"type": "longSum", "name": "2", "fieldName": "count"}
    },
    {
      "type" : "filtered",
      "filter" : {
        "type" : "like",
        "dimension" : "path",
        "pattern": "/ %/index.html %/download.html%",
        "escape": null,
        "extractionFn": null
      },
      "aggregator" : {"type": "longSum", "name": "3", "fieldName": "count"}
    }
  ],
  "context": {"skipEmptyBuckets": true}
}

返回结果

[{
  "timestamp" : "2018-03-18T16:00:00.000Z",
  "result" : {
    "1" : 434483,
    "2" : 21084,
    "3" : 1479
  }
}]

四、实践效果

测试环境：

单机：cpu 24 core + 内存64gb

查询延迟：0.5s ~ 2.1s

30天总量（查询的最长时间范围，其实时间范围任选）

原始数据量：10,960,000 (千万级别)

Druid中rollup后数据量：1,560,000 (百万级别)

path基数：1,059,460 (百万级别)

1天总量（一个segment，查询的最小粒度）

原始数据量：324,850 (十万级别)

Druid中rollup后数据量：56,760 (万级别)

path基数：55,064 (万级别)

五、总结分析

利用druid做有序漏斗的思路为什么是可行的？为什么其他的存储引擎不行呢，比如ES？

熟悉了整套方案后，大家可能会有这方面的疑问，那么这里从数据分布上来回答这个问题。通常，做搜索匹配可能很容易想到像用ES这样的搜索架构来解决问题，但是这里有几个特殊点ES不适合

1. 同一个session下的path做了合并，而ES快是快在分词后建立对应的索引，而该方案是需要把path拼接在一起做全匹配，这里没有用的ES的优势而且ES一个string字段最长大小限制是32kb。
2. 在若是用ES来匹配的话，是需要基于全量数据做扫描的，所以这里性能不行。而Druid因为会将原始数据相同的维度的行做roll up合并，那么实际在druid中存储的是聚合合并后的数据。通过观察数据分布，很多用户其实只访问了官网首页后就离开了，相比其他路径会有数据级的差距，这里也是发挥Druid数据压缩的优势。同时，Druid只需要在字典里面查询出满足条件的bitmap索引后，即可快速扫描统计出满足条件的指标数。

几点总结：

1. 技术方案无绝对，适合即可。
2. 关注数据分布。
3. 把控方案成本。