一键采集上传常见的细节问题(浏览器与Web服务器的HTTP端口上传机制(组图) )

　　一键采集上传常见的细节问题(浏览器与Web服务器的HTTP端口上传机制(组图)

)

　　顺便说一下，这里是 HTTP。当用户请求一个网页时，浏览器向服务器发送一个 HTTP 请求消息以获取该页面中收录的对象，服务器接受该请求并以收录这些对象的 HTTP 响应消息进行响应。 HTTP 使用 TCP 作为其支持的传输协议。

　　浏览器与 Web 服务器的 HTTP 端口建立 TCP 套接字连接。客户端通过 TCP 套接字向服务器发送请求消息。该消息收录请求行、标题行、空白行和实体主体四部分；同样，Web 服务器接受请求并返回 HTTP 响应。响应收录四个部分：状态行、标题行、空白行和实体正文。 HTTP的具体规则可能要单独写一篇文章文章应用层协议的原理来解释，这里就不多说了。

　　二、bury 点上传机制

　　由于在线日志是直接在服务器端生成的，log采集工具可以直接将收录日志的服务器的采集日志数据传输到相应的文件系统，所以不存在日志上传的问题。但是对于离线日志，数据是在客户端生成的，所以必须考虑上传机制。

　　通常使用的离线日志上传机制如下：

　　1、实时上报：服务器提供日志接口。当一个事件被触发时，它直接调用日志接口来记录服务器上的日志。频率低，数据量小，实时性要求高的数据可能不受限制。

　　▶优势：

　　• 可以实时记录信息到服务器，

　　▶缺点：

　　•如果埋点过多，产生的数据量过大，会占用大量带宽，给用户带来损失。

　　•某些前端行为，例如停留在某个活动中，无法通过这种在线方式捕获。

　　•客户端没有临时存储机制。网络不可用时，无法正常调用日志接口，导致数据丢失。

　　2、Delayed 上报：服务端提供日志上传接口，客户端临时将日志存储在本地。当达到一定大小或一定时间后，将日志通过上传接口进行压缩上传。这个时间和数据量一般是根据公司的业务情况定制的。

　　▶优势：

　　•占用带宽小

　　•更灵活地捕捉用户行为

　　▶缺点：

　　•时效性差，需要等待一定的时间或数量发送

　　在实际操作中，为了获取更多的数据，我们一般采用多种方法的组合。

　　三、数据存储过程

　　通常，系统数据分为两类，一类是业务交互数据，一类是日志数据。业务交互数据包括注册、登录、订单、产品、支付、用户等业务过程中产生的数据，通常存储在DB中，包括Mysql、Oracle等。一类是日志数据，是由用户在产品使用过程中与客户端的交互，如页面点击、采集、停留、评论、分享等。

　　这里主要讲埋点数据。一般埋点数据主要是单独存放在日志服务器中，与业务服务器分开，主要是为了解耦。一些小公司为了节省服务器资源（钱），也会把所有的数据放在一起。

　　数据到达日志服务器后，将数据写入磁盘，然后将Flume采集日志发送到Kafka，使用Kafka进行分发（减峰，可根据不同业务线采集)。之后Kafka会通过Flume消费离线数据到HDFS，或者进入实时存储进行实时分析。 HDFS将数据导入Hive数据仓库（ODS、DWD、DWS），最后Hive分析结果并使用Sqoop导入MySQL进行查询，最终实现数据的可视化。

　　当然，上述选择的技术也需要根据实际情况来决定。有以上相同效果的还有很多，比如数据存储和HBase、Redis等，数据计算和Spark、Storm等，我们选择哪个框架也是一门学问。

　　简而言之，有两种数据流：

　　1、实时存储，实时分析生成数据报表；

　　2、离线存储，进入数据仓库。

　　无论是实时数据采集还是本地存储的数据采集稍后发送，最终都会进入数据仓库。然后这些数据经过层层逻辑处理到达数据应用层。我们熟悉的大数据分析平台和行为分析平台都是应用层的典型案例。

　　▷ 数据仓库解释请参考我之前写的《什么是数据仓库》

