目录
第一章大数据发展趋势
一、大数据概念
1. 定义：自己定义
2. 历史：2002年，dougcuting----->做全网搜索引擎（存储、计算）
2003年，谷歌提出GFS论文----->提出HDFS
2004年，谷歌提出MapReduce论文----->dougcuting模仿MR
2006年，雅虎开源（阿帕奇社区）----->正式更名为Hadoop
2008年，飞速发展
2010年，进入国内
3. 特点：数据大
类型多
处理快
价值低
真实性
4. 思维转变
二、大数据应用
1.衣----->韩都衣舍
2.食----->莱格宝（李子坝梁山鸡）
3.住----->万达
4.行----->旅游大数据
常用工具:文档代码编辑工具 notepad++ UltraEdit Myeclipse或者eclipse
数据分析常用工具 putty开源 RecureCRT 或者 Xhell 或者 MobaXterm
华为数据挖掘：Miner---------->（调用）Spark/Hadoop
5V：
数据体量巨大
数据类型繁多
处理速度慢
价值密度低
真实准确性
GB、TB、PB、EB、ZB、BB
Miner、Farmer、Hadoop、LibrA（高斯DB2000）、Manager
华为开源贡献第三
第二章 HDFS技术原理
管理网络中跨多台计算机存储的文件系统——分布式文件系统（GFS、TFS和HDFS）
HDFS(Hadoop Distributed File System)基于Google发布的GFS论文设计开发，运行在通用硬件上的分布式文件系统。
应用：
适合做：大文件存、流式数据（一次写入，多次读取）
不适合：小文件存储（浪费块空间）、随机读写（循迹时间>读取时间）、低延迟处理（数据倾斜（集群性能降低））
可以做：追加写入、批处理
文件权限：只读权限（r）
写入权限（w）
可执行权限（x）
服务器之间用接割技术
Namenode（主节点）：元数据
Datanode（从节点）：数据以块存储： 1.0 ——64M
2.7/华为c7——128M（默认）
HDFS的块比磁盘的块大：其目的是为了最小化寻址开销
运行：一个管理节点（namemode）-多个工作节点（Datanode）
通常Datanode从磁盘中读取块，但对于访问频繁的文件，其对应的块可能被缓存在Datanode 的内存中，以堆外快缓存的形式存在。
默认情况下，一个块仅缓存在一个Datanode的内存中
一个任务分成多个子业务（并发）
NTFS 2T
FAT32 2G
EXT3
EXT4 16G
方便存储管理查找文件
xxxx.log：日志文件
Fsimage：文件镜像，记录文件路径
主备选举：谁先启动得快谁就是主
在本地网络中，两个节点被称为“彼此近邻”
把网络看成一棵树，两个节点间的距离是它们到最近共同祖先的距离总和
脑裂：两个老大
华为：权限和角色绑定
写数据时NN返回DN列表和块位置信息
hdfs dfs -put：写入
hdfs dfs -get：读取
第三章 MapReduce分布式离线批处理
MapReduce基于Google发布的MapReduce论文设计开发，用于大规模数据集（大于1TB）的并行计算，具有如下特点：
MapReduce是一种可用于数据处理的编程模型。
MapReduce：map+reduce（键-值对）
MapReduce作业（job）：输入数据、MapReduce程序和配置信息
Hadoop将作业分成若干个任务（task）来执行【map任务+reduce任务】
这些任务运行在集群节点上，并通过YARN来进行调度。如果一个任务失败，它将在另一个不同的节点上自动重新调度运行
输入数据------>分片（默认128M）
map任务将其输出写入到本地磁盘。而非HDFS
每个map任务会为每个reduce任务进行分区（partit），使用哈希算法
combin有局限性，只能做词频统计
可以将文本和表互相转换
第四章 YARN资源管理器
资源管理、任务调度
ResourceManager：资源管理器
Application master：任务监督管理
nodemanager：节点管理器
Container：容器
（1）client提交任务，ResourceManager接收任务，启动并监控第一个APP Mstr和Container
（2）APP Mstr通知nodemanager管理资源，并启动更多container
（3）任务最终运行在container中；一个任务只有一个APP Mstr
YARN本身不会为应用的各部分（client、master和进程）彼此间通信提供任何手段【RPC协议】
YARN有一个灵活的资源请求模型：当请求多个容器时，可以指定每个容器需要的计算机资源数量（内存和CPU），还可以指定对容器的本地限制要求。
YARN应用也可以在运行中的任意时刻提出资源申请
第五章 ZooKeeper集群分布式协调服务
雅虎公司开发
分布式协调服务框架，解决数据管理问题，协调整个集群
功能：小型存储、监督、选举
依赖与kerberos（密码）和ldapserver安全认证
HA主备必须依赖zookeeper
第一次主备选举：第一次凭借UID号；主坏掉后，数据全的为主（最后和Leader通信的）（获取票数占一半及以上）
服务器最好为奇数：因为选举leader
无论在哪个server读数据，读到的数据都一样（最终一致性）
（实时性）
（可靠性）
（原子性）
（顺序一致性）
ACL（访问控制列表）：设置权限
日志增强：了解每个节点的状态
Zookeeper与Yarn：主备选举，监督（RM）
Zookeeper与Streaming：主备选举，监督，存放任务书（Nimbus）
Zookeeper与HBase：主备选举，监督，存放META表（HMaster）
Zookeeper与HDFS：HA高可靠（NM）
第六章 HBase分布式NoSQL数据库
一、数据库
数据库---->事务级操作（随机读取和写入）（和前端交互）
Oracle <= 50G
数据库（database）----->命名空间（namespace）
表（table）----->table
字段（fields）----->列
谷歌提出bigtable论文
维度（属性），维度高----->交叉点变多、检索困难----->降维、特征工程
面向列：处于同一列的数据往往具有某些相似性，方便数据的压缩处理（灵活动态存储，减少开销）
物化视图：对某些列的统计值进行缓存来减少开销
开源----->列族建好后不能删除；华为----->将列族下线后可以删除
二、特点
百万列、百亿行
列有列族（簇）、行有RegionSeriver：Region+RowKey（键值对）
RowKey：将行分类，每一行的索引
RowKey是默认索引，开源没有二级索引（华为有）
列族不会很多（中小型公司<=3）
（大公司或者做HBase开发公司>3（降维操作））
一台服务器只有一个RegionServer
一个RegionServer可以有多个Region（一个范围内的RowKey集合）
主节点：HMaster所在的节点----->通过ZK管理其余节点----->监控节点、存储Mate表
0.96版本后：Mate表（永不分裂的表/不超过10G/数据达到ZB级别，Mate才会10G）记录RegionServer所在节点的路由信息
0.96版本前：Root表
时间戳：记录时间的标签（秒）
（当前时间-1970年1月1日00：00：00）
类型：是否是正常写入
当Region接近10G时，会另分Region（逻辑在一起、大致均分）（一起提交的一份数据不能被分开）
Region一般4-6G
Region一个一个生成的，分裂后数据是追加剩余Region写入
当场查询就是修改完的数据；指定时间戳查询原始数据
保留版本只保留默认的版本（2个或3个或0个）
真正修改数据的时候：Region大合并
小合并：一个HFile内；
大合并：不同HFile、不同Region
开启负载均衡后还是不均衡----->RowKey没设置好----->没遵守散列性
RowKey怎么设计----->三原则----->唯一性、散列性（分散存储）、长度原则（8-16字节）
缓存（MemStore）不够时进行刷盘
HFile格式就是RowKey格式
数据库为行存，HBase为列存
合并（compation）
分裂（split）
HBase创建表的时候只需要接列族（不需要接列族的类型）
逻辑架构：HMaster》HRegionServer》HRegion》部分Rowkey
没flush时挂了，找HLog恢复
最基本单元：Region
最小存储单元：Cell
物理单元：列族
Zookeeper——HBase：
分布式锁=第一次启动时主备选举
事件监听机制=主备切换
微型数据库角色=存放META表
HFile文件越多，读取时延越大
Region分裂时会暂停服务
第七章 Hive数据仓库
一、历史
Facebook开发
二、物理架构
HBase -----> Hive：
命名空间 ----->库
表 ----->表
字段（列族）----->字段
三、特点
1、Hive自身没有计算能力----->MapRduce、Spark
2、Hive自身没有存储能力----->元数据库（内部表）DBServer----->直接访问HDFS、HBase（外部表/映射）
3、内、外部表之分
4、易于编程（底层MR）---->开发成本---->把代码封装成命令---->UDF函数编程
Hive SQL----->HSQL----->HQL（类SQL语句）
5、提供灵活的ETL（抽取/加载/转换）功能
6、只能做结构化分析
四、架构
1、分区（目录）----->字段----->分区太多造成索引复杂
2、分桶（文件）
动态分区分桶----->冗余存储----->重要数据----->参数一致
抽样（随机性、代表性）
select * from table（从表查询全部内容）
insert into（插入）
数据倾斜：大表和小表join时产生----->调优（大小表换位置）
Hash算法：01010101（初始数据）----->E1246 % 5（16进制文件/分桶数）----->余数就是放在哪个分桶
桶内排序：查询简单，无需再计算
不支持单行插入
文本----->MapReduce（临时表）----->表数据
外部表可以插入内部表
1、为什么分内外部表？
外部表：删除数据只能删除Hive上的映射，HDFS上数据还在
内部表：输入抽取到Hive上后，HDFS上没有数据了
2、数据导出到内部表后，HDFS上还有无数据？（数据不存在HDFS上了）
1.数据上传HDFS（创建Namenode映射）
2.创建临时表
3.HDFS往临时表里导入数据（改变映射）（映射完成后HDFS上数据没有了）
4.把数据抽入内部表（真正导入数据）
临时表：暂时创建，用完后关闭（放在内存中）；把文本数据转变为表格式
左连接：返回包括左表中的所有记录和右表中连接字段相等的记录（左边有的，右边没有的为null）
右连接：返回包括右表中的所有记录和左表中连接字段相等的记录（左边没有的，右边有的为null）
内连接：只返回两个表中连接字段相等的行（显示左边右边共有的）
第八章 Kafka
基于发布（发送）订阅（抽取）的消息系统
保证消息不丢失
生产者（Producer）-------发送------->Kafka（Broker）-------订阅------->消费者（Consumer）
一台服务器一个Broker
Zookeeper（C60强依赖，C80自带）：监督、主备、小型数据存储（offset偏移量------->标记消费程度）
0.89之前：kafka必须依赖zookeeper（独立）
0.89之后：kafka集成zookeeper（集群）
Consumer group：多个consumer组成（不会消费同一分区）------->避免拥挤
Prodecer按队列发送数据
生产总是在末尾追加消息
topic（主题）》partition（分区）------->减少读取时间
topic：大类分类（创建后不能改名）
partitions：分区（小类分类）-------->会分成多个小文件
双副本机制（下一台Broker）
埋点日志（计数器、跟踪器）
理解生产者（producer）、消费者（consumer）
index索引（大范围）
log日志（大范围中的小范围）
日志清理：删除、压缩
过期时间、分区内总内存大小
消息持久化到硬盘-------->保证数据不丢失
消息多次发送-------->保证消息传输可靠性
（最多一次）
（最少一次）华为
（仅有一次）理想状态
理解异步（数据顺序不一致）和同步（数据顺序一致）
第九章 Flume
海量日志聚合的系统，流式日志采集工具
抽取日志/数据
channel：临时存储数据
source：抽取数据
sink：投递数据
一个Fulme就说一个agent
两个Flume间用AVRO类型和RPC协议传递消息
事件驱动
是sink去channel上拿数据
下一级Flume（下一跳）
一个存储只能对应一个抽取，一个抽取可以对应多个存储
了解Flume各种架构（多抽取、多投递）
第十章 Loader
实现FusionInsight HD与外界交换数据的数据加载工具
sqoop二次开发，sqoop 2.0不稳定，1.4.7相对稳定
抽取时，网络端MapReduce会丢数据
数据库<-------(抽取数据)-------MapReduce（文本转换表）-------(抽取数据)------->HD集群
导入：数据库----->Loader；导出：数据库<-----Loader
sqoop：Map；Loader：Map+Reduce
不会有脏数据（影响判断）----->格式不一致/脏----->识别不了
大部分ETL工具都是玩配置文件
第十一章 Streaming
基于开源的Storm，学会Streaming就学会了Storm
分布式实时计算框架
批处理：离线（直梯）
流处理：实时（斜梯）（水流）
逻辑架构：Nimbus》Supervisor》Worker》Executor》Task
物理架构：Client》Spout》Bolt》Task
Spout：数据源头
Bolt：每台服务器
Zookeeper：监控运行状态、主备选举、任务书的存储
下一跳：接收来自上一跳的消息
ACK校验结果必须为0（采用异或算法）
异或：输入相同为0，不同为1
同或：输入相同为1，不同为0
前后都有Kafka，保证数据不丢失
主从热切换
Streaming保证消息可靠性：
消息发送策略（广播、随机、全局）、最少一次发送、进程启停、ACK机制
第十二章 Spark
基于内存的分布式批处理引擎
Spark（scala）：一站式解决方案（生态圈）----->2009年诞生----->2011年起步
Scala：易写不易读；Java：易读不易写
MAHOUT：机器学习服务
通过血统机制/检查点机制（快照）----->容错
RDD（分布式弹性数据集）----->内存计算（关闭后丢失）----->运行时一定持久化到本地
窄依赖：子RDD由父RDD最多一个分区得到（一对一）
宽依赖：子RDD由所有父RDD分区所得到（一对多）
宽窄依赖看子RDD
RDD的生成：
1.由父RDD生成（血统机制）
2.手工建立RDD
3.读取本地数据生成RDD
Stage划分（决定启动几个Task）：遇到宽依赖就划分
启动Task：接近宽依赖的分区
Task个数 > 分区个数
每个stage的末端RDD分区个数决定了stage中的task个数
Transformation：语法不错，就不会报错（不运行、只做状态的保存）
Action：运行，加载至内存中
context：容器
SC.算子：使用RDD算子
Spark SQL在底层也需要编译
Spark SQL：
DataFrame：结构化数据格式（指定到名称的DataSet）（无界表）
DataSet：表格式
无界表：新的数据不断涌入，旧的数据不断清除------>内存不会溢出
Structred Streaming：在SparkSQL基础上的流式数据处理引擎
下盘（前端看不出）：
（1）处理完数据后全部下盘
（2）追加数据下盘
（3）更新（旧或追加）数据下盘
val RDD2 = SC.textFile("/tenant/username/aa.txt") .
flatMap(line => line.map(_.split(","),1)).
reduceByKey(_+_).
saveAsTextFile("/tenant/username/output")
（Map方法，Map键值对）+（ReduceBykey，Reduce累加）
第十三章 Flink
流处理、容错可靠、可扩展1000节点、高吞吐低延迟
PV、UV
Flink算子和MapReduce算子混合调用
安装：
1、本地单节点
2、集群
3、云端
Scala<---(1:50)--->Java -------->核心代码相似，语言不一致但可相互转换
(spark) (Flink)
SparkCql————Runtime-------->核心不一样
（时间） （时间+数据量）
Task slot：槽位（用于运行Task）
检查点不会丢失
扫一扫
892
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
