大数据思想：
分布式存储
分而治之：

• 计算向数据移动（数据计算本地化）
• 分布式并行计算

大数据基于什么样的计算场景

• 1.数据量海量（GB,TB,PB）
• 2.文件记录数（百万级别以上）
• 3.时效性（实时业务：毫秒级，秒级响应 离线业务：分钟，小时）

HADOOP

1.HADOOP简介

• 官网;hadoop.apache.org
• 由来：解决问题：Google：海量网页的存储和如何快速检索
  如何解决：GFS(有了HDFS),MAPREDUCE(有了MAPREDUCE),BIGTABLE(有了HBASE)
• Hadoop组件

• Hadoop生态系统（最底层：hdfs，yarn资源管理框架，再上一层是MapReduce（离线计算）tez（dag计算）spark（内存计算））

  
  

2.HDFS

• Hadoop1.x架构

  
  
• Hadoop1.x架构 角色（服务）
  NameNode ：块的元数据
  接受客户端的读写请求
  获取block块的位置
  DataNode
  存储block
  存储block副本
  读写客户端的读写块的请求
  secondaryNameNode
  ssn是NameNode冷备份：
  主要进行镜像文件和操作日志的合并：fsimage（元数据镜像文件）和edits log（数据的操作日志）
  ssn合并流程图：
  
  合并流程详解：
  1.NameNode会把fsimage和edits文件进行持久化存储到磁盘，当触发checkpoint条件的时候，进行合并工作，ssn开始工作
  2.NameNode会创建一个新的edits.new的文件，来记录新的操作日志
  3.snn会将fsimage和edits.new文件加载到内存中，在内存中进行合并
  4.合并完成之后会生成一个新的fsimage.ckpt的文件
  5.snn会把合并好之后的fsimage文件复制到nn，替换掉原来的fsimage以及edits
  6.之后一直循环往复
  checkpoint
  1.两次检查点的时间差在60分钟
  2.记录操作日志的edits文件大小超过64m，会强制合并
  注意，一般情况下，不要把snn当做nn的备份，但是可以说成是冷备份
  冷备份：只是缓存一部分nn的数据，当服务宕机的时候，不能切换
  热备份：当服务宕机后，可以随时切换
  jobtracker
  负责管理集群中的资源
  负责分配要执行的任务
  tasktracker
  实际工作的任务节点
  Hadoop1.x存在的问题：
  1.NameNode单点故障
  2.NameNode压力过大，内存受限，无法扩展
  3.jobtracker压力过大，无法扩展
  4.无法兼容除了mr之外的其他任意框架（storm，sprak）
  -Hadoop2.x
  Hadoop1.x和Hadoop2.x区别
  
  Hadoop2.x如何解决1.x的问题
  NameNode单点故障：hdfs ha通过一个主备切换的NameNode完成：集群中包含两台NameNode，一台处于active，一台standby
  切换策略：手动切换和自动切换
  NameNode压力过大，内存受限，无法扩展：联邦hdfs federation：将存储的元数据信息分布在多台NameNode
  所有的NameNode共享DataNode得到数据
  jobtracker压力过大，无法扩展 ：引入yarn（资源管理框架）实现了高可用的resourcemanager
  无法兼容除了mr之外的其他任意框架（storm，sprak）spark，storm可以运行在yarn的资源管理框架上
  -Hadoop2.x角色（服务）
  NameNode
  两台位于主备的NameNode，切换：
  手动切换：通过命令启动（延迟高）
  自动切换：zookeeper实现 ：
  1当namenode启动之后，会分别向zk注册信息，竞争锁，先抢占到锁资源的NameNode是active
  2zk实时监控NameNode的健康状态，当有一台宕机之后，另一台会竞争锁资源，将本身的状态设置为active
  3当另一台宕机的NameNode重新启动之后，向zk注册，发现锁被其他NameNode占用，将状态置为standby
  journalnode
  存储对应的元数据信息
  执行过程：当处于active的NameNode的命名空间发生数据变化的时候，会通知大部分的JN，超过半数生效
  另一个处于standby的nn会监控jn的数据变化，当有变化的时候，同步数据到本台命名空间（为了保证数据同步，实时切换）
  zkfc：监控NameNode的健康状态，实时切换
  -Hadoop2.x高可用集群架构图
  

