TDH-大数据基础


------------------------------------------------------------------------------------
*******大数据概念和基础**********
1.大数据的四个特点:数据规模大,生成、处理速度快,数据类型多样,价值巨大密度低;
2.大数据历史:三篇论文(GFS,mapReduce,bigTable),CDH,HBASE,SPARK,TDH等;
-------------------------------------------------------------------------------


----------------------------------------------------------------------------------------
****************HDFS*********************
1.HDFS为什么不适合存储大量小文件?
答:1.大量文件的元数据占用NameNode大量内存空间
2.磁盘寻道时间超过读取时间
-------------------------------------------------------------------------------------------- ----
2.HDFS 何时离开安全模式?
答:ActiveNameNode启动时HDFS进入安全模式只读,datanode主动汇报可用block的可用情况
即上报率=可用block数量/namenode元数据记录的block数>=99.9%时离开安全模式
-------------------------------------------------------------------------------------------------
何时触发安全模式?
1.namenode磁盘不够;2.DataNode无法启动;3.namenode重启;4.block上报率低阈值;5.日至报错;6.强制关机
----------------------------------------------------------------------------------------------------
3.ActiveNN与standbyNN的切换?
答:QJM机制实现最终一致,允许延迟,journalnode(2N+1)只要N+1个写入成功即可,他写edits编辑日志
文件,activeNN挂掉standbyNN状态变为active
---------------------------------------------------------------------------------------------
4.HDFS写文件过程?
答:1.客户端请求上传文件,输入命令;
2.检查HDFS目录,允许上传;
3.客户端将文件切块block并请求namenode;
4.namenode返回datanode信息;
5.客户端与datanode建立传输,写成功后通知namenode;/先写数据再写日志
6.更新edits编辑日志(立即)和fsimage文件(定期)写入namenode,同时写入journalnode,最后写入内存(最新);
7.后面standbyNN与activeNN定期同步。
------------------------------------------------------------------------------------
5.HDFS优缺点?
优点:高可用(nameNode HA),高容错(冗余多副本),高扩展(10k),海量数据,成本低
缺点:大量小文件不可存,不支持并发写入,不支持低延时,不支持随机写
---------------------------------------------------------------------------------------------
6.HDFS元数据俩种存储方式?
内存元数据:namenode
文件元数据:edits+fsimage
--------------------------------------------------------------------------------------------
7.HDFs最小文件存储单元 block?
1.存储在datanode,大小默认128M,多副本、均匀分布在多个datanode(默认三个副本);
2.block放置策略:副本1放在clinet 副本2放在另一台机架,副本3放在和副本2一起的另外节点,其他随意;
3.block文件 命名:“ blk blk_文件大小”
-------------------------------------------------------------------------------------------------------
8.HDFS各个角色
1.ActiveNN作用:
唯一的集群管理节点;管理HDFS文件系统命名空间;维护元数据信息(文件位置、权限、块信息等);处理客户端请求;管理块策略
2.standbyNN作用:
备份master节点宕机后替换activeNN;周期同步activeNN的edits文件,并定期合并fsimage文件和edits到本地磁盘;
3.nameNode作用:
存储元数据(fsimage+edits),fsimage(文件块信息、位置、目录、副本数),edits(文件操作记录)
4.dataNode作用:
Slive工作节点;存储数据block;定期与namenode心跳汇报block信息(集群启动有可用block数汇报);客户端的数据读写操作;
---------------------------------------------------------------------------------------------
9.HDFS高可用?
通过QJM机制部署2N+1个journalNode节点,N+1个操作成功(写edits)即可,利用ZK选举Active节点


-------------------------------------------------------------------------------
***********************YARN*************************************
-------------------------------------------------------------------------------
1.yarn与mapreduce的关系?
答:
1.yarn是资源调度框架,mapreduce是分布式计算框架;
2.yarn将jobTracker的资源管理和任务调度划分开了,通过ResourceManager进行资源的统一管理和分配,
ApplicationManager进行解析mapreduce程序然后变成一个个小任务,需要多少资源向ResourceManager请求,
然后nodeManager和applicationManager协作分配containner执行任务。


2.如何部署yarn RM NM和hdfs的datanode namenode节点?
答:1.dataNode和nodeManager放在一起
2.yarn的ResourceManager单独放
3.俩个active不放在一起,standby节点放在别的节点
4.namenode 和RM 至少俩个

3.Yarn三个角色ResourceManager/applicationManager/nodeManager介绍?
ResourceManager:统一管理集群的所有资源,分配资源给applicationManager,接受nodemanager资源上报信息
applicationManager:管理应用程序,申请资源,任务调度
nodeManager:管理单个节点资源,上报资源使用,管理container生命周期

