《大数据技术体系详解:原理、架构与实践_董西成(著)》
-
flume篇
-
如何保证以下情况,flume不会丢失数据
-
Agent所在机器突然crash,机器重启后恢复;
-
Agent所在机器突然crash,机器重启后无法恢复;
-
-
假设公司有10台web应用,试说明如何收集这些机器弄下nginx的日志(存放目录:/var/log/nginx),并保证数据不丢失情况下存在hdfs,请给出配置文件内容和Agent的启动方式
-
-
kafka篇
-
kakfa不能保证数据的时序性,即producer发送的消息x,y写入broker,comsumer读出的消息可能是y,x,若需要使用kafka保证数据时序性,有哪些可行方案;
-
尝试使用低阶API,编写consumer读取数据,并将offset存在zookeeper,以便故障恢复
-
比较kafka和flum的异同;
-
数据存储篇
-
数据序列化和存储格式
-
分布式文件系统
-
hdfs
-
datanode挂了后,如何在其他节点重构丢失数据?
-
namenode的主备切换和状态同步
-
文件的分块操作在客户端完成
-
namenode federation机制,viewFs作用;
-
容错性设计
-
namenode故障:导致整个文件系统不可用,解决方案:激活standby namenode
-
datanode故障:不影响使用,可以重构其他节点的相同副本
-
数据块损坏:通过校验码校验,由namenode负责重构正常副本的数据块;
-
-
副本放置策略
-
考虑因素:读写性能,可靠性
-
通讯模式:相同机架,内部交换机通信 不同机架:外部节点通信,延迟高;
-
客户端与datanode同节点:xxxxx;客户端与datanode不同节点:xxxxx
-
-
存储介质
- ARCHIVE(高存储密度,耗电少,存储冷数据),DISK(磁盘介质,默认),SSD(固定硬盘),RAM_DISK等
-
集中式缓存管理
-
缓存在内存中
-
提高内存使用率
-
防止那些被频繁使用的数据从内存清除
-
提供数据的稳定性
-
支持zero-copy,缓存数据已被校验过,新API使用零开销;
-
-
-
hdfs访问方式
-
hdfs shell
-
dfs:文件操作命令 dfs -moveFromLocal xxx dir
-
fsck:文件一致性检查命令 fsck dir -files -blocks -locations
-
distcp:分布式文件复制命令,集群内并行复制和集群间并行复制 distcp hdfs://nn1:8020/xxx hdfs:nn2:8020/yyyy
-
dfsadmin 管理员命令
-
-
-
InputFormat和OutputFormat
-
问题:
-
HDFS不合适存储大量小文件的原因
- https://blog.csdn.net/SunnyYoona/article/details/53870077
-
HDFS建议存储三个副本的原因
-
HDFS 默认设置数据库为128M的好处
-
查看文件副本数和调整block大小
-
hadoop fsck -setrep -w 1 -R dir #修改dir 目录的副本数为1
-
修改hdfs-site.xml中的dfs.replication的值,只对client端起作用
-
hadoop dfs -D dfs.replication=1 -put 80M dir # 上传文件同时指定副本数
-
hadoop fs -stat dir 查看目录的副本数和block情况
-
修改垃圾桶文件保留时间 fs.trash.interval # 回收站保留时间(分钟)
- https://blog.csdn.net/silentwolfyh/article/details/53907118 (回收站操作)
-
设置datanode可接受最多损坏磁盘数目2
-
将机器中某一个datanode加入黑名单
-
-
导致Balance操作的失败
-
1、整个集群已经达到平衡状态
-
2、经过计算发现没有可以被移动的block块
-
3、在连续5次的迭代中,没有block块被移动
-
4、当datanode节点与namenode节点通信的时候,发生IO异常
-
5、已经存在一个Balance操作
-
-
hdfs 集群节点动态添加和删除
-
参考地址
-
https://cloud.tencent.com/developer/article/1031641
-
https://www.cnblogs.com/yinzhengjie/articles/11063804.html
-
-
-
-
-
分布式结构化存储
-
hbase
-
数据模型
-
逻辑模型
-
物理模型
-
{rowkey,colum family,colum qualifier,timestamp} -> value
-
同一表数据按rowkey升序排列,同一行的不同列按列升序排列;同一个cell按版本号(时间戳)降序排列
-
列式存储和行式存储比较
-
-
-
基本架构
-
master/slave结构,master和slave不直连,由zookeer进行协调,让master是无状态的
-
HMaster:无状态,多个由zk协调
-
协调regionserver
-
元信息管理
-
-
RegionServer
- 负责单个region的存储管理,并与client交互,处理读写请求;
-
zookeeper
-
存储hbase的元信息和状态信息
-
保证集群只有一个master
-
存储所有region的寻址入口
-
实时监控regionserver的上线和下线,并通知给master
-
-
-
内部原理
-
构建在HDFS上,包括region定位,读写流程管理和文件管理
-
Region定位
-
客户端与zookeeper交互,查询hbase:meta系统表所在的regionserver,此表维护每个用户表的rowkey区间和region存放位置关系
-
客户端与hbase:meta表的regionserver交互,获取rowkey所在的regionserver
-
客户端与rowkey所在的regionserver交互,执行相关操作;
-
-
regionserver内部组件
-
blockcache:读缓存,负责缓存频繁读取的数据,采用LRU策略
-
metastore:写缓存,负责暂时缓存未写入磁盘的数据,并进行排序
-
HFile:一种多级索引的数据存储格式,负责hbase的实际数据存储,均持久化到HDFS
-
WAL: 即write ahead log 预写日志:保存HDFS的日志文件,以便RegionServer宕机恢复数据
-
-
RegionServer的读写操作
-
写流程(org.apache.hadoop.hbase.client.BufferedMutatorImpl#backgroundFlushCommits)
-
regionserve接收到写请求,将写入的数据以追加方式写入hdfs上的日志文件,即WAL(用于regionserver宕机恢复数据),
-
regionserver将数据写入内存数据结构metastore,再通知客户端写入成功;当metastore写入数据达到阀值时,regionserver会将数据顺序刷盘到Hdfs
-
-
读流程
-
写流程使数据位于内存或磁盘中,读书数据则需要从多个位置寻址数据,如读缓存blockcache,写缓存metastore,以及磁盘HFile文件,并进行数据合并后返回;
-
扫描器查询读缓存blockcache
-
扫描器查询写缓存metastore;
-
如blockcahce和memstore都未找到数据,hbase将读取HFile的数据;
-
-
-
HFile和Metastore的结构
-
Metastore:有序的Key/Value内存存储格式,每个colum family都有一个metastore
-
HFile:类似B+树的多级索引的 Key/Value存储格式;
-
-
-
访问方式
-
hbase shell
-
DDL
-
create ‘table_name’,‘colum family’
-
list:查看所有表;
-
disable:下线一张表,不会删除,disable ‘table_name’
-
describe:查看表信息
-
drop
-
-
DML
-
put
-
get
-
delete
-
deleteall
-
scan
-
count
-
-
-
Hbase API
-
表操作API:org.apache.hadoop.hbase.client.HBaseAdmin
-
数据读写API:org.apache.hadoop.hbase.client.HTable
-
-
phoenix
-
sql on hbase的方案,将sql转换为hbase的scan的操作,并以JDBC结果集方式返回给用户;
-
支持二级索引
-
-
-
-
kudu
-
基本特点
-
C++开发
-
OLAP负载
-
可以与MR,SPARK集成
-
与impala集成
-
顺序写和随机写并存
-
高可用,使用raft协议
-
结构化数据存储
-
-
解决问题
-
流式计算结果实时更新和查询
-
时间序列相关应用:查询海量历史数据等
-
-
数据模型
-
纯列式存储格式
-
Master Server
-
负责管理元数据,源数据包括table的描述信息和位置信息等
-
管理table server ,监听其健康状态
-
-
支持多个master,但只有一个是active,其他master采用raft协议选举
-
table server
-
存储实际表数据
-
通常有3个副本存放在不同的TableServer上,同一table上的副本分为leader和follower;
-
每个table只有一个leader副本,提供写服务,follower副本负责同步数据,提供读数据
-
采用raft协议选举leader,实现高可用;
-
-
-
-
问题:
-
HFile文件保存hbase表中每个cell数据时,会存储哪些信息,(rowkey,column family,timestamp,value)?
-
Hbase提供了coprocessor(协处理器)以加快读写速度,其原理是?
-
asynchbase
-
-
分布式资源协调和资源管理
-
YARN产生背景
-
MRV1的局限性
-
可靠性差,采用master/slave架构,master存在单点故障
-
扩展性差,JobTracker同时兼备资源管理和作业管理功能,制约hadoop集群的扩展性
-
资源利用率低,MRV1采用槽位的资源分配模型,槽位间不能共享
-
无法支撑多种计算框架
-
-
设计动机
-
提供集群资源利用率
-
服务自动部署
-
-
设计思想
-
资源管理:负责集群的资源(cpu,内存,磁盘)的管理
-
作业控制:管理应用程序的运行
-
总体是将作业控制和资源管理分开
-
-
基本架构
-
总体采用master/slave架构,ResourceManager为master,NodeManager为slave,ResourceManager负责向各个NodeManager进行资源统一调度和管理
应用程序提交时,提供一个跟踪和管理应用的ApplicationMaster,负责向ResourceManager申请资源,并使NodeManager启动可以占用一定资源; -
基本组成:ResourceManager,NodeManager,ApplicationMaster,Container等
-
ResourceManager
-
全局的资源管理器,负责整个系统的资源管理和分配,由调度器(Scheduler)和应用管理器ApplicationsManager组成
-
调度器:根据资源容量,队列等方面限制条件,将资源分配给各个应用程序,调度器是一个可插拔的组件,YARN提供多种调度器,如Fair Scheduler
和Capacity Scheduler -
应用程序管理:负责管理整个系统的所有应用,包括应用提交,与调度器协商资源并启动,监控ApplicationMaster
-
-
-
ApplicationMaster
-
与调度器RM 获取资源(Container)
-
分配资源给job
-
与NM通讯以启动和停止job
-
监控所有job运行状态
-
-
NodeManager
-
负责向RM汇报本节点上资源使用情况和各个Container的情况
-
接收并处理来自AM的任务启动/停止的请求;
-
-
Container
-
资源分配的基本单位,对运行环境的抽象,封装了如内存,CPU,磁盘,网络等资源;
-
每个任务会对应一个Container
-
三种可选的ContainerExecutor
-
-
-
YARN高可用
-
RM HA: yarn引入active/standby的机制通过冗余ResourceManager来解决单点故障,内部通过zookeeper协调;
-
RM recovery
- 保存元数据: active的AM运行过程,会将应用程序元信息,
-
NM recovery:内置重启功能
-
-
YARN工作流程
-
YARN 资源调度器
-
层级队列管理机制
-
扁平化队列:
-
层级队列:
-
子队列:队列可以嵌套,每个队列均包含子队列;用户只能将应用程序提交到最底层队列;
-
最少容量:每个子队列均有一个最少容量比属性;队列选择器总是优先选择当前资源利用率低的队列;最少容量不是总会保证最低的容量;
-
最大容量:资源使用的上限,任何时候使用资源的总量不能超过改值;
-
-
-
多租户资源调度器
-
作业类型:
-
批处理作业
-
交互式作业
-
生产性作业
-
-
设计思路
-
虚拟多个hadoop集群
-
扩展hadoop调度器,支持多个队列和多用户;
-
-
2种租户资源调度器
-
Capacity 调度器:按比例划分资源
-
容量保证
-
灵活性
-
多重租赁
-
安全保证
-
动态更新
-
-
Fair 调度器
-
资源公平共享
-
调度策略配置灵活
-
应用程序在队列间转移
-
-
-
基于节点标签的调度
-
设计思想:为每个nodemanager打上标签
-
-
YARN资源隔离
-
为不同任务提供独立可使用的计算资源
-
内存资源隔离
-
线程监控方案
-
基于轻量级资源隔离技术Cgroups的方案
-
-
cpu资源隔离
- Cgroups的方案
-
cpu隔离机制
- LinuxContainerExecutor
-
-
-
资源管理系统Mesos
-
基本架构
-
master/slave,由zookeeper协调
-
资源分配策略
-
将资源调度的控制权交个各个框架;
-
资源拒绝
-
资源过滤
-
资源回收
-
-
-
-
大数据计算引擎
-
批量处理引擎MapReduce
-
产生背景
-
设计目标
-
易于编程:编程环境(应用逻辑)和运行环境(数据分片,节点通信,数据传输等)
-
良好的扩展性:
-
高容错性:计算迁移或数据迁移来支持;
-
高吞吐率:分布式并行读取;
-
-
编程思想
-
解决问题:数据切分,数据传输,节点故障,扩展性等
-
分而治之:map()和reduce阶段
-
-
编程组件
-
InputSplit:split是一个逻辑概念,包含一些源数据信息,比如数据起始位置,数据长度,数据所在节点等,一个split对应一个block,split的数量
决定map的数目 -
5个可编程组件
-
InputFormat:数据输入格式转换
-
数据切分,分成若干split,以确定map task个数和对应的split
-
mapper的数入:给定某个split,解析成一系列的<k,v>
-
基类:FileInputFormat,派生类:TextInputFormat和SequenceFileInputFormat
-
TextInputFormat:针对文本文件按照数据量大小将文件和目录切分split
-
SequenceFileInputFormat:针对二进制文件按照数据量大小将文件和目录切分split
-
-
-
Mapper
-
输入<k,v>;输出<k,v>
-
map方法:输入<k,v>,Context:上下文参数,可以获取当前执行环境信息,<k,v>要求可序列化
-
序列化的类:IntWritable,FloatWritable,LongWritable,Text等
-
-
Partitioner(org.apache.hadoop.mapreduce.Partitioner)
-
对mapper输出的中间结果进行分片,将同一组数据交给同一个reduce处理;
-
mapreduce默认采用org.apache.hadoop.mapreduce.lib.partition.HashPartitioner#getPartition,基于hash值分片
-
-
Reducer
-
对map的输出进行合并,map阶段产生的数据,按key分片后,分散到不同的reduce task上,reduce进行迭代后产生最终的<k,v>
-
reduce方法:输入<k,v> 即map阶段的输出,Context:上下文参数,处理为多个reduce task
-
-
OutputFortmat
-
定义输出数据格式,
-
基类:FileOutputFormat,派生类:TextOutputFormat,SequenceFileOutputFormat
-
-
Combiner
-
运行在map阶段
-
对mapper输出进行聚集;
-
-
-
-
设计思路
-
新旧版本API
-
新版本:org.apache.hadoop.mapreduce,旧版本:org.apache.hadoop.mapred
-
接口变抽象类
-
上下文封装
-
-
2个实例
-
分组统计
-
倒排索引
-
-
进阶
-
数据压缩
-
利用cpu资源换取IO资源
-
冷数据:采用压缩比高的算法
-
热数据:采用压缩效率高算法;
-
基于块压缩:LZO和Bzip2
-
基于文件压缩:Gzip和snappy
-
-
多路输出和输入
-
org.apache.hadoop.mapreduce.lib.output.MultipleOutputs
-
org.apache.hadoop.mapreduce.lib.input.MultipleInputs
-
-
DistributedCache(org.apache.hadoop.filecache.DistributedCache)
-
-
-
内部原理
-
构成:MRAppMaster,一系列MapTask,ReduceTask构成,由ResourceManager获取资源,由NodeManager启动运行;
-
启动步骤
-
用户向YARN集群提交应用程序,程序包含如下信息:MRAppMaster,应用jar包,启动MRAppMaster命令和资源(cpu,内存等)
-
ResouceManager为所在应用分配第一个Container,并和对应的NodeManager通信,在此Container中启动MRAppMaster
-
MRAppMaster启动后,向ResourcerManager注册并监控应用程序的运行状态,为MapTask和ReduceTask申请资源并运行
-
MRAppMaster以轮询方式通过RPC协议向ResourcerManager申请和领取资源;
-
申请到资源后,则通过调度算法将资源分配给内部的job,并与NodeManager通信,要求它启动这些任务;
-
启动的MapTask,ReduceTask通过RPC协议向MRAppMaster汇报自己的状态和进度,以让MRAppMaster可以监控运行状态;
-
应用程序运行完成后,MRAppMaster通过RPC向ResourcerManager注销,并关闭;
-
-
MapTask和ReduceTask
-
数据传输模式pull模式
-
MapTask:处理输入数据集合中一片数据,并产生数据片段,并写在本地磁盘上;
-
ReduceTask:从每个MapTask上远程拷贝一个数据片段,经分组聚集写在HDFS
-
MapTask流程:
-
read阶段:HDFS->InputFormat,并解析一系列<key,value>
-
map阶段:<key,value>-> map()函数->生成新的<key,value>
-
collect阶段:map()-> collect()->形成若干数据分片并写入内存缓存区;
-
spill阶段:缓存区溢满——>写入本地磁盘->本地排序,并进行合并,压缩等操作;
-
combine阶段:数据处理完成后,MapTask会对所有临时文件进行一次合并,以确保最终只产生一个数据文件;
-
-
ReduceTask流程:
-
shuffle阶段:从各个Map Task远程拷贝一片数据,并根据数据分片大小采取不同操作,若超过阀值,则写磁盘,否则放到内存中;
-
Merge阶段:从远程拷贝数据的同时,ReduceTask会启动多个后台线程对内存和磁盘上的文件进行合并;
-
Sort阶段:根据用户编写的reduce函数,按key进行排序;
-
reduce阶段:将每组数据交给用户编写的reduce函数处理;
-
write阶段:将输出结果写到HDFS上;
-
-
-
MapReduce关键技术
-
数据本地性
-
目的:减少任务执行过程中网络传输的消耗;
-
输入数据和实际计算资源间的距离分类
-
同节点(node-local)
-
同机架(rack-local)
-
跨机架(off-switch)
-
-
-
推测执行;
-
-
Q&A
- 如何判断job需要经过map和reduce过程;
-
-
-
DAG计算引擎
-
spark产生背景
-
spark主要特点
-
spark 编程模型
-
核心概念
-
RDD
-
弹性分布式数据集,是一个只读,带分区的数据集合,并支持多种分布式算子
-
特点:
-
分布在集群中的只读对象集合,由多个Partition构成,这些Partition可能存储在不同机器上;
-
多存储级别,RDD可以存储在磁盘或内存中,
-
失效后自动重构
-
并行转换构造
-
-
RDD只是一个逻辑概念,并不对应磁盘或内存的物理数据,仅仅记录RDD的由来,如父RDD,计算父RDD的逻辑等;
-
组成:
-
一组Partition
-
每个Partition计算函数
-
所依赖的RDD列表
-
计算每个Partition所倾向的位置
-
-
RDD的操作
-
transformation算子:转换操作,将一个RDD转换为另一类RDD,包括map,filter,groupByKey等
-
action算子 :处理RDD得到一个或一组结果,包括saveAsTextFile,reduce,count等;
-
两者区别:
接口方式不同:transformation:RDD[X]->RDD[Y],Action:RDD[X]->Z
运行方式不同:spark是惰性计算,transformation:记录RDD的转化关系不会触发分布式计算。action:触发分布式计算
-
-
DAG
- 数据流的依赖关系,并让不同计算阶段直接通过本地磁盘或内存交换数据
-
-
基本框架
-
spark应用由一个Driver进程和多个Executor进程组成
-
driver进程运行用户程序,并生成逻辑计划,物理计划和调度任务;
-
Executor进程拥有独立计算资源的JVM实例,内部以线程的方式运行Driver分配的任务;
-
-
编程接口
-
构造SparkContext:封装Spark应用运行的上下文环境,如配置信息,数据库管理,任务调度器;每个应用有且仅有一个;
-
构造RDD
-
Sacla 集合转换为RDD
-
分布式/本地文件转换为RDD
-
文本文件:textFile(path:String,numsPartition:Int):RDD[String]
-
sequenceFile文件:sequenceFile[K,V] (path:String,numsPartition:Int)
-
任意文件转换RDD:newAPIHadoopRDD
-
-
-
RDD 转换操作
-
transformation 是惰性操作,不会触发分布式计算;
-
包含map(),filter(),flatMap(),reduceByKey(),groupByKey,join(),repartition()等
-
-
RDD action
-
会触发相关transformation算子的执行
-
包含 reduce(),collect(),count(),take(),saveAsTextFile(),countByKey()等
-
-
共享变量
-
广播变量
-
累加器
-
-
RDD持久化
-
持久化到磁盘或内存,可以重用RDD
-
支持persist()和cache()两个函数,cache将RDD持久化到内存,persist()支持多存储级别;
-
checkpoint机制:将RDD写入文件系统;
-
区别:spark自动管理cache和persist持久化数据,checkpoint持久化数据需由用户自己管理;checkpoint会清除RDD血缘;而cache和persist不会
-
-
-
运行模式
-
支持同一程序可以运行在多个不同环境中
-
local:本地模式,driver和executor都在本地
-
standalone:独立模式,master/slaves的集群环境,根据Driver是否运行在独立集群,可以分为:
-
client模式:driver运行在客户端,不受mastegr
-
cluser模式:driver/executor都运行在slaves上;
-
-
YARN模式:运行在YARN集群,根据driver是否由YARN管理,可以分为:
-
yarn-client:
-
yarn-cluster:
-
-
spark shell
-
-
应用提交
- spark由统一的spark-submit提交任务,语法如下:
bin/spark-submit \ -- class <main-class> \ -- master <master-url> \ -- deploy-mode <deploy-mode> \ -- conf <key=value> \ <application-jar>
-
参数说明
-
class :应用程序入口类,比如com.greekw.spark.MainApplication;
-
master:指定spark的运行模式;
-
deploy-mode:spark Driver的部署模式,包括cluster和client2种;
-
conf:spark应用的配置参数,如–num-executors=3;
-
application-jar:应用程序所在的jar,和依赖的jar,可以存放在本地或者HDFS上;
-
-
具体示例:
提交spark应用到YARN集群,driver需要运行在集群中,需要一个CPU,3GB内存,启动3个Executor,每个Executor需要4个core,8G内存
提交到YARN中的spark队列;bin/spark-submit \ -- class com.greekw.spark.MainApplication \ -- master yarn-cluster \ -- deploy-mode cluster \ -- driver-memory 3G \ -- num-executors 3 \ -- executor-memory 8G \ -- executor-cores 4 \ -- queue spark <application-jar>
-
-
内部原理
-
spark应用从提交到运行需要经过3个阶段,生成逻辑计划,生成物理计划和调度任务执行
-
生成逻辑计划:通过RDD间的关系,构建DAG,DAG的节点是RDD对象,边是转换关系
-
生成物理计划:根据第一阶段生产的DAG,划分为若干个stage,每个stage由若干个可执行的并行计算任务构成
-
调度任务执行:根据依赖关系,调度并计算给定的stage
-
driver端执行: 生成逻辑计划和生成物理计划。Executor端:调度任务执行
-
一个spark应用会包含一个或若干个作业(job),每个作业被划分为若干个阶段(stage),每个阶段内部包含一个或多个可执行的任务Task
-
Application:spark应用,内部只包含一个SparkContext对象
-
Job:每个Action算子会产生一个job,一个Application会产生多个Job;
-
Stage:每个Job可产生多个Stage
-
Task:每个Stage可产生多个Task,这些Task之间通常是没有依赖关系,可并行执行;
-
-
spark shuffle
-
-
-
交互式计算
-
产生背景
- 以MapReudce批处理计算引擎存在一些问题,如IO交换密集,任务调度和启动开销大,无法充分利用内存,Map端和Reduce端开销大等
-
分类
-
按存储方式可以分为:
-
ROLAP:关系型数据库的OLAP,优点:数据实时性高,缺点:运算效率低,用户等待响应时间长
-
MOLAP:多维度数据组织的OLAP,优点:运算效率高,缺点:占用内存大
-
HOLAP:
-
-
-
常见开源实现
-
基于ROLAP的Impala和Presto
-
基于MOLAP的Druid和Kylin
-
-
Impala
-
基本特点
-
借鉴MPP并行数据库思想,可支持更好的并发
-
全内存实现,省掉大量IO消耗
-
充分利用网络读,减少网络消耗
-
-
基本架构
-
对等式架构,没有主从之分,由三类组件构成,分为Catalogd,Statestored,Impalad
-
Catalogd:元信息管理,负责从hive metastore同步信息,并将任何元信息改变通过Catalogd广播同步给各个Impala服务
-
Statestored:状态管理服务,实现节点间元数据同步和协调
-
Impalad:承担协调者和执行者角色,作为协调者:接收客户端请求并对其进行词法分析,语法分析,生成逻辑查询计划和物理计划;作为执行者:利用本地资源执行发过来的片段,将结果返回给协调者
-
单点计划和计划并行,分割:
-
解析树转换为单点计划树
-
单点计划转换为分布式的执行计划,支持2种分布式的join策略:表广播和哈希重点分布
-
-
-
访问方式
-
支持JDBC/ODBC访问
-
支持HQL查询
-
支持用户自定义函数和聚集函数
-
不支持面向单行update和delete
-
不支持事务
-
采用运行时检查方式
-
-
-
pestro
-
基本架构
-
Master/slave架构,由一个Coordinator,DiscoveryServer,和多个Worker组成;
-
Coordinator:协调者,负责接收客户端查询sql词法分析,语法分析,生成逻辑计划和物理计划等
-
DiscoveryServer:服务发现组件
-
Worker:任务执行者,负责任务执行,并将结果发送给协调者;
-
-
访问方式
- 插件式架构,能通过连接器接入外部数据库,支持hive,mysql,hdfs,hbase,redis等
-
pestro和impala比较
-
-
MOLAP
-
思想:利用空间换时间
-
Druid
-
基于列存储
-
由实时和离线2部分构成
-
外部依赖:zookeeper,存储集群数据信息和规则的Metadata storage和存放备份数据的Deep Storage
-
-
kylin
-
核心思想:利用空间换时间,通过预计算,将查询结果预先存储到hbase
-
组件说明:
-
Rest server
-
JDBC/ODBC接口
-
Query 引擎
-
Routing
-
MetaData
-
Cube构建引擎
-
-
-
-
-
实时计算引擎
-
产生背景
-
传统流水计算平台存在问题
-
扩展性差
-
容错性差
-
无法保证数据处理完整
-
-
常见开源实现
-
数据采集
-
数据缓冲
-
实时分析
-
结果存储
-
-
storm
-
基本概念
-
-
spark streaming
-
概念和架构
-
思想:微批处理,采用以时间为单位划分数据流,每个切片内的数据对应一个RDD
-
DStream
-
-
基本设计
-
StreamingContext:封装运行环境的上下文信息,包含调度器,控制逻辑等
-
基本流程
-
设置数据源,并创建DStream
-
实现计算逻辑
-
启动程序:sc.start()
-
等待程序执行完成:sc.awaitTermination()
-
-
数据源
-
基础数据源:文件系统API,socket等
-
高级数据源:kafka,flume等
-
spark streaming 以长服务存在,可能会启动多个reciever的任务,会占用一个core,常驻内存
-
文件系统API
-
sc.fileStreamKeyClass,ValueClass,InputFormatClass
-
基本要求:
-
目录下所有文件必须是相同格式
-
文件必须是原子操作产生,即rename或move操作等
-
文件写到目录后,不能被修改
-
-
-
kafka
-
基于Receiver方法:启动若干个receiver从kafka接收数据,并将数据缓存到executor,spark streaming应用异步作业处理数据;
-
基于Direct方法:直接读取kafa中数据,不需要缓存,通过kafka低阶API读取指定offset的数据
-
对比优势:
-
简单易用:Receiver需要采用union算子将多个并发流合并一起,且读取kafka topic中任务数要与Topic的Partition数一致
-
高效:direct直接读取,不需要缓存
-
Exactly-once语义:kafka offset存储到checkpoint文件,即使任务失败也不会导致数据重复消费
-
-
-
transformation操作
-
window()函数:将窗口长度较小的RDD组成的DStream合并成窗口长度较大的RDD的DStream
-
mapWithState函数:正对PariDStream,即为Key/value结构,根据key更新对应的value
-
-
-
-
容错性
-
spark streaming主要将流式计算转换为批处理,最终仍会转换为spark批处理
-
Driver容错
-
Executor容错
-
应用容错
-
checkpoin机制:记录应用程序的上下文信息,包括RDD及其状态信息等
-
offset 管理机制 :记录处理RDD偏移量,以kafka为例,记录topic名称,每个patition未处理的offset
-
-
-
流式计算引擎对比
-
数据模型
-
编程模型
-
一致性语义
-
编程语言
-
吞吐率和延迟
-
-
-
-
-
数据分析
-
数据分析语言
-
产生背景
-
sql表达更简单
-
sql集成性好
-
-
SQL on hadoop
-
基于计算引擎
-
基于MPP架构
-
-
Hive架构
-
hive对外访问方式
-
Web UI
-
CLI
-
Thrift协议(支持JDBC/ODBC)
-
-
hive服务端
-
驱动器(Driver):负责SQL解析,生成逻辑计划,物理计划,查询优化和执行等
-
Metastore:负责管理和存储元信息,保存数据库基本信息和表定义;
-
hadoop: hive依赖hadoop
-
-
部署模式
-
嵌入式模型:Metastore和数据库2个进程嵌入到Driver
-
本地模式:Driver和Metastore运行在本地;
-
远程模式:远程共享Metastore,使用Beeline,JDBC,Thrift访问
-
-
-
-