BigData NA

数据挖掘

• 想要做数据挖掘，我们首先需要做以下的几个步骤。

数据集成

• 将多个数据源或者是异构数据源的数据，在数据仓库本地进行整合。

数据清洗

• 对冲突的属性进行删减，对噪声数据进行剔除，进行离群点检测。

数据归约

• 比如，我們要計算年齡分段（0-100歲），分成少年，青年，中年，老年。

托管表和外部表

  在数据仓库中，我们往往要做数据集成工作，但是我们做数据集成工作就要收集数据，这样会导致数据仓库的容量紧张。
  为了解决该问题，我们提出了托管表和外部表的两个概念。
  所谓托管表，就是数据完全传输并且存储在数据仓库中。
  所谓外部表，就是数据没有存储在数据仓库中，数据仓库只是创建了一个表空间，里面存储的是数据实际存储位置的映射。

  那么在实际做相关的分析工作的时候，托管表的速度最快。

day 4

*******************************************
数据仓库：
数据仓库从广义上来讲，其实就可以理解成为是一个大型的数据库，但是这个大型的数据库和普通的数据库概念和作用上其实还是有很大的区别的。
首先从性能上来讲，数据仓库的性能往往是极大地优于数据库的。从数据角度来讲，数据仓库中的数据是数据库的集合，我们在进行数据分析和数据挖掘的时候，首先先要做数据的获取操作。数据仓库从多个数据源获取数据，也就相当于是从多个数据库获取数据。数据被集成到数据仓库中。
一般来讲，数据库是面向于业务的，一般只有在业务场景才会进行使用（Hbase除外），而数据仓库一般是面向于分析的，所以数据库是OLTP型业务，数据仓库是OLAP型业务。数据库由于其面向于业务，所以其中的数据往往都是最新的。而数据仓库从数据库获取数据，用于自身分析，它的数据一般都是历史的。
数据库一般面向于行存，数据仓库一般面向于列存。
数据仓库可以产生数据集市，而数据库只能产生子表。
假设一家公司的所有数据都被导入到一个数据仓库中，我们可以在这个数据仓库中分出一部分的数据，创建一个新的表，或者是虚拟表，这个时候创建出的新的库文件，就是数据集市。比如，公司的所有数据叫做 数据仓库。而财务对应的数据，就是数据集市。

***************************************
数据挖掘：
想要做数据挖掘，我们首先需要做以下的几个步骤：
数据集成：将多个数据源或者是异构数据源的数据，在数据仓库本地进行整合
数据清洗：对冲突的属性进行删减，对噪声数据进行剔除，进行离群点检测。
数据归约：比如，我们要计算年龄对购买力的影响，那么年龄我们一般设定为0-100，这样就需要计算100次，为了减小计算的次数，节省计算的时间，我们一般会将0-100岁分段成，少年，青年，中年，老年

**************************************
托管表和外部表
在数据仓库中，我们往往要做数据集成工作，但是我们做数据集成工作就要收集数据，这样会导致数据仓库的容量紧张。
所以为了解决该问题，我们提出了托管表和外部表两个概念。
所谓托管表，就是数据完全传输并且存储在数据仓库中
所谓外部表，就是数据没有存在数据仓库中，数据仓库只创建了一个表空间，里面存储的是数据实际存储位置的映射。

那么在实际做相关的分析工作的时候，托管表的速度最快，但是最消耗存储空间，外部表由于需要从远端读取数据，所以速度会慢，但是由于本地只存储了映射，所以消耗存储空间少。

*************************************
streaming
streaming是基于开源的Storm创建的一个新的组件，Streaming的核心特点就是其具有实时性，数据到达Streaming之后，就会马上执行相关的计算操作。而且和以往的组件不同的是，Streaming是对数据先行做的计算，而不是先进行存储操作。

