大数据技术栈通常包括数据采集、存储计算、分析可视化、开放共享、业务应用等几个关键分层，在这些能力引擎中，数据存储是一个关键的能力域。在海量数据聚集整合后，首先就是要将数据存放起来，所以存储引擎的技术选型会直接影响后续的数据用途和分析效果。

存储引擎的选型要考虑一些关键因子，比如数据源类型（结构化/非结构化）、数据规模（GB/TB/PB）、数据增长系数（每年都会增长20%？）、数据加工分析的方式（长期存储？SQL查询？交互式访问？），这些因子必将决定存储引擎的选型方法。

传统关系型数据库（RDB），是企业生产经营中最为普遍的IT存储系统，大多存放业务系统的结构化数据集。在初期往往单节点服务器就能驾驭存储需求，后续随着存储容量逐渐增加大多采用集群的方式去扩展支撑，而且RDB能够支持数据的操作与更新，对增删改查来说绝对是好手，完全遵循了ACID的特性，而且支持标准的SQL语法。因此RDB应用场景非常广泛，技术也非常成熟。但即便如此，似乎RDB没有能在今天大数据时代有所作为。首先今天有很多半结构化/非结构化数据集需要存储并处理，传统关系型数据库并不支持，就更别谈数据规模了。而且RDB主要采用行存储的方式保存数据，从后期查询的支持来讲很难于随机访问，而且系统的扩展性并不出色，不论MqSQL还是PostgreSQL，原生版本的扩展性能需要大量的调优。

对于传统RDB的特点，其实Hadoop生态圈的HDFS具有较多特性差异。比如大规模文件存储支持了海量非结构化数据，什么视频音频、文本日志、社交物联网统统不是问题，而且可以根据节点数量大规模扩展，以提升系统整体的存储容量。HDFS可以承载Hive任务作业，依托于M/R机制实现大规模数据的加载和分析。但Hive只适用于一次写入、多次读取的场景，对于频繁更新和随机访问而言并非长项，因为些都受限于M/R机制和对标准SQL的支持。在大数据早期，HDFS+Hive长期支撑了很多客户的系统，比如电信运营商的详单数据存储和预处理、互联网公司的网络日志采集和分析等，直至今日仍然有很多企业在持续使用，正可谓大数据的关键技术组件。

除了传统SQL结构化数据外，在大数据领域还有NoSQL数据库。当时随着互联网web2.0的兴起，传统的关系数据库在应对大规模和高并发的SNS纯动态网站显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库（NoSQL）则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。NoSQL数据库主要有四大分类：键值（Key-Value）存储数据库、列存储数据库、文档型数据库和图形数据库，所以是典型的支持非结构化数据，这里面由于时间关系暂不展开。在NoSQL四种类型中，以Hbase为代表的列存储数据库是非常有代表性的。由于存储方式的特点使其对海量数据的随即访问支持非常好，而且底层也支持HDFS存储，其系统扩展性也不是问题，列存储大大提高了存储压缩率。现在Hbase不仅支持一级索引，还可以通过功能开发实现二级索引的支持，所以技术成熟度也是不错的。

上述介绍中，你会发现海量数据的大规模分析与高效低延迟访问有较大差别，两者各有优势不可兼得。在现实情况中会经常发现两套存储引擎的交替使用，分别用于实时读写与海量数据分析，可以先将数据写入HBase中，再定期通过ETL到Parquet进行数据同步。但是这样做有很多缺点，比如第一：用户需要在两套系统间编写和维护复杂的ETL逻辑；第二，时效性差，因为ETL通常是一个小时、几个小时甚至是一天一次，那么可供分析的数据就需要一个小时至一天的时间后才进入到可用状态；第三，更新需求难以满足。在实际情况中可能会有一些对已经写入的数据的更新需求，这种情况往往需要对历史数据进行更新，代价太大；第四，存储资源浪费。两套存储系统意味着占用的磁盘资源翻倍了，造成了成本的提升。所以Cloudera开发了Kudu存储引擎，解决了前面种应用场景的问题。但是新技术需要磨合才能实际生产运用，否则会带来风险。

通过上述介绍，如果你需要常规结构化数据集的存储管理和查询分析，那么你需要RDB存储引擎；如果系统将承载海量非结构化数据集，那么存储和分析就需要用到HDFS+Hive的存储引擎；如果你需要海量非结构化数据集的低延迟随机读写场景，那么你需要使用类似于Hbase这样的存储引擎；如果你需要支持结构化数据，而且支持行级的插入、更新、删除，并尝试新技术去应对海量数据分析和低延迟随机访问，那么Kudu也可以选择。

大数据存储引擎是一个既复杂而又关键的领域，一个好的存储技术架构有助于后续业务的“生根发芽”。

在短时间内爆发大量数据，这时数据资源的采集、存储和分析和应用等，都是大数据行业的难点。行为数据、日志数据的处理，往往成为企业数据建设首先面对的瓶颈，这些数据不易保存，实时获取分析难度较大，但是数据价值却不可估量。

在大数据中，90% 以上的数据爆发来自于行为数据，就像现在的互联网、移动互联网、甚至在产生于物联网中用来描述人和物的每一分每一秒的变化的数据状态，这些都是行为数据。

行为数据能用做什么？

行为数据能做什么？有一个简单的例子 —— 分析访客行为的路径，我们拿一个网站的数据进行分析，针对网站的访客，我们可以通过分析其访问前期、中期、后期的行为习惯去了解哪些引流的渠道需要加强投入，以及使用这些来指导内容编辑和竞品研究分析工作。

实际上在做需求时，还有更多的细节要求如：对数据的实时性的要求比较高、要求数据的热点情报的准确性、与客户数据的协同分析等。

行为数据的处理方式

用户行为数据通常具备以下特征：

用户基数大；

高基数维度比较多；

数据量大；

时序的特征。

我们用到的高基维，其中有些维度都是上千万的高基维参数。用户行为数据的处理，在支持原始数据查询的同时，也要支持原始数据的聚合能力。

原始数据的聚合分析这块又分为两种，一种是过去常用的做法，通过一个固化的业务模型或者主题，提前计算好的数据，叫做物化视图。

第二种是基于原始数据存储之后，在实时查询的过程中进行多维交叉的计算，这个称为实时聚合。

在查询过程中对实时聚合的一个分析，也是大家在进行数据挖掘分析中共同面临的一个问题，就是针对海量数据。

