文章目录
-
- 第一章 大数据概述
-
-
- 1.1 进入大数据时代的原因
- 1.2 大数据概念
- 1.3 大数据应用
-
- 第二章 大数据采集基础
-
-
- 2.1 传统数据采集技术
- 2.2 大数据采集基础
-
-
- 2.2.1数据的发展
- 2.2.3大数据采集技术
-
-
- 第三章 大数据采集架构
-
-
- 3.1 概述
- 3.2 Chukwa数据采集
- 3.3 Flume数据采集
- 3.4 Scribe数据采集
- 3.5 Kafka数据采集
-
-
- 3.5.1 概念理解
- 3.5.2 消息队列通信模型
- 3.5.3 kafka的架构原理
-
- 3.6 小结
-
- 第四章 大数据迁移技术
-
-
- 4.1数据迁移
- 4.2 数据迁移相关技术
- 4.3 数据迁移工具
- 4.4 Kettle数据迁移实例
-
- 第五章 互联 数据抓取与处理
-
-
- 5.1 络爬虫概述
- 5.2 络爬虫
- 5.3 络爬虫的抓取策略
- 5.4 页更新策略
- 5.5 络爬虫方法
- 5.6 络爬虫工具
-
2.1 传统数据采集技术
-
数据采集:将要获取的信息通过传感器转换为信 ,并经过对信 的调整,采样,量化,编码和传输等步骤,最后送到计算机系统中进行处理,分析,存储和显示
-
传统数据采集系统特点
1.数据采集系统一般都包含有计算机系统,这使得数据采集的质量和效率等大为提高,同时节省了硬件投资。
2.软件在数据采集系统中的作用越来越大,增加了系统设计的灵活性。
3.数据采集与数据处理相互结合得日益紧密,形成了数据采集与处理相互融合的系统,可实现从数据采集、处理到控制的全部工作。
4.速度快,数据采集过程一般都具有“实时”特性。
5.随着微电子技术的发展,电路集成度的提高,数据采集系统的体积越来越小,可靠性越来越高。
6.出现了很多先进的采集技术,比如总线采集技术、分布式采集技术等。 -
数据采集系统框架
第三章 大数据采集架构
3.1 概述
数据采集的方式多种多样,如通过卫星摄像机和传感器等硬件设备进行遥感数据、交通数据、人流数据的采集;通过半自动整理的方式采集商业景气数据、税务数据、人口普查数据等;通过互联 服务器自动采集业务数据、用户行为数据等等。
大型的互联 公司、金融行业、零售行业、医疗行业等都有自己的业务平台,在此平台上,每天都会产生大量的系统日志数据。
通过采集系统日志数据,可以获得大量数据。(属于半结构化数据,也可转化为结构化数据–二维表)
常用大数据采集架构:
- Hadoop的Chukwa:Chukwa是一个开源的用于监控大型分布式系统的数据收集系统。这是构建在Hadoop 的 HDFS 和 map/reduce 框架之上的,继承了Hadoop 的可伸缩性和鲁棒性。
- Cloudera的Flume:Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。*
- Facebook的Scribe:Scribe是Facebook开源的日志收集系统,在Facebook内部已经得到大量的应用。
- Apache Kafka:是由Apache开发的一个开源消息系统项目。它是一个分布式的、分区的、多副本的日志提交服务。
- Collectors
Agents 采集到的数据存储到Hadoop 集群上。Hadoop 集群擅长处理少量大文件,而对于大量小文件的处理则不是它的强项,针对这一点,Chukwa 设计了Collector
Collector 用于把数据先进行部分合并,再写入集群,防止大量小文件的写入
为防止 Collector 成为性能瓶颈或成为单点产生故障, Chukwa 允许和鼓励设置多个Collector
Agents 随机地从Collectors 列表中选择一个Collector 传输数据,如果一个 Collector 失败或繁忙,就换下一个Collector,从而可以实现负载的均衡 - Demux 和 Archive
Chukwa架构中放在集群上的数据是通过 map/reduce 作业来实现数据分析,在 map/reduce 阶段,Chukwa 提供了Demux 和Archive 任务两种内置的作业类型
Demux 作业负责对数据的分类、排序和去重
Demux 作业在执行过程中,通过数据类型和配置文件中指定的数据处理类,执行相应的数据分析工作,一般是把非结构化的数据结构化,抽取中其中的数据属性。
Demux 的本质是一个 map/reduce 作业,所以可以根据自己的需求制定自己的 Demux 作业,进行各种复杂的逻辑分析
Chukwa 提供的 Demux interface 可以用 java 语言来方便地扩展。
Archive 作业则负责把同类型的数据文件合并,一方面保证了同一类的数据都在一起,便于进一步分析, 另一方面减少文件数量, 减轻Hadoop 集群的存储压力 - dbadmin
主要用于数据存储
Chukwa使用 mdl 语言,把集群上的数据抽取到 mysql 数据库中,对近一周的数据,完整保存,超过一周的数据,按数据离当前时间长短作稀释,离当前越久的数据,所保存的数据时间间隔越长
通过 mysql 来作数据源,展示数据。同时使用 hbase 或类似的技术,直接把索引化的数据存储在集群上。 - HICC
主要用于数据展示
HICC 是 Chukwa 提供的数据展示端
在展示端,Chukwa 提供了一些默认的数据展示 widget,可以使用“列表”、“曲线图”、“多曲线图”、“柱状图”、“面积图式展示一类或多类数据,给用户直观的数据趋势展示
在 HICC 展示端,对不断生成的新数据和历史数据,采用robin 策略,防止数据的不断增长增大服务器压力,并对数据在时间轴上“稀释”,可以提供长时间段的数据展示。
从本质上, HICC 是用 jetty 来实现的一个 web 服务端,内部用的是jsp 技术和 javascript 技术 - Hadoop大数据业务处理流程:Flume数据采集–MapReduce清洗–存入Hbase–Hive统计分析–存入Hive表–Sqoop导出–Mysql数据库–Web展示
- Topics
Topics是消息的分类名
Broker为每一个Topic维护一个分区日志。每一个分区日志都是有序的消息序列,消息是连续追加到分区日志上,并且这些消息是不可更改的。
分区中的每条消息都会被分配顺序ID ,也称为偏移量,是其在该分区中的唯一标识。
一个topics可以有多个分区,这些分区可以作为并行处理单元,从而使Kafka有能力高效地处理大量数据。
Topics消息会被均匀的分布到Partition0、Partition1和Partition2分区日志中
每个Partition中的消息都是有序的
生产的消息被不断追加到Partition log上,其中的每一个消息都被赋予了一个唯一的offset(偏移)值。 - Producers—-消息的生产者(消息的入口)
Producers是向它们选择的主题发布数据。生产者可以选择分配某个主题到哪个分区上。
Producers直接发送消息到Broker上的leader partition,不需要经过任何中介一系列的路由转发。
Producer客户端自己控制着消息被推送到哪些Partition。实现的方式可以是随机分配、实现一类随机负载均衡算法或者指定一些分区算法。
Kafka Producer 可以将消息在内存中累计到一定数量后作为一个batch发送请求。Batch的数量大小可以通过Producer的参数控制,参数值可以设置为累计的消息的数量(如500条)、累计的时间间隔(如100ms)或者累计的数据大小(64KB)。
Producers可以异步、并行的向Kafka发送消息,但是通常producer在发送完消息之后会得到一个future响应,返回的是offset值或者发送过程中遇到的错误 - Consumers—消息的消费者(消息的出口)
Kafka提供一种单独的消费者抽象,此抽象具有两种模式的特征消费组:Queuing 和Publish-SubScribe。
消费者使用相同的消费组名字来标识,每个主题的每条消息都会发送到某个consumers实例,这些实例所在的消费者需要提出订阅,才能获得消息。
Kafka支持以组的形式消费Topic,如果Consumers有同一个组名,那么Kafka就相当于一个队列消息服务,而各个Consumer均衡的消费相应Partition中的数据。
若Consumers有不同的组名,那么Kafka就相当与一个广播服务,它会把Topic中的所有消息广播到每个Consumer。 - push-and-pull
Kafka的发布和订阅消息过程中,Producer 到 Broker 的过程是 push,也就是有数据就推送到 Broker;而 Consumer 到 Broker 的过程是 pull。它是通过 consumer 主动取数据的,而不是 Broker 把数据主动发送到 consumer 端的。
从图可以看出,Kafka采用了push-and-pull消息传输机制。这种机制中,Broker决定了消息推送的速率,而Consumer可以自主决定是否批量的从Broker接受数据。 - Apache Zookeeper
Apache Zookeeper是Apache Hadoop的一个子项目,作为一种分布式服务框架,提供协调和同步分布式系统各节点的资源配置等服务,是分布式系统一致性服务的软件。Apache Kafka主要是利用Zookeeper解决分布式应用中遇到的数据管理问题,比如,名称服务、状态同步服务、集群管理、分布式应用配置项的管理等。 - kettle的两种设计
Transformation(转换):完成针对数据的基础转换。
Job(作业):完成整个工作流的控制。
作业是步骤流,转换是数据流。这是作业和转换最大的区别。
作业的每一个步骤,必须等到前面的步骤都跑完了,后面的步骤才会执行;而转换会一次性把所有空间全部先启动(一个控件对应启动一个线程),然后数据流会从第一个控件开始,一条记录、一条记录地流向最后的控件。
3.3 Flume数据采集
注意:
为保证Flume的可靠性,Flume在Source和Channel之间采用 Interceptors拦截器用来更改或者检查Flume的events数据。
在多channel情况下,Flume可以采用默认管道选择器(即,每一个管道传递的都是相同的events)或者多路复用通道选择器(即,依据每一个event的头部header的地址选择管道)实现 channel的选择。
为了保证负载均衡,采用sink线程用于激活被选择的sinks群中特定的sink。
3.4 Scribe数据采集
1.生产者分为producer0,producer1,producer2。消费者以消费者组的形式存在,consumer0,consumer1在consumer GroupA里,consumer0,consumer1在consumer GroupB里面。kakfa集群里面存的以topic分类的消息。
2.producer0生产了一个以topicA分类的消息分别存在了partition0和partition1里(leader),broker0中存的partition0消息复制到了broker1和broker2(follower),同样broker1里存的partition2消息复制到了broker0和broker2中
3.在一个消费者组里的consumer0和consumer1分别消费broker0中的主消息和broker1中的主消息
数据抽取是从不同的数据源(不同物理环境和背景以及多样化的数据)中通过采用不同的方法抽取数据的一个过程。此外,可以通过使用机器学习方法对 页内容中半结构化的数据进行抽取。而对于非结构化数据,可通过一种模拟线性模型的模糊匹配方法进行处理;在实际的应用中,数据源通常为传统关系型数据库,数据抽取的方法大概包括全量抽取(数据迁移)、增量抽取(只抽取自上次抽取后传统关系型数据库的数据表中有变化的数据)
数据转换是从数据源中抽取获得的数据格式与目标数据格式可能存在不一致的情况。所以需要对抽取后的数据进行数据转换以及加工处理,包括数据的合并、汇总、过滤和转换,重新对数据进行格式化等过程。
数据清洗是指数据在加载到数据仓库之前,可能会存在一些问题数据,即“脏数据”,如不完整数据、错误数据和重复数据等,须进行数据清洗,这是一个不断反复的过程。对于数据清洗的研究,以及有比较丰富的数据清洗算法可供参考使用,相似重复数据监测与消除算法、DBMS的集成数据清理算法和增量数据清洗算法等层出不穷。
数据加载是将经过数据转换和数据清洗后的数据依照实际数据模型定义的表结构装载到目标库中。通常包含两种方式装载,一种是通过SQL语句进行直接的插入(insert)、删除(delete)和更新(Update)操作,另一种是采用批量装在方法,如bcp,bulk
4.4 Kettle数据迁移实例
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!