4.ResourceManagerHA高可用?
1个activeRM 多个standby RM;ZK选举ActiveRM,宕机后主备切换;

5.yarn的资源调度策略?
1.FiFo Scheduler:先进先出,不灵活,利用率低;
2.capacity Scheduler:提前做预算;多个队列共享资源;空闲资源优先给实际资源/预算资源小的队列;
特点:弹性分配;多租户;多层次;保证容量
3.fair scheduler:见面分一半 资源抢占;占用资源小于最低资源限制 则强制停止其他队列任务;队列中有任务等待,则根据权重分配


-------------------------------------------------------------------------------
***********************mapreduce*************************************
-------------------------------------------------------------------------------
1.mapreduce核心思想?
1.分治思想;2.移动计算而不是移动数据

2.特点:计算跟着数据走,批处理,高容错,扩展好

3.MR的几个阶段?
split:Split的大小默认 等于 Block大小,决定map任务数量;
map:split切片输入,key-value输出
reduce:由若干Reduce任务组成,数量由程序指定
shuffle:中间环节,包括分区(哈希取模)将map中间结果输出到buffer区,然后分区排序,当达到阈值溢将
一个临时文件写到磁盘上,map任务结束前临时文件合并为一个map文件,fetch等

Partition决定了Map任务输出的每条数据放入哪个分区,交给哪个Reduce任务处理
• Reduce任务的数量决定了Partition数量
• Partition编号 = Reduce任务编号 =“key hashcode % reduce task number”

Hadoop1和2的区别?
1.1有单点故障,资源描述简单,负载太重;2融合yarn 高可用,高扩展,资源有专门的角色管理,任务和资源分开

4.mapreduce key-value输入输出的原因?
答:
1.通用数据格式
2.shuffle过程要排序合并,哈希取模可以决定分区partition

5.shuffle是调优关键?
答:shuffle的过程:先写内存(内存中先分区后排序) 然后溢写硬盘 再合并(大文件的分区排序)

-------------------------------------------------------------------------------
***********************spark*************************************
-------------------------------------------------------------------------------
1.RDD?
数据集拆分;数据存储在内存或者磁盘;多分区;失效自动重构;转换操作构造

2.RDD俩种依赖?
窄依赖(父RDD中的分区最多只能被一个子RDD的一个分区使用)和宽依赖(子RDD依赖于所有父RDD)

3.spark 角色?
1.driver;main函数在里面
2.sparContext:加载配置信息,初始化运行环境,创建DAGScheduler和TaskScheduler
3.Executor:可以有多个 多线程
4.task:

4.spark的几种运行模式?
1.local:单机运行,spark以多线程形式运行在本地;
2.standlone:集群运行(规模不大)
3.yarn-client/yarn-cluster(生产环境);

5.spark运行过程:
生成逻辑查询计划-物理查询计划-任务调度-执行任务

6.mapreduce比起saprk优缺点:
答:1.通用性强
2.mapreduce对现实的描述过于简单只有map,reduce俩个,spark细分rdd,分多个partition

----------------------------------------------------------------
********************Sqoop*********************
------------------------------------------------------------
Sqoop:用于rdbms和hadoop之间的数据导入导出
1.1和2版本的对比:
1.不安全,但是简单快速高效,2.增加安全机制,多用户,集中管理,稳定性和速度都不好


----------------------------------------------------------------
********************flume*********************
-----------------------------------------------------------
1.数据流模式:source---channel(可以缓存)---sink
2.事务机制:支持重读重写
3.agent:jvm的运行单元,将外部数据送到目的地,内涵一个数据流,以event作为数据单元进行传输
4.1个souece对应多个channel,1channel对应1个sink
5.flume单层架构(数据暴露,安全性差,产生许多小文件),多层架构(安全但是复杂)


-----------------------------------------------------------------
********************kafka*****************
------------------------------------------------------------------
1.kafka的几个角色?
broker:server;
topic:消息贴标签组成一类 分类的过程,同一类,方便处理,有了topic
就可以隔离其他类数据,他是一个逻辑概念;
partiion:物理概念要落盘 不可更改只读,一个topic多个分区,一个分区一个目录,
一个分区代表一个文件夹 一个分区多个副本 放在不同的broker上;
zk:broker的负载均衡,leader的选举,元数据存储,CG之间的rebalance,配置管理等;


2.kafka的partiton是一个先进先出队列,写入消息追加尾部,消费消息在队列头部;

3.kafka的CG内部的cosumer是互斥的,不同CG之间是共享消息的;

