2.同时存储的技术的发展，也让我们面对不同的业务和分析场景，能够有最适合的数据存储方案。例如ES，Hbase，hive等。同时分析人员能通过海量的数据和高性能的计算引擎，不仅限于传统的BI报表。我们能够有机会去挖掘数据内的关联性以及通过ML技术，在海量数据中挖掘出来数据的关联性甚至对趋势进行预测指导业务的开展。或者搜索技术能够在海量数据中。

数据采集需要做的就是在第一个阶段中，为后续的分析人员提供高质量和高效的数据。对应不同的应用场景，能够满足不同场景的需求。而且我们要做的可能不仅仅是把数据原封不动的从一个地方搬运到大数据存储，在数据转换和加载的过程中，需要我们将数据进行部分清理和筛选以及数据规范化的工作，为后续的分析人员提供更加精确和清晰的数据。

首先来看一个传统行业内也是现在铁路行业内最常用的数据分析场景。现在大多数应用还是基于传统的管理信息系统内，可能伴随着数据量的增长，我们需要采购一些常规的数据仓库工具来进行业务分析，再经过一次ETL生成一些相对建议的BI报表，更多的是指统计分析报表，对数据通过清洗转换生成部分统计数据。

有了这些海量的数据存储作为基础，通过大数据技术对计算能力的大幅提升，我们也能针对海量的数据中挖掘分析出我们需要的信息，比如运用机器学习算法对于大量的样本采样，分析出数据中蕴含的关联性，search，只能BI。

数据采集其实就是为后面的分析人员提供高质量和有保障的数据，对应不同的应用场景，能够满足不同场景的需求。而且我们要做的可能不仅仅是把数据原封不动的从一个地方搬运到大数据存储，在数据转换和加载的过程中，需要我们将数据进行部分清理和筛选以及数据规范化的工作，为后续的分析人员提供更加精确和清晰的数据。而且我们要做的可能不仅仅是把数据原封不动的从一个地方搬运到大数据存储，在数据转换和加载的过程中，需要我们将数据进行部分清理和筛选以及数据规范化的工作，为后续的分析人员提供更加精确和清晰的数据。

—————————————————————————————————

ETL数据采集，主要是从各种系统里面用不同的语言和方法抓数据，以满足各种商业场景需求。简单来说，如果把数据分析类比成做菜，ETL相当于备菜。备菜不是个容易的事，首先，你要熟悉做这道菜的原料，比如，鸡丁，花生，葱，姜，辣椒等。哪里买，怎么运输过来。其次，你要会用刀，砧板，碗等工具和器材来处理这些食材。再次，你要知道鸡丁切多大，葱花多碎等。最后，把所有准备好的材料递给主厨即可。所以我们可以看到ETL也就是对数据的抽取转换加载在数据分析钟是十分重要的过程，他的数据质量能够直接影响后面分析人员得出的结论。

以前我们定义的数据分析流程如上图所示，把业务系统应用（特别是大量管理信息系统中的数据）他们的数据存储都依赖于传统的RDBMS也就是关系型数据库，通过ETL过程，所谓的ETL过程也就是对数据进行抽取，转换，加载到传统意义上的数据仓库中（taradata数仓一体机，oracle一体机中），再从传统数仓中通过ETL过程，或者通过进行一些比较成熟的统计方法，生成BI报表（Excel表格，初步的可视化图表等等）

大数据时代到来，数据分析的手段和工具，方法也与日俱增。同时，系统应用也越来越多，与此同时，很多不同于传统管理信息系统的应用与日俱增，里面包括了大访问量下的大量的系统日志，比如12306一天的售票量和点击量，在卖出巨大数量级的火车票的同时，也会生成巨大的系统和用户访问日志。同时设备信息也可以通过现在的手段进行监测和实时的观察，并通过流式数据的方式加载到适用于各个场景的不同数据存储工具内，并通过更加成熟，先进的手段进行数据分析，不仅仅生成多维度统计的BI统计报表，或者通过机器学习的算法分析挖掘出更多数据中蕴藏的规则和信息。

1.传统ETL 数据源有限，数据仓库单一，生成传统BI报表

2.现阶段，数据源种类的多样化，数据存储越来越多，不仅仅生成BI报表，同时包括海量数据的检索，数据分析，BI报表，各式应用。

1.2 组件特点

在数据分析过程中，我们会发现其实相比起数据分析，数据的ETL往往是更加消费精力和工作量的过程。以往的经验中，在ETL过程，对于分析人员并不友好，传统针对大数据平台的ETL过程，更多需要开发人员通过Python脚本、或者通过DIY代码根据每个业务场景和分析场景的需求来进行数据的抽取，清洗以及导入。但往往需要伴随大量的代码工作，而且需要开发人员来进行，但是这些可能不是最后对数据进行分析的人员，所以不能很好的把握对数据的ETL要求，提供什么样的数据给分析人员进行分析工作。同时需要大量的时间投入，导致可能分析到的数据已经失去了现在这个时刻的意义导致错误的结论。

同时，为了解决这些问题，apache摄取同时也提供了一些简易的工具进行数据的加载，比如sqoop，或者有人采用kettle进行数据加载。但是存在的问题就是工具虽然简化了ETL流程，但是数据的质量无法得到监控和保证，很多脏数据的采集也可能导致分析结果的失准。

1.简单易用-不需要写代码即可实现数据的采集，数据的过滤，数据的储存

2.保证数据的质量-可以实时对数据传输的过程进行更多的自定义功能和结果的监控

3.数据的完整性-可以实时监控错误的数据的数量

拖拽方式实现数据采集

可视化拖拽方式实现数据采集流程的设计、管理

