3、数据采集与埋点：数据资产使用日志的采集方案、前端埋点与后端日志的协同、常见埋点工具介绍
数据资产到底有没有被用起来？谁在用？用了多久？用到了哪个字段？
这些问题，光靠拍脑袋是回答不了的。你得有数据。说白了，使用热度分析的第一步，就是把“用”这个动作变成一条条可计算的日志。今天我们就来聊聊，怎么把这件事做扎实。
3.1 数据资产使用日志的采集方案
先说说日志里该记什么。我见过不少团队，上来就记了一大堆“用户点击了按钮”、“页面加载完成”之类的信息，结果分析热度时发现——根本对不上资产。
我个人习惯，一条合格的使用日志，至少包含四个要素：
- 谁：用户ID、角色、部门（用于权限分析和用户画像）
- 什么：资产ID、资产名称、资产类型（表、字段、API、报表）
- 何时：操作时间戳（精确到毫秒，最好用服务器时间）
- 如何：操作类型（查询、导出、订阅、分享）、操作上下文（来自哪个页面、哪个应用）
核心原则：日志是给机器读的，不是给人读的。字段越少越好，结构越固定越好，能枚举就别用自由文本。
举个例子，我在一个项目中接手过一套“自由发挥”的日志，用户填写的“操作描述”五花八门，有写“看看数据”的，有写“跑个报表”的，还有写“测试”的。最后清洗数据花了两周，得不偿失。
3.2 前端埋点与后端日志的协同
很多同学会问：埋点到底放前端还是后端？我的答案是：两者都要，但分工不同。
3.2.1 前端埋点：捕捉“意图”
前端埋点负责记录用户的交互行为。比如：
- 用户点击了“数据预览”按钮
- 用户打开了某个数据集的详情页
- 用户拖拽了某个字段到查询面板
这些行为反映的是用户的使用意图。但前端数据有个问题——容易丢。用户网络断了、浏览器崩溃、页面还没加载完就关掉了，这些情况都会导致日志丢失。
3.2.2 后端日志：记录“事实”
后端日志记录的是服务端实际发生的操作。比如：
- API接口被调用了（请求路径、参数、返回数据量）
- 数据查询被执行了（SQL语句、执行时间、返回行数）
- 数据导出任务完成了（导出格式、文件大小、耗时）
后端日志更可靠，但缺少用户操作的上下文。比如，用户通过API查了某个表，但他是从哪个页面进来的？他查这个数据是为了做什么？这些信息后端很难知道。
3.2.3 协同策略：用“会话ID”串联
我建议的做法是：前端和后端使用同一个会话ID（Session ID / Trace ID）。用户每次打开页面，前端生成一个唯一的会话ID，然后把这个ID通过HTTP Header或请求参数传给后端。这样，前端埋点和后端日志就能关联起来。
小技巧：在日志中增加一个“事件序列号”，按时间递增。这样即使前端和后端日志到达时间有偏差，也能通过序列号还原出用户的操作顺序。
我曾经在一个数据门户项目中，就是靠这个会话ID，把用户从“点击搜索”到“导出结果”的完整链路串了起来。结果发现，有30%的用户在点击“导出”后，因为等待时间超过5秒而放弃了操作。这个发现直接推动了后端查询性能的优化。
3.3 常见埋点工具介绍
工具选得好，能省一半的力气。我按自己的使用经验，把工具分成三类：
| 类别 | 代表工具 | 适用场景 | 我的评价 |
|---|---|---|---|
| 埋点SDK | 友盟+、GrowingIO、神策数据 | 前端用户行为分析 | 开箱即用，适合快速验证 |
| 日志采集 | Filebeat、Logstash、Fluentd | 后端服务日志收集 | 轻量、稳定，适合大规模部署 |
| 日志存储与分析 | ELK Stack（Elasticsearch + Logstash + Kibana） | 全量日志存储、检索、可视化 | 生态成熟，但运维成本不低 |
3.3.1 埋点SDK：快速上手，但别被“全自动”忽悠
很多埋点SDK号称“全埋点”，能自动采集所有点击事件。听起来很爽，对吧？但我在项目中踩过坑——全埋点采集的数据太杂了。用户滚动页面、鼠标悬停、甚至页面resize都会被记录下来。你想想看，分析热度时，这些噪音数据会让你完全找不到重点。
我建议：用“可视化埋点”或“代码埋点”。只采集你真正关心的行为。比如，只记录“数据预览”、“数据导出”、“SQL查询”这三个关键事件。数据量小，分析起来也快。
3.3.2 ELK Stack：日志分析的“瑞士军刀”
ELK是我个人最常用的组合。它的核心流程是：
- Filebeat 部署在每台服务器上，读取日志文件，发送给Logstash
- Logstash 对日志进行解析、过滤、格式化（比如把JSON字符串解析成结构化字段）
- Elasticsearch 存储索引后的日志，支持全文检索和聚合分析
- Kibana 提供可视化仪表盘，直接展示使用热度趋势
嗯，这里要注意：Logstash很吃内存。如果你的日志量不大（每天几十GB以内），直接用Filebeat + Elasticsearch + Kibana就够了，跳过Logstash，能省不少资源。
避坑指南：我曾经在一个项目中，把Logstash和Elasticsearch部署在同一台机器上，结果Logstash把内存吃光了，Elasticsearch直接OOM。后来我学乖了——Logstash单独部署，或者用Kafka做缓冲层。
3.4 整体采集架构
说了这么多，最后给你看一张我常用的采集架构图。它把前端埋点、后端日志、ELK串联在了一起。
这张图的核心思路是：前端埋点负责“意图”，后端日志负责“事实”，消息队列做缓冲，ELK做最终存储和分析。这样既能保证数据的完整性，又能兼顾分析的灵活性。
最后一个小建议：不要一开始就追求“全量采集”。先挑3-5个核心资产（比如最常用的数据表、最热门的API），把采集链路跑通，验证数据质量。等流程稳定了，再逐步扩展到全量资产。步子迈大了，容易扯着蛋。