首先，针对这些数据，需要快速的检索出所需要的数据的行号。其次，在获取数据所在位置之后，如何快速地把数据装载到内存里，最后是装载到内存之后通过分布式计算的方式，怎么去把我们的结果计算出来。

这些就是在做数据的实时查询过程中的需要具备的基本技术条件。

挖掘数据新的价值

面对海量实时行为数据的技术思考，主要是从四个角度来进行：

第一，必须要以原始数据存储。为什么要基于原始数据存储？因为在整个的数据分析阶段，可以细分为三个阶段。第一个就是传统的是 BI 阶段。第二个是数据的挖掘，第三个是数据的预测分析。

想解决这三个阶段的过程，以传统的方法是建一个数仓，基于数仓来实施的时，只能面向比较固化的业务报表模式，产生一些数据的分析结果，得到决策结果。如果想做数据挖掘时，基于固化业务模式计算的结果的很难满足数据挖掘需求，所以必须从初始阶段基于原始数据去提取其特征。

基于固化的的业务报表模型所获取数据计算的结果，对数据挖掘分析的价值不高。存储引擎必须以原始数据进行存储，才能既满足 BI 阶段的需求，又可以解决未来数据挖掘与数据预测分析的需求。

第二，要满足实时多维的查询，是为了在数据基于原始数据存储之后，去做到聚合结果能够满足用户对海量增量数据快速查询的需求。

第三，快速响应需求，在企业内部，其实数据部门的需求量是最大的，各个业务部门的需求都往数据中心提，所以数据部门必须去解决好如何快速地响应业务需求。

第四，数据的探索分析，以往把数据，按照固化的业务报表模式所获取的结果，做二次分析的空间量比较小。所以必须要基于原始多维的数据进行数据的探索，挖掘数据新的价值，而不是按照已有的固化的业务模式，只是生产出一些固化的业务模型的数据。

平台架构

数果现在基于之前做过的一些技术的预言跟验证，自行研发了一个基于 Hadoop 加速引擎，称为 Tindex。之前我也在网络上做过万亿级日志与行为数据存储查询技术剖析http://infoq/cn/articles/trillion-log-and-data-storage-query-techniques 的文章 ，也讲解了 Tindex 是如何实现的。Tindex 的实现主要基于三点，第一点基于索引，第二点基于类似存储的方式，第三点做了分布式内存计算的框架在 Tindex 中，使之能够支持数据的实时的多维分析的能力。

基于加速引擎这块，在其上层做了一个适配层，有 SQL引擎。SQL 引擎支持 SQL 语句和表达式，还有大数据生态技术，目前已经是完全支持。基于适配层，来做不同的行业应用。这是数果整个平台技术架构的一个图。

平台特性

平台的特性方面，支持海量增量数据实时接入。在数据接入这块，现在提供可视化埋点，跟文件、MR 的一些数据的采集，就像我们目前在做的单进程的接入式，基本上在 3 万以上，从数据的产生，到数据显示、出现查询结果，在 5 秒以内即可实现。

第二个特性，基于明细数据的存储与预聚合的存储分别去搭建。为什么不仅要基于原始数据存储，还需要预聚合存储？因为其有两种不同的需求。第一个是面向固化的高频查询的数据，我们可以基于预聚合存储的方式，去查询其周期跨度比较长的需求，一年两年都可以进行查询。但是基于近半年或者一年的数据需要进行深度数据探索分析的，便可以基于原始明细数据做实时聚合分析。还有在基于原始明细数据进行分析的时候，他会更佳灵活。

第三，海量数据中怎么去实现快速检索，是基于搜索引擎的索引技术进行改造的。但是在筛选方式上，目前只能支持时间筛选、文本筛选和数值筛选，例如文本筛选中支持分词与模糊匹配，数值筛选中，数值的分组和数值的范围这些均可支持。

这个展示的是灵活多维的分析，在这个界面中，左边的这一列中是基于原始明细数据产生的所有的维度，可以根据权限去进行显示。而在指标方面通过界面拖拽进行多维实时分析，选择想要的数据分析结果，进行可视化的展示，可以自由地数据探索。因为数据是基于原始明细数据的存储，所以不需要提前预计算。可以在界面上进行任意数据交叉分析，去了解数据的分布态是非常便捷的。

通过指标的灵活定义，来实现实时响应的业务需求，这个指标定义这块有几个指标，一种叫单指标，即按照某一个维度进行一个聚合计算，通过界面可以简单、快速完成。另一种叫复合指标，需要进行一些四则运算，可以通过这个界面定义出来。

在指标这方面还有比较复杂的，需要通过多个维度进行定义的，可以通过一些表达式，进行快速的定义，定义完成后就通过界面，直接看到结果，获得图形显示，进行数据分析。

支持实时监控与跟踪告警，在多维分析界面中把分析结果定义出来后，可以直接形成一个实时监控大屏，不需要重新开放，多站完成各类需求。

最后一个也是最重要的一个特性，是支持二次的开发。数果的平台提供普通类查询，有 Timeseries、TopN、select、groupby、firstN、scanQuery。也提供像用户分组，用户漏斗查询，用户留存查询这类高级查询，还支持多种条件的过滤，像日期范围、数值范围、地理坐标范围，还有字符串的精准匹配。还支持多种聚合的方式。如统计，分组，还有聚合再聚合，这类业务场景，也是在业务需求中经常出现的。

基于平台我们做了什么？

基于这个平台实现了指标任意定制，因为数据是基于原始明细记录存储的，所以指标的定制这方面，不需要提前预计算，直接通过界面，通过一些表达式便可以轻松实现。

维度的自由的筛选，可以通过界面，自由地拖拽数据，就可以完成交叉分析。

基于平台提供用户行为分析模型，例如实时的用户分群，可以通过界面快速的完成。再例如实时的路径分析，实时的流程分析，实时的漏斗分析。提供了一个智能算法模型，相当于在这个模块实现了，将机械学习跟深度学习的算法吸收进来，跟我们的平台打通，就可以实现通过界面的简单拖拽，来完成大部分算法的模型。用户也有一些固化的模型，像用户的扩群，用户 RFM 细分的模型，用户流失预测的模型。基于这方面也提供了一个实时大屏的模块，能够由用户自由拖拽完成其实时监控的需求。

随着大数据越来越被重视，数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台：

Apache Flume Fluentd Logstash Chukwa Scribe Splunk Forwarder

大数据平台与数据采集

