李晋面试总结

集群规模

• 团队规模 5个人 OLAP 1 数据采集1 报表 2 组长
• 数据量 3 千万条 实时 5-6 百万条
• 12核 24 线程 内存 64 G 硬盘 8 T * 8 个
• kafka 3台 副本两个 mysql 4台 hdfs + yarn
• CDH 6.2
  • hadoop 3.0.3
  • hive 2.1
  • spark 2.4
  • linux版本CentOS-7 就是linux7

集群安装步骤 : 免密 ip映射 集群同步

公司概况

自我介绍!!!

	面试官您好  我叫李晋 	毕业后一直从事大数据开发这一行业，离线数据分析和实时数据分析之前都有做过，包括数仓的搭建也都有参与过，之前工作离线主要是基于hive和spark来进行开发，实时使用的是flink进行的开发，另外平常的话喜欢逛逛博客呀，学习学习新技术，自己呢也会写一点总结什么的以上就是我的一点个人介绍

项目背景

根据大数据分析 实现精准的广告投放 以便提高公司业务量 同时的话可以根据用户的消费水平 消费行为 推荐给用户对应的商品

基础流量指标分析 (流量会话聚合表) (指标有 日/周/月 pv uv 总访问时长等)

• 比如统计日活 月活这些指标 我们可以清晰的看出我们的产品目前的状态 根据日活月活分析判断我们的产品是否需要更进一步的推广
• 假如当前日活月活稳定在一个正常值，但是增长缓慢，可以尝试进一步推广，扩大用户规模

归因事件分析

首次归因 进行分析 同一个用户购买一件商品归因分析 先按时间将待归因事件进行过滤 然后在取出第一个事件 得到的就是首次归因 和业务人员以及前端人员一起商量

比如提交订单这个事件

• 他可能有多种行为导致他提交订单的操作
• 包括自己搜索呀, 点击某个广告位 某个运营位 点击他人分享等 我们一般会和运营人员进行商讨 选择合适的归因模型
• 比如选择首次归因 判断用户每次提交订单的行为是从那个行为上最先感兴趣的的
• 如果大部分都是某个广告位点击进行的 那我们就提高此广告位的曝光率 以便提高订单的转换率

离线数据系统的整体架构

数仓分为 行为域 业务域

主要负责行为域域

项目是一个纯离线的项目 , 整体上分三层 , 数据采集层 , 数据计算层 , 数据服务层

数据整体框架流向

离线

• 日志数据 使用 flume 采集至 hdfs 中(采集到的都是 json 格式的数据) flume 构建拦截器将脏数据直接过滤
• 基于hive搭建的一个离线的数仓 hive中分了四层 ods dwd dws ads
• 将hdfs中的数据 直接load到hive的 ods 也是就贴源层
• 经过一系列的数据清洗转换集成等操作形成一张大宽表放置到 dwd 层
• 将数据分主题进行计算各类成品表 因为有一些的成品表可能很多数据都可以由一张中间表得出 我们就制作了中间表放置在dws层
• 最后ads层就是我们的成品报表
• 成品报表我们一般会导入至hbase中以供后续提供给运营部进行分析什么的 这也就是olap那块了
• 其他的比如多维统计我们一开始使用的是hive的高阶聚合函数 后来的话使用的是kylin
• 一些临时性的指标查询我们使用的是 presto 基于内存计算 对接多种数据源
• 第二个项目是对第一个项目进行了一些改进和扩展 改进主要是ods - dwd 数据处理那块
  • 匿名数据的标识我们之前采用的是直接使用设备ID作为匿名数据的标识
  • 改进后使用动态绑定的方式 做了一张设备账号评分关联表 根据每个设备上账号的登录次数我们给与评分 将匿名用户归给评分高的用户 当然了如果该设备没有登录过任何一个账号 那就还使用设备ID
  • 新增了用户画像板块 主要就是提取一些基本标签

实时

