大数据面试题库

基于hadoop的数据分析工具 只有使用数据 没有存储数据能力 存储是HDFS 计算MR 将数据披一层SQL的外层 我们尽管写SQL 就能操作数据

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

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

开启分桶：INTO 分桶数 BUCKETS

分区分桶

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

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

数据倾斜

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

Orc和Parquet

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

一个事实表和多个维度表进行关联 多个维度集成到一个事实表中 大宽表一般都是事实表 包含了维度关联的主键和一些度量信息 维度表是事实表中维度具体的信息 一般join来组合数据 分析比较方便

星形模型

基于星形模型基础上 维度表又跟维度表相关联 间接连接到事实表 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，去除了数据冗余 但操作复杂

雪花模型

多个事实表连接一个维度表 不同事实表共享维度信息 常用于数据关系更复杂的场景

星座模型

数据建模模型

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

数仓分层

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

Hive优化

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

SQL优化

使用桶的map join

小表放不了内存

先将小表读进内存 然后在map阶段进行一个表匹配

小表join大表   小表join小表 

SMB是基于桶的map join 的有序桶

大表join大表  

先将产生数据倾斜的key单独使用mapJoin  其它的使用reduceJoin来实现 最后进行一个合并

Skew Join

Join优化

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

推测执行

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

并行执行

ROW BETWEEN UNBOUND PRECEDING AND CURRENT ROW

滑动窗口

LAG() 往前第几行默认什么代替   LEAG() 往后第几行 默认什么代替   First_VALUE()  取窗口中第一个值   Last_VALUE()取窗口中最后一个值

取值型窗口

rank 间断    disRank 不间断    row_number 不间断 不重复  

分析型窗口

常见开窗函数

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

二进制存储 存储方式行存储 可分割 可压缩  作为中间存储格式 将大量小文件存到一个文件中 kv形式  

Sequence File

自动合并小文件 或 调整参数减少map数量  和 reduce数量

concatenate

将多个小文件合并成一个切片

CombinerFileInputFormat

归档工具  将多个小文件打包成一个har文件 减少元数据同时 仍然可以透明的访问 缺点一旦创建不能改变 需要重新创建一个har文件 

archive

合并操作

union

小文件解决方案

全局排序 在一个Reduce排序 数据越多 效率越低

orderBy

内部排序  每一个Reduce内部产生排序文件 进行排序

sortBy

控制map数据如何拆分到reduce端

distinctBy

具有distinctBy和sortBy的功能  只能顺序排 不能倒排

clusterBy

hive的排序以及区别

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

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

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

压缩格式区别：

Hive

内存分布式的计算框架 可以解决大数据领域的各种计算任务

都是基于内存计算  都有SQLAPI  都是完善的容错机制  都有Exactly Once一致性

共同点

Spark是准实时的 微批次处理 延迟性只能到达秒级 只支持基于时间的窗口  Flink是一有新数据就处理 真正的流式计算，支持毫秒级计算   基于时间驱动  基于数量驱动

流的处理角度

Spark对机器学习的支持很好 可以在内存中缓存中间计算结果来加速机器学习算法的运行 但大部分机器学习算法是一个有环的数据流 Spark却用无环图来表示 Flink支持在运行时间中的有环数据流 更有效的对机器学习算法进行运算

迭代角度

Spark的架构Master、Worker、Driver、Executor    Flink的架构Jobmanager、Taskmanager 和 Slot

架构角度

不同点

与Flink的区别

extends Serializable 序列化-->Java的序列化器   缺点-->Java的序列化能够序列化任何的类。但是比较重（字节多），序列化后，对象的提交也比较大 性能低

Kryo 序列化-->Spark2.0开始支持一种 Kryo序列化机制   速度是Serializable的 10 倍  当RDD在 Shuffle 数据的时候 简单数据类型 数组和字符串类型已经在 Spark内部使用Kryo来序列化  注意：即使使用 Kryo 序列化，也要继承 Serializable 接口

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

RDD序列化

保存到内存 效率高 数据不安全容易丢失 懒执行

cache

保存到磁盘（临时文件，作业结束后会删除），效率低，数据安全 懒执行

persist

保存到磁盘 永久保存 HDFS，效率低，数据安全 可以切断RDD的依赖关系

checkpoint

持久化

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

RDD 与 RDD 一对一 关系 所以无需等待其它分区数据 即可继续往下执行 继承NarrowDependency

宽依赖

RDD 与 RDD  一对多 （会有Shuffle的产生） 会等所有分区都执行完毕 就开始 继承ShuffleDependency

窄依赖

依赖关系

任务划分就是靠宽窄依赖来划分的任务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可能会产生数据倾斜

不要求数据有序  将数据Partition 好，并持久化形成一个 ShuffleBlockFile 持久化减少内存存储空间压力，另一方面也是为了容错性

