数据采集与传输

背景：

在大数据分析平台背景下，针对用户行为分析、用户画像、个性化推荐等场景，

本文介绍首先需要做的数据采集与传输。

采集这类数据一般通过“埋点”的方法，记录用户提交了订单、后台库存的变化，

从而为后续大数据分析提供基础。

一、前端埋点方案

1、代码埋点

事件发生时，显示调用代码发送记录

国外：Google Analytics、Mixpanel

国内：百度统计、友盟、TalkingData、诸葛IO、Sensors Analytics 等

优点：控制精准；可以设置自定义属性，采集能力最强；（有的产品不一定能达到）

缺点：埋点代价大；发布代价大

2、可视化埋点

界面上点选控件，来指定触发事件以及发送数据的条件

国外：Mixpanel 等

国内：TalkingData、诸葛IO、Sensors Analytics 等

优点：部署直观、发布迅速、迭代快捷

缺点：能够覆盖的控件有限；UI变更会导致埋点失效；自定义属性和时间的设置能力有限；

3、全埋点/无埋点

预先收集所有控件操作，然后在后端程序或网页筛选要分析和统计的对象

国外：Heap

国内：百度、豌豆荚、GrowingIO

优点：数据可以向前“回溯”；可以自动获取一些启发性信息；

缺点：可视化埋点缺点；传输的数据量太大，浪费资源；

数据采集粒度对比，自上至下更获取数据更详细

全埋点/无埋点：某时某人点击了一个按钮

 可视化埋点 ：某时某人提交了一个订单

代码埋点 ：订单金额、商品名称、用户级别

后端接入数据：商品库存、商品成本、用户风险级别

数据回收一般是先收集，等待用户网络好时，压缩加密传输。

二、后端日志的传输方案

前端埋点通病：

传输时效性问题；数据可靠性问题；能够获取的数据信息有限；

因此，前后端都能获取数据时，优先在后端接入。

后端日志传输方案

application -> 日志文件 -> flume_agent -> flume_collector  ->  HDFS    &    Kafka（用于实时场景）

_______客户机___________________|__中心服务器___|____存储服务器      

优点：内网传输，时效性、安全性、可靠性问题迎刃而解；服务端模块打日志，发版、更新更简单；

缺点：部分前端行为采集不到；改动后与业务服务耦合，影响业务稳定性；日志打印是技术难题；日志流管理有门槛；

百度在flume_agent把日志格式化为protobuffer，节省带宽，兼容性好。格式化工作尽早做。

日志如果直接打kafka，缺点是耦合性太强，对现有业务改造大。

日志是追加写的，所以适合flume+kafka，不停的append。

三、数据库数据的传输方案

数据分析不仅是针对用户，有时需要针对订单、商户、商品分析，所以不可避免要采集数据库数据。

经常变动的信息，应该添加埋点、或日志。

不常变动的信息，可以导入分析。

两个导入方案：

（1）固定周期导入整张表做snapshot，体现为Hive同一张表的不同partition；

（2）snapshot + delta 内容太大时，使用此方案，类似于增量备份

sqoop：关系型数据库与HIVE之间互相传输的工具；

导入到HIVE后，可以利用HQL转化存储格式为orcfile parkquet，提升存储和查询效率；

日志存储格式建议用 google protobuffer，但是不能直接vim打开。但是比json节省空间，前后兼容性好，

数据仓库的建立方案：

olap为了读取优化  列存储，基于htfs很适合 orcfile parkquet  ,上层 spark sql 、hive、impla的都通用

oltp