大数据面试题库

分区是将数据 根据数据的某个字段进行一个数据路径分区 主要思想就是分而治之 将大文件拆分多个小文件 减少查找数据的扫描量 底层是HDFS存储 文件太大存到一半 集群崩了 白存了

分桶是解决分区的一种优化方案 因为分区根据某个字段分 容易出现数据倾斜而分桶是根据数据的hash值对桶数取余 数据倾斜较小

开启分桶：INTO 分桶数 BUCKETS

hive底层是MR计算引擎 所以当reduce阶段 shuflle的时候呢 存储数据不均匀造成数据倾斜 

定位原因 如果是压缩引发的采用分割的压缩算法   null值不需要的情况先过滤   需要的话就+随机盐   join产生的问题就预先聚合  增加桶数

两个都是hive的存储方式 只是分别应用的场景不同  ORC是Hadoop生态系统面向列的 与Hadoop环境中大多数框架兼容  性能高  读和写速度快  Parquet适合嵌套数据结构 兼容性更强

ER模型和维度建模 ER模型遵循三范式  维度建模遵循以分析决策设计表

星形模型

雪花模型

星座模型

空间换时间 复杂问题简单化  一般分五层 ODS数据原始层-->将数据进行Json数据的预处理  DWD数据明细层--> 将ODS经过ETL清洗过滤 装载到此层  DWS数据设计层-->将DIM层的维度表跟DWD事实表Join所形成的宽表   ADS数据服务层--> 这一层的数据一般可以视图展示了

设计好的模型事半功倍  合理的分区分桶减少数据倾斜 设置合理的MR的task数 优化存储数据块  挑选合适的数据存储方式

谓词下推 投影下推 常量折叠 分区裁剪

小表join大表   小表join小表 

大表join大表  

Skew Join

利用更多的资源换取时间  空间换时间

当Stage之间没有依赖关系时 我们可以进行并行执行

滑动窗口

取值型窗口

分析型窗口

小文件过多会造成HDFS的namenode元数据特别多  占用太多内存 影响性能  对于MR来说消耗资源 一个文件一个map任务

Sequence File

concatenate

CombinerFileInputFormat

archive

union

orderBy

sortBy

distinctBy

clusterBy

压缩技术能够有效减少存储系统的读写字节数，提高网络带宽和磁盘空间的效率 运用得当能提高性能，但运用不当也可能降低性能

数据来源：bzip LZO  （用压缩并且选择支持分片的压缩方式）

数据计算：LZO LZ4 Snappy（压缩/解压速度快 支持Hadoop Native库）

共同点

不同点

原因是Job产生的任务会并行在 Executor去执行（算子内）但有些操作会在 Driver端执行（算子外）  算子内可能会用到算子外的数据

cache

persist

checkpoint

RDD之间的依赖关系 避免重复计算 提高容错效率，如果有一个分区数据丢失，只需要从父 RDD 的对应 1 个分区重新计算即可

宽依赖

窄依赖

任务划分就是靠宽窄依赖来划分的任务stage用的  遇到宽依赖就切割stage就是产生Shuffle Stage里面的Task的数量 是由 Stage中最后一个RDD的Partition数量决定的 最后一个Stage任务类型时 ResultTask  其它都是ShuffleMapStageTask

一个Application有多个Job 遇到行动算子 就触发一个Job  一个Job有多个Stage阶段  是由DAG有向无环图划分的   一个Stage阶段 有很多Task 数量是否分区决定 由TaskScheduler分配Task到对应阶段

Driver端声明了一个变量   所有Task需要修改这个变量 但是修改的只是Task自己内部的 修改不了Driver端  累加器作用就是修改Task变量 能影响到 Driver端的全局变量

Driver端声明的变量 序列化传输到 Excutor中Task中 每一个Task都有这么一个变量   数据量太大 就会占用大量的Excutor的内存空间 广播变量作用就是Excutor端只会存储一份该数据提供多个Task使用 防止数据被修改  所以是只读变量

