《大数据技术体系详解：原理、架构与实践_董西成(著)》
-
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访问
-
-
-
-