任何完整的大数据平台，一般包括以下的几个过程：

数据采集–>数据存储–>数据处理–>数据展现(可视化，报表和监控)

其中，数据采集是所有数据系统必不可少的，随着大数据越来越被重视，数据采集的挑战也变的尤为突出。这其中包括：

我们今天就来看看当前可用的六款数据采集的产品，重点关注它们是如何做到高可靠，高性能和高扩展。

1、Apache Flume

Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 Flume使用JRuby来构建，所以依赖Java运行环境。

Flume最初是由Cloudera的工程师设计用于合并日志数据的系统，后来逐渐发展用于处理流数据事件。

Flume设计成一个分布式的管道架构，可以看作在数据源和目的地之间有一个Agent的网络，支持数据路由。

每一个agent都由Source，Channel和Sink组成。

Source

Source负责接收输入数据，并将数据写入管道。Flume的Source支持HTTP，JMS，RPC，NetCat，Exec，Spooling Directory。其中Spooling支持监视一个目录或者文件，解析其中新生成的事件。

Channel

Channel 存储，缓存从source到Sink的中间数据。可使用不同的配置来做Channel，例如内存，文件，JDBC等。使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。

Sink

Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。Sink支持的不同目的地种类包括：HDFS，HBASE，Solr，ElasticSearch，File，Logger或者其它的Flume Agent。

Flume在source和sink端都使用了transaction机制保证在数据传输中没有数据丢失。

Source上的数据可以复制到不同的通道上。每一个Channel也可以连接不同数量的Sink。这样连接不同配置的Agent就可以组成一个复杂的数据收集网络。通过对agent的配置，可以组成一个路由复杂的数据传输网络。

配置如上图所示的agent结构，Flume支持设置sink的Failover和Load Balance，这样就可以保证即使有一个agent失效的情况下，整个系统仍能正常收集数据。

Flume中传输的内容定义为事件(Event)，事件由Headers(包含元数据，Meta Data)和Payload组成。

Flume提供SDK，可以支持用户定制开发：

Flume客户端负责在事件产生的源头把事件发送给Flume的Agent。客户端通常和产生数据源的应用在同一个进程空间。常见的Flume 客户端有Avro，log4J，syslog和HTTP Post。另外ExecSource支持指定一个本地进程的输出作为Flume的输入。当然很有可能，以上的这些客户端都不能满足需求，用户可以定制的客户端，和已有的FLume的Source进行通信，或者定制实现一种新的Source类型。

同时，用户可以使用Flume的SDK定制Source和Sink。似乎不支持定制的Channel。

2、Fluentd

Fluentd是另一个开源的数据收集框架。Fluentd使用C/Ruby开发，使用JSON文件来统一日志数据。它的可插拔架构，支持各种不同种类和格式的数据源和数据输出。最后它也同时提供了高可靠和很好的扩展性。Treasure Data, Inc 对该产品提供支持和维护。

Fluentd的部署和Flume非常相似：

Fluentd的架构设计和Flume如出一辙：

Fluentd的Input/Buffer/Output非常类似于Flume的Source/Channel/Sink。

Input

Input负责接收数据或者主动抓取数据。支持syslog，http，file tail等。

Buffer

Buffer负责数据获取的性能和可靠性，也有文件或内存等不同类型的Buffer可以配置。

Output

Output负责输出数据到目的地例如文件，AWS S3或者其它的Fluentd。

Fluentd的配置非常方便，如下图：

Fluentd的技术栈如下图：

FLuentd和其插件都是由Ruby开发，MessgaePack提供了JSON的序列化和异步的并行通信RPC机制。

Cool.io是基于libev的事件驱动框架。

FLuentd的扩展性非常好，客户可以自己定制(Ruby)Input/Buffer/Output。

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据/日志格式是它的另一个特点。相对去Flumed，配置也相对简单一些。

3、Logstash

Logstash是著名的开源数据栈ELK (ElasticSearch, Logstash, Kibana)中的那个L。

Logstash用JRuby开发，所有运行时依赖JVM。

Logstash的部署架构如下图，当然这只是一种部署的选项。

一个典型的Logstash的配置如下，包括了Input，filter的Output的设置。

几乎在大部分的情况下ELK作为一个栈是被同时使用的。所有当你的数据系统使用ElasticSearch的情况下，logstash是首选。

4、Chukwa

官网：https://chukwa.apache.org/

Apache Chukwa是apache旗下另一个开源的数据收集平台，它远没有其他几个有名。Chukwa基于Hadoop的HDFS和Map Reduce来构建(显而易见，他用Java来实现)，提供扩展性和可靠性。Chukwa同时提供对数据的展示，分析和监视。很奇怪的是它的上一次 github的更新事7年前。可见该项目应该已经不活跃了。

Chukwa的部署架构如下：

Chukwa的主要单元有：Agent，Collector，DataSink，ArchiveBuilder，Demux等等，看上去相当复杂。由于该项目已经不活跃，我们就不细看了。

5、Scribe

代码托管：https://github/facebookarchive/scribe

Scribe是Facebook开发的数据(日志)收集系统。已经多年不维护，同样的，就不多说了。

6、Splunk Forwarder

以上的所有系统都是开源的。在商业化的大数据平台产品中，Splunk提供完整的数据采金，数据存储，数据分析和处理，以及数据展现的能力。

Splunk是一个分布式的机器数据平台，主要有三个角色：

Search Head负责数据的搜索和处理，提供搜索时的信息抽取。

Indexer负责数据的存储和索引 Forwarder，负责数据的收集，清洗，变形，并发送给Indexer

Splunk内置了对Syslog，TCP/UDP，Spooling的支持，同时，用户可以通过开发 Input和Modular Input的方式来获取特定的数据。在Splunk提供的软件仓库里有很多成熟的数据采集应用，例如AWS，数据库(DBConnect)等等，可以方便的从云或者是数据库中获取数据进入Splunk的数据平台做分析。

这里要注意的是，Search Head和Indexer都支持Cluster的配置，也就是高可用，高扩展的，但是Splunk现在还没有针对Farwarder的Cluster的功能。也就是说如果有一台Farwarder的机器出了故障，数据收集也会随之中断，并不能把正在运行的数据采集任务Failover到其它的 Farwarder上。

总结

我们简单讨论了几种流行的数据收集平台，它们大都提供高可靠和高扩展的数据收集。大多平台都抽象出了输入，输出和中间的缓冲的架构。利用分布式的网络连接，大多数平台都能实现一定程度的扩展性和高可靠性。

