大数据技术基础学习笔记2

Flink为流处理和批处理分别提供了Stream API和Batch API，
正是这种高层的抽象极大便利了用户编写大数据应用。
Flink目前支持的主要的流的类型及其流之间的转换关系
DataStream: 是Flink 流处理API中最核心的数据结构，代表了一个运行在多个分区上的并行流
一个DataStream从StreamExecutionEnvironment通过env.addSource(SourceFunction）获得
DataStream上的转换操作是逐条的，map() flapmap() filter()
DataStream可以执行rebalance()再平衡，用来减轻数据倾斜和broadcasted（广播）等分区转换
KeyedStream：表示根据指定key进行分组的数据流。
一个keyedStream可以通调用DataStream.keyBy()来获得。
在KeyedStream流上进行任何的transformation都将变回DataStream。
在实现过程中是什么样的呢？
KeyedStream是把key信息写入到了transformation中。
每条记录只能访问所属key状态，在上的聚合函数可以方便操作和保存对应key状态
WindowedStream：WindowedStream带彪了根据key分组，
并且基于WindowAssigner切分窗口的数据流。
WindowedStream都是从KeyedStream衍生而来的。
在WindowedSream流上进行任何的transformation都将变回DataStream。
JoinedStreams：
CoGroupedStreams:
相同：两者代码实现有80%是一样的，
JoinedStreams在底层调用了CoGroupedStreams来实现Join功能
区别：
Co-group侧重的是group，是对同一个key上的两组集合进行操作
join侧重的pair，是对同一个key上的每对元素进行操作
cogroup比join更通用一些，join只是cogroup的一个特例，
所以join是可以基于cogroup来实现的。
cogroup接口之后提供join接口是因为用户更熟悉join（数据库），
而且能够跟DataSet API保持一致，降低用户学习成本
JoinedStreams和CoGroupedStreams是基于window上实现的，
所以CoGroupedStreams最终又调用了WindowedStream来实现

ConnectedStreams:
在DataStream上又一个union的转换
dataStream.union(otherStream1，otherStream2，otherStream3,…)
用来合并多个流，新的流会包含所有流中的数据。
union有一个限制，就是所有合并流的数据类型必须一致。
ConnectedStreams提供了和union类似的功能，用来链接两个流，但是二者有区别
区别：
（1）ConnectedStreams只能连接两个流，而union可以连接多个流
（2）ConnectedStreams连接两个流的类型可以不一致，而union连接的流的类型必须一致
（3）ConnectedStreams会对两个流的数据应用不同的处理方法，并且双流之间可以共享状态
第一个流的输入会影响第二个流时，会非常有用。

AllWindowStream

数据采集—数据存储------数据计算—数据分析----数据挖据–数据可视化

flume HDFS 离线计算 Hive Miner
kafka HBase 迭代计算
实时计算
批处理和流处理

zookeeper (HA)
HDFS：主NameNode 备NameNode
NameNode
DataNode
HBase:主HMaster 备HMaster
HMaster
HRegionServer

yarn的角色：
ResourceManager ：主 备
NodeManager
App Master

MapReduce on yarn ： 主ResourceManager 备ResourceManager
ResourceManager
NodeManager

Spark on yarn client： 主ResourceManager 备ResourceManager
Spark on yarn cluster： 主ResourceManager 备ResourceManager
ResourceManager
NodeManager
Storm：主Nimbus 备Nimbus
Nimbus
Supervisor
Flink：主JobManager 备JobManager
JobManager
taskManager

data-----informatioon------knowledge-----wisdom

sql hive sql HQL
spark sql
streaming sql continous sql CQL

Spark Streaming:是在批处理的基础上模拟流处理
Flink：是在流处理基础上模拟批处理过程

Storm特点：
事件驱动
相应高，低时延
先计算，在存储
Flink:事件驱动

Flume:
驱动
轮询

zookeeper作用：
分布式协调服务
分布式锁机制
微型数据库
=================================
StreamAPI BatchAPI
StreamGraph Opitimizer plan
JobGraph
ExecutionGraph
物理执行图
==========================================
Flink中的执行图分成四层：
StreamGraph---->JobGraph—>ExecutionGraph----->物理执行图
StreamGraph:根据用户通过Stream API编写的代码生成的最初的图。用来表示程序的拓扑结构
JobGraph：StreamGraph经过优化后生成JobGraph，提交给JobManager的数据结构。
主要的优化为：将多个符合条件的节点chain在一起作为一个节点，这样可以减少
数据在节点之间流动所需要的序列化 反序列化 传输消耗
ExecutionGraph：JobManager根据JobGraph生成ExecutionGraph。
ExecutionGraph是JobGraph的并行化版本，是调度层最核心的数据结构
物理执行图：JobManager根据ExecutuionGraph对Job进行调度后，在各个taskManager上
部署Task后形成的”图“，并不是一个具体的数据结构
========================== =======================================
当Flink集群启动之后，首先会启动一个JobManager和一个或者多个TaskManager.
又client提交任务给JobManager,JobManager再调度任务到各个TaskManager去执行
然后TaskManager将心跳和统计信息汇报给JobManager。
TaskManager之间以流的形式进行数据传输。

client： 提交Job的客户端，可以运行在任何机器上（只要JobManager相连通就行），提交Job
之后，client可以结束进程（Sreaming的任务），也可以不结束并等待结果返回。

JobManager：主要负责调度Job并协调Task做checkpoint,职责像Storm的Nimbus.
从client处接受到Job和Jar包等资源后，会生成优化后的执行计划，
并以Task的单元调度到各个TaskManager去执行。

TaskManager：在启动时候就设置好了槽位数Slot，每个Slot会启动一个Task，Task为线程。
从JobManager处接受需要部署的Task，部署启动后，与自己的上游
建立一个Netty连接，接受数据并进行处理。

Flink的任务调度是多线程模型，并且不同Job Task混合在一个TaskManager进程中。
类似storm中的进程模型

====================================================================
Flink认为Batch是Streaming的一个特例。Flink底层引擎是一个流式引擎，
在上面实现流处理和批处理。
窗口window就是从Streaming到Batch的一个桥梁。
Flink中给出了非常完善的窗口机制（包括消息的乱序处理和checkpoint机制）
在流处理的应用中，数据是连续不断的，不可能等到所有数据都到了才开始进行处理。
当然我们可以每来一个消息就处理一次，但是有时候需要做一些聚合类的处理。
例如：在过去一分钟内有多少用户点击了网页，在这种情况下，必须定义一个窗口，
用来收集最近一分钟内的数据，并且对这个窗口内的数据进行计算
窗口可以分为时间驱动（时间窗口）和数据驱动（count window）
翻滚窗口：无重叠
滚动窗口：有重叠
绘画窗口：活动间隙

淘宝网会记录每个用户每次购买的商品个数----统计不同窗口中用户购买的商品总数

===============================================================
segment file组成：
由2大部分组成，分别为index file和data file，
此2个文件一 一对应，成对出现，
后缀“.index”表示为segment索引文件、
后缀“.log”表示为数据文件。

segment文件命名规则：
partion全局的第一个segment从0开始，
后续每个segment文件名为：
上一个全局partion的最大offset上一个全局
partion的最大offset(偏移message数)。

数值最大为64位long大小，19位数字字符长度，没有数字用0填充。
Kafka的存储布局非常简单。

Topic的每个分区对应一个逻辑日志。
物理上，一个日志为相同大小的一组分段文件。
每次生产者发布消息到一个分区，
代理就将消息追加到最后一个段文件中。
当发布的消息数量达到设定值或者经过一定的时间后，
段文件真正写入磁盘中。写入完成后，
消息公开给消费者。

同一个topic下有不同分区，
每个分区下面会划分为多个文件，
只有一个当前文件在写，
其他文件只读。

当写满一个文件（写满的意思是达到设定值）后，

新建一个空文件用来写，
老的文件切换为只读。

文件的命名以起始偏移量来命名。

一个日志文件默认1G，当达到1G的时候，
创建新的log文件和index文件。

如果参数设置过小，
则会产生大量的log文件和index文件，
系统在启动时，
需要加载大量index到内存，占用大量句柄。

如果设置太大，分段文件
比较少，不利于快速查找消息。