Hash Shuffle

引入了MR的shuffle机制 将所有的 Task 结果写入同一个文件，并且对应生成一个索引文件  只需要根据索引找文件

 Sort Shuffle

是对Sort Shuffle一种策略的实现

Tungsten Sort Shuffle

shuffle

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

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

在部署spark集群中指定资源分配的默认参数（尽量给当前的应用分配更多的资源）

资源调优

避免创建重复的RDD 对多次使用的RDD进行持久化 提前预聚合shuffle的操作 尽量使用高性能的算子 使用广播变量  使用Kryo优化序列化性能  优化数据结构

代码调优

调节Executor的堆外内存

内存调优

可以降低资源浪费 提高spark任务的运行效率  task数量应该设置为sparkCPUcores的2-3倍  数据在HDFS中，降低block大小，提高RDD中partition数

并行度调优

调优

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

是Spark的基本数据结构  允许程序员以容错方式    在大型集群上执行内存计算  表结构类似于 没有字段名 并且只有一个字段 而且没分开

RDD

封装了RDD 只关心要做什么，而不用关心怎么去做，将一些优化的工作交由 Spark 框架本身去处理    表结构类似于 将RDD的数据炸开 然后每个数据都有对应的字段名  行转列

DataFrame（弱类型）

封装了DataFrame 具有RDD的优点（强类型 ） 支持强大的Lammsba函数  具有很多类型转换  以及 SparkSQL的优化执行引擎的优点    表结构类似于 将DataFrame列转行  并且有字段名

DateSet（强类型）

RDD、DataFrame、DateSet之间的区别

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

提交参数

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

五大属性

适当增加spark standby master 

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

spark如何保证宕机迅速恢复

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

reduceByKey和groupBykey的区别

根据CPU的数量来决定的  部分减少了文件和文件句柄  并行度很高的情况下还是会产生很多小文件 

优化前是 T*R   优化后C*R

conslidate

如何解决HashShuffle时在map端产生的小文件

task计算

shuffle聚合

解压 反解压 序列化 反序列化

RDD的持久化和广播变量

90％

预留10％  防止OOM溢出

统一内存管理

Spark

高吞吐量的分布式消息订阅系统 可以处理消费者流数据  支持离线和实时数据处理  每秒能达到100条消息传输  Kafka是无序的 只有一个partition内顺序读写

1.生产者：将产生的消息存放到对应的Topic消息根据分区规则存放到不同的Partiton，然后同步到Replication2.offest：唯一的标识一条消息 一个消息只能被一个组消费一次 一个组记录当前Topic消息消费的进度3.topic：生产者发送的消息类别称为主题4.partition：主题中的数据会被切分为至少一个或多个Partiton   每个分区中数据插入有序，新增的数据都会分配到队列尾部5.replication：每一个分区都拥有副本保证数据的安全 Partiton为了数据的读写 Replication为了数据的备份，没有读取功能6.consumer：消费者就是从Topic读取数据 消费者组一组共享一个Topic的偏移量 一个消费者组内包含一个或者多个消费者 不同的组可以同时消费相同的Topic7.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结果  安全 效率低

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

数据不丢失ACK机制 精准一次消费

核心就是引入了生产者id 和 sequence number  新的生产者初始化的时候都会被分配一个PID，这个PID对用户而言是完全透明的  对于每个PID，消息发送到的每一个分区都有对应的序列号，这些序列号从0开始单调递增 生产者每发送一条消息就会将对应的序列号的值加1  broker端会在内存中维护一个序列号 新的+1比旧的大  broker接收 新的比旧的超过2 broker报错 新的比旧的小 broker不接收

幂等性

事务主要是为了解决幂等性无法跨Partition运作的问题，事务性提供了多个Partition写入的原子性 允许应用可以把消费和生产的 batch 处理 多个分区  要么全部成功 要么全部失败

事务性

数据不重复

Kafka把topic中一个Parition大文件分成多个小文件segment，通过多个小文件segment，就容易定期清除或删除已经消费完的文件，减少磁盘占用。 为了进一步的查询优化，Kafka默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。索引文件通过稀疏存储，降低index文件元数据占用的空间大小 针对数据压缩 新增的二级对数索引

文件存储设计特点

为了提高读写硬盘的速度，Kafka使用顺序I/O  收到消息后Kafka会把数据插入到文件末尾，每个消费者对每个Topic都有一个offset用来表示读取的进度

顺序写入

操作系统实现的一种主要的磁盘缓存，以此用来减少对磁盘I/O的操作 就是把磁盘中的数据缓存到内存中，把对磁盘的访问变为对内存的访问  内存作为磁盘缓存，甚至会将所有可用的内存用途磁盘缓存，这样当内存回收时也几乎没有性能损失，所有对于磁盘的读写也将经由统一的缓存