其中Flume，Fluentd是两个被使用较多的产品。如果你用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

Splunk作为一个优秀的商业产品，它的数据采集还存在一定的限制，相信Splunk很快会开发出更好的数据收集的解决方案。

第一部分系统目标

省安全生产监督管理局安全数据采集管理中心的总体建设目标，就是建设一个对安监网安全巡查的数据进行统一采集、存储、管理的中心平台，实现能够使县市乃至省级安监局相关单位在安监专网网络范围内通过此系统将安全巡查过程中智能安全帽所记录巡查的各类数据（视频、音频和照片）上传到系统平台，进行统一存储管理，便于各县市省级单位同事及领导登录系统后，对上传的各类数据（视频、音频和相片）进行检索、查看、浏览、下载，满足对安监网巡查工作更细致的情况追踪和监控，实现更高效的业务转化。

系统主要特点

1、拥有自主研发的智能安全帽，使用该安全帽可实现在巡查工作过程中的全自动巡查记录或重点记录，在不影响巡查工作的各项操作下，实现静默且稳定的图像资料记录和保存，实现巡查工作的忠实记录和保存，以便于巡查工作更好的保存和追踪。

2、拥有自主研发的智能安全帽数据采集柜，具备智能的门锁技术，实现安全帽和储存柜的互相绑定，安全帽配合采集柜实现设备保存、设备充电、设备数据自动采集三合一功能，大大简化使用流程和提升使用便利性。

3、采集柜本机具备超大容量存储空间的同时，可实现手动或自动上传备份数据或者传输数据至制定数据位置，实现数据的分布存储或集中存储的不同需求。可根据条件设置自动化执行任务，实现自动定时或针对性备份或传输特定数据，同时不同数据支持互相迁移。

4、灵活多样、满足多途径的数据检索、统计和再利用能力，通过通用浏览器即可方便访问数据管理平台，实现远程的数据检索、预览、下载或备份。

5、完善的日志管理和追踪功能，用户在系统中的各项操作均会生成日志记录，方便层层溯源追踪把控。

6、完善的用户层级和权限管理，上百项细致入微的用户自定义权限内容，精确把控不同用户可在系统中获取的数据及操作权限，方便不同的使用和管理需求。

7、支持网状模型连接扩展，可无限扩展架构层级，无损添加新节点，满足不断扩张成长的业务需求。

通过该系统平台的建设，帮助省安监局各地单位建立远程的巡查数据管理入口，实现巡查业务更加精确高效安全的同时，将各地区的数据区块汇总接入，最终建立起属于省安监局单位独有的云端巡查数据管理中心。

第二部分系统逻辑结构

该方案可分为两种形成，每种形式各有优势和缺点，可以根据实际的需求情况，采用不同的搭建形式，满足不同的建设目标。、

一、分布存储独立架构

该架构下系统包含：一级应用服务器一台运行数据管理中心平台软件；一级数据服务器一台用于备份特殊重要数据满足少量独立存储需求；二级分布式数据采集柜多台。

通过多台数据采集柜互联构成采集柜网状结构，经由网络统一直接连接到一级应用服务器托管，实现应用服务器对所有网络内的数据采集柜的远程连接、访问和管理，同时一级数据服务器接入应用服务器，作为数据管理平台的备份数据存储中心，常规数据全部储存在区块中各自独立的数据采集柜内，网络内电脑通过浏览器开启数据管理中心后台登陆，即可实现远程的数据访问与管理，并根据应用服务器内的权限层级设定，实现不同的功能和效果。

结构拓扑图见（图1）

优点：

该模式下搭建平台更为简单快速，由于单层结构设计，可以大大免去网络层级的部署和规划，同时简化接入流程，提供快速更高效的平台建设和数据传输流程。数据采集柜接入网络，连接应用服务器即可实现托管。建设简单，相对建设成本较低，满足快速搭建小型网络平台或初期建立平台雏形，后续可方便的升级变换架构，升级成中心存储集群式。

缺点：

由于采用较为简单的单层结构，数据全部分布存储于数据采集柜，数据存储较为分散，访问并管理的效率较低，同时由于分布存储的原因，只安排了较小的数据服务器满足低比例的特殊备份需求，大量数据分散存储于不同地区采集柜中，数据产生丢失或者无法访问的风险较高，需要稳定的供电和网络维持基本的连接。同时分布式存储导致的数据访问并发情况较多，对网络的承载压力较大，传输链路较多跳转，导致效率较低。

二、中心存储集群架构

该架构下系统包含：一级应用服务器一台运行数据管理中心平台软件；一级数据服务器多台或多级数据服务器多台用于备份特定区块数据满足集群数据存储需求；二级分布式数据采集柜多台。

通过多台数据采集柜互联构成采集柜网状结构，经由网络连接到区块内独立数据服务器，区块设立可依据地区或者业务规划来定，多区块数据服务器最终通过网络统一连接中心应用服务器，实现应用服务器对所有网络内的数据采集柜和数据服务器都能实现远程连接、访问和管理，设定不同的权限层级可满足区块内数据访问的相对独立和区块间的数据仍能通信的需求，同时通过中心应用服务器设定自动化自定义条件任务，自动执行数据从数据采集柜汇总备份到区块数据服务器进行多层级分布式存储，最终实现数据的多重安全备份，高效汇总和自动化的分配目标。

结构拓扑图见（图2）

优点：

该架构下搭建而成的平台具备多区块分布存储备份，数据永不丢失，安全可靠，同时基于分布式存储技术接入网络后可实现更高效的可访问性和更稳定的数据传输。基于自动化的自定义任务可以在网络闲时自动静默汇总分散于采集柜中的零散数据集中传输至区块内的专用数据服务器进行存储，同时借由数据服务器的高速处理能力，实现更高效的远程访问、预览、下载、传输及检索操作。架构内采集工作、数据存储、中心访问分工明确，互不干扰运行更加稳定，同时可方便的无限拓展数据服务器数量，满足长远的平台成长需求。

缺点：

该方案搭建需要配合规划区块，搭建相对独立的数据服务器，同时由于多层级的架构加大了初期建设的工程难度和成本，基于分布式存储的形态需要安排更多的服务器安装空间。

第三部分系统运行环境

系统分为采集端CS程序和浏览器BS管理程序两部分。

系统采集程序运行在windows环境下，支持各种版本的windows系统，数据库支持SQL Server系列的数据库或其它版本的关系型数据库。