• hdfs工作原理
  读写流程
  写流程

  
  
  

  读流程

  
  
  
  写流程
  block块的放置策略
  block块的第一个副本放置在提交请求的节点的datanode。如果是集群外提交，随机分配节点
  

  第二个副本放置在与第一个副本不同机架的节点上
  第三个副本放置在跟第二个副本同机架的节点
  机架感知策略
  机架感知默认是关闭的
  当DataNode向NameNode汇报block信息的时候会传递一个ip的参数，根据ip的参数来划分机架
  hdfs：安全模式
  安全模式是HDFS所处的一种特殊状态，在这种状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求。在NameNode主节点启动时，HDFS首先进入安全模式，DataNode在启动的时候会向namenode汇报可用的block等状态，当整个系统达到安全标准时，HDFS自动离开安全模式。如果HDFS出于安全模式下，则文件block不能进行任何的副本复制操作，因此达到最小的副本数量要求是基于datanode启动时的状态来判定的，启动时不会再做任何复制（从而达到最小副本数量要求）
  -hdfs api
  Configuration conf=new Configuration()
  FileSystem fs =new FileSystem(conf)

• HDFS CLI
  hdfs dfs
  -HDFS权限
  hdfs没有用户系统
  遵循posix（rwx）u（用户） g（用户组）o（其他用户）
  如果想要配置用户名和密码。使用kerberos
  目的：防止好人做错事，不能阻止坏人做坏事
• Hadoop特点：
  1.安全性
  多副本：默认3个
  当某一个副本坏了之后，会自动拷贝其他副本
  2.扩展性
  可以扩展多个节点
  3.处理海量数据
  gb，tb，pb
  百万级别文件数
  10k+节点数
• Hadoop的设计思想
  分布式存储
  分而治之：分布式并行计算
  计算移向数据：目的：计算本地化

• hdfs存储结构：字节

  
  

3.MAPREDUCE

• 分布式计算框架
• MR的原语
  map端输出的值必须是（K，V）。将相同的key归属于一组，在reduce端做计算

• MR的设计思想

  
  
  

  1计算向数据移动
  2并行计算
  3mr设计算子
  map将input输入的一行记录变成（KV）格式的数据
  reduce 将相同的key的数据生成的迭代器进行累加操作

• MR的执行过程

  
  
  

  将所有的业务转换成map和reduce两个阶段

• MR案列
  wordcount
  fof（好友推荐）
  天气排序
  TF-IDF(词频)
  ITEM-CF(好友推荐)
  PAGERANK
• MR源码
  maptask
  reducetask
  注意：数据源和目的源没有限制
  inputformat（createrecordreader返回recordreader）getSpilits（）
  outputformat （outputrecordwriter返回recordwriter）write（）和close（）

4.YARN

• 资源调度框架
  是Hadoop2.x引入的

• 角色（服务）
  Resourcemanager：管理整个集群资源
  nodemanager：
  启动完成之后会向rm中汇报资源
  具体执行task
  ApplicationMaster
  提交application的时候会创建AM
  分配task
  监控task

  
  
  

  Container

• 注意yarn属于hadoop，但是其他集群也可以运行在yarn上

5.Hive

hive原理架构

• hive简介
  hive是数据仓库
  数据库和数据仓库的区别
  数据库用来支撑业务系统的交互式查询，hive用来做复杂的离线业务查询
  数据库中的数据维持更新，数据仓库会把历史数据都保留下来，会形成一个时间拉链数据
  数据库存储的是单一系统的数据，hive是将多种数据源的数据规整（数据模型）到一起
  hive本质是MapReduce 延时性高，不能做到很快的响应过程

• hive架构

  
  
• hive的角色服务
  Driver
  是一个hive进程提供对外访问服务
  分类hive（结构命令行的sql提交）和hive server2（beeline或者jdbc方式）
  Client:CLI和JDBC（通过基于rpc的thrift方式进行访问）和web UI（弃用）
  metastore：元数据：表示hive表的相关信息
• hive的搭建
  按照元数据的数据和管理分为三类
  1，使用hive自带的derby数据库存储元数据---不用
  2.使用网络访问一个远程的关系型数据库保存数据
  3.hive直接访问元数据服务获取元数据，元数据服务通过网络来管理关系型数据库
  基本属性：
  hdfs path：hive表存储的hdfs目录
  mysql属性：
  drivename url username password
  hive.metastore.uris:通过9083端口访问元数据服务
  访问方式的分类
  1.服务端直接执行命令自己启动元数据服务
  2.先开启一个元数据服务，服务端通过9083的端口进行连接
  注意：企业推荐使用远程服务的模式访问hive
  1.先手动启动hive的元数据服务
  hive --service metastore
  2.hive/hiveserver2都是通过9083的端口进行元数据的fangwen
  3.hive开发人员使用
  4.hiveserver2只提供查询业务

DDL

• 建表操作
  

  数据类型
  建表语句
  

  1.create tablename（col type）row format （delimited fileds terminated by "collection item by" map keys teminated by ")/serde serdeproperties
  2.create table tablename like tablename
  3.create table tablename as select_statement
  -创建数据库
  create database db_name

