数分大杂烩

用户行为分析之数据采集

2021-03-19  本文已影响0人  锦鲤的那盏茶

本篇文章非原创,转自公众号 数据社的文章
原文章地址:https://mp.weixin.qq.com/s/FwscikDGtM1Dil-L3utI0g

1.用户行为简介

        用户行为分析主要关心的指标可以概括如下:哪个用户在什么时候做了什么操作在哪里做了什么操作,为什么要做这些操作,通过什么方式,用了多长时间等问题,总结出来就是WHO,WHEN,WHERE,WHAT,WHY以及HOW,HOW TIME。
        根据以上5个W和2H,我们来讨论下们如何实现。

2. 用户行为数据采集

image.png

埋点

        埋点一般分为无埋点和代码埋点。这两种各有优缺点,这里只做一个简单的介绍:
        全埋点是前端的一种埋点方式, 在产品中嵌入SDK,最统一的埋点,通过界面配置的方式对关键的行为进行定义,完成埋点采集,这种是前端埋点方式之一。

优势:

劣势:
作为前端埋点会存在一些天然的劣势

        代码埋点,这个也是目前我们使用的埋点方式,代码埋点分为前端代码埋点和后端代码埋点,前端埋点类似于全埋点,也需要嵌入SDK,不同的是对于每个事件行为都需要调用SDK代码,传入必要的事件名,属性参数等等,然后发到后台数据服务器。后端埋点则将事件、属性通过后端模块调用SDK接口方式发送到后台服务器。
        我们采用的是代码埋点,分为前后端。埋点是一个特别重要的过程,它是数据的源头,如果数据源头出现问题,那么数据本身就存在问题,分析结果也就丧失了意义。
        由于我负责日志检测,也就是埋点后的事件日志的检测告警,并通知对应的埋点开发人员,运营方,产品方,所以也就遇到了过其中存在的很多坑,大部分是流程方面的。

        事件属性是有一套元数据管理系统,业内的一些服务也是这种结构。一般是先定义事件、属性,后埋点的方式,原因是事件日志数据是需要经过检查的,需要检查事件是否存在,属性是否缺失,数据是否正常等等。

遇到的坑:

有了上面的思路,下面我们来说下实现的相关技术问题,如何落地用户行为分析。

3.数据采集

          根据运营定义好的埋点接口形式获取到的用户的访问日志数据,一定要提前后端和前端定义好数据的保存格式,也就是保存哪些字段内容,需要把埋点数据按照约定的格式统一封装,以便于存储分析。

下面该数据采集神器Flume出场了。

image.png

实时的埋点数据采集一般会有两种方法:

  1. 直接触发的日志发送到指定的HTTP端口,写入kafka,然后Flume消费kafka到HDFS
  2. 用户访问日志落磁盘,在对应的主机上部署flume agent,采集日志目录下的文件,发送到kafka,然后在云端部署flume消费kafka数据到HDFS中

那么Flume 采集系统的搭建相对简单,只需要两步:

flume配置模板:

a1.sources = source1
a1.sinks = k1
a1.channels = c1

a1.sources.source1.type = org.apache.flume.source.kafka.KafkaSource
a1.sources.source1.channels = c1
a1.sources.source1.kafka.bootstrap.servers = kafka-host1:port1,kafka-host2:port2...
a1.sources.source1.kafka.topics = flume-test
a1.sources.source1.kafka.consumer.group.id = flume-test-group

# Describe the sink
a1.sinks.k1.type = hdfs
a1.sinks.k1.hdfs.path = /tmp/flume/test-data
a1.sinks.k1.hdfs.fileType=DataStream

# Use a channel which buffers events in memory
a1.channels.c1.type = memory
a1.channels.c1.capacity = 100
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.source1.channels = c1
a1.sinks.k1.channel = c1
上一篇 下一篇

猜你喜欢

热点阅读