• 对离线数据采集部分进行了更改 使用flume将数据直接采集到kafka 中
• 通过编写flink程序对数据进行处理后使用侧流输出将离线部分的数据写到hdfs中
• 实时使用的数据分主题侧流输出到kafka对应的topic中
• 业务数据采用的canal 实时将mysql的增量数据采集对kafka对应的topic中
• 对各主题的数据进行计算然后导入至clickHouse中或redis中 以供数据的展示使用

数据建模!!!

• 一般的数据建模分两种

  • 一种是自上而下 也就是从需求出发 根据业务需求 对接运营人员 整理所需要的各种指标 根据这些指标然后自上而下寻找可以得出这些指标的事实表 维度表等 着这样一步一步捋清楚 然后进行分析开发
  • 自下而上 从数据源出发 根据我们之前埋点的数据分析能够计算的各种指标 和运营人员对接 沟通所需要的指标 然后进行分析

• 关于大数据开发 , 阿里提出过 oneData标准, 里面提出了建模时指标统一规范定义 对数据开发的帮助其实是很有帮助的 因为之前开发的时候可能遇到两个表join的问题 , 比如按id进行join id这个字段有int 类型的也有String 类型的 数据类型不统一 , 进行join的话默认是按 int类型来进行join 所有的String类型字段就会进入同一个reduce中 导致数据倾斜 解决办法就是使用函数 cast( id as int )

• 具体我自己实际操作也没有什么大的方向的建模 也就是一些小的表的建模

• 比如之前给我一个需求，就是计算新用户留存

• 一开始我们那边没有一个固定的规划，留存分析的需求会比较随机，比如某一天突然来一个需求，求X日的新用户在Y天（比如7天）后的留存。面对这种需求，我们都是临时去拿X号的日活表join 7天后的日新表来计算。

• 还有像这样的需求，指定日期段内，比如10.01 -> 10.20号期间，查询出连续活跃天数超过5天的用户，我们也是用临时手段来做。

• 后来，我为这一类的需求（留存，活跃分析等），就设计了一套模型，为这一类的需求分析提高了便利和效率

• 我是这样做的

  • 首先，我设计了一个表模型，叫做 用户连续活跃区间记录，表里面主要记录
  • 用户的首访日期，用户的活跃区间起始日，用户的活跃区间结束日
  • 如果在计算日仍然活跃的用户，则它的最后一个活跃区间的结束日为9999-12-31
  • 这个表的设计，我借鉴了“拉链表”的思想

• 有了这个表之后，计算留存分析，就变得很容易；只需要查看连续活跃区间表中连续活跃结束日是9999 的就可以了

• 计算用户连续活跃天数这种需求，也很容易直接group by 用户 max(datediff ( 时间差 ) ) 就可以得出了

数据采集

• 将app端的日志数据通过flume采集到hdfs , 当时的为了保证数据采集的安全可靠 , 我们采用了 taildir + filechannel + hdfssink 同时为了防止 日志服务器连接hdfs要开启太多的连接, 我们配置了级联的方式来采集, 还将sink的策略选择了 fileover ,保证其中sink挂掉之后还能正常工作 同时, 我们在flume channel中里面还设置了一个拦截器, 直接将有问题的数据过滤掉了, 然 据里面的时间取出来,让对应的数据进入到对应时间的的文件夹 因为flume中可以设置header 和 body 在sink写入文件中时我们使用通配符的方式 直接让他取header中找对应的数据
• 业务数据的话我们采用的是sqoop来进行采集的, 直接将mysql中的数据直接采集到了hive中 这边的数据一般都是采用了增量抽取的方式来进行采集的

数据计算层

• 数据计算层的话我们主要是 基于hive做的一个离线数据分析, 建模的话 采用的是维度建模, 分了四层, 包括就是 ods , dwd , dws , ads

• ods 的数据就是我们flume采集到的数据 , flume采集到的数据放在hdfs中 , 我们直接在hive中建表然后load到表中, 因为采集到的数据都json格式数据嘛, 我们就建表的时候指定了jsonserde

