1 实验目标
本次实验的核心任务是对半结构化的用户浏览器行为日志进行清洗、解析和加工。原始数据是分散在数千个TXT文件中的非结构化日志,无法直接用于分析。我需要通过一系列ETL操作,将这些零散的日志转换成规整的结构化数据表,并进一步聚合出可供后续可视化和预测建模使用的统计指标。
2 实验环境与数据
实验平台:助睿数智(Uniplore)数据科学平台
使用工具:助睿ETL数据集成平台(主要)、助睿BI(辅助观察)
数据来源:首届中国互联网数据挖掘竞赛公开数据集
数据规模:1000名用户,4周行为记录,原始日志约825MB
核心数据表:
demographic.csv:用户人口属性信息
behavior_events:解析后的事件明细表(已存放在公共数据库)
需产出的统计表:browser_coverage、browser_hourly等
原始日志采用半结构化格式,每个文件代表一次开机会话,内部使用<=>和[=]作为分隔符。这种格式人眼可读但对机器不友好,必须先做结构化转换才能进行后续分析。
3 实验操作步骤
3.1 项目初始化与数据准备
进入数据集成平台后,我首先新建了一个名为“浏览器用户行为日志数据加工”的项目。
由于实验所用的原始数据已经存放在平台的公共空间,我通过“文件库”创建了一个名为“互联网用户行为日志数据集”的目录。
然后将公共空间中需要用到的20个TXT日志文件导出到这个目录下,作为后续解析的数据源。
3.2 建立目标数据表结构
在开始解析日志之前,我需要先创建好用来存放结构化数据的表。我新建了一个名为“创建原始行为日志数据表”的转换流,拖入“执行SQL脚本”组件,执行了建表语句。这张表命名为behavior_events,包含会话ID、用户ID、事件发生秒数、进程名、访问URL、窗口句柄等20余个字段,用来承载每一条具体的行为记录。
3.3 半结构化日志解析
这是本次实验最关键的一步。我新建了名为“行为日志数据转化结构化数据”的转换流,按照“获取文件→解析内容→筛选字段→写入数据库”的思路搭建工作流。
第一步:批量获取文件路径。 拖入“获取文件名”组件,配置指向刚才存放20个TXT文件的目录。这个组件会遍历目录下的所有文件,输出每个文件的完整路径和短文件名。
第二步:编写解析逻辑。 拖入“Java代码”组件,与“获取文件名”组件连接。我在组件中编写了解析代码,代码的核心逻辑是:
从文件名中解析出用户ID和会话开始时间,拼接成唯一的会话ID
读取文件内容,跳过前两行(文件头信息)
逐行解析,按[=]分隔符拆分成键值对
提取T、P、I、U、V、W、N、C等关键字段的值
输出一行结构化的记录
配置输出字段时,我添加了session_id、user_id、l_start、t、p、i、u等15个字段。
第三步:筛选有效字段。 Java代码组件输出的字段较多,其中有些是中间变量不需要入库。我拖入“字段选择”组件,在“移除”标签页中获取所有字段后,只保留session_id、user_id、l_start、t、p、i、u、a、b、v、w、n、c、source_file这14个字段,其余全部删除。
第四步:写入数据库。 拖入“表输出”组件,配置连接到团队私有数据库,目标表选择之前创建的behavior_events。我勾选了“裁剪表”选项,确保每次运行会先清空再写入,避免重复数据。在“数据库字段”标签页中,我将工作流中的字段与数据库表字段逐一对应起来。
第五步:执行转换。 点击运行按钮,日志页面显示执行成功。我打开数据库查看behavior_events表,数据已经正确写入,半结构化日志成功转换成了规整的结构化表格。
3.4 确定分析方向
拿到结构化数据后,我需要决定聚焦哪个应用进行分析。我新建了一个转换流“统计进程用户规模”,统计每个进程名的使用人数。
具体的加工路径是:从behavior_events读取数据 → 通过字段选择只保留user_id和process_name → 将空的process_name替换为“未知” → 按process_name排序 → 按process_name分组,对user_id做去重计数 → 输出到program_stats表。
为了直观观察统计结果,我进入助睿BI平台。基于program_stats表创建数据集后,制作了一个水平条图,X轴是用户数,Y轴是进程名并按用户数降序排列。
图表清晰地显示:浏览器类进程(chrome.exe、360chrome.exe、sogouexplorer.exe、QQBrowser.exe等)的用户覆盖数远高于其他软件。考虑到浏览器记录还包含URL字段可以进一步挖掘网站偏好,我决定将后续分析聚焦于浏览器行为。
3.5 加工目标统计表
根据分析方向,我需要产出多张统计表。本次实验先完成前两张:浏览器覆盖率表(browser_coverage)和浏览器时段活跃表(browser_hourly)。
首先创建目标表结构。 新建两个转换流“创建浏览器的用户数总使用时长统计表”和“创建每个浏览器按小时统计活跃用户数统计表”,分别用“执行SQL脚本”组件执行建表语句。
然后构建主加工流。 我新建了一个名为“互联网用户行为日志数据清洗抽取”的转换流。考虑到完整的behavior_events表数据量大,实验平台已经将其存放在公共数据库中,我直接使用公共数据源连接进行读取。
整个加工流程分为两条分支,共享前期的清洗步骤:
公共清洗步骤:
表输入:从公共数据源的behavior_events表读取全部数据
字段选择:保留session_id、user_id、session_start_time、process_name、url、event_seconds这6个关键字段
过滤记录:只保留process_name属于主要浏览器(iexplore.exe、360chrome.exe、chrome.exe、sogouexplorer.exe、QQBrowser.exe)的记录
排序记录:按session_id和event_seconds升序排列,确保同一会话内的行为按时间顺序处理
分析查询:在同一个session_id分组内,取下一行的event_seconds值,存入新字段next_event_seconds
计算器:用next_event_seconds减去当前行的event_seconds,得到停留时长duration_sec
字段选择:只保留user_id、process_name、session_start_time、url、duration_sec
过滤记录:筛除duration_sec ≤ 0的无效记录(每条会话的最后一条记录无法计算时长)
剪切字符串:从session_start_time中提取日期部分(yyyy-MM-dd)
字段选择:将session_start_time的类型从String改为Date
计算器:从session_start_time中提取小时数(0-23)
排序记录:按user_id、日期、process_name、小时排序
分组:按user_id、日期、process_name、小时分组,对duration_sec求和得到total_duration_sec,对url做计数得到visit_count
经过上述分组后,数据粒度从“每条窗口切换记录”压缩到了“每个用户每天每浏览器每小时”的汇总记录。
分支A - 生成浏览器覆盖率表:
在公共分组步骤后连接一个新的“分组”组件
只按process_name分组
对user_id做去重计数得到user_count,对total_duration_sec求和得到total_duration_sec
使用“表输出”组件写入browser_coverage表
分支B - 生成浏览器时段活跃表:
在公共分组步骤后连接“排序记录”组件,按process_name和hour升序排列
连接“分组”组件,按process_name和hour分组
对user_id做去重计数得到active_user_count
使用“表输出”组件写入browser_hourly表
最后执行整个转换流。运行成功后,我通过数据库的“数据探查”功能查看了browser_coverage和browser_hourly两张表,数据均符合预期。
4 数据加工成果总结
通过本次实验,我完成了以下数据加工任务:
半结构化日志解析:成功将20个TXT格式的半结构化日志文件,经过文件名解析、字段拆分、键值对提取等操作,转换成了behavior_events结构化明细表,为后续分析奠定了基础。
分析对象筛选:通过对所有进程的用户覆盖数进行统计和可视化对比,锁定了“浏览器”作为核心分析对象,理由是其用户覆盖面广且包含URL字段便于深度挖掘。
指标表产出:围绕浏览器使用行为,加工出了两张核心统计表:
browser_coverage:记录每个浏览器的用户数和总使用时长,用于分析市场格局
browser_hourly:记录每个浏览器在每个小时段的活跃用户数,用于分析使用时段偏好
加工流程复用:通过“分支”的设计模式,在同一个转换流中同时完成了两张不同粒度的统计表加工,避免了重复读取和处理相同的数据,提高了ETL效率。
这些加工后的数据表可以直接对接下一步的可视化分析和流失预测建模,实现了从原始日志到分析就绪数据的完整转化。