4.kafka最小数据存储单元是segment,它包含(offset.index offset.timeindex,offset.log)三个文件,offset
是消息在分区中的唯一标识,他是有序的。
offset.index数据格式:偏移量,位置;
offset.timeindex数据格式:时间,偏移量;

5.kafka机制:
消息在broker中(server)按照topic分类,打上标签;然后 每个topic划分为多个partition,每个partition进行
多个备份副本;多个consumer组成CG 进行订阅消费数据

6.队列在资源调度的作用?
答:共享集群资源,隔离任务

7.kafka分了topic和partition作用?
答:利用多分区多副本实现高可用,一个topic(逻辑概念)代表一类数据,一个topic分为多个partition(物理概念),
一个partition为一个文件夹表示一种业务

8.kafka partition leader 和follower如何工作》?
答:partition leader 是选举出来的主要负责一个分区的读写;follower同步分区信息到各个副本

9.zookeeper为什么不亲自负责kafka的partition和副本之间的leader的选举?
答:通过Zookeeper,从Kafka集群中选举出一个Broker作为Kafka Controller Leader
• Kafka Controller Leader负责管理Kafka集群的分区和副本状态,避免分区副本直接在Zookeeper
上注册Watcher和竞争创建临时Znode,导致Zookeeper集群负载过重,Kafka Controller Leader通过ISR(分区和备份列表)来选举
partition Leader

-----------------------------------------------------------------
********************inceptor*****************
------------------------------------------------------------------
1.架构?
1.metastore:元数据存储在TxSQL
2.client:waterdrop

2.数据模型?
1.database:系统会为每个数据库创建一个目录,目录名=数据库名.db;先删表再删库;
2.table:内表:外表:
3.分区:
含义:将表按照某个或某几个字段(分区键) 划分为更小的数据集;
存储:分区数据存储在表目录下的子目录中,一个分区对应一个子目录,分区目录名为“分
区键=value”;
目的:减少全盘扫描,提高查询效率
选取分区键:离散值、大量出现再select where中
4.分桶:
1.分桶时候 俩张表同样操作,join的列,表一 join表二 where A1=A2 俩表各自利用哈希取模分桶,
同样值的分在同样的桶里面,分桶有"打散"和"聚合"的功能(同样值的在一个桶,也可能成倍数的桶里)
2.提高取样效率;
3.先分区再分桶;

5.读时模式:
数据入库不检查规范性,在查询时验证

-----------------------------------------------------------------
********************slipertream*****************
------------------------------------------------------------------
1.输入流的模式:
微批(Micro-batch)模式:将Input Stream按时间划分成若干小数据块(Batch)来处理;
事件驱动(Event-driven)模式:以单条数据被Input Stream接收为事件,逐条读取并处理;

2.Derived Stream(衍生流)
含义:对已有的Stream变形(Transform)得来
-Transform通常由CSAS(Create Stream As Select)完成
3.streamSQL与普通SQL的区别
无阻塞模式

-----------------------------------------------------------------
********************hyperbase*****************
------------------------------------------------------------------
1.特点:高可靠,高并发,高性能,基于列,
key-value存储,半结构化,newSQL,HFile落地,数据强一致性

2.表结构: RowKey | 列族 | 列限定符 | 时间戳
3.表特点:多版本,稀疏,无类型,动态增加列,大规模,
4.角色?
HMaster:
管理元数据;
管理表的创建、删除和修改;
为HRegionServer分配Region;
HRegionServer宕机后,重新分配其上的Region;
负责HRegionServer的负载均衡;

HRegionServer:
处理客户端请求;
region的分裂;
storeFile的合并;

ZK:
HMaster高可用;
监控HRegionServer的上下线信息, 并通知HMaster;
存储元数据的寻址入口;
存储所有Region的寻址入口;

5.数据存储过程?
1.Client 访问ZK获取meta表的region位置,然后记录在ClientCache中;
2.读取meta表,根据namespace/表名、rowkey获取要写入的region位置,并将meta表写入ClientCache中;
3.HRegionServer先写HLog文件(数据和操作);
4.HRegionServer先写MemStore,当数据量超过阈值时,溢写到磁盘为一个storefile(Hfile);
5.当Store中的StoreFile数量超过阈值时,若干小StoreFile合并为一个大StoreFile;
6.当Region中最大Store的大小超过阈值时,region会等分为两个子Region;


6.数据读过程?
1.12步骤同写过程;
2.先从memStore读再从storeFile中读;

7.


----------------------------------------------------------------
**********************search***********************
----------------------------------------------------------------
1.es基于lucene(单机),solr(实时性能差),search增加了sql;

 

转载于:https://www.cnblogs.com/Lxiaojiang/p/9599961.html

  • 0
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值