大数据分而治之  多个节点都跑着任务  任务中间可能会进行一些 汇聚 数据打散重组等操作  中间过程是Shuffle  一个节点任务之间产生Shuffle只会产生磁盘I/O 多个节点任务之间之间产生Shuffle会产生网络 I/O和磁盘I/O  Shuffle可能会产生数据倾斜

Hash Shuffle

 Sort Shuffle

Tungsten Sort Shuffle

key分布不均匀 导致shuffle的时候 一个节点负载过重  一旦数据倾斜就会就可能产生 网路I/O  磁盘I/O  硬件故障  内存过度

使用HiveETL预处理  过滤少数导致倾斜的key  提高shuffle操作的并行度    双重聚合    将reducejoin 转为 mapjoin   采样倾斜key并分析join操作   使用随机盐和扩容RDD进行join

资源调优

代码调优

内存调优

并行度调优

用于处理结构化数据的模块  无论使用哪种方式 或 语言  执行引擎都是相同的 开发人员可以轻松地在不同的 API 之间来回切换 使数据处理更加地灵活

RDD

DataFrame（弱类型）

DateSet（强类型）

Driver的核心数3~5   以及内存数量512M  Executor的数量2   内存1G   核心数1

分区列表  分区计算函数 血缘  RDD存储结构  计算向数据靠拢

适当增加spark standby master 

编写脚本 定期检查master状态 出现宕机后对master 进行重启操作

都会产生shuffle reduceBykey的话他会分组+聚合 并且每个区内预聚合 减少shuffle的落盘量   groupBykey只能分组要聚合的话你得配合sum使用 数据量不会减少

conslidate

90％

预留10％  防止OOM溢出

1.生产者：将产生的消息存放到对应的Topic消息根据分区规则存放到不同的Partiton，然后同步到Replication
2.offest：唯一的标识一条消息 一个消息只能被一个组消费一次 一个组记录当前Topic消息消费的进度
3.topic：生产者发送的消息类别称为主题
4.partition：主题中的数据会被切分为至少一个或多个Partiton   每个分区中数据插入有序，新增的数据都会分配到队列尾部
5.replication：每一个分区都拥有副本保证数据的安全 Partiton为了数据的读写 Replication为了数据的备份，没有读取功能
6.consumer：消费者就是从Topic读取数据 消费者组一组共享一个Topic的偏移量 一个消费者组内包含一个或者多个消费者 不同的组可以同时消费相同的Topic
7.zookeeper：存储KafaKa的元数据信息 帮助进行Leader的选举
8.broker：Kafaka集群的每一个服务器都叫Broker

RangeAssignor（默认）：以一个主题为单位 均匀分配 多的 前面的往下多分一个区 一个组分配的区时连续的   缺点-->如果每个主题刚好都多一个 那么每次都是第一个消费者都会多分配一个 主题越多就会出现部分消费者过载的情况

RoundRobinASSignor：将所有消费者 以及 订阅的所有消费主题 按照字典序排序 然后轮询分配 相对均匀 差值不超过1 订阅多个主题相对数据比较混乱 适合单个主题

Sticky粘性的:均匀 不变 订阅哪些主题 消费哪些 进可能保持均匀

当数据到Partition后 Partition返回ACK给Producer  Producer接收到ACK确定后发送下一条 否则返回重新发送

0-->最多一条：producer无需等待Partiton返回ACK结果 直接发送第二条 Broker故障丢失数据  1-->只有一条：Partition分区接收到数据 写到本地log 返回ACK结果 Follower同步的时候 leader故障 丢失数据  -1-->最少一条：Partition分区接收数据 写到本地log 广播 所有Follower都同步了 才返回ACK结果  安全 效率低

使用最少一次+幂等性+事务+架构 = 保证数据精准一次消费

幂等性