对安全帽采集数据的管理后台使用浏览器，支持目前主流的各种版本的浏览器。

第四部分产品介绍

智能安全帽

l高清宽动态摄像头，支持高清录像

l开机自动录像，免去繁琐操作

l机身一体化设计，镜头及照明灯内置，产品更美观

l高强度复合材料帽身，提供专业的安全帽应有的防护功能

l简约的功能操作设计，一键开机，一键录像，一键亮灯

l支持大容量最高128GB存储扩展，满足更持久的录像需求

数据采集柜

l高强度框架式机身，抗冲击防腐蚀外壳

l安全内部排布设计，满足长时间连续稳定运行需求

l内置键盘鼠标，屏幕支持触摸，多种操作方面满足不同场景需求

l多设备独立存储仓设计，方便单独存储安全帽以及其他装备。

l智能电子独立门锁设计，可实现独立开启每个存储仓位。

l支持多设备同时接入，满足大批量安全帽充电需求同时实现自动化数据采集上传

l支持网络化运行，可单机使用也可接入网络后交由统一服务器托管，实现多台采集柜互联构建采集网络。

l主柜6口，副柜10口，最多一主两副一共26口，但实际可用最多22口。

数据管理平台（服务器）

lBS轻量化设计架构，通用浏览器即可访问，满足更好的兼容性

l支持多条件数据检索，满足快速书筛选需求

l支持多层级网络架构，实现不同的平台建设需求

l支持用户权限管理，根据实际需求定义用户不同权限实现不同管控

l远程预览，远程下载，可通过网络随时访问数据并进行管理

l高度自定义的自动化任务系统，设定周期，时间，人员，单位等条件实现自动化数据备份操作。

第五部分：产品功能说明

一、产品示意图

PipeSight管道检测视频判读报告软件

对检测视频文件进行播放预览、添加检测信息、截取缺陷图像、判读描述等；可将判读结果数据自动生成为图文并茂的检测报告；可导出GIS平台通用的ShapeFile接口数据；提供电子地图查阅功能，在电子地图中标注出作业点的位置，查看作业点对应的检测数据、判读信息、缺陷图片和检测视频；

PipeLineTracer管道检测定位示踪软件

可进行管道坡度测量，曲线绘制，并分析生成报告；

PipeSonar管道声纳成像分析报告软件

可自动检索管壁轮廓并计算沉积深度、沉积宽度、沉积体积、水位高度。支持测量尺、测量环、测量网格等多种鼠标测量工具，以进行距离、宽度、高度、半径、直径等测量操作。提供高自由度的三维管道模型漫游功能，对实体、网格、点列三种管道模型均提供管内漫游和自由漫游方式。采用回波幅度和回波时间成像技术提供三种视图：管壁横断面图、管壁全景展开图和三维管道模型。具有视图联动功能，可将不同视图中选择的位置对行关联定位和标记。

PipeFell管道电法测漏定位软件

用于进行管道电法测漏检测数据的采集存储；可对电法测漏仪的结果数据进行存储、显示、编辑、导出、分析；可将电法测漏仪的结果数据自动生成为图文并茂的检测报告（包括项目信息、工程概况、缺陷分布示意图、检测设备简介、缺陷统计图表、详细缺陷图表等内容）；

目前有很多数据采集云平台，如百度统计，腾讯统计、乐驰云采集等等，还有一些平台也非常不错：

一. 友盟+

支持移动端和web端数据采集，个性化场景数据定制采集方案。官网给的一些demo可以参考来设计大数据的分析展现，例如：

友盟的：

百度的：

值得借鉴～

二. 乐驰云采集

以高性能分布式采集、存储为核心，建立分工明确的功能模块进行高度协作，融合打码、分词、代理、排重等实用性服务，帮助用户以最低成本、最少人力、最高效率完成大数据应用开发，从而满足当下广大中小企业对“实时、高难、海量”级大数据业务场景的根本需求。

http://lewell/service.html#tabcon_4

值得一看

三. 火车采集器

火车采集器，一款专业的互联网数据抓取、处理、分析，挖掘软件，可以灵活迅速地抓取网页上散乱分布的数据信息，并通过一系列的分析处理，准确挖掘出所需数据。火车采集器历经十二年的升级更新，积累了大量用户和良好口碑，是目前最受欢迎的网页数据采集软件。

对于网站采集数据的主流实现方式是通过javascript脚本引入，记录页面动作与变化，搜集数据后作为参数，通过gif图片(gif图片格式请求可以解决跨域问题)请求上报。

比如一些大型网站，可以看到他们的数据采集方式：如淘宝，百度，京东，聚划算等

个人设计的web采集数据方案：

lg.js脚本引入页面中通过gif图片请求到后端服务器服务器记录请求参数到日志文件日志文件实时抓取到消息队列实时计算系统消费队列消息，完成分析整理分析结果入ES，kibana二次开发展示ES历史数据入Hadoop

既然产品、研发与运营是互联网的三板斧，那么就不得不说说大数据时代的研发。我一直在困惑，究竟应该如何向广大的产品经理同学们讲清楚什么是大数据的研发。说详细了，必然使其困惑，而且我也不一定都能够明了其中的细节；说的粗略了，产品经理同学又会觉得不痛不痒，毫无感觉与世纪效果。再加上，本身打数据的研发就包罗万象，即便是单独成书则废寝忘食不能成也。除此之外，大数据门派众多，云计算、虚拟化、微服务都算是与大数据紧密相关的，那到底什么该讲什么不该讲呢？

我制定了大致这样的规则，我们想和各位产品经理同学讲一讲大数据的代表性工作，Hadoop平台以及围绕该平台大致需要做的一些事情，我们并不会具体到一种语言，也不会具体到某种技术，而是从宏观的视角，把产品经理在数据上扎的根生出的藤蔓深向原本只有工程师们才能够触及的墙角与远方，并在每一处需要精心雕琢与深究的地方稍加缠绕，略微展开谈一谈这些宏观过程其中的内部机理。还记得我们在第二部分介绍数据挖掘相关技能的时候，我们使用了CRISP-DM的流程来介绍数据挖掘与数据分析的标准化步骤。如果那个时候的介绍看成是逻辑层面的流程的话，我们这里想要沿着物理层面的主线来向数据产品经理同学们展现什么是打数据的研发。具体来说，我们会按照数据采集、数据存储、数据计算以及数据分析这样四个步骤去介绍这些过程在工程师的手中，在他们心爱的服务器上都发生了什么。

