(2020.11.10)
数据采集、汇聚方法和工具
1. 线上行为采集
- 客户端SDK埋点
a. 全埋点:记录终端设备用户的所有操作和内容;优点:不用频繁升级,一次性验证并发布后,可以获得终端的全量行为数据;缺点:数据存储、传输的成本高。
b. 可视化埋点:将终端设备上用户一部分操作通过服务器配置方式有选择性的记录并保存;优点:发布后不需要频繁升级,成本比全埋点低,并灵活配置;缺点:如果分析数据没有被采集,需要重新配置采集在进行后续工作,影响业务进度。
c. 代码埋点:根据需求定制每次的搜集内容,需要对终端模块进行升级;优点:灵活性强,对复杂场景可单独设计方案,对存储和带宽可以做较多的优化;缺点:成本高、维护难度大、升级周期长。
- 服务器SDK埋点:常见Http服务器的access_log,和客服端埋点结合使用,相互补充,以完成整个用户行为的采集。
2. 线下行为采集:通过硬件采集,eg:Wi-Fi信号采集、信令数据采集、图形视频采集、传感器探测
3. 互联网数据采集:网络爬虫,目前有很多开源框架(eg,Apache Nutch2、WebMagic、Scrapy、PHPCrawl等)可以快速根据自己的实际应用场景构建数据抓取逻辑,应遵循相应的协议和法规,同时避免对网络目标网站造成过大的请求压力。
4. 内部数据汇聚
- 从数据组织形式上三中分类
a. 结构化数据:规则、完整,能够通过二维逻辑来表现的数据,严格遵循数据格式与长度规范,eg:数据表和Excel等二维表
b. 半结构化数据:规则、完整,遵循数据格式与长度规范,但无法通过二位关系来表现,eg:Json、Xml等
c. 非结构化数据:结构不规则或不完整,需要经过复杂的逻辑处理才能提取信息,eg:办公文档、图片、音视频等
- 从时效性和应用场景可以分为两类
a. 离线数据:大批量数据周期性迁移,对时效性要求不高,一般采用分布式批量数同步的方式,通过连接读取数据,过程可以有全量、增量方式
b. 实时数据:面向低延时的数据应用场景,一般通过增量日志或通知消息方式实现
- 数据同步工具:在大规模的数据场景下,一般不建议采用ETL(Extract-Transform-Load)方式,建议采用ELT(Extract-Load-Transform)模式,即将数据抽取后直接加载到存储中,在通过大数据和人工智能相关技术对数据进行清洗和处理。因为ETL模式很容易出现一些有价值的数据资源被清洗掉,导致当某天要使用这些数据时,需要重新处理,甚至数据丢失无法找回。
a. Canal:Canal Serer摸底Mysql Slave交互协议,优点:流程架构清洗,部署和配置相对简单,同时可以额外做一些配置管理、开发改造的工作;缺点是Server中的Instance和Client之间是一对一的消费,不太适用于多消费和数分发的场景。
b. Sqoop:较为通用的解决方案,在结构化数据和HDFS之间进行批量数据迁移的工具。整体架构以Hadoop为核心,底层是MapReduce程序实现(MapReduce特性保证了并化和高容错率,任务运行在Hadoop集群上,减少了服务器资源的使用情况);优点:特定场景下,数据交换过程会有很大的性能提升;缺点:处理过程定制程度高,目前主要通过命令行中的配置参数来调整数据操作行为,在用户自定义逻辑和数同步链路监控方面薄弱,调度完全依赖于MapReduce,功能扩展性方面受到约束和限制。
c. DataX:阿里巴巴开源插件式离线数据交换工具,不支持非结构化数据同步;