　　数据仓库分为三层：原创数据层（ODS）、数据仓库（DW）和数据应用层（APP）。进入数据仓库的埋点数据会以表格的形式存储在ODS（Original Data Layer）中，经过轻聚合后转移到数据仓库的基础层，对数据进行聚合根据一定的维度和业务逻辑转向主题层，数据集市。

　　●原创数据层（ODS）：数据没有变化，不对外开放；暂存层，是接口数据的暂存区，为下一步数据处理做准备。

　　●数据仓库（DW）：也称为细节层。是对源数据进行ETL后的数据。一致、准确和干净的数据。

　　●数据应用层（DA或APP）：前端应用直接读取的数据。根据报表和专题分析要求计算生成的数据。

　　四、常见的埋地问题及原因

　　在进行统计时，我们经常会怀疑数据的准确性。当偏差小于5%时，我们很难感知。但是当偏差较大时，很容易发现数据不准确。以下是一些常见问题和可能的原因：

　　1、通常数据稳定，突然过高

　　1）可能是恶意刷流量。很多人认为高流量不好，但是如果超过50%的流量来源是未知数据源，一次访问十几页。搜索引擎会惩罚网站并被降级。

　　2）您的统计代码被其他网站使用。这种情况比较少见，但是我之前遇到过A站的统计码被BCD站不小心使用了。或者被盗，导致呈现的结果突然成倍增加。

　　3）非恶意浏览。流量或者下载量一下子增加了很多，但是什么也查不到，一切正常，只能说恭喜了。

　　2、平时数据稳定，上报数据偏低

　　1）日志迁移。由于日志迁移过程较长，部分日志没有参与存储。需要找运维同学重新部署昨天的统计任务，恢复数据。

　　2）新增埋点的上报数据全为0的情况，需要查看日志确认客户端功能是否正常。如果正常，则需要判断稳定性是否在计算和显示级别。一般来说，这类问题比较容易恢复。如果数据没有上报，只能等待下一个版本恢复。

　　3、数据异常

　　1）网络异常。比如在高峰期，大量用户同时提供行为数据，容易造成网络拥塞，就像春节期间的12306一样，容易造成部分请求丢失，导致数据不准确。对于缓存的本地数据，如果数据达到上限，可能会丢失部分数据。

　　2） 缺少重要的用户路径。比如我们可以看到平时紫外线不低于3000人，但是只有少数人。在这种情况下，可能会错过重要的用户路径，需要重新设计埋点。

　　3）统计口径不同。比如启动一个APP是活跃的？仅当主页加载时处于活动状态，或者当一个关键指标完成时。

　　4）无效请求。例如，竞争对手的恶意攻击和蜘蛛的爬行操作都会导致数据异常。

　　四、如何提高埋点质量

　　通过以上常见问题，我们需要做些什么来提高埋点质量？我将从以下几个方面来分析：

　　1、采集关键行为，使用后端埋点

　　什么是关键行为。比如订单支付，注册成功与否。后端埋点的优势我们在第二章已经讲过了，通过后端数据采集传递关键行为可以提高数据的准确率。

　　2、建立完美的埋点规范

　　有些公司的代码埋点错误率高达 50%。比如简单的点击事件的埋点。代码A应该埋点的点放在代码B上，这说明如果没有统一的标准，就会导致埋点错误。

　　1）埋点命名约定

　　比如我们规定埋点的名称只能由字母、下划线和数字组成，并保证其唯一性。例如设置ck点击，sw显示；隐藏事件的命名约定是：{team|business|role}_{component|page}_{specific element}_{action}

　　▶例子：

　　▷ 商标_NavBar_bar_ck。商标代表业务线，NavBar代表页面，bar代表功能，ck代表点击

　　▷patent_comt_share_ck。专利代表业务线，comt评估组件，分享按钮，ck点击

　　口径不同，那么我们得到的结果肯定是有偏差的。这时候指标字典就很重要了

　　2）构建指标字典

　　索引字典是业务数据标准化的基础。目的是统一管理索引，方便共享，对业务索引达成共识。索引字典一般保存在 Excel 或 Wiki 中，或放置在数据管理系统中。有血缘关系，追踪数据流向更方便。

　　指标一般分为三类：基本指标、普通指标、计算指标。索引字典通常收录两个部分：索引维度和索引度量。