Streaming架构：
（1）Topology：可以理解成为MR或者Spark中的Application，其中包含了任务的执行逻辑方法，以及相关的处理方式。对于传统的Application，也就是MR或Spark中的应用，我们在提交对数据的处理逻辑的时候，必须要同时提交文件的位置，而且文件必须在HDFS或者Hbase或HIVE中，而Streaming其只需要提交对数据的处理逻辑，实际的数据是托管给其他的组件来进行导入的。由于Streaming处理的一般都是实时数据，那么数据往往是我们无法预先定义的，所以我们只能预先定义好处理框架，等待数据的引入，然后根据框架计算结果并反馈。
（2）Nimbus：含义同AppMaster，但是在MR中，AppMaster如果想要分配一个任务给Container，该任务直接分配给Container，但是在Streaming中，任务的下发是由Nimbus先行给zookeeper，然后由Zookeeper转发。
（3）supervisor：含义同NodeManager，但是和NodeManager不同的是，NodeManager负责的是容器拉起，任务的下发，但是对其中任务的执行进度和执行情况，NodeManager不负责管理的。Supervisor除了下发任务以外，还需要对任务进行监控。
（4）Worker：架构等同于Container，但是Container是CPU和内存的封装体，Worker是一个物理进程，它是一个JVM进程，

所以：在实际的Streaming计算过程中，我们提交的topology是一个大的JVM进程，JVM被Nimbus拆分成多个子任务，然后每一个子任务都通过zookeeper下发到Supervisor上，Supervisor接收到该任务之后，会将该任务交给worker，然后worker会将子JVM进程。进一步拆分，拆分成为执行的task，每一个task都给executor计算。

（5）executor：task执行的容器，它仍然是一个CPU和内存的集成体。
（6）Spout：数据输入进程
（7）Blot：数据输出进程
（8）Zookeeper：分布式协调组件，在Streaming监控整个集群的资源使用率，相当于代理了RM中RS的工作，还负责了任务的下发，相当于代理了部分AppMaster或Driver的工作。

（9）task：task指的就是streaming中做的相关的操作，这些操作可能涉及到数据的输入输出或者是数据的计算，比如JVM的运行

（10）tuple：指的是Streaming每次收到的一个数据或一组数据。它是数据处理的基本单位
（11）stream：流，流是由多个连续tuple组成的一个带有顺序性的序列，其遵循先进先出的原则。执行输入计算和输出

Streaming执行流程：
1.用户提交topology给Client
2.Client收到请求之后，解压执行jar包，然后将topology发送给Nimbus。
3.Nimbus收到之后，会将JVM进程做分解，并且同时分配jobID，保证应用唯一性。
4.Nimbus将JVM进程中需要执行的操作的摘要信息发送给Zookeeper。摘要信息中主要包含的是任务的信息和jar包的名称
5.zookeeper根据集群的综合负载，下发任务给Supervisor。
6.Supervisor收到zookeeper下发的任务之后，会联系Nimbus下载对应的任务的jar包。
7.Supervisor会解压jar包，其中就包含了worker。
8.worker启动之后，会将执行的任务封装为task，然后要求Supervisor封装executor。然后将task下发到executor中执行。
9.executor完成之后，会将结果返回给worker，worker整合结果之后返回给Supervisor，然后返回给Nimbus，Nimbus整合结果，反馈给Client。
10.executor和worker会自我注销。（一般来说，Streaming都是下发计算方法，然后一直持续运行的，如果想要不进行计算，就必须人为手工关闭进程，这时候，executor和worker才会做自我注销操作。）
11.一旦在执行的过程中出现问题，由于本身executor需要周期性的上报心跳，所以一旦 executor出现问题，zookeeper就会及时获取，并且反馈信息给Supervisor，要求其重新启动worker或者是重新启动某一个task。
12.Supervisor一旦出现故障，那么Zookeeper会直接要求其他的Supervisor执行未执行 完成 的任务
13.Nimbus采用主备进程，一旦主Nimbus出现故障，我们可以进行及时的故障切换操作。