让我们还是先来看看数据采集吧。

现如今，相信很多人手上的手机已经变成了全屏幕的触屏手机，而如果时光回到十年前，你拿起那个屏幕尺寸更小，手机功能更少的键盘机的话，不知会作何感想。那个时候的手机对于我们来说，只有三个意义：电话、短信、小游戏。如果你的手机可以播放视频，那一定是诺基亚与摩托罗拉的高端机型了。在那个时候，我们通过移动电话设备产生的数据无非也就是通话与短信数据，这些数据存储在三大运营商，他们知道我们在什么时间给谁发短信或者打电话，如果他们乐意，甚至还可以知道我们发了什么，说了什么。那个时候的数据采集量小到可怜，而且大多数还握在运营商手中。

随着屏幕尺寸的扩大，安卓与iOS的入局，整个手机生态被打破，人们还是习惯于看大屏幕的收集，习惯使用一根手指去戳屏幕，习惯于在自己的电子设备上装上各色花花绿绿的应用，以至于在各种公共场合人们低头猛戳手机，甚至还收获了一个专有的名词叫做“低头族”。这个时候，出现了微信、微博，人们开始习惯使用微信给好友递送消息，而不再使用短信。这样的现象也改造着运营商的业务，以前每个月最需要在意的是套餐中包含多少条短信，而现如今则是每个月的套餐中的流量有多少。尽管运营商还是掌握着我们海量的数据，但是能够收集数据的人再也不止那三家运营商了。手机的生产者需要为手机在出厂的时候生产操作系统，因而他们成为了天然的数据收集方，原则上他们可以了解到你在手机里做的一切，就好比在一个封闭的屋子里装上了一个闭路电视，这个屋子就是该厂商生产的手机，你可以不进去，但是一旦你进去，所有的行为将被监控与知晓，至于这个闭路电视的监控视频内容何时被何人查看则取决于布下该系统的人的意愿罢了。除了这个房屋的建造者，还有很多的家居提供商也具备监控行为的能力，这些家居的提供商就是手机里花红叶绿的各色APP，原则上，只要你使用这样的家居产品，你在使用该产品的行为就会被记录，如果这样的家居公司与房屋的建造公司关系不错，除了能够收集自家家居产品的使用数据之外，还能顺便了解到但凡有本家公司家居产品的屋子里都还有哪些家居产品，甚至连用户是如何使用其他家居产品都是知道的。这样，数据进一步被积累，除了以前的运营商（地皮所有者）之外，手机操作系统厂商（房屋建造者）与手机内应用开发者（家居厂商）都是数据的拥有者。

原本数据只是一口池塘，池塘中仅有的几条大鱼已经翻不过来身了，而现如今风云突变，池塘变成了湖泊，不仅这几条大鱼能够鱼翔浅底，而且随着湖泊生态的演变，鱼群变得越来越密集，每条鱼都可以自由的吮吸着湖泊中的融氧，变强，变大。就在此时此刻，湖泊的平面再一次的上升，而鱼群们则更加跃跃欲试，这个湖就是我们现在知道的大数据。

抒情了这么久，只说了数据采集的一半，即可以采集哪些数据。当然，上面是以采集收集的数据为例来进行的说明的，而传统的网页也无非大同小异。可是这些数据究竟是怎么被厂商们采集回去的呢？也就是说到底采集的方法有哪些呢？

我们大致可以将数据的采集分为两类，一类谓之传送带式，一类谓之土方车式。且听我细细为你道来。

对于传送带方式的数据采集来说，实际上实在采集的前沿阵地和数据存储的大后方建立了一个传送带，一旦有星星点点的数据被采集回来就会被立即送上传送带，经过一段距离的传输就会被递送到存储的地方存储起来或者是被计算。就好像是在很多煤矿或者石料企业的现场看到一条长长的传送带，前方的挖煤机或者是采石机但凡能够搅下半点原料，这些原料就会被立刻送上传送带，送到后方。尽管在实际的场景中，这些传送带的后方有可能也是一些仓库，但不妨把这些仓库看成是在数据采集档口上的第一道存储服务器罢了。在这样的情况下，运送土方或者数据的通道是一直建立的，存储土方和数据的仓库也是时时刻刻在接受的，只要采集数据的过程不停止，那么运行这个传送带的机器与看守仓库的人就不可以停止与下班，因而在这样的实时数据采集过程中，人的注意力不可以离开，需要一直专注于整个流程，我们称他们是长连接，就好比是人的思想之弦一直紧绷，一刻不松懈的关注者另一端很长时间。与这样方式类似的数据处理形式称之为数据流处理，而打电话就是一种典型的数据流处理形式，在整个打电话的过程中，听话人需要一直关注对方在说什么，甚至需要通过听辨声音来判断通话是否还存在于线上或是已经挂断。

对于土方车式的数据采集来说，往往是挖掘机把挖掘到的土（数据）放到土方车上，但是这些土方车不会因为有了一抔土就立刻送走离开，而是等车装满后再听从现场指挥的命令按照次序离开并送到指定的地点，这样的方式因为是需要将数据积累到一定的量，因而是一种相较前一种数据采集的方式更加随意的方式，它的随意就体现在数据并不要求实时，而是一段时间发送一次。于是乎，在挖掘机工作的时候，土方车的驾驶员（传送人）与仓库的保管员（存储人）可以稍加休息或是处理其他事情。这种数据采集的模式称之为短链接，顾名思义，人们的神经并不需要死死地盯住一个事情，而是仅仅需要在需要处理的时候响应它，在处理完了之后转而去做别的事情或者处理别人的请求即可。目前大多数的APP内的数据采集使用的就是这样的短链接模式，先将数据积累在本地，然后再一段时间把这些数据递送一次。除此之外，当你访问网页的时候，也是这样的短链接模式，你送给服务器一个URL，告诉他你想要这个网址的内容，服务器找到之后发送给你，但是它并不关心你是否能够收到，只要它一旦发出就去处理别的事情了，除非你再次请求他，否则它也不会再来理你。

这就是你所应该知道的数据采集过程。

一、携程实时用户数据采集系统设计实践