内置组件丰富，支持结构化数据半结构化、非结构化数据的采集

支持实时流数据采集

1.3 数据接入组件

是一个轻量级，功能强大的数据采集引擎，最大程度简化了数据采集的过程，能过通过最简单的托拉拽的方式进行数据的采集，流转，加载。完成数据采集和清洗的要求。

上百个不同组件的支持，最大程度的覆盖了各类业务场景的需求。

采集数据的流程进行实时的监控和管理，并且会自动侦测到不符合配置规则的数据，并将错误信息实时输出。

配合平台集成和整合的完整的数据和用户安全机制和数据隔离，保证了数据传输的安全性，解决数据安全性问题。每个用户拥有独立的大数据平台连接串和存储区域。

可以实时侦测增量数据，对新增的数据，不用修改任何配置可以实现自动抓取和探测。或者定义采集规则定期进行抽取工作。

2 数据采集管道介绍

2.1 管道特点

可以看见他比较像是一个工作流，由一个个不同的节点和连线连接而成，组成了几条有序的通路，数据会通过这个通路按顺序进行有序的流转。每一个节点和组件也代表了对数据进行的一次读写或者操作。这样的一流程构成了一条数据采集的管道。以后我们定义的每一个数据采集任务，比如把某个mysql/orcale表读取到大数据平台的这个采集任务就是通过这个管道完成的整个任务。

为什么要叫他采集管道：它不同于我们平时配置一个sqoop任务，它更像是一个流转的通道，在这个通道中进行数据的传输和流转，比如石油管道，从一个矿井到一个炼油厂。这里我们定义的数据源就像像是一个石油矿井，同样我们把需要进行分析处理的数据作为起始点，经过管道的传输和流转，也就是类似中间步骤的操作，我们将不同种类的油种送到不同的炼油厂，也就是把不同业务需要的数据加载到各个不同的目的地，让分析人员进行数据分析和挖掘。

简单易用，不需要代码

2.2 数据源，处理器，目标源介绍

数据源：特点，只有右侧的输出没有输入，也就是上面说的是数据的起始位置，他将我们需要采集的数据从不同类型的数据源中抽取出来，并将数据输出传递给后面的节点

处理器：特点，左侧节点为数据的输入，右侧节点为数据输出，主要进行对输入数据的处理或者分流或者计算也就是ETL过程中Tansform的过程。规范化或者流转数据。

目标源：特点，只有左侧的数据输入，没有数据输出。代表是采集管道的终点。代表我们数据最终流转到的位置，也就是最终对抽取处理后的数据加载到的位置。

2.3 常用数据源组件

同时数据采集组件也提供了一共23种不同的数据源。

我在这里大致归了类有如下几种类型：Kafka 流式数据，消息队列内的数据，进行抽取

2.4 常用处理器组件

同时数据采集组件也提供了一共43种不同的处理器来对读入的数据进行处理。这里大致介绍一下现在拥有的处理器组件。

1.字段操作的组件

2.对数据进行稍微复杂处理的组件

2.5 常用目标源组件

目标源：上面介绍过的最终加载的目的地。支持16种不同目标源

大数据存储：离线分析业务到hive数仓，流式数据采集到Kafka，进行高并发高效的查询场景Hbase，HDFS存储，Flume、MonoDB

JDBC，本地文件系统，HTTP请求。

3 任务管道介绍

3.1详情的任务管道

3.2 创建采集任务

例如，我们有这样一个需求，将现有系统中mysql数据库中的某个数据表的数据采集到大数据平台进行分析。我们首先需要一个jdbc类型的数据源，通过右侧区域筛选到JDBC的数据源，拖动到中间的画布区域。会发现有很多叹号出现，这里也就是提示我们需要配置JDBC连接的字符串，以及需要的SQL语句来抓取数据，以及配置连接数据库的用户名密码等等。

3.3 运行任务详细信息

往后我们会通过一个案例demo来现在大概介绍一下上面提到的数据预览功能，在这之前我们先了解一下数据预览的功能。在我们配置完或者并没有配置完，需要检测一下数据的流转以及配置是否正确，可以通过点击上面菜单栏的小眼睛按钮，对部分抽出的样例数据进行初步的跟踪和查看，类似开发过程中的debug功能。首先看看是否有工具检查到的配置报错，有报错会有提示信息，其次，可以通过查看数据的流入和流出，审查数据是否以正确的方式进行了流转和传递。

这里有部分的购票数据，我们需要把支付的银行卡号转化成不同的卡种：VISA或者master，以便以后人员的统计和分析，这里我们使用了一个Jython 脚本进行了卡号的变换，并把计算出的卡种类写入到credit-card-type字段中。点击预览按钮，点击到这一个节点。我们可以看见左侧就是流入的数据，右侧是输出的数据。

同时，我们不仅仅可以对一个组件的数据处理进行预览和检测，同时，可以选择两个不同的组件查看这段区域的数据流转状况。同样的案例，在售票数据中，有部分不是采用银行卡支付的数据，我们需要把这部分数据过滤掉，在中间通过一个流选择器，把由信用卡支付产生的数据从出口1输出给上放的处理业务，进行转换和存储，把非银行卡支付的数据删除，以免影响后面业务的分析。这里我们点选数据源和垃圾箱这两个节点，我们可以看见绿色是现在观测数据流转的起始位置，红色为终止位置。同时，在下方我们可以看见前三行数据都是银行卡支付，所以后面的红色区域无数据输入，下面的两行数据，为非银行卡支付的数据，通过流转指向了输出2，并输出给了垃圾箱这个目标源。

对于配置好而且确认无误的采集管道，点击开始按钮执行任务，可以看见数据采集