事务性

文件存储设计特点

顺序写入

pageCache

零拷贝

pageCache

零拷贝

会把消息持久到磁盘 有效避免消息丢失的风险 

对生产者和消费者的一个解耦   并且中间做了一个缓冲解决了生产者与消费者处理速度不一致的问题

影响

如果是处理速度及时  必须 消费者数=分区数

如果是处理速度不及时 提高每批次拉取的数量

硬件故障

软件故障

资源耗尽

数据损坏

监控系统

当batch大小达到了闻值(batch.size) 或batch积累消息的时间超过了linger.ms时batch被视为“已完成或"准备就绪”。batch.size和inger.ms都是Producer端的参数。batch.size默认值是16KB，而linger.ms默认值是0毫秒。一旦达到了batch.size值或越过了linger.ms时间，系统就会立即发送batch。

允许您在Kafka中建立一个灵活的消息管道，将数据从一个主题传递到另一个主题，并进行任何必要的数据转换和处理

是度量事件时间的 解决分布式环境下网络延迟 背压造成数据乱序的

周期型

定点型

延迟数据处理

source端

转换

sink端

1.首先是否分组  分组每个组达到要求才能显示 不分组只有一条主流 主流达到要求进行显示 2.windowAssigner：分配器类型-->定义如何将数据流分配到一个或多个窗口  基于时间的滑动 滚动 会话  基于计数的滚动 滑动 3.Trigger：指定触发器类型-->满足什么样的条件触发计算 触发时机  每一个窗口分配器都有一个默认的触发器 4.Evictor：数据剔除器 在触发器触发之后 窗口函数使用之前或之后 从窗口中清除元素 5.Lateness：时延设定-->是否处理迟到数据,当迟到数据达到窗口是否触发计算 6.OutPut：输出标签-->通过getSideOutput将窗口中的数据根据标签输出 7.window Funtion：窗口上处理逻辑 增量 全量聚合

将数据进行分割 拍快照的  定期生成 会跟随数据一起流动 广播给下游的所有算子  当算子收到barrier 说明上一批数据已经走完 开始拍摄快照 存储到HDFS持久化 下一批数据继续传输 保证实时性

barrier对齐

barrier对不齐

原因是反压

解决办法

join

CoGroup

Interval Join

类似于有点Spark的RDD的血缘 程序出错 我们如果从头开始计算 效率低 没有时效了  有这个状态之后  Flink只需要获取到上一步的状态 重新计算即可  状态分有状态无状态 无状态就是算子用不到状态 有状态就是需要用到历史数据做计算的  状态一般都是Flink运行时帮我们管理 序列化 故障恢复等都实现好了  也可以自己管理 自己开闭一个内存空间 但是太麻烦了  状态又分为算子状态 和 键分区状态  算子状态是可以用于所有算子 一个并行度一个状态对应一个槽  就是说当前并行度的算子共享一个状态 键分区状态 只能用于分区算子 相同的key共享一个状态  但是一个槽里面可能有多个key 状态可以存在内存 文件 RockDB 或者 远端持久化到HDFS 状态存太久了 也太浪费资源 所以状态的TTL就是来管理它过期如何处理 怎么过期 等等

生产数据的速率比Task消费速率快 反压传播是从下游到上游传播  反压是流处理系统中用来保障应用可靠性的一个重要机制 上游处理单元降低数据发送的速率，以缓解下游处理单元的压力 反压会造成检查点时长拉长 变大 反压可以静态反压 动态反压 静态反压就是自己调参数 缺点就是调大还是会有压力  调小有效利用资源 基本都是动态反压 消费者动态告诉生产者处理能力  处理的条数Spark 缓冲区剩余空间  反压流程是1.5以前是将你的资源全部堵塞  资源耗尽才会停止发送数据  问题就是Socket阻塞的问题 导致其它的任务也无法发送任务 1.5以后呢就是上游会给下游发送一个消息 告诉下游这次要发送多少条 下游会根据条数申请足够的资源 如果下游资源不够 就会发送一个消息返回0   上游就会停止发送任务 不会堵塞每个阶层 提高了socket的复用性

