数据采集合同 浅谈数据采集

2023-03-28 19:55:00 来源 : haohaofanwen.com 投稿人 : admin

下面是好好范文网小编收集整理的数据采集合同 浅谈数据采集,仅供参考,欢迎大家阅读!

数据采集合同

前言

现代系统对于数据的需求越发迫切,尤其在万物互联的物联网时代,上到服务层的数据平台,数据中台,下到基础设施层的数据仓库,数据建模,数据计算等都离不开大量数据的支持。因此建立一个高效的,全量的数据采集机制和通道成了其中必不可少的一环。

目标定义和分析

既然要采集数据,我们首先就要明确一个问题:数据采集的含义和目的。

一般来说,数据采集是指尽可能地收集目标对象,设备,服务等数据产生方的数据,传输汇总到相应区域,为之后的数据挖掘分析提供基础。

这里可以衍生出两个点:数据采集目标和数据传输

数据目标

数据目标可以从横向和纵向两个维度进行展开。横向就是指我们采集数据的维度有哪些,比如一些用户属性数据,行为数据,系统数据等等。纵向则是从数据产生传播链路上展开,比如远端设备和应用数据,云端服务数据等。稍微思考下,不难得出这个结论:越接近链路上游的数据价值越大,同时越接近链路上游的数据非结构化程度越高。

数据传输

数据传输决定了数据的及时性和稳定性。同样的,越接近链路上游的数据稳定性越差越易丢失,越接近链路上游的数据及时性越强。

着力点分析

有了初步的目标分析后,我们需要从以下两个方面下手,from whom和where。

from whom(使用方)

使用方,即会有哪些方需要进行数据采集。我们很容易得出会有设备方(包括手机,车机,平板,各自的系统,app等等),云端(各服务端包括外部,内部服务)。这还不够,这里我们不要忘了,一个灵活的数据采集方案不能缺少配置服务,大数据运营人员可以根据不同的需求进行实时的配置调整,用来控制采集开关,数据内容格式,传输通道(包含实时通道,非实时通道等多通道选择)等。

where(涉及点)

接下来我们再看下会涉及到哪些点。前端设备方,需要统一采集的sdk用于数据采集,传输和配置获取。云端服务端,同样需要数据采集sdk,同时还需要对应的配置服务。数据到数仓或数据服务通道的选择比如kafka,flume等。

通用方案

经过上述分析,我们不难得出下面的逻辑要素架构图(包含主要链路流程:设备端数据流,服务端数据流,配置流三条链路)

思考

上述方案在互联网等一些2C端领域比较通用,但这个方案能适用所有场景吗?让我们将场景切换到物联网领域,比如智能电动汽车,看看有哪些问题。首先两种场景数据采集目标是一致的,那么我们就从着力点这边去对比下各自的特点

互联网C端(比如抖音app)物联网(比如智能电动汽车)

设备端 单app数据量较小,用户量巨大,数据传输稳定 单设备数据量大,用户量较大(随着电动汽车等物联网设备的普及,后期用户量巨大),数据传输不稳定(弱网环境较多)

服务端 数据量大,数据传输稳定 数据量大,数据传输稳定

配置端 包含开关控制,内容格式管理,传输通道(数据类型通道)等配置 包含开关控制,内容格式管理,传输通道(除了数据类型通道,还可能包括多协议选择)等配置

通过对比不难看出,物联网场景下数据量会比一般互联网C端场景数据量有成倍的提升(为什么会出现这个现象,是因为物联网的数据采集往往不仅局限于应用层,系统层也非常多的数据需要采集,感兴趣的同学可以以车机为例去看下车机端的逻辑要素架构图分析下可能的数据产生点,这里不做赘述),主要提升侧都在远端设备端,而且从数据传输上来看,物联网领域会面临较多的弱网环境,导致传输不稳定。

改进

从上述对比,我们可以得出两个痛点(数据量大和传输不稳定),对症下药我们分别从逻辑要素架构和部署架构两方面去解决它。

数据量大

逻辑要素架构 对实时性要求不高的数据采取本地暂存,数据压缩,定时上报的策略,同时协议层可采用轻量级协议如mqtt,减小数据包大小。配置中心需要具备配置本地存储,定时上报策略的能力。

部署架构 提高服务端入口带宽,采用多数据中心部署,每个设备的数据就近存放到靠近(物理距离)它的数据中心,定时将将多数据中心数据汇总到总数据中心。

传输不稳定

逻辑要素架构 协议层采用具备服务质量控制的协议如mqtt,设置需要的服务质量(Qos)要求。配置中心需要具备配置协议选择的能力。

部署架构 采用多数据中心部署,就近存储数据,多数据中心与总数据中心间采用专线连接保证传输质量。

总结

本文只是较为粗浅地分析了下当前一些热门场景下的数据采集方案,在具体实践的时候根据需求的不同可能还会进行相应的细节修改。


相关文章

    暂无相关信息
专题分类