pageCache

基于sendfile实现零拷贝，数据不需要在应用程序做业务处理，仅仅是从一个DMA设备传输到另一个DMA设备。此时数据只需要复制到内核态，用户态不需要复制数据，然后发送网卡

零拷贝

高吞吐的本质

为什么快

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

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

不能保证消息的有序性

实时的消息易丢失  没有kafka做削峰 会造成数据堵塞

影响

框架中kafka起到了什么作用  不用kafka有什么影响

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

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

kafka消息数据积压  kafka消费能力不足怎么办?

恢复

硬件故障

通过查看日志是否有错误消息

软件故障

增加硬件

资源耗尽

通过备份恢复数据

数据损坏

通过监控系统及时发现问题 以及解决

监控系统

kafka挂掉原因以及怎么恢复

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

生产者端的Request流程，消息打批之后发出？

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

上下游切换

Kafka

流批一体  所有流式计算场景 正确性保证 分层API 聚集运维 大规模计算 性能卓越

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

数据按照生成的顺序进入流中 水位线就是自增的 但一对一消耗资源 所以我们周期内取最后一条作为当前窗口水位线

有序

正常情况 数据都是乱序进入流中的 所以我们找周期内最大的那个时间戳作为水位线

无序

周期型会不停的发射水位线 去尝试触发触发器 触发成功窗口结束计算

周期型

在事件触发的方法中发出水位线 定点生成器会不停的检测OnEvent()中的事件 当发现带有水位线信息的特殊事件时 才发出水位线

定点型

对于延迟到的数据我们可以用水位线延迟时间  但是延迟太久会影响实时性和效率

允许窗口延长关闭  正常情况窗口触发完成计算之后就会销毁  但是他会等延迟时间到达之后会再次触发窗口计算 窗口时间+水位线时间=计算第一次  计算第一次结果+延迟时间=计算第二次

lateness

保证消费一次如果迟到数据还没到  为了保证数据至少一次 创建侧输出库 让迟到数据存储到侧输出库 通过测输出流输出 必须是迟到数据

测容器

延迟数据处理

水位线

每个算子维护一个事务日志 跟踪已处理事件 重放失败事件 在进入下一个算子之前 删除重复事件

least+去重

依赖sink端存储的去重性 和 数据特性  实现简单 开销较低  缺点依赖存储和数据特性太强

least+幂等

分布式快照

能够进行重复消费  将偏移量记录在State中 与下游的算子一起 经过checkPoint机制 实现快照统一  我们只能说事件发生多次 我们只能反映一次给状态后端一次 有效一次

source端

基于分布式快照算法 实现了整个数据流中各算子的状态数据快照统一

转换

数据不能重复  采用幂等写入方式任意多次向一个系统写入相同数据，只对目标系统产生一次结果影响    结合事务和 checkPoint机制 保证只对外输出保证一次影响

不支持事务的存储系统 使用预写日志 不能百分百精确一次 它有二次确认 当数据成功写入 会再次确认相应的检查点  需要将二次确认持久化  用于后面的故障恢复 有确认消息才能保证数据成功 缺点就是二次确认 检查点和写入都成功 确认消息失败 会导致重复写入

预写日志

第一阶段消费数据时  协调者向所有参与者发起是否可以执行预提交操作，等待所有参与者的响应  所有参与者执行事务操作 存储checkPoint并持久化   如果参数者事务操作执行成功  对协调者返回同意 反之 返回终止  第二阶段 协调者获取到所有消息 都是同意才发出提交请求  参与者完成操作 释放事务期间占用的资源  向协调者发送事务完成消息   协调者反馈消息 完成事务 如果一个失败或超时了发出回滚请求  参与者进行最近的checkPoint回滚 释放事务期间占用的资源  向协调者发送回滚完成消息 协调者反馈消息 取消事务

两阶段提交

sink端

精准一次消费

窗口机制

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

等到上游所有的并行子分区barrier都到齐 才去保存当前任务的状态 缺点：先到达的分区要做缓存等待，会造成数据堆积（背压）

barrier对齐

解决Barrier对齐 当一个barrier先到达 不用等barrier到齐 不缓存等待 继续向下走 但是这些数据都会打一个标记 然后等后面的barrier到了 然后将这些标记数据在拿到一起计算

barrier对不齐

checkPoint  Barrier

因为CheckPoint barrier跟随普通数据一起流的 不会越过普通数据 导致端-端期间的时长边长 为了保证准确一次 多个管道就需要对齐 接收到较快的管道数据后 后面的数据就会缓存起来不处理  放到state里面   导致checkPoint变大 还有问题可能定期生成器出问题了 就是代码问题