Nimbus的HA
Nimbus负责整个集群的资源监控和任务分配，那么一旦Nimbus出现故障，它不会像MR或Spark一样自动进行故障恢复，因为Streaming和Yarn之间是弱耦合的，所以streaming必须要保障自身的安全性。那么Streaming中的Nimbus就是通过主备进程来保证整体系统的安全性的。Nimbus分为了主备进程，平时只有主进程在执行操作，但是备进程不做工作，虽然备进程没有执行相关的操作，但是备进程也必须获取相关的任务执行信息和情况。保证在主出现故障的情况下，备可以完整的接管所有的任务，Nimbus是通过主备周期性的上报心跳信息给Zookeeper来保证整体的系统安全性的，一旦zookeeper没有收到Nimbus的 心跳就会认为Nimbus出现故障，然后就会联系备Nimbus提交故障切换的请求。

Streaming的节点失效。
一旦Streaming出现节点故障的情况，由于周期性的Worker会代理executor上传心跳信息，所有一旦Zookeeper没有收到worker发送的信息，就会认为整个worker出现了故障，那么如果worker中的信息有缺失，zookeeper就会认为worker中的某一个或某几个executor出现了故障。这个时候，zookeeper就会进行故障切换，将worker的JVM进程下发到其他的Supervisor上或者要求原Supervisor重启worker进程。

Streaming消息可靠性（what、why、how）
在Streaming中，消息可靠性是一种保证机制，主要是用于保证在计算的过程中对计算的准确性进行保证，Streaming本身要求的是低延迟处理，那么在这种情况下 ，我们还需要保证整体处理的准确。我们提出了3种方式来对数据的计算准确性进行保证。
最多一次：就是在整个数据输入到输出的阶段中，我们只需要进行最多一次准确性 确认。一般来说，做准确性确认需要消耗系统的相关资源。那么最多一次确认消耗的开销最小，这样的话就可以保证在海量 数据计算的情况下，尽可能多的节省资源
最少一次：就是在整个数据输入到输出的阶段中，我们必须至少指定一次准确性确认，一般来说，最少一次的确认机制，都不会等于1次的，那么这样的话，确认机制就会消耗比较多的 资源，那么计算可以消耗的资源 就会减少，那么计算处理的数据量一般就不会很大。
精确一次：精确一次就是通过程序调用API接口，进行精细化的确认，但是精细化的确认消耗的资源也是最大的。所以整体来说，精确一次的话，计算所能处理的资源也就最少。
                含义                      消耗的资源
最多一次            最多执行一次确认机制              最少
最少一次            至少执行一次确认机制              一般
精确一次            通过调用API接口，进行精细化确认       最多

由于本身Streaming在保障的主要是低延迟，所以用户在使用Streaming的时候，需要指定一个超时时间，一旦任务的执行超过了超时时间，那么我们就认为任务执行失败

ACK机制
ACK机制主要是用于保证数据准确性，那么首先数据会到达Spout，之后Spout会发送一个数据起始的信息给ACKer（ACker主要用于接收各个组件发送来的确认包，ack报文），之后acker会在本地建立一棵tuple tree，里面记录的是tuple从输入到输出整个流程中需要经历的各个进程。那么数据从spout到达bolt，每个Blot处理数据完成的时候，除了需要发送数据给下一级的Blot以外 ，还需要发送一个ack报文给acker，用于确认自身的数据处理完成。当acker发现自身tuple tree中所有的需要经历进程都已经收到ack报文的时候，就代表整个执行流程全部完成，那么这个时候acker就会给spout进程发送一个ack报文，标识整个处理流程正常结束，如果某一个blot进程在超时时间内没有发送报文给acker，acker就会认为blot处理失败，就会反馈一个任务失败信息给spout，报文发送通过调用ack()和fail()两个接口进行发送。

可靠性的机制关闭方法一共有以下三种
1.通过关闭acker的角色，使整个确认信息失效无法使用。
2.Spout在发送信息的时候，往往会携带messigeID，那么一旦被acker收到之后，就会通过该ID进行回复，那么第二种方法就是通过发送信息的时候不携带MessageID，那么acker就无法对确认信息进行回复。
3.第三种方案就是不构建tuple tree，那么对于 acker来说，它就认为数据从spout到达第一级bolt之后就已经完成了，之后就不会反馈ack了。