前言
对于当前的各种系统来说，对数据的需求越来越迫切，尤其是在如今万物互联的物联网时代，不论是服务层的数据平台，还是基础设施层的数据仓库，不论是数据建模，还是数据计算等都需要大量的数据作为支持。所以，创建一个高效合理的数据采集机制和通道成了非常重要的一环。
目标定义和分析
在我们进行数据采集之前，我们应该先明确一个重要的问题：数据采集的含义和目的。
一般说来，数据采集指的是尽量多地收集目标对象，设备，服务等数据源所产生的数据，并将得到的数据以需要的形式传输汇总到指定的区域进行存储，为以后进行数据挖掘分析打下基础。
这里就可以衍生出两个知识点：数据采集目标和数据传输
- 数据目标
数据目标可以分为横向和纵向两个维度来看。横向指的是我们采集数据的维度有哪些，比如用户的属性数据，行为数据，系统数据等等。纵向则是在数据产生传播链路上展开，比如远端设备和应用数据，云端服务数据等。稍微思考下，不难得出这个结论：越接近链路上游的数据价值越大，同时越接近链路上游的数据非结构化程度越高。
- 数据传输
数据传输可以决定数据的及时性和稳定性。同样的，越接近链路上游的数据稳定性越差越易丢失，越接近链路上游的数据及时性越强。
着力点分析
在明确了分析目标后，我们可以从两个角度下手进行分析，这两个角度就是：from whom和where。
- from whom（使用方）
使用方，即需要进行数据采集的需求方。我们很容易就可以得出会有设备方（包括手机，车机，平板，各自的系统，app等等），云端（各服务端包括外部，内部服务）。但这还远远不够，我们不能忘记了，一个灵活的数据采集方案少不了配置服务，大数据运营人员往往可以根据不一样的需求及时进行调整。可以调整数据采集规则，包括数据内容格式，传输通道（包含实时通道，非实时通道等多通道选择）等。
- where（涉及点）
接下来我们再看下会涉及到哪些点。前端设备方，需要统一采集的sdk用于数据采集，传输和配置获取。云端服务端，同样需要数据采集sdk，同时还需要对应的配置服务。数据到数仓或数据服务通道的选择比如kafka，flume等。
通用方案
经过上述分析，我们不难得出下面的逻辑要素架构图（包含主要链路流程：设备端数据流，服务端数据流，配置流三条链路）
思考
上述方案在互联网等一些2C端领域比较通用，但这个方案能适用所有场景吗？让我们将场景切换到物联网领域，比如智能电动汽车，看看有哪些问题。首先两种场景数据采集目标是一致的，那么我们就从着力点这边去对比下各自的特点
| 互联网C端（比如抖音app） | 物联网（比如智能电动汽车） | |
|---|---|---|
| 设备端 | 单app数据量较小，用户量巨大，数据传输稳定 | 单设备数据量大，用户量较大（随着电动汽车等物联网设备的普及，后期用户量巨大），数据传输不稳定（弱网环境较多） |
| 服务端 | 数据量大，数据传输稳定 | 数据量大，数据传输稳定 |
| 配置端 | 包含开关控制，内容格式管理，传输通道（数据类型通道）等配置 | 包含开关控制，内容格式管理，传输通道（除了数据类型通道，还可能包括多协议选择）等配置 |
通过对比不难看出，比起一般互联网C端场景的数据量，物联网场景下数据量会有成倍的提升（为什么会出现这个现象，是因为采集物联网的数据不仅仅局限于应用层，系统层也需要采集数据，主要提升侧都在远端设备端，而且从数据传输上来看，物联网领域常常会面临较多的弱网环境，从而使得传输不稳定。
改进
从上述对比，我们可以得出数据采集中需要面对的两个痛点（数据量大和传输不稳定），为了针对性地解决，我们需要从逻辑要素架构和部署架构两方面去解决它。
- 数据量大
- 逻辑要素架构对实时性要求不高的数据采取本地暂存，数据压缩，定时上报的策略，同时协议层可采用轻量级协议如mqtt，缩小数据包体积。配置中心需要具备配置本地存储，定时上报策略的能力。
- 部署架构 提高服务端入口带宽，采用多数据中心部署，每个设备的数据就近存放到靠近（物理距离）它的数据中心，定时将将多数据中心数据汇总到总数据中心。
- 传输不稳定
- 逻辑要素架构 协议层采用具备服务质量控制的协议如mqtt，设置需要的服务质量（Qos）要求。配置中心需要具备配置协议选择的能力。
- 部署架构 采用多数据中心部署，就近存储数据，多数据中心与总数据中心间采用专线连接保证传输质量。
总结
本文只是较为粗浅地分析了下当前一些热门场景下的数据采集方案，在具体实践的时候根据需求的不同可能还会进行相应的细节修改。