• 然后我们使用spark 程序对ods层的数据进行了一些加工处理, 包括集成了一些地理维度数据, 过滤掉了一些缺少关键字段信息的数据, 我们在这里还将匿名数据的问题进行了解决 , 之前时直接使用设备ID来作为匿名数据的用户 之后进行了改进使用动态绑定的方式来对匿名用户进行确定 主要就是做了一个 设备账号评分关联表

  • 设备账号评分关联表
    一个设备可能登录了多个用户 , 这张表保存了每个设备上每个账号的登录得分 登录一次得分 +100 没有登录则分数就会衰减
    • 数据过来 取出数据中 用户id 和 设备ID ，如果有用户ID ，则使用用户ID 作为 该数据的标识
    • 如果没有用户ID ，则拿 设备ID 去关联评分字典查询，取出分值最高的 用户ID 作为 guid
    • 如果设备ID 和字典表没有关联上 ，就使用设备ID作为 guid
  • 账号设备评分关联表实现流程
    数据中存在匿名访问数据 我们需要对匿名访问数据关联一个guid
    因为设备ID是必须存在 不存在我们就直接过滤掉了 但是一个设备上可能登录多个账号我们需要选择一个作为guid 使用动态绑定的方式 构建了一张设备账号评分关联表 表中的字段包括 设备ID 账号ID 得分 最后登录时间
    • 按设备和账号进行分组, 计算每个分组内会话次数, 每次会话算一次登录, 一次登录得 100分
    • 将 计算好的结果 和 前一天的设备账号评分关联表 数据进行full join 连接条件 登录ID 和 设备ID 相同
      • 前一天 登录 今天 登录 score相加
      • 前一天 登录 今天 没有登录 score衰减 为 0.7
      • 前一天 没有登录 今天 登录 score为 今天 的值

• 集成地理位置信息

  • 日志数据中一般只记录了经纬度 没有记录对应的省市区,需要集成
  • 公司有对应的地理位置字典表 但是字段是省市区 经纬度 使用geohash的方式将数据进行了处理 变成 省市区 geohash值 然后广播出去
  • 将数据中的经纬度也转换成geohash值 到广播的数据中匹配 匹配的上就取出对应的省市区
  • 匹配不上就使用ip2region进行查找匹配

• dwd层放的就是我们处理好的明细宽表

• dws层的数据主要就是对最终的结果报表数据做准备的

  • dws这一层我们分主题做了一些轻度聚合表和一些中间表, 基础流量指标分析 , 活跃度相关报表的分析等等的, 主要是为了最后的结果数据做准备, 比如流量主题的我当时做了有流量会话聚合表 (指标有 日/周/月 pv uv 总访问时长等),
  • 用户活跃度相关分析, 做了一个日活明细表, 保存了当天活跃的用户, 这个表就是来自于流量会话聚合表, 取出了里面所有的guid然后又做了一个用户连续活跃区间记录表, 这是一个拉链表, 可以清楚的看到用户那天活跃那天没活跃

• 最后ads层 , 这里面就是放的是一些我们计算时用到的需要进行展示的表

• 接下来就是数据服务层的一些东西了, 也就是olap平台 这块的话也分三部分,

  • 第一部分 常规的我们保存在ads层的一些固定的报表, 这些表我们一般就是直接使用 blukload 导入到hbase中, 用来做数据的可视化展现
    • 写spark程序将
  • 多维数据分析, 我们之前的时候直接用的hive的高阶聚合函数 , 像 with cube , grouping sets(可自己定义聚合维度) , with rollup(层级聚合), 后来引入了kylin , 就使用kylin来做, 聚合好的结果默认就是保存在hbase中
  • 然后的话就是一些非固定模型的在线实时计算, 我们当时使用的是presto , 他是一个纯内存的计算引擎, 可以对接多种数据源

• 整体的话就是这样, 其他的话, 比如当时我们元数据管理系统用的是atlas 任务调度的话当时使用的是azkaban

• Atlas跟大数据中各种数据源组件进行了深度整合，它可以自动去获取这些数据源组件中的数据的元信息，纳入自己的存储提供管理查看，可以省却大量的人工录入元信息工作

