git中文件的颜色分类
棕色: 当前文件不受版本控制,未添加到版本控制
绿色: 当前文件已经加入版本控制,但是没有提提交
黑色: 当前文件和远程保持同步,未修改
蓝色: 本地已修改,未提交
红色: 内容有冲突,未解决
zookeeper
分布式协调服务的开源框架----本质上分布式的小文件存储系统
特性:全局数据一致,可靠性,顺序性(全局有序,偏序),数据更新原子性,实时性
zookeeper server的状态:looking,leading,following,observing
集群(2n+1)角色:leader,follower,observer
数据模型和标准文件系统相似,采用树形层次结构
每个节点称为一个znode(兼具文件和目录两种特点,具有原子性操作,每个Znode的数据大小至多1M,znode通过路径引用且路径必须是绝对的)
znode有三部分组成(stat状态信息,data与znode关联的数据,children该znode下的子节点)
znode的四种类型:presistent永久节点,ephemeral临时节点,presistent_sequential永久系列化节点,ephemeral_sequential临时序列化节点
watcher监听机制:客户端向服务端注册watcher,服务端事件发生触发watcher,客户端回调watcher得到触发事件的情况
一次性触发:同样的事件不会重复触发一个watcher event
事件封装(通知状态,事件类型,节点路径):将触发事件封装到watchedevent对象中
event异步发送:
先注册在触发:
事件状态为none时不需要客户端注册节点来进行监听
选举机制(默认使用FastLeaderElection算法):采用投票数大于半数胜出的逻辑
全新集群选举:集群启动过半数,服务id大的就是leader
非全新集群选举(有机器宕掉):逻辑时钟小的选举忽略-->数据id大的胜出-->服务id大的胜出
hadoop--分布式文件系统和对海量数据进行分析计算的基础框架系统
核心组件:hdfs(分布式文件系统,海量数据存储),yarn(作业调度和集群资源管理框架,解决资源任务调度),mapreduce(分布式运算框架,海量数据计算)
特性优点:扩容能力,成本低,高效率,可靠性
配置文件:hadoop-env.xml,core-site.xml,hdfs-site.xml,mapred-site.xml,yarn-site.xml
hadoop-env.xml:配置Hadoop的环境变量
core-site.xml:Hadoop的核心配置文件
hdfs-site.xml:HDFS的核心配置文件
mapred-site.xml:MapReduce的核心配置文件
yarn-site.xml:YARN的核心配置文件
slaves:记录集群主机名
HDFS:分布式文件系统(大数据存储)--主从架构,分块存储,名字空间,元数据管理,数据存储,副本机制,一次写入多次读出
namenode:管理元数据(目录结构及文件分块的位置信息)
datanode:存储真实信息--block块数据
副本机制:默认是3副本
写流程
client向namenode申请上传文件
namenode检查文件是否存在,若不存在允许上传,返回允许上传通知
将文件按照block块(128M)切割,申请上传第一个block块
通过设置的副本个数,得到上传datanode地址的列表,并返回给client
client和datanode建立pipeline连接,将block块拆分成packet(64k)
将packet发送到各个datanode上依次创建副本,
写入成功后返回一个ack确认码,紧接着上传第二个block块以此类推
读流程
client向namanode申请读取一个文件,
namenode检查文件是否存在,如果有,返回该文件的block块信息
将block块信息返回给client
client可以根据信息与datanode建立管道连接,并行读取文件块信息
???问题:
当读写数据时,namenode或者datanode挂掉时,会出现什么情况??
namenode宕机时,我们是高可用集群备用namenode会成为主namenode进行接管集群
datanode宕机时,因为副本机制,客户端会寻找备份的数据进行访问
NameNode检查该datanode上数据块还在哪些DataNode上有备份，
通知相应的DataNode服务器将对应的数据块复制到其他服务器上，以保证数据块的备份数满足要求
mapreduce---textinputformat->自定义mapper->分区,排序,规约,分组->自定义reducer->textoutputformat
wordcount案例代码--提交到yarn的命令 hadoop jar jar包 全类名 input output
序列化(结构化对象转换为字节流),反序列化(序列化逆过程)
实现Writable序列化接口--重写方法
排序
实现WritableComparable接口
combiner:运行在每一个maptask所在的节点,对每一个maptask的输出进行汇总,减少网络传输
是mapper和reducer之外的一种组件,父类是reducer(接收全局的mapper的输出)
三阶段:map阶段,shuffle阶段,reduce阶段
并行度机制:job执行有几个maptask由切片数决定,有几个reducetask可以自己手动设置
性能优化:
资源相关参数
maptask和reducetask使用的内存设置,cpu核数,使用jvm参数的设置
在yarn上运行yarn使用的物理内存总量的设置,shuffle阶段环形缓存区的设置
容错相关参数
maptask和reducetask失败的重试次数,失败比例(失败的个数/总的个数)的设置
task不进行数据处理运算的最大时间设置(task的超时设置)
效率跟稳定性参数
task打开推测执行机制(推测出'拖后腿'的任务,开启一个备份任务处理同一份数据,那个先完成处理将作为最终处理结果)
fileinputformat做切片时最大切片和最小切片设置
功能案例
分布式缓存,存在数据倾斜问题---通过map端join解决(没有reducer)
CombineTextInputFormat类---小文件处理场景,解决产生大量小文件的问题
GroupingComparator自定义分组
执行流程
map阶段
通过textinputformat从datanode中读取数据,获取split,从中获取到k1,v1
使用自定义的map类来进行数据的处理得到k2,v2 相同的数据进行分区处理存放到环形缓冲区
环形缓存区默认是(100m),等达到阈值(80%)后,进行spill溢写操作,生成小文件,但还会继续向剩余的20%中写入数据,
产生的小文件局部的排序,规约进行marge合并操作形成一个中间临时文件
reduce阶段
reduce进行数据的拉取,将临时文件拉到内存缓存区,进行数据的简单分类
进行merge全局的归并排序,分组得到新的k2,v2
使用我们自定义的reduce类来进行数据的处理得到k3,v3
最后通过textoutputformat进行数据的输出到文本文件
???mapreduce中shuffle的环形缓冲区??
相当于一个环形队列,便于写入缓冲区和写出缓冲区同时进行
hdfs元数据管理机制--metadata文件路径名、数据块的ID以及存储位置等信息
内存元数据和元数据文件(fsimage镜像[文件系统的目录和序列化信息],edits日志[所有增删改等操作])
oiv查看fsimage文件[hdfs oiv -i fsimage_0000000000000000115 -p XML -o fsimage.xml]
oev查看edits文件[hdfs oev -i edits_0000000000000000081-0000000000000000089 -o edits.xml]
secondary namenode---执行checkpoint操作
辅助namenode管理集群,将edits日志合并到fsimage文件中
Hadoop集群的动态扩容,缩容
扩容:
修改主机名,设置免密登录,修改slaves文件增加新节点,解压Hadoop并将主节点配置文件拷贝过去
添加datanode,创建dfs.hosts文件,修改hdfs-site配置文件
datanode设置负载均衡
缩容:
创建dfs.hosts.exclude文件,添加退役节点主机名/ip,修改hdfs-site.xml配置文件
刷新集群
hdfs安全模式
yarn:资源管理,任务调度框架---resourcemanager(资源的管理,监控),nodemanager(负责节点的正常运行),app master(具体应用程序的的调度和协调)
运行流程:
client向resourcemanager中的组件app manager提交任务
app manager在任意nodemanager中开启空间运行appmaster(提交任务程序携带过来的)
app master向RM中的组件Resource Schduler申请资源,并把资源列表返回给app master
app master去各个NM中开辟空间运行maptask和reducetask,
各个task定时向app master上报自己的运行状态
最后appmaster将运算结果展示给客户端
yarn的调度器
FIFO Scheduler(队列调度器):先进先出,顺序执行
Capacity Scheduler(容量调度器):资源可以共享
Fair Scheduler(公平调度器):资源公平分配
多租户资源隔离(创建用户设定用户,进行配置运行job所需要的资源)
hadoop高可用集群---没有secondarynamenode
使用QJM/Qurom Journal Manager(基于paxos算法-分布式一致性算法)实现高可用:消除单点故障(spof),系统鲁棒性(系统的生存能力)的配置和扩展
使用2n+1台JournalNode存储edits日志
Failover Controller:部署在每个namenode上
healthmonitor:监控namenode的状态
activestandbyelector:监控namenode在ZK中的状态
ZKFC(ZKFailoverController):订阅HealthMonitor和ActiveStandbyElector的事件,并管理NN的状态,另外zkfc还负责解决fencing(脑裂)问题,负责master的选举(zookeeper)
hadoop的联邦机制:解决namenode内存瓶颈问题的水平横向扩展方案
存在多个namanode/namespace,对应指定的blockpool,共用所有的datanode
hive
数据仓库DW/DWH:面向分析的集成化的数据环境,为企业提供决策支持
面向主题的,集成的,非易失的,时变的
数据仓库和数据库的区别
OLTP:操作型处理,联机事务处理
OLAP:分析型处理,联机分析处理
数据库是面向事务的设计,数据仓库是面向主题的
数据库存储业务数据,数据仓库是存储的历史数据
数据库设计要尽量避免冗余,数据仓库是有意的引入冗余(为了分析数据)
数据库是为了捕获数据,数据仓库是为了分析数据
分层架构:ODS(源数据层),DW(数据仓库层),ADS(数据应用层)
用空间换时间,通过预处理数据提高效率
元数据的管理
元数据:记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态
技术元数据和业务元数据
存储在mysql中
数据模型
database(db):在hdfs表现为hive.metastore.warehouse.dir目录下一个文件
table 内部表:在hdfs中表现所属db目录下的一个文件夹
external table 外部表:数据存放位置可以在hdfs中任意指定位置
partition table:在hdfs中表现为目录下的子目录
bucket(分桶表)table:在 hdfs 中表现为同一个表目录下根据 hash 散列之后的多个文件
表的分类:内部表,外部表,分区表,分桶表
create table 表名(字段 类型,.....) row format delimited fields terminated by '指定分割符';
create external table 表名(字段 类型,...) row format delimited fields terminated by '指定分割符' location '指定创建的位置';
create table 表名(字段 类型,...) partitioned by (分区字段 类型,...) row format delimited fields terminated by '指定分割符';
create table 表名(字段 类型,..) clustered by(表中某一字段) sorted by(表中字段 DESC) into 4 buckets row format delimited fields terminated by '指定分割符';
hivesql操作
强制删除cascade
drop database 库名 cascade
排序种类
order by 全局排序,只有一个reducer
sort by 局部排序,数据进入reducer进行排序
distribute by(字段) 根据指定字段将数据分到不同的reducer
cluster by(字段) 当字段一样时,包含distribute by+sort by
hive join
hive参数配置方式
配置文件
命令行方式配置参数:启动hive时,添加-hiveconf设定参数
参数声明:SET 关键字设定参数
hive函数
内置函数
自定义函数:UDF(普通函数,一进一出),UDAF(聚合函数,多进一出),UDTF(表生成函数,一进多出)
UDF:写一个类继承 UDF，并重载 evaluate 方法
hive函数高阶特性
UDTF函数--explode(hive内置的,一行转成一行多列，也可以将一行转成多行多列)
lateral view侧视图
行列转换****
行转列
concat_ws(分隔符,拼接的内容)
collect_set(字段) 对字段进行去重汇总
collect_list(字段) 不去重
列转行
explode配合lateral view将某列数据拆分成多行
reflect函数:可以支持在sql中调用java中的自带函数
select reflect("java.lang.Math","max",col1,col2) from test_udf
json数据解析
hive窗口函数
sum,avg,min,max
分组排序
row_number:分组内按顺序 1 2 3 4 5 ....
rank: 分组内排序,相等则会留下空位 1 2 2 4 5 ...
dense_rank: 分组内排序,相等则不会留下空位 1 2 2 3 4 ...
hive数据压缩
优点:减少了存储磁盘空间,减少网络传输带宽
缺点:花费额外的时间/cpu做压缩和解压缩计算
hive数据存储格式
行式存储和列式存储
支持存储数据的格式
TEXTFILE:默认
ORC:列式存储格式,以二进制方式存储,先根据行组划分后在进行列式存储
PARQUET:列式存储,二进制存储,根据block大小划分行组后进行存储
存储文件的压缩比总结:orc>parquet>textfile
在实际的项目开发当中，hive 表的数据存储格式一般选择：orc 或 parquet。压缩方式一般选择 snappy
注:orc存储默认的是zlib压缩,比snappy压缩的小
hive调优
fetch抓取机制:默认设置为more后,在全局查找,字段查找,limit查找是不走mapreduce
mapreduce设置本地模式,开启hive的本地模式(set hive.exec.mode.local.auto=true)
join查询的优化
map端的join避免数据在reduce端发生数据倾斜
大表join大表
空key的过滤:对应的数是异常数据需要过滤掉
空key的转换:不是异常数据,需要给空key赋予一个随机数
大小表,小大表join
group by优化--map端聚合
数据倾斜问题
maptask的个数设置
小文件场景,大文件场景(增加maptask的个数提高执行效率)
reducetask的个数设置
执行计划书---explain
并行执行机制:hive会把一个查询分为多个阶段,默认一次执行一个阶段,可以开启并发执行
严格模式:设置开启查询的严格模式
对于分区表，除非 where 语句中含有分区字段过滤条件来限制范围，否则不允许执行
对于使用了 order by 语句的查询，要求必须使用 limit 语句
限制笛卡尔积的查询
jvm重用机制
JVM 重用可以使得 JVM 实例在同一个 job 中重新使用 N 次
推测执行机制
针对执行比较慢的任务,启用一个备份任务,处理相同的数据,先完成的作为最终结果
???问题:
为什么要分层
清晰数据结构,数据血缘追踪,减少重复开发,把复杂问题简单化,屏蔽原始数据的异常
flume
分布式的海量日志采集、聚合和传输的软件
核心角色agent--java进程(运行在日志收集节点)
souorce:采集源,跟数据源对接
channel:管道,缓存数据
sink:下沉地,
event:数据传输过程中流动的是event(封装数据),基本单元
event headers,event body,event信息
启动flume采集日志
bin/flume-ng agent -c conf -f conf/新建的采集配置文件 -n agent的名字 -Dflume.root.logger=INFO,console
source
spooldir source:采集一个目录
exec source:采集一个文件
负载均衡load-balance:一个agent中的sink对应多个source进行分发数据(轮询,随机,hash取模)
当一个节点负载较大,无法承载的时候,可以将这个节点的请求,均匀分布在其他节点上,来共同承担负载
容错failover
一个agent监控文件变化,把数据根据权重大小发送给另外一个agent节点(主节点,有备份节点),主节点宕机后可以发送给备份节点
一般是一主一备,也可以一主多备
拦截器interceptor
timestamp interceptor:时间戳拦截器
static interceptor:静态拦截器 为event添加key-value 头信息
获取event的头信息:%{key}
自定义拦截器
自带的拦截器不能对日志内容进行操作
当需要删除一些不需要的字段时需要自己定义拦截器进行操作
自定义soruce和sink
一般情况下官方提供的就可以满足我们的需求
azkaban:工作流任务调度工具
oozie和azkaban对比
oozie: 知名度较高的是oozie:因为出现时间较早,
但是设置调度是基于xml的方式来配置任务调度依赖关系
提供了非常不友好的界面(等待时长和访问不方便)
azkaban:轻量级的调度工具
基于properties文件进行配置
只要能够在liunx命令操作的软件,都可以放置在azkaban上面运行
提供了一个非常友好的管理的界面:提交任务,配置等都可以操作,访问方便
开源的,免费的
sqoop:hadoop体系和RDBMS(关系数据库管理系统mysql,oracle等)体系之间数据的导入导出
导入导出命令翻译成mapreduce程序
导入:RDBMS--->HDFS 导出HDFS-->RDBMS
全量导入
增量导入
append
lastmodified
append:附加
merge-key:更新合并增加
导出
updateonly:只进行更新操作
allowinsert:更新操作的同时也进行了新增操作
网站流量日志分析项目
数据采集
数据:网站日志文件,页面埋点js自定义采集
js自定义采集
在页面中预先加入javascript代码,收集数据通过http参数方式传递给后端脚本
通用的方法(京东响应一张1*1图片)是js脚本创建一个Image对象，将Image对象的src属性指向后端脚本并携带参数，此时即实现了跨域请求后端
使用google提供的js引入方案,自调用匿名函数
flume采集数据
taildirsource:进行实时采集数据,替代spoordir+exec两个组件,同时监控目录和文件
数据预处理
点击流模型数据
pageviews:每次session内访问了几步和每一步的停留时间
visit:某一个会话session内，进入会话的起始页面和起始时间，会话结束是从哪个页面离开的，离开时间，本次session总共访问了几个页面等信息
数据仓库设计
数据仓库建模
事实表和维度表的确认
事实表:分析主题的度量,可以度量的数据存放(一堆主键的集合)
维度表:针对事实表从多个维度角度进行数据的分析(唯一的主键)
维度建模的三种模式
星型模式:一个事实表,多个维度表
雪花模式:一个事实表,多个维度表,但是维度表可以拥有其他维度表,实际中尽量避免这种模式,维护成本高效率低
星座模式:多张事实表,多个维度表,事实表可以共享维度表
注:本项目中使用的是星型模型,事实表是网站流量日志,维度表取决于业务
数据入库
导入到ods层
流量分析
基础指标
pv:页面访问总次数
uv:网站的独立访客数
vv:会话次数
复合级指标
平均访问频度
人均浏览页数(平均访问深度)
平均访问时长
跳出率
分析模型
基础分析(pv,uv等)
来源分析(来源分类,搜索引擎,搜索词,访客记录等)
受访分析(受访域名,受访页面,受访升降榜,热点图)
访客分析(地区运营商,终端详情,新老访客)
统计分析
数据导出
工作流调度的设置
数据模块的可视化
echarts:数据可视化图表工具,原先是百度的现在转给apache了
impala: 基于hive的大数据分析查询引擎
直接使用hive中的源数据库metadata
hive和impala的对比
impala没有使用mapreduce进行并行计算,使用的是执行计划树
hive采用推的方式来传递数据,impala采用拉的方式传递数据
hive内存不够时会采用外存,而impala会直接报错
hive任务调度依赖于Hadoop,impala调度由自己完成(simple-schedule)
hive依赖hadoop的容错,impala执行过程出现故障直接报错
hive复杂的批处理查询任务,impala实时数据分析(一般只针对hive中的数据)
impala的架构
impalad:impala服务
impala state store:跟踪集群中的Impalad的健康状态及位置信息
cli:impala客户端
catalogd:获取元数据信息并存放
impala操作
和hive中sql类似
oozie
工作流调度系统:按照DAG(有向无环图),基于xml文件进行配置
工作流节点两种类型
Control Flow Nodes : 控制工作流执行路径，包括start，end，kill，decision，fork,join
ActionNodes : 决定每个操作执行的任务类型，包括MapReduce、java、hive、shell等
工作流类型:
workflow:顺序执行流程,没有定时和条件触发功能
coordinator:将多个job组织起来,设置触发事件和频率
bundle:将多个coordinator管理起来
定时调度
基于时间的定时任务调度
设置起始时间,结束时间,执行调度频率
基于数据的任务调度
有了数据才会触发调度
hue:UI系统,在浏览器端的Web控制台上与Hadoop体系进行交互
界面集成框架,集成大数据体系软件框架
redis
nosql适用场景:分关系型数据库,key-value键值对存储数据库
高并发读写,海量数据读写,数据的可扩展性,快速的存取数据
常用的nosql
memcache
数据存在内存,不支持持久化,支持简单的key-value模式
redis
数据在内存,支持持久化(备份恢复),key-value模式,多种数据格式string,list,set,hash,zset
mongoDB
文档型数据库,数据在内存中(内存不足把不常用的数据存到磁盘),key-value模式(对value---尤其是json,提供了丰富的查询功能),
支持二进制数据及大型对象,
HBase
列式存储,对大量的数据进行随机、实时的读写操作
redis:数据存在内存中,可以定期写入到磁盘中备份(或写入追加的记录文件中),实现持久化
redis的特点
高效率,原子性,多种数据结构,稳定性(持久话,主从复制),支持过期时间,支持单行事务,消息订阅
数据类型
string,list,hash,set(string类型的无序集合,元素唯一),sorted set(zset,有序,唯一)
javaAPI操作
jedis
持久化:数据从内存到磁盘,避免数据丢失
RDB:快照机制的持久化
优点:持续化文件小,适合灾难性恢复
缺点:因持久化的时机问题,容易导致数据丢失
AOF:日志机制的持久化,所有操作命令都记录下来
优点:数据保存完整
缺点:文件很大,不适合灾难性恢复
注意:默认开启RDB机制的,实际生产环境中两者配合使用
共有16个数据库:编号从0-15 通过 select 编号 选择使用的数据库
主从复制架构
sentinel架构(哨兵)
集群模式的搭建
最少需要三个主节点,每个主节点需要一个从节点,所以需要三主三从的配置
???面试的问题
缓存穿透
---查询一个一定不存在的数据
由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩 filter提前拦截，不合法就不让这个请求到数据库层！
当我们从数据库找不到的时候，我们也将这个空对象设置到缓存里边去。下次再请求的时候，就可以从缓存里 边获取了。
缓存雪崩
---Redis挂掉了，请求全部走数据库。 对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。
对于“Redis挂掉了，请求全部走数据库”这种情况
事发前：实现Redis的高可用(主从架构+Sentinel（哨兵） 或者Redis Cluster（集群）)，尽量避免 Redis挂掉这种情况发生。
事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库 被干掉(起码能保证我们的服务还是能正常工作的)
事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。
对于“对缓存数据设置相同的过期时间，导致某段时间内缓存失效，请求全部走数据库。”这种情况
在缓存的时候给过期时间加上一个随机值，这样就会大幅度的减少缓存在同一时间过期。
HBase:是建立在hdfs之上，提供高可靠性、高性能、列存储、可伸缩、实时读写nosql的数据库系统。
存储结构化和半结构化数据
支持的数据类型: byte[]
hbase表的特点:大,面向列存储,稀疏表(在列值为空的时候不占用内存)
hbase基本特性
海量存储,列式存储(列族存储),极易扩展(上层处理能力,存储的扩展hdfs),高并发,稀疏
hbase基本架构
client:来进行对hbase的访问
zookeeper:管理hbase集群
确保只有一个master节点
存储region的位置信息
监控regionserver的状态并汇报给master
存储hbase表的schema,以及列族信息
master
监控regionserver
处理regionserver的故障
处理元数据的变更
处理region的分配和移除
进行数据的负载均衡
通过zk发布自己的位置给client
regionserver
存储实际数据
处理自己的region
刷新缓存到hdfs
维护hlog日志文件
执行压缩
负责处理region分片
hbase表模型
行键rowkey
列族column family:一般创建3-5个,创建表的是必须指定列族
列column
时间戳timestamp
版本号versionnum
hbase的shell操作
list
create
put
alter
scan
delete
删除表
disable 表名 禁用表
drop 表名 删除表
清空表
truncate 表名
查询
过滤器查询
rowkey过滤器 rowFilter
列族过滤器familyFilter
列过滤器QualifierFilter
列值过滤器ValueFilter
单列值过滤器 SingleColumnValueFilter
列值排除过滤器SingleColumnValueExcludeFilter
rowkey前缀过滤器PrefixFilter
分页过滤器PageFilter
多过滤器综合查询(new FilterList().addFilter(...))
hbase底层原理
架构(逻辑架构:region和store 物理架构:hlog,memstore和storefile)
一个hregionserver包含一个hlog(wal预写日志)和多个region
一个region包含多个store(包含一个列族的多有数据)
一个store包含一个memstore和多个storefile(hfile)
region的管理
region的分配
regionserver的上线
regionserver的下线
master的工作机制
master上线
1 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master。
2 扫描zookeeper上的server父节点，获得当前可用的region server列表。
3 和每个region server通信，获得当前已分配的region和region server的对应关系。
4 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。
master下线
zk监控master挂掉了,会删除创建的znode锁,standby master会在zk上进行创建锁成为active master
master中只维护表和region的元数据,宕机在短时间内对hbase集群没有影响,表的数据读写还可以正常运行,因为只要有regionserver参与
无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并
hbase写数据流程
1) hbase的客户端连接zookeeper, 获取hbase:meta表所在的regionserver地址
2) hbase的客户端连接对应regionserver, 从中获取meta表数据:
查询当前插入表对应region所在regionServer的服务器地址
3) hbase的客户端连接regionserver地址, 开始进行写入数据
4) 首先将数据写入HLog中 , 然后将数据写入对应region的对应memstore中
当这两个地方都写入成功后, 客户端认为数据是写入成功的
-----------------客户端任务结束了--------------------------------
5) 当memstore写满后, 启动flush机制:
5.1) 首先关闭当前写完的这个memstore中并且开启一个新的memstore
5.2) 将写完的内存的数据放置到一个队列中
5.3) 等待flush的子线程来读取队列中数据, 将其写入到hdfs上面, 形成一个
storeFile的文件
6) 当storeFile文件数量达到一定阈值(3个)后 . 启动compact机制:
主要目的: 将多个storeFile文件最终合并称为一个大的storeFIle文件
执行数据的删除, 数据更新 数据的排序
7) 当storeFile文件数据量达到一定的阈值(10gb)后 启动 split机制:
将storeFile一分为二的操作, 形成两个大storeFile文件 (物理操作)
8) 当storeFile被切割后, region也会执行切割操作, 形成两个region, 每一个
region管理一个storeFile文件即可, 具体由那个hregionserver来管理
region, 交于给Hmaster来决定, 在这个过程通知meta表更新region信息
hbase读数据流程
1) hbase的客户端连接zookeeper, 获取hbase:meta表所在的regionserver地址
2) hbase的客户端连接对应regionserver, 从中获取meta表数据():
查询当前查询表对应region所在regionServer的服务器地址
如果指定了rowkey 或者rowkey的范围, 返回对应region所在regionserver地址
如果没有执行rowkey, 返回当前表所在的所有region的regionserver
3) hbase的客户端连接regionserver地址: 并行执行, 开始读取数据
4) 在读取数据: 先到memstore中--->storeFile文件 ---> 读取最大的storeFile文件
尽量少说:blockCache--->缓存数据, 将那些经常读取的数据, 写入到cache缓存中去, 提高读取数据效率
5) 客户端返回对应数据
hbase三个重要机制
flush机制
regionserver全局的memstore大小默认是堆大小的40%,超过会触发regionserver的flush机制到磁盘的操作,阻塞客户端的读写
region中的memstore默认是128m,超过会触发region的flush
内存中的文件在自动刷新之前能够存活的最长时间默认是1小时
设置一个store中的storeflie文件个数(默认是3个),达到个数后会进行合并形成一个新的hfile文件
compact机制(把小的storefile文件合并为大的storefile文件)
minor : 将相邻的多个storeFile合并称为一个大的storeFile文件
对文件数据进行排序操作 不会对数据删除修改的 ----这个操作一般比较快
majar : 将minor执行后形成的文件和之前的storeFile文件再次合并操作:
这是完整的合并操作
对整个数据再次排序操作,如果发现有的数据已经被打了标记(修改, 删除) ,
如果是删除的, 直接跳过, 不输出. 如果是修改的数据, 默认版本号为1,
直接将历史数据删除, 将新的数据输出即可(时间戳)
split机制
当storefile达到一定的阈值(10G)后,触发split机制
将storefile一分为二,region也会进行切割,形成两个region
hbase和mapreduce的集成
hbase和hive的对比和集成
hbase和sqoop的集成
预分区:针对一个表按照行键进行切分,一个region管理startrowkey--endrowkey
作用:增加数据读写效率,负载均衡防止数据倾斜,方便集群容灾调度region,优化map的数量
设置预分区的方式(首先要确定rowkey的设计规则,来确定预分区的设置)
创建表的时候手动指定分区
创建表的时候用16进制生成分区
创建分区规则文件,创建表的时候指定该文件
使用javaAPI创建表的时候进行设置分区
rowkey的设计原则
长度原则:越短越好,不超过16k,降低存储内存和检索效率
散列原则:设计需要分散,避免出现数据倾斜
唯一原则:保证是唯一不重复的
热点问题
加盐处理:在rowkey前面增加随机数,是其均匀分布在不同的region中
哈希处理:同一行永远用一个前缀加盐
反转处理:固定产长度或数字格式的rowkey进行反转,例如手机号的反转
时间戳的反转:
协处理器:可以将计算过程放在server端,减少网络通信,提高性能
observer:一些散布在 HBase Server 端代码中的 hook(钩子)
regionObserver:客户端数据操纵的钩子
WALObserver:wal相关操作的的钩子
MasterObserver:DDL-类型操作的钩子
endpoint
主要是进行聚合操作,主要在client端进行工作
注:两种协处理器对比
Observer 允许集群在正常的客户端操作过程中可以有不同的行为表现
类似于 RDBMS 中的触发器，主要在服务端工作
可以实现权限管理、优先级设置、监控、 ddl 控制、 二级索引等功能
Endpoint 允许扩展集群的能力，对客户端应用开放新的运算命令
类似于 RDBMS 中的存储过程，主要在 client 端工作
可以实现 min、 max、 avg、 sum、 distinct、 group by 等功能
加载方式
静态加载和动态加载
二级索引:提高效率,达到以空间换时间
solr(es)+hbase方案
hbase调优
通用调优
namenode元数据目录的个数设置,备份时间间隔设置,备份采用ssd设置....
linux优化
开启系统的预读缓存设置,关闭进程睡眠池,调整ulimit上限默认值为比较小的数字,开启集群时间同步
hdfs优化
保证RPC调用的线程数,副本数,块大小的调整
mr优化
job任务服务线程数,http服务器工作线程数,文件排序合并,设置任务并发,传递输出数据的压缩,
hbase优化
开启hdfs追加同步配合hbase的数据同步和持久化,datanode允许的最大文件打开数量
数据操作的等待时间,写入效率,存储效率,hstore文件大小,hbase客户端缓存
内存优化
设置分配给hbase的内存大小为16-48G
jvm优化
开启并行gc,同时处理垃圾回收的线程数,禁用手动gc
zookeeper优化
设置会话超时时间(master和regionserver的交互)
namespace介绍
hbase版本的确界(上界和下界)
ELK:elasticsearch(lucene实现的),Logstash,Kibana
全文检索:将非结构化数据中的一部分数据提取出来重新组织成为结构化数据(称为索引),对结构化数据进行搜索
elasticsearch:实时分布式搜索和分析引擎(面向文档的,存储对象和文档)
es和solr对比
solr利用zk进行分布式管理,es自带分布式协调管理
solr支持多种数据格式,es仅支持json
solr适合于传统搜索,es实 时性更好
logstash:具有实时渠道能力的数据收集引擎
kibana:提供分析和可视化的web平台
kibana的查询
索引映射(mappings):为了指定字段的类型
索引库配置:修改分片和副本数
副本可以改,分片不能改
分页解决问题
size+from浅分页:数据量小的时候
scroll深分页
初始化:将符合条件的数据缓存起来
遍历:从初始化中取数据进行展示
安装ik分词器
因为中文分词比较复杂,所以需要安装插件来解决
es和hbase实现二级索引
第一大步骤
在es中创建对应索引库和对应类型,对应字段
在hbase中将数据读取出来,导入到es中建立索引体系
第二大步骤
接收用户关键词
根据关键词到es集群中查询,得到结果数据
获取文档的id值,根据es中的id(hbase中的rowkey)到hbase中获取数据返回给用户
kafka:消息队列,应用之间传送数据,分布式,分区的,副本的,多订阅者分布式MQ系统
常见的消息队列
RabbitMQ:可复用的企业消息系统
activeMQ:
RocketMQ
kafka:快速,可扩展,可持久化,分区特性,可复制,可容错
消息队列的两种模式
点对点模式
消息队列,生产者,消费者
不能重复消费
发布/订阅模式
角色主题,发布者(生产者),订阅者(消费者)
kafka架构
Kafka Cluster：由多个服务器组成。每个服务器单独的名字broker（掮客）。
kafka broker：kafka集群中包含的服务器
Kafka Producer：消息生产者、发布消息到 kafka 集群的终端或服务。
Kafka consumer：消息消费者、负责消费数据。
Kafka Topic: 主题，一类消息的名称。存储数据时将一类数据存放在某个topci下，消费数据也是消费一类数据。
kafka的元数据存放在zookeeper中
kafka的分片机制
解决单台服务器存储容量有限的问题(当文件太大时,可以分为多个部分,分片存储)
kafka的副本机制:只是为了容错,并发读写和吞吐量有分区来保证
提高了数据的高可用,容灾
kafka保证数据不丢失
生产者不丢失
消息确认状态ack码:0 只负责发送数据,1 一个主分片收到数据,-1 所有partition的副本都收到数据
生产模式:同步和异步
broker端不丢失
设置ack为-1 保证数据都写入成功
消费者不丢失
通过提交偏移量来保证(offset commit)
kafka存储机制和查询机制
存储机制
segment中有两个文件log,index
当log文件达到1g时,就会向下一个segment中写数据
查询机制
index文件名中的数字代表起始偏移量
可以根据数据偏移量确定数据在那个文件中来查找
生产者分发策略
可以自己指定分区
根据key计算hash值来确定分区
使用轮询的方式
消费者负载均衡
一个partition只能被一个组中的成员消费
CAP理论及kafka中的CAP机制
consistency一致性,availability可用性,partition tolerance分区容错性
cap理论:分布式系统中,一致性,可用性和分区容错性最多只能同时满足两个
kafka满足CA,使用ISR同步策略尽可能减少分区容错问题
kafka集群的监控和运维
安装kafka-eagle来实现
注:一个Topic可以被多个消费者或者组订阅，一个消费者/组也可以订阅多个主题
kudu
kudu:随机读写,高吞吐的数据分析,(吞吐量不如hdfs,随机读写不如hbase)
kudu架构
表（Table）是数据库中用来存储数据的对象，是有结构的数据集合
kudu中的表具有schema（纲要）和全局有序的primary key（主键）
tablet(kudu表的水平分区，类似于HBase的region),table server(数据存储,读写服务),master server(管理集群,元数据管理)
scala:模式匹配和提取器两大功能
伴生类和伴生对象
名字相同的class(伴生类)和object(伴生对象)
样例类:使用case修饰的class
方法
apply方法
快速的使用类名来创建对象
tostring方法
equals方法
hashcode方法
copy方法
unapply方法
实现将对象拆分成一个个元素
样例对象:使用case修饰的object
模式匹配
偏函数:模式匹配中去除match后
泛型:和java中类似
上下界
上界:[T <: 类型] T必须为指定类或指定类的子类
下界:[T >: 类型] T必须为指定类或指定类的父类
非变[T]
class Pair[T]
类型B是A的子类型，Pair[A]和Pair[B]没有任何从属关系
协变[+T]
class Pair[+T]
类型B是A的子类型，Pair[B]可以认为是Pair[A]的子类型
逆变[-T]
class Pair[-T]
类型B是A的子类型，Pair[A]反过来可以认为是Pair[B]的子类型
函数的柯里化
原先接受多个参数的方法转换为多个只有一个参数的参数列表的过程。
相当于把参数列表的参数: 从"一个多"变为"多个一"的过程.
func(1,1)--->func(1)(1)
函数的闭包
闭包其实就是一个函数，只不过这个函数的返回值依赖于声明在函数外部的变量。
可以简单认为，就是可以访问不在当前作用域范围的一个函数。
注:柯里化也是一种闭包
隐式转换和隐式参数(使用implict修饰)
以implicit关键字声明的带有 单个参数 的方法。它是自动被调用的，自动将某种类型转换为另外一种类型
spark:大规模数据处理的统一分析引擎,分布式计算工具
速度快,方便使用,通用,兼容性(运行在各个地方)
Spark可以用于批处理、交互式查询(Spark SQL)、实时流处理(Spark Streaming)、机器学习(Spark MLlib)和图计算(GraphX)
spark安装部署
local单机模式:解压即可使用
standlone独立集群模式
standlone-HA高可用模式
使用zookeeper进行管理(原理面试)
on-yarn模式:将spark打成jar包交给yarn去运行,和spark集群本身没有关系
cluster模式:driver程序运行在yarn集群中,结果在driver输出,客户端看不到
一般开发中使用的比较多
client模式:driver程序在client运行,driver输出结果,客户端能看到
spark core
RDD:弹性的分布式数据集/分布式集合
特点:分区列表,计算函数,依赖关系列表,分区器/分区函数(默认为HashPartitioner),最佳位置列表(存储的位置)
创建rdd
sc.textfile("path")
rdd.flatMap/map/reduceByKey方法()
sc.parallelize/makeRDD(scala集合/列表/数组)
方法
transformation操作:rdd的转换
action操作:rdd的收集和存储
注意:transformation操作不会立即执行,调用action才会触发执行
Spark会在调用Actino操作的时候,对整个的Spark任务做一些步骤的优化
RDD不真正的存储数据,只在Action操作时,才真正的去加载数据进行计算
rdd创建的时候默认分区是2:分区可以说就是并行度
RDD分区的原则是使得分区的个数尽量等于集群中的CPU核心(core)数目，这样可以充分利用CPU的计算资源
在实际中为了更加充分的压榨CPU的计算资源,会把并行度设置为cpu核数的2~3倍
注:大部分框架的分区都是为了提高效率(读写效率,查询效率,提高并行度)
算子演示
持久化/缓存
对于频繁使用的rdd进行缓存来提高运算的效率
rdd.cache()进行rdd的缓存
内存不够是可以缓存到磁盘中rdd.persist(StorageLevel.MEMORY_AND_DISK_2)
容错机制--checkpoint
RDD的计算成本很高,数据比较重要, 那么仅仅只做缓存/持久化还是不够的, 应该要将该RDD的计算结果存放到一个更加安全的位置
设置checkpoint的路径sc.setCheckpointDir("path"),需要存储的rdd:rdd.checkpoint
rdd依赖关系
窄依赖:父rdd的一个分区只会被子rdd的一个分区所依赖
宽依赖:父rdd的一个分区被子rdd的多个分区所依赖
注:子rdd的一个分区依赖多个父rdd是宽依赖还是窄依赖?-----不能确定,需要看父rdd的分区被多少子rdd分区依赖
DAG:有向无环图,数据执行转换的流程
stage:可以根据宽依赖来划分
从后往前进行判断是否是宽依赖(回溯算法)
原理名词
application
driver
cluster manager
executor
rdd
DAG
job
stage
task
累加器:accumulators
rdd是在分布式环境运行,创建在driver端,但是执行在worker节点executor进程中,不会把累加结果给到driver
使用累加器,支持在所有不同节点进行累加
广播变量:broadcast variables
用来把变量在所有节点的内存之间进行共享
意思就是把经常使用的数据广播出去,提高效率节省资源
spark sql
容易整合,统一的数据访问,兼容hive,标准的数据连接
数据抽象:底层都是rdd
DataFrame:一个分布式表
RDD-泛型+Schema+sql操作+优化
DataSet:DF+泛型+优化
RDD+Schema+sql操作+优化
查询风格
SQL风格
DSL风格
创建DF/DS
样例类+反射
指定类型和列名
添加StructType
注:使用spark.read.text("path")返回值是DF,spark.read.textFile("path")返回值为DS
sparksql读写数据
读数据:spark.read.text/json/parquet/csv/jdbc === 底层:spark.read.format("格式").load
写数据:df/ds.write.text/json/parquet/csv/jdbc === 底层:df/ds.write.format("格式").save
spark整合hive:spar-on-hive模式,针对hive的元数据使用sparksql的引擎进行操作
IDEA中使用Spark整合hive只需要将这些配置文件放到项目的配置文件目录(core-site.xml,hdfs-site.xml,hive-site.xml)
SparkStreaming:流式处理计算框架,实时性只能做到秒级(500ms-10s....)
特点:容易使用,容错,整合到spark体系(流式处理,批处理,交互式查询结合)
原理:将源源不断的数据按照时间批次划分成一个个的小批次数据,可以使用sparkCore的处理引擎
数据抽象:底层是rdd
DStream:离散化的数据流(源源不断的数据流),
本质是一系列时间连续上的rdd
对于DStream的操作就相当于对里面的每一个RDD进行操作
容错性,DStream底层的RDD具有容错性,所以DStream也具有容错性
近实时/准实时性
API操作
transformation
无状态转换:map/flatmap/filter...和rdd一样
有状态转换:updateStateByKey(func) 根据key进行状态操作
窗口操作:reduceByKeyAndWindow等
action/output
saveAsTextFiles/xxx和RDD中一样
print():直接打印dstream中的内容
foreachRDD(func):循环遍历DStream中的每一个RDD
updateStateByKey:有状态计算,记录上一次的计算结构
窗口(三种情况)
窗口大小,滑动间隔
sparkstreaming和kafka整合两种模式(面试)
Receiver模式
1.会开启一个Receiver接收器接收Kafka的数据,但是一个Receiver效率低,多个Receiver又需要手动合并union数据,很麻烦
2.如果Receiver挂了,会导致数据丢失,如果开启WAL预写日志,效率又低
3.Receiver使用的是Kafka的高阶(高层/封装)API,offset由Receiver维护在ZK中, Spark也会维护一份在Checkpoint中,可能会不一致
Direct模式(开发中使用这个)
1.SparkStreaming直接连接Kafka的各个分区,速度非常快
2.Direct模式使用的是Kafka的低阶(底层)API,offset默认由Spark维护在Checkpoint中,offset也可以由程序员手动维护在MySQL/Redis中, 这样可以保证数据Exactly Once(精准一次)
sparkstreaming存在的问题
延迟高,不支持连续处理
不支持基于事件时间处理数据
流处理/批处理的api没有统一
StructureStreaming:基于sparksql处理数据,统一了流/批处理的api
DataFlow Model
对事件发生时间进行处理
事件时间和处理时间
event_time:事件实际发生的时间
process_time:处理时间,事件系统发现/接收到的时间
数据抽象
DataFrame,DataSet
Source:数据源
Operator:对DF/DS的操作,和sparksql中一样
Sink:数据输出源(下沉地)
outputmode参数值类型:append默认(只输出新增数据),聚合使用complete(输出整个结果表),更新输出update(只输出有更新的结果数据)
扩展:二分查找,IP地址转long,位运算
spark专业术语
application:spark应用程序,用户编写的spark代码,包含driver,executor代码
driver:驱动程序
clustermanager:资源管理器(mster/resourcemanger)
worker/nodemanager:进行任务的真正运行计算(worker中有多个executor进程)
executor:执行器/执行进程(里面有多个task线程---task数=分区数>=cpu核数)
RDD:弹性分布式数据集--=分区列表,计算函数,依赖关系,分区器,最佳位置
窄依赖:一对一
宽依赖:一对多
DAG:有向无环图(一个action形成一个),就是一个job(根据宽依赖划分为stage)
DAGScheduler:
TaskScheduler:
job:
stage:
taskset:
task:
spark运行的特点
进程专属
支持多种资源管理器
job就近提交
移动程序的执行原则:移动计算比移动数据划算
spark源码解析
spark性能优化----笔试面试都会有(哪些方面的调优)
基础优化:尽量将任务分配的资源调节到可以使用的资源的最大限度
资源参数的设置(任务分配更多的资源)
增加executor的个数,增加每个executor的cpu的个数,增加每个executor的内存量
并行度设置
spark作业中的并行度指各个stage的task的数量,设置适当,否则惠导致资源浪费
使用缓存和checkpoint
避免数据丢失和重复进行计算,但checkpoint写入hdfs对性能消耗比较大
使用广播变量:将经常使用的数据广播出去
使用kryo序列化
默认使用java的序列化机制,kryo序列化比java系列化机制性能提高10倍,原因是不支持所有对象的序列化同时kryo需要用户在使用前注册需要序列化的类型
spark2.0后,简单类型,简单类型数组,字符串类型的rdd已经默认使用kryo序列化
本地化等待时长设置
进程本地化(process_local):task和数据在同一个executor中,性能最好
节点本地化(node_local):task和数据在同一个节点中,数据需要在进程间传输
机架本地化(reck_local):同一机架的两个节点上,数据需要通过网络节点之间进行传输
(no_pref):从哪里获取数据都一样,没有好坏之分
(any):task和数据可以在集群的任何地方,而且不在一个机架上,性能最差
算子调优
rdd的复用
读取小文件使用wholeTextFiles(分区数有参数决定)
尽早的filter:过滤不需要的数据,减少内存的占用,提高作业运行的效率
mappartition/foreachpartition:每个分区的数组组成的迭代器(企业中使用这个,提高效率)
当内存不够处理一整个分区的时候就会发生内存报错的问题
foreach:对每一个元素进行处理
filter+coalesce减少分区
reducebykey本地预聚合
在map端提前进行处理本地聚合,
groupbykey不会进行map端的聚合,会把数据shuflle到reduce端再进行聚合
shuffle调优
map和reduce端缓存区(内存)的大小
map端:设置缓存大小,大了可以减少shuffle中map端溢写文件的次数
reduce端:大了可以减少reduce端拉取次数
reduce端拉取重试次数和等待的时间间隔
重试次数:耗时的shuffle操作的作业,增加重试次数(默认是3次)
等待时间间隔:因网络原因导致任务重复失败后,设定增大等待间隔时长(默认5s),增加shuffle操作的稳定性
bypass机制开启阈值
如果需要排序使用普通机制 reduceTask>阈值(默认200)
如果不需要排序使用bypass机制 reduceTask<阈值(默认200)
jvm参数调优
降低cache内存提高用于计算的内存---val conf = new SparkConf().set("spark.storage.memoryFraction", "0.4")
设置Executor堆外内存--不是JVM内存--conf spark.yarn.executor.memoryOverhead=2048
设置JVM进程间通信等待时间--conf spark.core.connection.ack.wait.timeout=300
数据倾斜
预处理导致倾斜的key
过滤:将可能导致数据倾斜的key进行过滤清除
使用随机key
提高reduce并行度
使用mapjoin
spark在什么情况下会发生数据丢失?(数据丢失的场景)
断电宕机,
spark开发常见问题
内存溢出(oom)
spark内存模型:execution内存,storage内存,other内存
a.driver内存溢出(driver heap oom)
b.map task所运行的executor内存溢出
c.shuffle(reduce)阶段的内存溢出
gc导致的shuffle文件拉取失败:调大重试次数/调大拉取等待时间
yarn_cluster模式jvm栈内存溢出--conf spark.driver.extraJavaOptions="-XX:PermSize=128M -XX:MaxPermSize=256M"
避免sparksql的jvm内存溢出
将长sql拆分成多条短sql去分步执行,避免过多的表进行join操作
spark内存管理
堆内和堆外
sparkMLlib: 数据类型,算法以及工具---通用的学习算法和工具组成--底层运算都是基于线性代数
算法工具,特征化工具,管道,持久化工具...
api分为两个包
spark.mllib--基于RDD的原始算法api
spark.ml--基于dataframes的高层次api,可以用来构建工作流(Pipeline)
数据类型
向量:一组数据组成的集合
矩阵:多个向量组成的集合
具体分为:本地向量(LocalVector),标签向量(LabaledPoint),本地矩阵(LocalMatrix),分布式矩阵(DistributeMatrix)
sparkmllib特征工程
TF-IDF:从文本中提取出重要的词汇---值越大越好
可以做文章的分类,如海量新闻爬取,自动分类..
Word2Vec:将文本转为词向量
可以获取词向量
CountVectorizer:统计词汇出现的频率
sparkmllib特征转换
StringIndexer:对特征数据性编码
IndexToString:对编码后的特征进行还原
OneHotEncoder:独热编码
注意:OneHotEncoder只能对数值对象进行编码,需要相对红 绿 蓝进行StringIndexer编码在进行OneHotEncoder编码
最后的输出结果是稀疏向量,观察的话需要手动还原
StandardScaler: 将数据转换为一个符合标准正态分布的数据
sparkmllib特征选择
ChiSqSelector:卡方检验挑选出和结果列/标签列/目标列最为相关的n个特征
VectorAssembler:向量装配器-可以将多列数据转为/装配为一个向量
K-means聚类算法:物以类聚人以群分,按照数据相似性进行分群--按照数据之间的距离来进行聚类(选定聚类中心点)
过程分析
0.确定K值,也就是要聚为几类 ,如3类,还有选择初始化的聚类中心的位置(随机选),设置最大迭代次数,如10次
1.计算各个点到各个聚类中心的位置,离哪个聚类中心近,就聚为哪一类
2.重新计算各个聚类的新的聚类中心的位置(也就是求一下各个聚类的新的质心/重心/中心)
3.判断是否达到了终止条件(达到了最大迭代次数或聚类中心不再变化),如果达到了就结束聚完了,如果没达到就重复执行123
K值的确定
RFM分析(客户价值模型):R--最近一次消费,F--最近一段时间的消费频率,M--最近一段时间的消费金额
衡量当前用户的价值和客户潜在价值
RFE分析(用户活跃度模型)
PSM分析(用户价格敏感度模型)
flink:分布式大数据处理引擎--核心是一个数据流引擎---实时的流式计算框架
特点
支持高吞吐,低延迟,高性能
支持事件时间概念
支持有状态计算
高度灵活的窗口操作
基于轻量级分布式快照(Snapshot/Checkpoints)的容错机制
基于jvm实现独立的内存管理
支持savepoints保存点
大数据项目架构
Lambda:数据分为两条流:流式计算平台,离线计算平台
Kappa:实时计算和批处理过程使用同一套代码
IOTA:所有的计算过程分散在数据产生、计算和查询过程中
flink的四大基石
checkpoint:分布式一致性的快照
state:有状态的计算
time:watermark水印时间,数据事件时间
window:滚动窗口,滑动窗口,会话窗口,自定义窗口
flink安装运行模式
local本地模式
standlone集群模式
standlone-ha集群模式
flink on yarn模式
session会话模式(小任务执行)
yarn-session.sh(开辟资源) + flink run(提交任务
/export/servers/flink/bin/yarn-session.sh -n 2 -tm 800 -s 1 -d
/export/servers/flink/bin/flink run /export/servers/flink/examples/batch/WordCount.jar
job分离模式(开发中使用的比较多,一般适合大任务)
/export/servers/flink/bin/flink run -m yarn-cluster -yn 2 -yjm 1024 -ytm 1024 /export/servers/flink/examples/batch/WordCount.jar
数据抽象
DataSet
DataStream
触发执行
execute(),count(),collect(),print()
flink的批处理--DataSet
source
基于集合的
env.formElements(可变参数)
env.formCollection(集合)
env.generateSequence(start,end)
基于文件的
env.readTextFile("path")
env.readCsvFile[泛型]("csv文件")
transformation
map和mapPartition,flatMap,filter,reduce,reduceGroup,Aggregate,distinct,join
左外连接(leftOuterJoin),右外连接(rightOuterJoin),全外连接(fullOuterJoin)
Union(并集不去重),Reblance(内部使用round robin方法将数据均匀打散)
min(返回最小的数据)和minBy(返回最小值所在的一整条数据)
corss(笛卡尔积)
sink
print(),printToErr(),collect(),writeTextFile(path,WriteMode.OVERWRITE)
注:不管本地还是hdfs,parallelism>1将把path当成目录名称,=1将把path当成文件名
创建运行环境
ExecutionEnvitonment.createLocalEnvironment() 本地环境
ExecutionEnvitonment.createRemoteEnvironment("hostname",port,"jar包") 集群环境(一般flink run)
ExecutionEnvitonment.getExecutionEnvironment() 根据实际情况创建环境(推荐)
广播变量
将变量(小变量)发给各个TaskManager,然后各个TaskManager中的subTask可以去各自的TaskManager中获取广播变量
累加器
在全局创建一个累加器变量,然后各个SubTask可以将数值累加到该累加器中
分布式缓存文件
是将文件(小文件)发给各个TaskManager,然后各个TaskManager中的subTask可以去各自的TaskManager中获取文件
flink流处理---DataStream----StreamExecutionEnvironment.getExecutionEnvironment
source
基于集合
senv.fromElements
senv.fromCollection
senv.generateSequence
基于文件
senv.readTextFile
基于socket---用于测试,监听端口号
自定义非并行数据源---继承SourceFunction[泛型]
自定义并行数据源---继承parallelSourceFunction[泛型]
自定义多功能并行数据源(常用)----继承RichParallelSourceFunction[泛型]
自定义mysql数据源---继承RichParallelSourceFunction
自定义kafka数据源
transformation
keyBy流处理中使用,批处理中使用groupBy
connect:将不同类型的DataStream进行连接,返回的ConnectedStreams[类型, 类型]中的泛型就是两个被连接的数据类型
分区
sink
下沉到mysql---继承RichSinkFunction[泛型]
下沉到kafka
下沉到redis
注:流处理需要单独开启执行execute()
flink的窗口操作
按照时间和数量划分:time-window,count-window
窗口长度和滑动间隔分:滚动窗口,滑动窗口
基于时间的滑动窗口timeWindow()
基于时间的滚动窗口timeWindow()
基于数量的滑动窗口countWindow()
基于数量的滚动窗口countWindow()
会话窗口SessionWindows():会话窗口必须基于事件时间
注:对于一些复杂的window操作可以使用apply方法
EventTime-Watermaker:基于事件时间的水印时间
水印时间=事件时间-允许最大延迟时间
水印事件>=窗口结束时间---才能触发窗口计算
Allowed Lateness 允许延迟/侧道输出
解决watermark+EventTimeWindow解决不了的数据乱序问题
状态管理计算
flink的容错--checkpoint:周期性地基于Stream中各个Operator的状态来生成Snapshot快照,
checkpoint和state的区别
state
一般代表算子的运算产生的中间结果,一个task/operator的状态
默认保存到java的堆内存中/taskmanager节点内存中
可以被记录,失败的情况下数据还可以恢复
checkpoint
全局状态的快照,所有的task/operator的状态
把stage的数据进行持久化
比如KafkaConsumer算子中维护的Offset状态,当任务重新恢复的时候可以从Checkpoint中获取
checkpoint的执行流程
每个需要checkpoint 的应用在启动时， Flink 的JobManager 为其创建一个CheckpointCoordinator(检查点协调器)，CheckpointCoordinator 全权负责本应用的快照制作
CheckpointCoordinator周期性的向该流应用的所有Source算子发送Barrier(栅栏)
当某个Source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自己快照制作情况，同时向自身所有下游算子广播该Barrier，恢复数据处理
下游算子收到Barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身快照情况，同时向自身所有下游算子广播该Barrier，恢复数据处理。
每个算子按照步骤3不断制作快照并向下游广播，直到最后Barrier传递到Sink算子，快照制作完成
当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败
checkpoint持久化存储方式
MemoryStateBackend--内存存储,不推荐生产环境使用
推荐使用的场景为：本地测试、几乎无状态的作业，比如 ETL、JobManager 不容易挂，或挂掉影响不大的情况
FsStateBackend--state存储在内存,checkpoint存储在文件系统中,生产环境中使用
注:分布式情况下,不推荐使用本地文件
推荐使用的场景为：常规使用状态的作业、例如分钟级窗口聚合或 join、需要开启HA的作业
RocksDBStateBackend-- key/value 的内存存储系统,先存入内存,内存不足时存入磁盘
注:唯一增量checkpoint的Backend
推荐使用的场景为:超大状态的作业/有增量Checkpoint的需求的时候,例如天级窗口聚合、需要开启 HA 的作业、最好是对状态读写性能要求不高的作业
checkpoint的设置
全局设置:修改配置文件flink-conf.yaml
单任务设置:env.setStateBackend(new FsStateBackend("path")--实际开发中使用
flink容错--重启策略---checkpoint启动才会有重启策略,默认固定延迟策略(次数不限,无限重启)
固定延迟重启--fixed delay
发生异常每隔多少秒重启一次,共多少次
失败率重启--failure delay
无重启策略--no restart
flink容错--savepoint
flink-sql
flink程序优化
flink checkpoint进行容错处理
开启checkpoint--设置保存的hdfs的位置--配置最小时间间隔,最大线程数,超时时间--配置程序关闭额外触发checkpoint--配置重启策略
flink时间窗口
watermark水印时间
并行度优化
kafka中topic的分区数量
kafka中datastream并行度和kafka的分区一致
hbase的sink为6个分区
flink反压原理
背压问题
流系统中消息的处理速度跟不上消息的发送速度,会导致消息的堆积
产生的原因
垃圾回收卡顿可能会导致流入的数据快速堆积
一个数据源可能生产数据的速度过快
解决方案
将拥堵的消息直接删除--会导致数据丢失，许多流处理程序而言是不可接受的
将缓冲区持久化，以方便在处理失败的情况下进行数据重放--会导致缓冲区积压的数据越来越多
将拥堵的消息缓存起来，并告知消息发送者减缓消息发送的速度--对source进行限流来适配整个pipeline中最慢组件的速度，从而获得稳定状态
Flink CEP
CEP:复杂事件处理,基于流处理的技术
canal
MySQL开启BinLog日志记录功能
原理:canal本质时伪装成一个mysql的从节点,从mysql中同步binlog日志
canal伪装成一个mysql slave,向master发送dump协议
mysql接收dump请求,将binlog发送给canal,canal解析binlog
离线数仓项目
Kettle
ETL(数据的抽取,转换,加载)工具
缓慢变化维(SCD):随着时间发生变化的维度
拉链表:增加列---开始时间,结束时间
业务开发分析
DataX:离线数据同步工具/平台
优点:性能好,每秒1万条记录,适合高性能的场景,适用于数据直连方式的数据同步
缺点:配置繁琐没有图形化界面,无法对数据进行复杂转换操作
核心组件
reader:数据采集模块,从源采集数据
writer:数据写入模块,负责写入目标库
framework:用于连接reader和writer，作为两者的数据传输通道，并处理缓冲，流控，并发，数据转换等核心技术问题
zeppeline:数据可视化的框架
kylin:OLAP引擎--
维度和度量
维度是观察数据的角度,度量是被聚合的统计值
cube和cuboid
cuboid:每一种维度的组合，将度量做聚合运算，然后将运算的结果保存为一个物化视图，称为Cuboid（立方形）
cube:所有维度组合的Cuboid作为一个整体，被称为Cube（立方体）。一个Cube就是许多按维度聚合的物化视图的集合
注:有n个dimension的cube会有2^n个cuboid
工作原理----本质上是多维立体分析(mloap cube)
指定数据模型model,定义维度和度量--与计算cube,计算所有的cuboid保存为物化视图--执行查询时,读取cuboid,运算产生查询结果
理解cube,cuboid,segment的关系
可以简单的理解为segment(代表一段时间内源数据的预计算结果,是指定时间范围的cube,可以理解为cube的分区,对应hbase中第一张表)是因为增量构建形成的,用起始时间和结束时间来标识
全量构建不会形成segment,一个cube中可以有多个segment
segment中包含所有的chuboid
全量构建和增量构建
cube碎片管理
使用jdbc操作kylin
使用zeppelin操作kylin
kylin cube优化--cuboid剪枝优化---构建cube的时候选择跳过哪些多余的cuboid,减少额外的空间占用方法
cuboid的数量
cube的大小
当前cube的大小/源数据的大小====膨胀率(一般在0%-1000%)
膨胀率高的原因:
cube中维度数量较多,没有很好的cuboid剪枝优化,导致cuboid数量较多
cube中存在较高基数的维度,导致包含这类维度的每一个Cuboid占用的空间都很大，这些Cuboid累积造成整体Cube体积变大
存在比较占用空间的度量
使用衍生维度
聚合组
实时数仓项目
protocol buffers(protobuf):一种数据格式---生成的是字节码,可读性比较差
phoenix
基于HBase的开源SQL引擎
Druid:开源的,分布式,面向列式存储的实时分析数据存储系统---OLAP分析存储系统
数据摄取
静态数据源--本地/hdfs
流式数据源--kafka
架构和原理
5个节点
Overlord节点:主节点,接受索引任务,对内负责将任务分解并下发给MiddleManager
MiddleManager节点:执行任务的工作节点,将任务发给单独的jvm运行的peon(只能运行一个任务)
Coordinator节点:Historical的mater节点，主要负责管理和分发Segment
Historical节点:管理历史的segment:
Broker节点:转发client查询请求
数据存储:基于datasource与segment的数据存储结构
imply: 基于druid进行了一些组件的开发
superset:开源的数据分析和可视化工具
对接mysql数据库,对接kylin,对接druid
springBoot:可以快速的使用spring
常见的注解:
//指定当前类是数据库的一个实体类, 默认情况下,去数据库查找当前类名的表
@Entity
//可以自动生成get/set方法
@Data
//无参构造
@NoArgsConstructor
//有参构造
@AllArgsConstructor
//指定当前字段为数据库中的ID
@Id
//指定ID的生成策略,设置为自增
@GeneratedValue(strategy = GenerationType.IDENTITY)
//指定列信息,默认情况下,找当前字段名的列,如果字段名和列名不同,可以指定到对应的列名
@Column()
@GetMapping //定义请求方式为Get.
@PutMapping //定义请求方式为Put.
@PostMapping //定义请求方式为Post.
@DeleteMapping //定义请求方式为Delete.
//定义一个Spring的组件
@Component
//下面3个都是Component的儿子
@Service
@Repository
@Controller
//将返回值转换为JSON,由SpringMVC自己完成.
@ResponseBody
//包含Controller和ResponseBody
@RestController
机器学习
整体流程
需求分析,数据预处理,特征工程,算法建模,模型评估,模型应用
最主要的是特征工程
基本术语
数据集:这组记录的集合,每条记录为样本
特征/属性
特征值/属性值
特征向量
训练集
算法模型的分类
有监督学习:数据集中有标签列的值
分类问题(离散值)
回归问题(连续值)
无监督学习:数据集中没有标签列/结果列
聚类问题:将具有相似特征的数据聚为一类
数据降维:数据的主要特征保留,次要特征舍弃
半监督学习: 使用有监督学习方法先处理一部分有标记的数据, 训练场模型, 然后再用该模型套用哪些大量的未标记的数据, 并将结果和人工标记的部分数据进行对比,再改进模型,提高模型的效果
强化学习:
模型选择-----泛化能力:指的是模型在新数据上的适应能力
欠拟合:数据在训练集/测试集上的表现都很差(泛化能力差)
产生的原因:模型过于简单/数据太少没有充分利用
解决:增加模型复杂度增加参数/增加数据/增加特征项....
过拟合: 数据在训练集上表现良好, 在测试集(新数据)上表现不好(泛化能力差)
产生的原因:模型过于复杂/噪声数据太多/特征选择过多
如何解决:简化模型减少参数/加强数据预处理/特征工程...
机器学习的交叉验证
简单交叉验证:将数据集按照8:2/7:3分为训练集:测试集
k折交叉验证:数据分为k份,每次依次取出其中的一份用来做测试集,剩下的用来做训练集
留一验证:只使用样本数据中的一项(条)当作验证数据，而剩下的全作为训练数据，一直重复，直到所有的样本都作验证数据一次
机器学习三要素
模型--数据符合的规律/函数
策略--评价模型好坏的误差函数
0-1损失函数
平方损失函数
绝对损失函数
对数损失函数/对数似然损失函数
注:损失函数数值越小,模型越好
算法--求解函数最优解的过程函数
指的是使用哪种算法求解函数最优值(较优值)
可以理解为使用怎样的数学方法求解模型参数--最小二乘法/梯度下降法...
扫一扫
1999
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
