------------------------------------------------------------------------------------
*******大数据概念和基础**********
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；
)