通过WebUI界面点开算子右边 backPressure看反压

解决

也可以通过WebUI定位到第一个黑色节点的位置 但是由于可能该节点的瓶颈可能不会高反压 但是导致上游节点反压 如果不是第一个 就是紧接的下游节点   系统资源问题CPU 网络 磁盘I/O-->优化代码 增加并发和机器  GC垃圾回收问题-->性能问题常常源自过长的GC时长 可以通过打印日志 或者 使用分析GC的工具    CPU瓶颈或者线程争用-->使用代码分析工具来定位热点线程 CPU分析工具对于探查这类问题也很有用  负载不均-->瓶颈是数据倾斜造成的，可以尝试删除倾斜数据 改变数据分区策略将造成数据的key值拆分 也可以进行本地聚合/预聚合

资源调优

并行度调优

状态后端

多使用ParameterTool工具 是可以序列化的 可以读取外部配置 作为参数传递

看反压 资源利用率 关键指标  检查点时长  GC等等

堆上内存

堆外内存

内存分配策略

内存管理监控和调优

允许将外部文件或数据加载 到任务中 方便访问

通过getRumTimeContext.getCache放到每个taskManager中

通过getRumTimeContext.getDistributedCache().getFile()访问缓存中的数据

缓存数据不会自动清理 只能手动清理

数据要足够小

适用场景

性能影响

资源管理

测试和监控

不同的窗口内积攒的数据量不同 数据的产生速度导致的

解决

配置文件级别

执行环境级别

算子级别

代码运行时

通过webUI定位到多个task的subTask判断是否倾斜 如果某个subTask接收数据量大于其它的 基本数据倾斜了

解决

快 线性扩展 高可靠性  简单方便  功能多  采用LSM Tree 的结构 定期合并 定期删除历史数据 数据导入时全部是顺序 append 写 单条 Query 就能利用整机所有 CPU 数据压缩 提高性能 磁盘存储数据 多核并处理 SQL支持 向量化引擎 实时数据更新 支持近似计算 数据复制和对数据完整性的支持

CPU瓶颈 就不利于同时并发多条查询 不适合Join操作 没有完整的事务 缺少高频率、低延迟的修改或删除已存在数据的能力，仅用于批量删除或修改数据  聚合结果必须小于一台机器的内存大小 不适合Key-value存储，不支持Blob等文档型数据库 支持有限操作系统，正在慢慢完善

接口类型

日志类型

内存类型

外部存储

单条查询就能利用整机的CPU 竭尽所能榨干硬件能力，提升查询速度  使用页缓存将对磁盘的访问变为对内存的访问 减少磁盘I/O 使用零拷贝读取磁盘文件后不需要做其他处理 不需要放到内存缓冲区里面，直接用网络发送出去

是列式存储数据库 使用了向量化引擎

CH是自底向上的、追求极致性能的设计思路

着眼硬件，先想后做-->group by 都是在内存进行 使用hashtable装载数据

算法选择是性能首要考量指标：对于常量使用 Volnitsky（字符串搜索算法）  对于非常量使用 CPU 的向量化执行 SIMD（一个控制器来控制多个处理器）暴力优化；正则匹配使用 re2（一切从简） 和hyperscan 算法（以自动机理论为基础 分为编译器和运行期）  而且一有新算法 尝试性能不错 直接换

不断测试 不断的优化 实验得结果

因为CH单条查询就能利用整机的CPU 当单个查询比较短时，建议100Queries / second（每秒100条并发） 不支持高并发

小公司没有数据治理

基于外部库去关联表  因为表太多了 Flink一直关联效率特别低  还容易产生各种问题

Hive  SparkSQL   Impala  CH