• 写各种的脚本然后然后根据互相之间的依赖呀串成一串 , 提交到azkaban上去执行

业务域 :

主要从业务库表中拿去数据来进行分析, 业务库的数据一般来自业务系统的数据库mysql中, 主要表格包括 :

• cms 是网站的内容管理相关表 发帖, 回帖…

• oms 是订单相关的表, 和交易有关的 生成订单, 添加购物车…

• pms 是关于产品相关的表, 产品评论 内容 回复 …

• sms 营销类表 优惠卷 广告 …

• ums 会员相关的 …

• ods层 : 放置了每天的用户,订单等等的增量数据

• dw层 : 将ods层中的增量导入dwd层, 同时对一些重要的表做了拉链表(全量表) 例 订单表, 缓慢变化维度表. 便于查询历史上任何一天的数据的状态,

• dws层 : 主要是一些宽表, 根据需求将事实表和维度表进行join形成一张宽表, 以此为基础计算所需的报表

主要的策略 : 大表 增量抽取 小表 全量抽取

主要负责!!!

• 基础流量指标分析 (流量会话聚合表) (指标有 日/周/月 pv uv 总访问时长等)
  • 用户活跃度主题 (拉链表 用户活跃区间) ( 指标 连续活跃超过 5 天 10天 连续沉默 … 用户留存 )
• 归因事件分析(支付订单 这个操作可能有多个条件导致 通过点击某个运营位,点击广告位看到点进去购买 或者直接搜索) 一般使用首次归因进行分析 同一个用户购买一件商品归因分析 先按时间将待归因事件进行过滤 然后在取出第一个事件 得到的就是首次归因 和业务人员以及前端人员一起商量
• 多维指标的统计 之前的话是使用hive的高阶聚合函数来进行 后使用kylin

离线指标计算

基础指标

基础流量指标分析 (流量会话聚合表) (指标有 日/周/月 pv uv 总访问时长等)

• 比如统计日活 月活这些指标 我们可以清晰的看出我们的产品目前的状态 根据日活月活分析判断我们的产品是否需要更进一步的推广
• 假如当前日活月活稳定在一个正常值，但是增长缓慢，从这里或许我们就能得出，用户增长稳定但增速变慢了，可以尝试进一步推广，扩大用户规模

归因分析

归因事件分析(支付订单 这个操作可能有多个条件导致 通过点击某个运营位,点击广告位看到点进去购买 或者直接搜索) 一般使用首次归因进行分析 同一个用户购买一件商品归因分析 先按时间将待归因事件进行过滤 然后在取出第一个事件 得到的就是首次归因 和业务人员以及前端人员一起商量

比如提交订单这个事件

• 他可能有多种行为导致他提交订单的操作
• 包括自己搜索呀, 点击某个广告位 点击他人分享等 我们一般会和运营人员进行商讨 选择合适的归因模型
• 比如选择首次归因 判断用户每次提交订单的行为是从那个行为上最先感兴趣的的
• 如果大部分都是某个广告位点击进行的 那我们就提高此广告位的曝光率 以便提高订单的转换率

用户活跃度

我们当时有一张日活表, 就是记录了每天的活跃用户

用户活跃度分析

需求 : 求一个月内用户连续登录超过5天的人数 10 天的人数…