• 分区
  目的：提高数据的检索效率
  展现形式：在hdfs路径中包含了多级目录
  创建分区：在创建表的时候要指定partition by(col type)
  分区类型：
  静态分区：向分区表导入数据的时候，分区列的值人为规定
  动态分区：通过表中的某一个字段值将数据存放到指定目录
  添加分区：
  alter table tablename add parition(col=value) -----只适用于静态分区
  删除分区：drop table tablename drop parition(col=value)只适用于静态分区
  修复分区：当在hdfs中已经存在多级目录文件的时候，创建外部表的时候需要修复分区（向关系型数据库中添加元数据）
  msck repair table tablename
• 分桶：目的：抽样查询和事务支持
  展示形式：将一个数据文件拆分成桶的个数个文件
  分桶原则：取其中某一列的值，将值取hash值，再将hash值%桶的个数
  实现方式：创建表的时候指定clustered by tablename(col) into number buckets
  抽样查询：tablesample bucket (x out of y)
  x:从哪个桶开始取数据
  y:桶的个数的倍数或者因子
• 视图 hive也支持视图
  create view vier_name as selecte_statement
  特点：
  1.不支持物化视图
  2.hive视图不能执行insert或者load操作
  3.支持迭代视图
• 索引
  目的：提高检索效率
  创建视图：create index index on tablename(col) as"指定索引器" in the tablename(存储索引数据)
  hive中的视图需要自己创建
  alter index index_name on tablename rebuild
• 函数
  hive中提供了非常丰富的函数支持，
  数值函数
  字符函数
  日期函数
  转换函数
  复杂类型函数
  聚合函数
  UDTF函数
  条件函数
  用户也可以自定义函数
  1.使用java代码完成编写类，继承UDF类
  2.实现evaluate方法，将所有的代码逻辑写到此方法中
  3.将项目打成jar包，上传到hdfs或者本地linux系统
  4.如果是hdfs
  create fuction funx_name as '包名+类名' using "hdfs_path"
  5.如果是本地linux系统
  add jar path
  create function func_name as '包名+类名'

DML
-增
1.insert into tablename values()
2.insert into directory dict as select_statement
3.load data local inpath 'path' into table tablename
4.from tablename insert into new_table select col
注意：1.2几乎不用，3,4,使用较多

• 删改：
  hive支持删除和修改数据，但是需要事务的支持
  开启事务之后又很多限制
  1.不支持rollback，commit，begin
  2.必须是orc文件格式
  3.表必须被分隔
  4.事务默认不开启，需要手动开启

hive的运行

• hive参数的设置
  参数的分类
  1.hiveconf==设置在hive-site.xml文件的属性
  2.system
  3.env
  4.hivevar
  设置方式
  1，在hive.site.xml中设置 全局生效
  2，启动命令行的时候添加 --hiveconf k==v
  3.进入命令行之后 set k=v
  4.在当前用户的家目录下创建.hiverc的文件
• hive的运行方式
  cli有三种
  可以提交sql语句
  与hdfs交互
  与linux交互，但是命令前要加！
  脚本运行方式
  hive -e 'sql'
  hive -e 'sql'>aa.txt
  hive -S -e 'sql'
  hive -f file
  hive -i file
  在hive的命令行中执行source file
• 权限管理
  1.基于元数据的权限管理
  2.基于sql标准的权限管理（推荐）
  3.基于第三方组建的权限管理
  4.默认的管理方式
  权限角色：用户：使用者
  角色：一组权限的集合
  默认角色
  public和admin
  权限分配
  grant和revoke
• hive的优化

6.HBASE

• hbase介绍
  hbase是数据库。不是内存数据库，也不是列式数据库。KV格式面向列存储的分布式数据库
  特点：
  1.高可靠性
  2.可伸缩
  3.面向列
  4.实时读写
  5.高性能
  数据规模：
  十亿级别的行，百万级别的列
  使用场景：
  1非机构化或者半结构化的松散数据
  2高并发客户端请求的数据
  3要求实时性比较高的数据

• hbase的原理架构
  hbase的架构

  
  
  

  角色：
  client：提交hbase的读写请求并维护客户端的缓存
  master：管理整个集群的regionserver
  分配region到哪一台regionserver
  维护regionserver的负载均衡
  负责为切分region分配新的位置
  zookeeper
  保证整个集群内任何时候都有唯一一台处于active的master
  存储region元数据的所在节点信息（所有region的寻址入口）
  存储table的相关信息
  实时监控regionserver的上线下线信息，并且实时通知master
  regionserver
  hbase集群的从节点：
  负责存储client的读写请求的数据，负责存储region
  当某一个region变大后，regionserver负责等分成两个
  其他组件：
  region：相当于表的概念
  当一个表创建完成之后，写数据时会先一个region写数据
  当region数据变大，达到某一个阈值之后，会切缝成两个
  store：相当于列族
  是实际存储数据的最小逻辑单元
  store中memstore位于内存的空间
  store中storefile：位于磁盘的文件
  注意：memstore和storefile共同组成了LSM树结构
  hlog