随着移动互联网的兴起，特别是近年来，智能手机、pad等移动设备凭借便捷、高效的特点风靡全球，同时各类APP的快速发展进一步降低了移动互联网的接入门槛，越来越多的网民开始从传统PC转移至移动终端上。但传统的基于PC网站和访问日志的用户数据采集系统已经无法满足实时分析用户行为、实时统计流量属性和基于位置服务（LBS）等方面的需求。

我们针对传统用户数据采集系统在实时性、吞吐量、终端覆盖率等方面的不足，分析了在移动互联网流量剧增的背景下，用户数据采集系统的需求，研究在多种访问终端和多种网络类型的场景下，用户数据实时、高效采集的方法，并在此基础上设计和实现实时、有序和健壮的用户数据采集系统。此系统基于Java NIO网络通信框架（Netty）和分布式消息队列（Kafka）存储框架实现，其具有实时性、高吞吐、通用性好等优点。

1、技术选型和设计方案：

一个典型的数据采集分析统计平台，对数据的处理，主要由如下五个步骤组成：

图1、数据平台处理流程

其中，数据采集步骤是最核心的问题，数据采集是否丰富、准确和实时，都直接影响整个数据分析平台的应用的效果。本论文关注的步骤主要在数据采集、数据传输和数据建模存储这三部分。

为满足数据采集服务实时、高效性、高吞吐量和安全性等方面的要求，同时能借鉴互联网大数据行业一些优秀开源的解决方案，所以整个系统都将基于Java技术栈进行设计和实现。整个数据采集分析平台系统架构如下图所示：

图2（数据采集分析平台系统架构）

其中整个平台系统主要包括以上五部分：客户端数据采集SDK以Http(s)/Tcp/Udp协议根据不同的网络环境按一定策略将数据发送到Mechanic(UBT-Collector)服务器。服务器对采集的数据进行一系列处理之后将数据异步写入Hermes(Kafka)分布式消息队列系统。为了关联业务服务端用户业务操作埋点、日志，业务服务器需要获取由客户端SDK统一生成的用户标识（C-GUID），然后业务服务器将用户业务操作埋点、日志信息以异步方式写入Hermes(Kafka)队列。最后数据消费分析平台，都从Hermes(Kafka)中消费采集数据，进行数据实时或者离线分析。其中Mechanic(UBT-Collector)系统还包括对采集数据和自身系统的监控，这些监控信息先写入Hbase集群，然后通过Dashboard界面进行实时监控。

（1）基于NIO的Netty网络框架方案

要满足前面提到的高吞吐、高并发和多协议支持等方面的要求。我们调研了几种开源异步IO网络服务组件（如Netty、MINI、xSocket），用它们和NginxWeb服务器进行了性能对比，决定采用Netty作为采集服务网络组件。下面对它进行一些概要介绍：Netty是一个高性能、异步事件驱动的NIO框架，它提供了对TCP、UDP和文件传输的支持，Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便的主动获取或者通过通知机制获得IO操作结果。

图3（Netty框架内部组件逻辑结构）

Netty的优点有：

a、功能丰富，内置了多种数据编解码功能、支持多种网络协议。

b、高性能，通过与其它主流NIO网络框架对比，它的综合性能最佳。

c、可扩展性好，可通过它提供的ChannelHandler组件对网络通信方面进行灵活扩展。

d、易用性，API使用简单。

e、经过了许多商业应用的考验，在互联网、网络游戏、大数据、电信软件等众多行业得到成功商用。

Netty采用了典型的三层网络架构进行设计，逻辑架构图如下：

图4（Netty三层网络逻辑架构）

第一层：Reactor通信调度层。该层的主要职责就是监听网络的连接和读写操作，负责将网络层的数据读取到内存缓冲区中，然后触发各种网络事件，例如连接创建、连接激活、读事件、写事件等，将这些事件触发到Pipeline中，再由Pipeline充当的职责链来进行后续的处理。

第二层：职责链Pipeline层。负责事件在职责链中有序的向前（后）传播，同时负责动态的编排职责链。Pipeline可以选择监听和处理自己关心的事件。

第三层：业务逻辑处理层，一般可分为两类：a. 纯粹的业务逻辑处理，例如日志、订单处理。b. 应用层协议管理，例如HTTP(S)协议、FTP协议等。

我们都知道影响网络服务通信性能的主要因素有：网络I/O模型、线程（进程）调度模型和数据序列化方式。

在网络I/O模型方面，Netty采用基于非阻塞I/O的实现，底层依赖的是JDKNIO框架的Selector。

在线程调度模型方面，Netty采用Reactor线程模型。常用的Reactor线程模型有三种，分别是：

a、Reactor单线程模型：Reactor单线程模型，指的是所有的I/O操作都在同一个NIO线程上面完成。对于一些小容量应用场景，可以使用单线程模型。

b、Reactor多线程模型：Rector多线程模型与单线程模型最大的区别就是有一组NIO线程处理I/O操作。主要用于高并发、大业务量场景。

c、主从Reactor多线程模型：主从Reactor线程模型的特点是服务端用于接收客户端连接的不再是一个单独的NIO线程，而是一个独立的NIO线程池。利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。Netty线程模型并非固定不变的，它可以支持三种Reactor线程模型。

在数据序列化方面，影响序列化性能的主要因素有：

a、序列化后的码流大小（网络带宽占用）。

b、序列化和反序列化操作的性能（CPU资源占用）。

c、并发调用时的性能表现：稳定性、线性增长等。

Netty默认提供了对GoogleProtobuf二进制序列化框架的支持，但通过扩展Netty的编解码接口，可以实现其它的高性能序列化框架，例如Avro、Thrift的压缩二进制编解码框架。

通过对Netty网络框架的分析研究以及对比测试（见后面的可行性分析测试报告）可判断，基于Netty的数据采集方案能解决高数据吞吐量和数据实时收集的难点。

》》点击阅读全文

在数字经济时代，未来每个企业都可能是数字企业。数字企业则必须有自己完整的大数据体系。上期小编邀请数据大牛为大家解析了大数据底层架构（资深数据大牛深度解析：大数据底层架构！），而今天我们介绍的，便是每个企业大数据体系中最基础和最根本的部分——数据采集。

数据采集是一切有效分析的前提。如：数据接入；数据传输；数据建模／存储；数据查询；数据可视化等。总体上可以将企业大数据体系分成：

采集与存储平台：主要职责是对企业的相关大数据进行收集，并将收集到的数据进行存储。以便与企业管理及运用，同时也是未来数字企业的最重要资产之一。