• 最简单的方法也是最笨的方法就是连续join 效率极低
• 为此我当时开发了一个拉链表样子的用户连续活跃区间记录表 表中字段大概就是 用户首次登陆日期 用户 连续活跃起始日 连续活跃结束日, 以此 再来开发最终报表就变得很容易了 而且根据这张表我们当时顺带的就将用户留存分析也做完了 因为留存分析需求一般不是太多我们之前一般都是现算, 之前的一般都是拿之前天的日活表去join 需要查看的天的日活, join上的就是留存了的, 现在我们只需要查看连续活跃区间表中连续活跃结束日是9999 的就可以了
• 具体表的实现 :
  • 使用 T-1 日的用户连续活跃记录表 fulljoin T 日的用户日活表( 这张表记录了每天的活跃用户 )
    • 分情况进行处理
      • 用户 t-1 为 9999 的且 当日活跃的 只需要修改连续活跃结束日
        • 用户 t-1 为 9999 但join不上的 说明当日没有活跃 修改 9999为 t-1日
      • 用户 t-1 为 null t 不为null 的 使用 t日作为 首访日期 连续活跃起始日 连续活跃结束日
      • 用户 t-1 结束日不为 9999 的不做任何改变
      • 有一个问题是之前已经是闭区间的数据 需要新生成一条数据然后 union 到之前的表中
      • 查询出是闭区间的数据 和 日活表进行join 将join上数据取出 t-1日的 首访日期 t日作为连续活跃起始日, 9999作为连续活跃结束日 和之前表 union到一起

多维聚合bitmap

bitmap算法 就是保存在内存中的连续的二进制位, 用于对大量的整数型数据做去重和查询操作 .

	一开始并不是使用kylin来进行多维统计的使用的hive 的高阶函数 with cube  ,  但是hive 的高阶聚合函数在进行多维计算时有一些的指标的计算需要使用到count(distinct) , 会消耗很大的资源, 因此我们当时借鉴了bitmap的思想, 来对那些需要去重聚合的指标进行计算

• 我们当时使用的是roaring bitmap 性能比较好, 它提供了方法将数据转换成bitmap类型, 一条数据在bitmap中只占用一个bit位 , 存进去数据后它会将相应bit位的值置为 1 , 下次相同的数据再进来还是会进入到同一个bit位上 , 这样就能实现去重 , 同时bitmap中还提供了计算bitmap中 1 的个数的方法, 这样我们就可以将去重总数统计出来了.

• 同时我们还通过 bitmap 的 思想实现了层级聚合的操作 , 比如计算好 省市区 的数据之后在计算 省市 的维度我们就可以使用bitmap 中提供的or操作来进行计算

  • 例 :
    省 市 区 人
    a b c [1001]
    a b d [1100]

• 计算

  • 那么如果要计算 a省b市 的人数 只需要将两个数据进行or操作 就能得到的结果 [1 1 0 1]
  • 因为hive中不支持bitmap类型 , 因此我们将数据转换成binary类型存储在hive中
  • 通过自定义函数的方式实现了这些方法, 同时我们编写sparkSQL 得到最终的结果

多维分析中的常用操作(上钻 … )：

数据立方体中最常见的五大操作：切片Slice，切块Dice，旋转Pivot，上卷（也叫向上钻取）Roll-up，下钻Drill-down

• 下钻Drill-down：向下从更细分的粒度（维度）来探索分析数据，如按照时间维度，按照天粒度来分析数据
  • 改变维的层次，变换分析的粒度。从上层降到下一层，或者说是将汇总数据拆分到更细节的数据。比如通过对2010年第二季度的总销售数据进行钻取来查看2010年第二季度4、5、6每个月的消费数据，当然也可以钻取浙江省来查看杭州市、宁波市、温州市……这些城市的销售数据。
• 上卷Roll-up： 向上从更粗的粒度（维度）来探索分析数据，比如时间维度，按照季度来分析数据
  • 钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据。
• 切片Slice： 查询某个维度等于某个指定值的数据集 比如按照产品种类等于电子产品的维度 来分析数据
  • 选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者2010年第二季度的数据。
• 切块Dice： 查询某个维度等于某几个指定值的数据集
  • 选择维中特定区间的数据或者某批特定值进行分析，比如选择2010年第一季度到2010年第二季度的销售数据，或者是电子产品和日用品的销售数据。
• 旋转Pivot：即维的位置的互换，就像是二维表的行列转换，如通过旋转实现产品维和地域维的互换。 旋转 变换维度展现顺序

用户画像

主要工作就是提取一些基础指标 或者 给专门的做机器学习的同时提供点数据 了解过一点机器学习算法

用户订单画像标签表开发