• 数据模型

  
  
  

  角色：
  rowkey：唯一标识一行数据，相当于mysql主键
  rowkey默认是字典序、
  rowkey的最大存储长度是64k，一般建议10-100字节
  column family：一组列的集合
  必须作为表的schema预先给出
  列族是权限控制，存储，属性设置的最小单元
  qualifier：表示某一个字段值，不需要预先给出
  可以在插入值的时候，同时给列赋值
  timestamp：时间戳，起版本号的作用
  一般使用系统的默认时间戳，也可以自定义（但不推荐）
  Ceil：存储数据的最小单元
  保存多个数据值
  数据格式都是KV格式的数据K：rowkey+column family+qualifier+timestamp
  V：value
  Ceil中存储的数据都是字节数字类型

• hbase的读写流程
  读：
  1.client发送请求给zk，从zk中获取到元数据存储的所在regionserver节点
  2.访问元数据所在的regionserver节点，访问表的元数据信息，找到表的存放位置。
  3.访问表所在的regionserver节点，找到对应的region，找到对应的store，从memstore中读取数据，如果读不到，去blockache中读取数据
  4.如果没有，去storefile中读取数据，并且将读取到的数据缓存到blockache中
  5.将结果返回给客户端
  写：
  1.1.client发送请求给zk，从zk中获取到元数据存储的所在regionserver节点
  2.访问元数据所在的regionserver节点，访问表的元数据信息，找到表的存放位置。
  3.访问表所在的regionserver节点，首先向WAL中进行写日志操作，完成之后，找到对应的region，向store的memstore写入数据
  4.当memstore中达到阈值（64mb）之后，会进行溢写操作
  5.存储到storefile，落地到磁盘，当磁盘的小文件过多的时候，会进行minor合并
• 存储结构
  WAL
  流程：客户端发送请求后，会先进行WAL写日志操作，预先存储到内存中
  logAsync会监控内存空间的数量是否有修改，如果有的话，直接将修改操作落地到hdfs
  logroller会将一段时间内的日志文件关闭，重新开启一个新的日志文件
  memstore和storefile
  使用了LSM树结构，包含位于内存的小的存储结构和位于磁盘的大的存储结构
• hbase API
  hbaseAdmin：
  createtable
  disableTbale
  deletetable
  HTable:
  get
  put
  scan
  delete
  FilterList:
  SingleColumnValueFilter
  PrefixFilter
  比较过滤器
  专用过滤器
  附加过滤器
• Hbase Cli:
  status whoami version
  create drop disable
  enable put get
  delete scan list
  flush split
• hbase-mapreduce整合
  MR从hbase获取数据
  MR将数据结果存入hbase
  注意：TableMapReduceUtil.initMapJob
  TableMapReduceUtil.initTableReduceJob
  Hbase优化
  表设计
  1预分区
  2.rowkey的设计原则：
  越短越好
  hash
  取反
  3不要设置过多的列族。1-2个
  4.SetMaxVersion
  5.SetTTL
  6.inMemory
  7.合并和切分
  合并：minor：小范围合并（3-10个文件）自动合并
  major：将所有的storefile文件合并成一个
  建议关闭自动合并，推荐手动合并
  切分：将一个region等分为两个region。分布在不同的regionserver上

---

写表操作
多客户端并发写，创建多个HTable对象
属性设置：
1关闭autoFlush
2设置客户端缓存
3WAL Flag（不推荐关闭）
多线程写

---

读表操作
多客户端并发读，创建多个HTable对象
属性设置：
1.scan设置抓取数据的条数
2.关闭resultScanner
3.指定查询的column和family，不要将一整行的所有数据读取进来
多线程读
blockache：一个regionserver共享一个blockache
blockache默认占用0.2的内存空间，对于注重读响应的系统，可以适当增大值
blockache有默认采用LRU的默认机制，默认淘汰最老的一批数据

• Htable和htablepool
• hbase索引
  用ES做整合
  步骤：
  1.通过程序将hbase中的数据读取存入ES中
  2.ES会创建索引，返回的值是rowkey
  3.当客户端请求进来后，先去es中查询获取rowkey的列表
  4.再根据rowkey去hbase获取对应的数据

终于写完了，好累。。。。。。。。。。。。。。