分析与挖掘平台：主要职责是对企业采集到的数据进行专门的分析、BI等，以及在此基础上进一步的数据挖掘、人工智能等。

洞察与决策平台：主要职责是利用大数据分析的结果，通过自动加人工双重决策，更高效的运用到产品，业务，商业等环节以及相应的行动等。

覆盖全局数据安全平台：主要职责是负责确保数据的安全性，保证企业的数据资产不受到损害，例如数据不丢失、不损坏、不被窃、不被改等。

数据采集与存储平台将占据非常重要的位置。将来自各种数据源的原始大数据采集、分析、存储等。通常中小企业也可以不用自己拥有专门的大数据分析与挖掘平台，选择与相对专业的企业合作。

面对来源各异、以结构化/半结构化为主的数据，拍拍信使用linkedin开源的camus来采集消息类数据，使用kettle来采集RMDB的数据，具有以下优势：

1提高采集效率，降低工程成本；

2支持Web、iOS、Android、HTML等多种平台；

3采集全面属性、维度、指标等，使数据资源更优质；

4建立预测模型，实时智能监控、分析、预测用户行为；

5支持代码埋点，和全（无）埋点，按需选择，灵活运用。

采集方案：客户端（前端）；服务器日志；业务数据库；历史数据；第三方数据等。

数据采集与存储平台一般也可以分为三个层次，即数据采集层、预处理层和存储层。同时，大数据采集平台还需要一个覆盖全局的数据安全体系。

采集层负责采集企业各种来源的大数据；预处理层负责对采集回来的数据进行一些规范化的处理；存储层则是将预处理后的大数据进行存储，将企业大数据资产用一种方式保存起来。数据安全体系即数据安全平台。值得注意的是，当存储技术足够好、存储设备成本足够低容量足够大时，预处理层或可以选择忽略。

本期对大数据采集的分享就到这里啦，欢迎大家联系探讨。

（小编的鸡腿就靠各位老板啦(づ￣ 3￣)づ）

感谢您对拍拍信的认可与支持

我们一直在路上

尽管“大数据”一词近年来屡遭热捧

但很多人都还不知道什么是大数据

更不知道大数据有甚卵用

这两年，发现“大数据”这个词出现的越来越频繁了

不仅企业，连国家都在部署大数据战略

一番百度了之后

Oh~ emmmmmmmmm~ +_+

还是没搞懂大数据到底是个什么玩意儿

直到有一天

我发现一个秘密

不管我在网上搜索什么

页面都会跳出我要搜索的相关产品或关联事物

然后，我恍然大悟！

所谓大数据，就是算法！

它能够“算”出我们“心中所想”

那么问题来了

大数据技术是如何采集到我们的信息的呢？

数据采集，又称数据获取，是利用一种装置，从系统外部采集数据并输入到系统内部的一个接口。在互联网行业快速发展的今天，数据采集已经被广泛应用于互联网及分布式领域，比如摄像头，麦克风，都是数据采集工具。

数据采集系统整合了信号、传感器、激励器、信号调理、数据采集设备和应用软件。在数据大爆炸的互联网时代，数据的类型也是复杂多样的，包括结构化数据、半结构化数据、非结构化数据。结构化最常见，就是具有模式的数据。非结构化数据是数据结构不规则或不完整，没有预定义的数据模型，包括所有格式的办公文档、文本、图片、XML, HTML、各类报表、图像和音频/视频信息等等。大数据采集，是大数据分析的入口，所以是相当重要的一个环节。

我们首先来了解一下数据采集的三大要点：

一、数据采集的三大要点

（1）全面性

数据量足够具有分析价值、数据面足够支撑分析需求。

比如对于“查看商品详情”这一行为，需要采集用户触发时的环境信息、会话、以及背后的用户id，最后需要统计这一行为在某一时段触发的人数、次数、人均次数、活跃比等。

（2）多维性

数据更重要的是能满足分析需求。灵活、快速自定义数据的多种属性和不同类型，从而满足不同的分析目标。

比如“查看商品详情”这一行为，通过埋点，我们才能知道用户查看的商品是什么、价格、类型、商品id等多个属性。从而知道用户看过哪些商品、什么类型的商品被查看的多、某一个商品被查看了多少次。而不仅仅是知道用户进入了商品详情页。

（3）高效性

高效性包含技术执行的高效性、团队内部成员协同的高效性以及数据分析需求和目标实现的高效性。也就是说采集数据一定要明确采集目的，带着问题搜集信息，使信息采集更高效、更有针对性。此外，还要考虑数据的及时性。

不同应用领域的大数据其特点、数据量、用户群体均不相同。不同领域根据数据源的物理性质及数据分析的目标采取不同的数据采集方法。

那么，接下来我们再来了解一下常用的数据采集的方法。

常用的数据采集方法归结为以下三类：传感器、日志文件、网络爬虫。

（1）传感器

传感器通常用于测量物理变量，一般包括声音、温湿度、距离、电流等，将测量值转化为数字信号，传送到数据采集点，让物体有了触觉、味觉和嗅觉等感官，让物体慢慢变得活了起来。

（2）系统日志采集方法

日志文件数据一般由数据源系统产生，用于记录数据源的执行的各种操作活动，比如网络监控的流量管理、金融应用的股票记账和 web 服务器记录的用户访问行为。

很多互联网企业都有自己的海量数据采集工具，多用于系统日志采集，如Hadoop的Chukwa，Cloudera的Flume，Facebook的Scribe等，这些工具均采用分布式架构，能满足每秒数百MB的日志数据采集和传输需求。

（3）Web 爬虫

网络爬虫是指为搜索引擎下载并存储网页的程序，它是搜索引擎和 web 缓存的主要的数据采集方式。通过网络爬虫或网站公开API等方式从网站上获取数据信息。该方法可以将非结构化数据从网页中抽取出来，将其存储为统一的本地数据文件，并以结构化的方式存储。它支持图片、音频、视频等文件或附件的采集，附件与正文可以自动关联。

此外，对于企业生产经营数据上的客户数据，财务数据等保密性要求较高的数据，可以通过与数据技术服务商合作，使用特定系统接口等相关方式采集数据。比如八度云计算的数企BDSaaS，无论是数据采集技术、BI数据分析，还是数据的安全性和保密性，都做的很好。

数据的采集是挖掘数据价值的第一步，当数据量越来越大时，可提取出来的有用数据必然也就更多。只要善用数据化处理平台，便能够保证数据分析结果的有效性，助力企业实现数据驱动。