• 标签包括 用户id 第一次下单时间 最后一次下单时间 一个月下单次数 一个月内下单总金额 最大订单金额 最小订单金额 平均订单金额 常用支付方式 常购买物品品类 收货地址…
• 需要使用到 订单表 订单商品明细表 都是从mysql中导入过来的表
• 将对应的字段取出

朴素贝叶斯

向量是一串数字

向量可以代表现实中某种事物的一系列特征和特征值

向量可以理解为：这串数字，基于原点，所指向的n维空间的，某个方向的，固定长度；最终代表的就是一个点

• 用户行为性别预测
  先经过大量统计得到一份经验数据 ( 相对教准确的数据 ) 将这些数据经过向量化 调用API得到训练模型将需要预测的数据也经过向量化 然后加载之前的训练模型对数据进行预测分析得到最终结果

实时指标统计

ETL 实时新老用户标记

判断一条数据所属用户是新用户还是老用户

使用布隆过滤器 + Rocks DB

布隆过滤器 更加的节省空间

RocksDB 可以存储更多状态、有长窗口（window state）、key、value的可以保存更大的数据（2 G）同时可以实现增量checkpoint

实现方式 :

• 使用设备ID 作为用户标识的, 进行keyBy, 设备ID相同的用户会进入到同一个分区中 使用BloomFilter 来判断是否为新用户

• 然后我们定义了一个OperatorState 保存BloomFilter, 因为如果使用 keyedState 来保存 一个设备ID 就对应一个BloomFilter 浪费资源  需要实现CheckPointFunction  , 这样子一个分区就会拥有一个属于自己分区的BloomFilter 节省资源 而且还不会数据倾斜
  

• 然后在实现的方法中使用 定义状态 状态里面保存了BloomFilter  来一条数据判断该条数据的设备ID 是否已经存在, 存在就将该条数据置为老用户, 同时我们使用了Rocks DB代替 stateBackEnd 来保存状态, 这样子就可以保存更多的状态数据 , 同时还可以实现增量checkpoin
  

  • RocksDB 的使用
    env.setStateBackend(new RocksDBStateBackend(checkpointPath, true));

直播间人气实时统计

规则 :

	进入直播间超过一分钟的人气值 +1 

	30分内连续进入直播间的人气值不变进入间隔超过30分的人气值+1

	下一次进入直播间的时间 - 上一次离开直播间的时间 > 30分钟 又算一个人气值

实现方式 :

• 按照主播ID, deviceID 进行 keyBy
• 使用进入直播间时间+1注册定时器 如果下次出去时间小于一分钟, 删除定时器 如果定时器触发 判断上次 进去时间 上次时间为空 人气值 +1 上次不为空且 这次进入- 上次出去 > 30 人气值 +1
• 计算好的数据在使用直播间号进行keyBy 将数据进行sum聚合求得最后每个直播间的人气值, 最后再将结果输出至redis中, 实时展示

实时统计直播间 pv , uv , 实时在线人数, 以及不同维度下的指标

pv uv 实时在线人数使用 flink 计算然后批量写入至redis中 编写定时器批量攒数据

将处理好的数据按批次导入至click house中, 统计多维指标

实现方式 :

• 将直播数据按 直播间ID进行keyBy 同一个直播间的数据进入同一个分区的同一个组内
• 因为要进行uv , 所以使用 布隆过滤器 来进行去重, 同时定义 pv , uv , online , BloomFilter 四个状态来保存数据
• 一条数据进来 判断在布隆过滤器中是否存在,
  • 不存在 那么 uv ++, pv ++ ,online ++
  • 存在 pv ++ , online ++ 同时将数据加入至BloomFilter中
• 数据出去 online–
• 结果数据最后输出至redis中实时展示, 因此我们定义了一个计算器10秒触发一次, 将数据输出至 redis 中 具体实现 :
  • 使用当前时间 / 10秒 ==> 和10 的差值
  • 当前时间 - 差值 +10秒就获得了10秒后的时间
  • 10内进入的数据每次都会生成一个定时器 但是定时器的时间都是一致的 指挥触发一次
  • 这样子就实现了10秒触发一次的定时器