原因是反压

降低Source的并发度、拉取频率、拉取量；提高checkpoint发送频率；提高同时能够进行的checkpoint数量；提高checkpoint超时时间；启用非对齐checkpoint

解决办法

检查点超时

先将数据缓存在state中  当窗口触发计算时进行join操作 为了满足流处理的实时性要求（等待所有参与join的事件到达后再进行处理） 也为了实现容错性（将状态持久化到可靠存储系统中）

join

除了输出匹配的元素对以外，未能匹配的元素也会输出 谁调的方法 谁就是左表

CoGroup

基于一个上界开区间 下界闭区间 在此范围的就可以做连接 数据必须先keyby才能进行连接

Interval Join

双流Join

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

状态

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

反压是什么

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

Metrics 配置

解决

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

解决反压

设置参数的时候内存调大  然后并行度也可以设置 测试出高压力下单并行度的处理上限 然后使用你这次任务需要用到多少QPS/单并行度=并行度条数了

source端的并行度一般跟数据源的并行度保持一致  转换端分组前与source保持 分组后并行度*2 防止数据倾斜  sink端并行度要与下游的抗压决定

多使用RockDB 基于LSMTree  有长窗口  可以存储较大的数量（2G） 可以进行增量检查点

状态后端

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

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

Flink优化

分配给Java 由java的垃圾回收来管理  存储用户定义的状态 数据结构 和 操作符状态   flink的内存管理器会为每个算子分配内存  回收内存

堆上内存

JVM之外的内存的 存储大量的数据 减轻JVM内存的压力  如RockDB的数据 

堆外内存

静态分配和分段内存分配

内存分配策略

提供了监控API 用于监控内存的性能和指标 有助于识别内存问题

内存管理监控和调优

flink的内存管理是如何做的

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

通过getRumTimeContext.getCache放到每个taskManager中

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

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

Flink的分布式缓存

适应TaskManager内存 不然会导致内存不足的问题

数据要足够小

适合静态变量 不适合变化特别快的数据

适用场景

避免广播大数据集  广播的数据需要序列化  需要性能开销

性能影响

需要调大TaskManager内存

资源管理

使用广播变量之前 进行充分的测试和性能评估  以便在程序中不会造成影响

测试和监控

使用广播变量的注意事项

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

重新设计Key  在窗口计算前预聚合

在使用window时 出现数据倾斜 怎么解决

fink.conf.yml

配置文件级别

setParallism()设置在方法后面设置  默认环境内所有都是此配置

执行环境级别

通过setParallism()定义单个算子

算子级别

通过在linux上面执行任务时 设置的并行度

代码运行时

flink的并行度有了解嘛 哪几种级别

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

先通过状态进行一个进行一个搜集 存入状态  进行一个聚合 然后在发送下去

keyBy后造成的数据倾斜

使用其它的重新分区函数

keyBy 之前发生数据倾斜

key拼接随机数前缀或后缀，进行keyby、开窗、聚合

keyBy 后的窗口聚合操作存在数据倾斜

Flink

列式存储数据库 底层也是  采用LSM Tree 的结构 定期合并 定期删除历史数据 数据导入时全部是顺序 append 写单条 Query 就能利用整机所有 CPU

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

优点

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

缺点

merge-->主要用于将多张表进行异步查询 最终合成一个结果集返回  要求要在同一个数据库内  相同表结构  引擎可以不同

接口类型

Log-->由数据文件 元数据文件 数据标记组成  

TinyLog-->由数据文件和元数据文件组成 不支持分区 没有mrk文件 无法读取数据

striptLog--> 由数据文件 元数据文件 数据标记组成

日志类型

将全量数据放入内存中 memory引擎-->直接将数据放在内存中 不压缩 不会格式转换 重启数据丢失 

set引擎-->去重 先写入内存 在写入磁盘  Join引擎-->连接表

内存类型

从其它存储系统读取数据 HDFS JDBC Kafka Mysql

外部存储

项目中常见引擎

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

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

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

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

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

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

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

并发量

ClickHouse

子主题

Redis

Flume

小公司没有数据治理

数据治理

离线数仓

flink的taskManager  4G

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

实时连表

实时项目

分布式SQL查询引擎  用于大规模的数据分析

Hive  SparkSQL   Impala  CH

替换组件

Trino

是一种压缩格式  google开发的   高性能和跨平台支持

ProToBuf

存储和管理图数据的系统

常用于  一张表的某一个字段和另一张表的关系

图数据库

分布式 实时的OLAP工具  多维数据建模  列式存储  多数据源

StarRocks

一种概念  描述用于管理和可视化数据资产的工具、平台或技术

Atlas可以被视为一个特定的数据地图工具，因为它专注于数据治理和元数据管理

数据地图

Doris

面试题库