直播期间各个主播直播收到的礼物分值计算

需要关联礼物维表 , 根据礼物维表的数据计算对应礼物的分值

使用广播状态, 将业务库中的礼物表数据广播至状态中, 然后connect关联查询

Flink中广播的数据可以实现实时的更新

实现方式 :

• 将维度数据连接MySQL查询出来 , 整理好之后将维度数据广播到状态里
• 将事实数据进行整理后 和 广播的数据进行connect 关联 然后调用 process 方法 , 因为需要和维度数据进行关联处理 , 因此使用 BroadcastProcessFunction
• 需要重写两个方法 : processBroadcastElement 处理广播数据 可以将广播的数据进行更新 processElement 处理事实数据 可以读取广播数据 不能修改
• 关联维度数据后将最终的数据输出 , 按主播ID 进行keyBy 后进行sum操作, 再将最终的结果数据输出值redis中

统计 : 10分钟内, 每隔1分钟统计一次各个分类、各种事件类型的热门商品（商品ID）

例 :

	[10:00] , [10:10] ,  华为 , 浏览 , p10 , 20             		   [10:00] , [10:10] , 华为 ,  加入购物车 ,  p10 , 20

	[10:00] , [10:10] ,华为 , 浏览 , p30 , 29 ...          		    [10:00] , [10:10] , 华为 ,  加入购物车 ,  p30 , 29 ...

实现方式 ：

• 先将数据进行keyBy（分类ID，事件ID，商品ID），划分窗口 ( 使用滑动窗口)
• 然后对窗口内数据进行增量聚合（效率高，全局聚合效率低，而且占用大量资源）
• 我们在增量合并的时候除了需要获得到：（ 分类ID，事件ID，商品ID，次数 ）, 还需要获取窗口的信息（窗口的起始时间，结束时间）
• 因此增量合并使用 aggregate 方法 , 这样能够在增量聚合的同时定义一个窗口 , 窗口触发后可以在这个窗口中获取到窗口聚合后的数据，并且可以得到窗口的起始时间和结束时间 输出结果为 : （ 分类ID，事件ID，商品ID，次数，窗口起始时间，结束时间 ）。
• 将数据以（分类ID，事件ID，窗口起始时间，结束时间）进行keyBy , 然后进行排序 ：使用ProcessFunction的onTimer定时器进行排序，每来一条数据，不直接输出，而是将数据存储到State（为了容错），再注册一个比当前窗口的结束时间还要大一毫秒的定时器。如果下一个窗口的数据触发了，那么Water Mark已经大于了注册的定时器的时间，上一个窗口的数据已经攒齐了，就可以排序然后输出。
• 将最终结果进行整理后输出至redis中

实时统计订单相关指标

分析的实时指标 ：直播间主播带货总金额、商品成交（ 下单 ）数量

• 直播间主播带商品各个分类的成交金额、商品成交（ 下单 ) 数量
• 一天内中的成交金额
• 各个分类成交金额（维度：省份、操作系统、手机型…）

实现方式 :

• 使用双流 Join
• 将业务库中的订单主表和订单明细表取出进行分析处理 , 业务数据使用canal读取过来的 , 数据是一个大的JSON串 我要需要的是他里面 data 对应的 一个小的 JSON 串 将里面的数据封装到一个bean 里
  • 订单主表：订单ID、用户ID、订单状态、订单金额、下单时间、更新时间
  • 订单明细表 ：订单主表ID、sku、数量、单价、分类ID、直播间ID
• 由于业务系统可能存在延迟, 我们将订单明细表划窗口, 使用侧流输出获取窗口中迟到的数据
• 将主流中业务订单明细数据left join 订单主表 关联上的就输出 tuple2 < > 关联不上就将关联不上的输出为null
• 将join后的数据和之前侧流输出的数据进行union然后将关联不上的和侧流输出的数据 也就是 主表数据为null的连接数据库进行查询
• 然后将最终的结果输出到clickhouse中