真实模拟面试流程

主题

可以帮助医疗机构更好地理解其财务状况，改进服务质量，并优化资源分配。1 初始化流环境。2.从Mysql中获取订单表，订单详情表。3.转换数据结构 转换成DataBean、筛选出订单状态为成功的订单表。4.然后根据将两个表进行一个表连接。没有连接上的和迟到的数据进行一个合并然后异步IO去Mysql查询。5.关联医院ID将医院信息表进行一个连接，然后在将患者信息进行一个连接。10.在订单详情表与商品金额进行一个连接，进行一个商品价格的补全，地理位置的一个集成，发送到kafka（复用性）。6.判断年龄不同的年龄设置不同年龄组。6.引入水位线延迟5秒。7.将患者性别,患者年龄分组，将两个字段进行一个连接。8.开窗，滚动窗口大小1分钟。9.进行一个全量聚合，在将窗口的开始时间和结束时间设置到databean里面。11.写到CH里面 然后就可以根据维度进行一个汇总数据。通过BI或者SPringBoot接口进行一个展示或使用。

实时分析用户的评价、医院满意度越高可以提高用户忠诚度、口碑、减少流失率、增加收入等。1.初始化流环境，2.获取数据源、获取评价事件，3.先转换结构，转为DataBean。3.关联医院ID、将医院表进行一个广播根据医生的ID进行一个连表，没有关联上的异步去查询，然后补全DataBean数据的医院ID和医院名称维度。5.按照用户id和医院id和医生ID进行分组  将用户ID和医院ID和医院ID进行一个连接。6.通过状态编程统计新增人数、设计一个标记  然后获取到表里面的状态进行一个赋值，判断等于空新评价 然后设置到表dataBean里面的字段（为第一次评价的） 收集bean对象。7.引入水位线延迟5秒。8。根据医院的ID和医生ID进行一个分组。9.开窗 滚动窗口大小1分钟。10.进行一个全量聚合。将窗口的开始时间和结束事件设置到DataBean里面。11.最后输出到CH里面 通过BI或者SPringBoot接口进行一个展示或使用。

join

CoGroup

Interval Join

FlinkCDC是一种用于捕获和处理数据库变化的技术，将数据库变化以流的形式提供给Flink应用程序

算子分为有状态和无状态、无状态根据当前输入输出结果、有状态就是需要历史数据进行一个计算得到结果。状态分托管和原始状态、托管就是Flink帮我管理、原始就是自定义 自己开辟空间进行管理。托管状态又分算子状态和按键分区状态。在实际应用中，很多状态会随着时间的推移逐渐增长，如果不加以限制，最终就会导致存储空间的耗尽。但是用一个进程去所有状态扫描看是否过期、太耗资源、所有就出现设置失效时间、只支持处理时间。状态的存储、访问以及维护，都是由一个可插拔的组件决定的、这就是状态后端。

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

通过getRumTimeContext.getCache放到每个taskManager中

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

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

适合静态表 避免广播大数据集  广播的数据需要序列化  需要性能开销、需要调大TaskManager内存、使用广播变量之前 进行充分的测试和性能评估  以便在程序中不会造成影响、数据量足够小、适应TaskManager内存 不然会导致内存不足的问题

配置文件级别

执行环境级别

算子级别

代码运行时

原因是反压

解决办法

FullGC

OOM

缓存未命中

流图

任务图

执行图

物理执行图

YARN

Standalone

JobManager

TaskManager

并行度

算子链

任务槽

触发任务执行

KeyedStream是一个非常重要的数据结构，只有基于它才可以做后续的聚合

keyBy和聚合是成对出现的，先分区、后聚合，得到的依然是一个DataStream

富函数类

分流

定时器

JM2~4G 足够

单个 TM2~8G 足够

开发完成后，先进行压测。任务并行度给 10 以下，测试单个并行度的处理上限。然后
总 QPS/单并行度的处理能力 = 并行度、并行度*1.2 倍，富余一些资源

source端

transform

sink

状态

Check Point

Meter平均值

Histogram 直方图

Gauge

Count计数器

零拷贝不是完全没有拷贝，只是省去了没必要的拷贝。一个场景:需要把磁盘的某个文件内容拷贝远程服务器。正常情况需要四步：磁盘文件读取到readBuffer、readBuffer通过CPU发送到用户缓冲区、用户缓冲区写到socketBuffer、socketBuffer复制到网卡NIC、最后到远程服务器。零拷贝的原理是把用户缓冲区和socketBuffer省掉，因为这两步需要CPU上下文切换，性能影响、直接读取到readBuffer中，通过DMA技术直接把readBuffer的数据发送到网卡NIC。操作在linux上面是sendfile()方法、在java程序是fileChannel.transferto()方法。底层也是sendfile()。

MMAP允许将文件的全部或者部分映射到进程的地址空间中、文件内容可以直接通过内存访问

页缓存将磁盘上的文件数据以页面为单位缓存在内存中、以加速文件的读取操作

MMAP用于管理消息日志文件、而页缓存是管理各种文件

首先kafka中消息存储在broker中、每条消息对应一个offset、cousumer每次消费数据都会记录数据的offset到（consumer_offsets，默认对50个分区取值）中、可以手动和自动提交。自动提交默认5秒去拉取最大的偏移量（下次该消费的数据offset）然后提交。提交的间隔中kill进行进程或者宕机。就会出现重复消费。还有一种情况就是partitionBalance机制、当消费者增加和减少、主题新增分区、就会触发重新平衡（默认5分钟）导致offset自动提交失败也会出现重复消费。解决办法：1.可以用异步的方式来处理消息，缩短单个消息的消费的时长、2.调整消息处理的超时时间拉长一点、3.减少一次性从Broker上拉取数据的条数、4.使用幂等性（耗费消费资源，增加集群压力）+事务。

消息发送到主题里面对key取余存储分区里面、消费者根据消息平衡消费指定分区、数据已经乱序了。为了保证数据的有序性、可以自定义路由策略、自己按key分区然后指定消费者消费某个分区。

ISR是一个队列集合 放的是Follower节点 类似于Raft算法中的候选人概念  表示有当主的能力 说明它节点正常 并且数据相差不大 如果Follower超过10秒没读取数据或者数据量与leader相差数超过4000条 都会提出ISR集合 放到OSR队列中   待该 Follower 恢复后，Follower 会 读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 Leader 进行同步数据操作  Leader故障后选举第一个恢复的node作为leader提供服务 以它的数据为基准 称为脏leader选举 其它的保证数据一致性 先截取高于HW的部分截掉 在去从新的leader同步数据

单表单主题

多表单主题

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

硬件故障

软件故障

资源耗尽

数据损坏

监控系统

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

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

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

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

影响

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

Segment

RangeAssignor（默认）

RoundRobinASSignor

Sticky粘性的

提供高并发的离线数据上传下载服务

只能以表的形式存储数据

自定义函数

计算引擎

图计算

广告组

数据组

需要对比数据准确性是否一样、看是否是第三方提供数据的问题、有时候需要同时跟开发同一张表、对比结果

java写数据质量管理的后端平台

我们当时没有分的太细、像我的话前期的架构设计、大表的数据拉取（订单表、处方表、咨询的信息表）、数据宽表设计（支付成功的宽表）、任务的压测我都有接触过、我们当时人很少基本就要全链路都要会才行、不仅仅只限于数据的指标一个分析、我们组长每次就去对接需求、然后汇报进度、会有进度表的、几号开发完、几号测试等这些。因为一开始就只知道粗粒度的时间、多久开发完、我们每次汇报的是更细粒度的时间。然后组长会给我们分配任务、尽可能把任务跟任务拆成没有依赖关系的。会给我们排期、我们也会每天写进度、完不成的提前沟通、遇到业务问题多提出来解决。

病例趋势分析

kafka由Producer、broker、consumer三个端组成、只要每个端数据得到保证、数据就不会丢失。producer：1.把异步发送改成同步发送，这样producer就能实时知道发送的结果、2.添加异步回调函数来监听消息发送的结果、如果发送失败，可以在回调中重试。broker：只要数据写到磁盘、基本不会数据丢失。使用ISR副本机制+ACK机制实现消息的可靠性，ISR队列里面有一个leader+多个follower组成、follower回去同步leader的数据、主备切换也可以用。ACK机制的有个应答机制0、1、-1、-1的时候是所有副本全部同步才返回消息给producer。consumer：我认为只要前两个只要不出问题、基本上消费就不会问题

Prometheus

一般在调度工具上写SQL、效率会很高

大数据分而治之  多个节点都跑着任务  指在数据处理过程中，需要重新分布、重组或重新组织数据，以便将数据合并或分发给不同的节点进行进一步处理   中间过程是Shuffle  一个节点任务之间产生Shuffle只会产生磁盘I/O 多个节点任务之间之间产生Shuffle会产生网络 I/O和磁盘I/O  Shuffle可能会产生数据倾斜

Hash Shuffle

 Sort Shuffle

bypass SortShuffle

我们公司处理的数据量比较大、Spark会有一些错误、可能需要通过源码了解真正的原因是什么

yarn集群

组件通信

1.避免创建重复的RDD、对于同一份数据，只应该创建一个RDD，不能创建多个RDD来代表同一份数据

2.尽可能复用同一个RDD、比如现在一个kv形式数据包含了单v的形式数据、我们尽可能就用kv形式的数据、减少RDD的数量

3.对多次使用的RDD进行持久化、SparkRDD原理是每次你对一个RDD执行一个算子操作时，都会重新从源头处计算一遍、如果持久化我们就可以从内存或者磁盘获取、减少计算

4.尽量避免使用shuffle类算子、因为shuffle会落盘产生磁盘I/O还可能产生网络I/O、性能极差

5.预聚合操作、在每个节点本地对相同的key进行一次聚合操作、大大减少需要拉取的数据数量从而减少磁盘I/O和网络I/O

6.使用高性能算子、reduceByKey、mapPartiton、foreachPartitions处理整个分区、而不是一条一条处理

7.广播大变量、广播的变量，会保证每个Executor的内存中，只驻留一份变量副本、Executor的task共享

8.使用kryo优化性能

9.优化数据结构、java中三种对象非常吃内存、对象、字符串、集合，

计算机网络技术、java、计算机组成原理、互联网程序设计、数据库系统原理

将偏移量记录在 state 中，与下游的其他算子的 state 一起，经由 checkpoint 机制实现了“状
态数据的”快照统一

仍然可以在Kafka中保留consumer_offsets主题，以备将来使用或与其他系统共享偏移量信息

1.布隆过滤器

2.FLink状态

3.FlinkSQL

5.Flink CEP

1.10重大改动

有一个作业管理器JobManager主要协调分布式运行  调度任务协调checkpoint，协调失败任务的恢复、任务管理器Task Manager 负责执行任务处理数据 启动后 TM会向资源管理注册 Slot 然后交给JobManger调用、JobManager又包括ResourceManager负责资源的分配和管理 一个集群只有一个 分发可用的任务槽、JobMaster相当于YARN中的ApplicationMaster组件 负责处理单独的任务、Dispatcher负责启动JobMaster

窗口就是无界流转为有界流进行批计算、窗口应该理解成一个桶、窗口把有流切割成有限大小多个存储桶、数据会分发到对应的桶中、当窗口到达结束时间触发计算。动态创建—当有落在这个窗口区间范围的数据达到时，才创建对应的窗口。窗口可以基于时间和计数、窗口又分滑动、滚动、会话、全局（自定义）窗口。

窗口机制

度量事件时间的、数据流中的标记、水位线主要基于数据的时间戳生成的、表示当前事件的进展、水位线是单调递增的、周期性就是不断的发射水位线、尝试触发触发器。往往跟窗口配合、对乱序的数据正确处理。延迟并不是其它数据会进来 只是延迟你这个窗口 等你的数据进来。上游传给下游要以最小的那个作为当前任务的事件时钟。每个任务都以“处理完之前所有数据”为标准来确定自己的时钟

时间语义

source端

转换

sink端

CheckPoint是Flink的核心容错机制，允许系统定期地保存数据流的中间状态，并在发生故障时从这些状态恢复。Checkpoint 是分布式快照，包括了所有数据源的状态信息。通过使用Checkpoint，Flink 可以确保在任务失败后能够从先前保存的状态中继续处理数据，而不会发生数据丢失或重复处理。检查点的保存是周期性触发的，间隔时间可以进行设置。我们应该在所有任务（算子）都恰好处理完一个相同的输入数据的时候，将它们的状态保存下来。如果出现故障只需要让源（source）任务向数据源重新提交偏移量、请求重放数据就可以了。目前只有RockDB支持增量快照，可以检查耗时。对于没有设置ID的算子，Flink默认会自动进行设置，所以在重新启动应用后可能会导致ID不同而无法兼容以前的状态。所以为了方便后续的维护，强烈建议在程序中为每一个算子手动指定ID。

原理

产生的原因

排查前，先把任务链禁用，每个算子都会单独执行，而不再成为一个链式结构。方便定位

map一进一出、flatmap一进多出、keyBy分组、aggregate聚合、reduce聚合、union合并、connnect共享、process最多、最底层

使用RockDB开启增量检查点、开启本地恢复、增大 block 缓存命中率高、增大 write buffer 和 level 阈值大小（320~640MB）、增大 write buffer 数量、增大后台线程数和 write buffer 合并数、开启分区索引功能

Gelly是一个库、用于图处理和分析、提供了一些图算法的API、用于解决复杂的图问题

FlinkML是Flink的机器学习库，用于构建和执行机器学习模型。它提供了各种算法和工具，以支持在Flink上进行机器学习任务

CEP库用于处理复杂事件序列，例如在金融领域的欺诈检测。它支持定义模式和规则以识别事件序列中的模式。

TableAPI&SQL、允许用户在Flink上使用SQL查询来操作数据流和表

Connector具有与各种数据存储和消息传递系统连接器、以便于系统集成

FlinkSQL CLI、用于Flink SQL的命令行界面，允许用户以SQL方式查询和处理数据

Flink DashBoard、一些Flink管理和监控工具，如Flink Web UI，允许用户实时监控和管理Flink作业

算子分为有状态和无状态、无状态根据当前输入输出结果、有状态就是需要历史数据进行一个计算得到结果。状态分托管和原始状态、托管就是Flink帮我管理、原始就是自定义 自己开辟空间进行管理。托管状态又分算子状态和按键分区状态。在实际应用中，很多状态会随着时间的推移逐渐增长，如果不加以限制，最终就会导致存储空间的耗尽。但是用一个进程去所有状态扫描看是否过期、太耗资源、所有就出现设置失效时间、只支持处理时间。状态的存储、访问以及维护，都是由一个可插拔的组件决定的、这就是状态后端。

1.首先存储问题、因为我们检查点是存储分布式系统HDFS上的（可以存储在其它的分布式数据库里面）、如果存储系统问题那么检查点就会写入失败

2.资源不足、如果当前作业的运行所需的taskManager内存不足或者磁盘空间不足、也会导致CP无法正常运行

3.网络问题、检查点需要在不同的TM之间传输状态数据、如果网络出现了问题可能也会导致数据传输失败、检查点也会失败

4.作业逻辑问题、作业本身的逻辑问题导致无法正确处理状态保存和恢复、也会导致检查点失败

5.作业超时、如果barrier屏障堵塞了导致检查点超时、系统也会认为失败

解决的话可以通过flink的日志、以及一些监控

Flink的Checkpoint保存了应用程序的状态、元数据和配置信息，以确保在发生故障时能够快速且正确地恢复应用程序的状态，从而保证数据的一致性和容错性、我们检查点一般1分钟发送一次、检查点的大小约300M

获取kafka的节点、配置kafka的主题、配置分组ID、配置偏移量、配置序列化器

flink任务更新如何上线

连表的时候出现数据倾斜、可能需要大量的内存来存储倾斜键的数据处理任务导致内存不足。就会频繁触发垃圾回收，以释放内存。这会导致任务的处理速度下降。直到内存溢出、JVM抛出OOM，导致任务失败。flink有会尝试重新启动该任务，但是内存问题仍然存在，任务可能会在短时间内多次失败和重启，导致不稳定的状态、可能还会数据丢失等一系列问题.当时我先去Flink日志去查看的，发现抛出的异常OOM错误。我就给当前任务的内存调大。然后重新跑了下任务，后面我将静态表进行了一个广播变量也是分批广播，动态表进行一些连接。一旦分组或者连表了我就把并行度调大成2倍。加随机盐让他们落到不同分区，实现一个负载均衡

Flink提供了内置的Kafka连接器，可以轻松集成Kafka、Java API直接读取Kafka需要自行处理很多细节，包括消息的分区、偏移量管理、容错性等

通常用于创建富文本文档，如网页、文档、博客文章

==用于比较两个对象的内存地址是否相同、基本类型的包装类、例如int自动缓存了-128~127、当你数据的地址值在这个范围内就是true、equals是一个用于比较对象的内容是否相同的方法

死锁是一种编程情况、死锁情况出现至少两个线程或更多资源、产生死锁的四个必要条件、只要除了互斥其它三个不满足一个就可以避免死锁、当四个条件均满足，必然会造成死锁，发生死锁的进程无法进行下去，它们所持有的资源也无法释放。这样会导致CPU的吞吐量下降。所以死锁情况是会浪费系统资源和影响计算机的使用性能的。那么，解决死锁问题就是相当有必要的了。

当一个变量被声明为volatile后，它保证了对该变量的读写操作都会在主内存中进行，而不是线程的本地内存。这意味着，当一个线程修改了这个变量的值，其他线程会立即看到最新的值，保证了可见性。

volatile 修饰的变量会禁止编译器和运行时环境对其进行重排序，这有助于确保代码的执行顺序符合程序员的预期。

标记阶段

复制阶段

标记-整理阶段

分代回收

并发垃圾回收

分区回收

Hive是构建Hadoop之上的一个数据分析工具、没有存储数据的能力，只有使用数据的能力、将HDFS的数据变成结构化化数据，这些结构化数据称为元数据存在MetaStore、HiveSQL通过Driver进行解析、编译、优化、最后执行MR来计算。

1.谓词下推

2.投影下推

3.常量折叠

4.分区裁剪

先将小表读进内存 然后在map阶段进行一个表匹配、小表放不了内存的使用桶的mapJoin

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

1.UDF映射，继承 GenericUDF 重写 initialize 初始化、evaluate 方法、getDisplayString 方法实现

2.UDTF一行对多行

3.UDAF多行变一行

会写MSCK REPAIR TABLE、他用于修复表的分区目录、Hive表的分区目录需要与表中的分区保持同步，但在某些情况下，hdfsAPi写hive分区表的时候hive查询不到的数据的情况、分区目录可能会与实际的表分区不匹配，可能由于文件操作或者手动的文件移动等原因

1.ReplacingMergeTree

2.SummingMergeTree

3.AggregateMergeTree

4.CollapsingMergeTree

5.versionedCollapsingMergeTree

正常 JOIN，将查询发送到远程服务器。 为了创建正确的表，在每个子查询上运行子查询，并使用此表执行联接。 换句话说，在每个服务器上单独形成右表

使用时 GLOBAL ... JOIN，首先请求者服务器运行一个子查询来计算正确的表。 此临时表将传递到每个远程服务器，并使用传输的临时数据对其运行查询。

1.CK是分布式列式数据库、将数据水平分割成多个分区，并在不同节点上存储和处理这些分区。在进行Join操作时，需要在不同节点上协调数据的合并，这可能涉及到大量的数据传输，从而导致性能开销。

2.CK采用列式存储，以提高读取和分析性能。虽然列式存储非常适合分析查询，但在Join时，需要将多个表的列合并到一起，这可能需要对较多的列进行读取和处理。

3.在CK的分布式设置中，数据通常被复制到多个副本以提高可用性和容错性。Join操作可能需要同时处理这些副本中的数据，从而增加了计算和网络开销。

4.Join操作的性能也受到数据量和Join的复杂性影响。如果要Join的表非常大，或者Join条件非常复杂，那么操作的性能会受到挑战

1.网络问题

2.写入策略

3.写入失败

解决

熟练

熟练

底层

调优

docker

k8s

两个不同的概念但是通常结合使用、自我感觉就像altas和ranger都是数据治理的工具、一个是关注数据的生命周期、一个是关注数据的安全访问控制

使用Docker创建和打包容器镜像，然后使用Kubernetes来部署和管理这些容器。Kubernetes负责将容器分配到工作节点、监控其运行状态、自动扩展、滚动更新、管理网络和存储等

经验

都是构建数据湖的工具

经验

Capacity：基于容量的调度器、允许管理员为不同的队列分配不同的资源、队列资源隔离

Fair：公平调度器、均衡分配资源、适用于共享集群

Fifo：所有应用程序被统一提交到一个队里中、顺序执行

1.维度建模原因是旨在提供用于报表、查询和数据分析的简单、易于理解的数据结构、ER建模满足不了这一点、主要的维度建模的方法主要就是选择业务、申明粒度、确定维度、确定事实。一个场景比如上面需求要看我这个每个地区诊断类型的数量这一个指标、我会先去将这个指标拆出来粒度、需要的维度、度量值、事实表类型等。2.声明粒度、粒度的话一条记录就表示一位用户的一次咨询病例类型、3.确定我的维度、根据维度的设计原则（维度属性尽量丰富 为数据使用打下基础  上游维度丰富 下游计算才会灵活、给出详实的 富有意义的文字描述、区分数值型属性 和 事实（分组的作为维度、计算的作为事实）、将尽可能多的通用的维度属性进行沉淀出来、直接把一些简单的维度放在事实表中、随着时间的流逝发生缓慢的变化的数据形成一张拉链表、为了提升效率 把常用的维度冗余到事实表） 我需要一个地区维度表根据维度的设计方法、选择维度或新建维度 维度在数仓里面要唯一、确定主维表（主维度表应该与多个事实表关联、形成一个维度建模的星座模型、不经常变化的）地区维度表应该算一个、确定相关维表（基于主维表的一些表、四川细分成都这些）、确定维度属性（维度表的字段了）。4.确定事实表、根据事实表的设计原则（尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大、只选择与业务过程相关的事实、分解不可加性事实为可加的组件（商品汇率=商品原价、商品优惠价格）、在选择维度和事实之前必须先声明粒度、在同一个事实表中不能有多种不同粒度的事实、事实的单位要保持一致（订单原价、订单优惠价格）、在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效用0代替、使用退化维度提高事实表的易用性）、我现在可能就需要一张事务型的一张事实表、事务型事实表就是一旦插入不能修改、更新方式就是增量更新、当然还有累积型事实表、描述一条数据的生命周期、可能会有多个时间段、周期型、每周每月的显示。5.我们也是照阿里的一个分层方式、因为我当时看过一本阿里巴巴大数据实践一本书、一般分四层ods原始数据层、dwd数据明细层、dws宽表层、dim数据维度层、asd数据展示层、分层主要目的还是空间换时间 复杂问题简单化  减少重复开发。

根据我们业务需求、根据里面的事件字段ID进行分主题、比如我们里面点击支付了、会有一个支付事件、可能就会分入到支付主题里面这一个情况。

那可能我们把离线数据当成迟到数据、专门去拉取离线一周前的数据

会进行一个开窗、用状态存储数据、用定时器进行触发、如果要连接的话可以用interval Join 进行一个上下界的连接数据、突然要的话那可能会专门跑一个任务单独重置offset用一个by-duration ：把位移调整到距离当前时间指定间隔的位移处进行一个拉取数据吧

CK是列式存储数据库、数据以表格的形式组织

HDFS是一种分布式文件系统，主要用于大规模数据存储和分析，特别是在Hadoop集群上进行大数据处理、它将数据分布在多个计算节点上、数据是以块的形式存储的、也是以块的形式容错的、支持一次写入多次读取、使用日志先行确保数据的一致性。EXT4是一个本地文件系统是在单个服务器上、不是分布式的。

HDFS的NameNode是HDFS文件系统的管理者，它维护了文件和目录的结构以及相关的元数据信息，用于管理文件系统的命名空间和权限，并提供数据块的位置信息、在数据读取和写入的时候都要跟namenode进行一个交互、读取的话可能会去请求他告诉块的一次位置信息、写入的话也需要请求它告诉负载比较均衡并且保证块不在同一个机架上。由于它的重要性，HDFS通常采取容错和高可用性的措施，以避免NameNode成为系统的单点故障

需要继承一个mapper类、这是Hadoop MapReduce框架中Mapper的抽象类、需要重写一个map方法

textFile就是常见的文本格式、orc是列式存储格式与Hadoop环境中大多数框架兼容  性能高  读和写速度快、Parquet也是一种列式存储格式 适合嵌套数据结构 兼容性更强、Avro是一种数据序列化格式，可用于数据的存储和传输、SequenceFile是二进制文件格式，一般作为中间格式存储、可以解决小文件问题

都是处理字符串的API、StringBuffer是线程安全的、因为它的方法都使用了锁 synchronized 修饰。这意味着在多线程环境下，多个线程可以安全地并发访问和修改同一个 StringBuffer 实例，而不会导致数据不一致的问题。StringBuilder是性能高、因为它不需要在每个方法上都获取锁。所以多个线程可以同时访问。常用的话基本都用StringBuilder、好像因为Java的编译器和JVM自动帮我们优化线程安全的问题

我知道的就是Iterator迭代器、增强for循环、forEach

在集合中允许你创建类型安全的集合、以便更好地处理不同类型的数据，某些情况下可以提高性能、允许编译器进行更多的优化、避免没必要的类型转换、拆箱/装箱操作，明确了指定数据类型、代码的可读性也会提高，泛型也可以在编译期捕获类型错误、避免运行时出现类型不匹配的问题。

继承Tread类创建run方法，实现Runnable接口实现run方法这种方式更灵活、避免的java单继承限制，还可以实现Callable接口和Future接口、允许线程返回结果并处理异常

为了确保程序健壮性和资源利用率、JDBC连接数据库会使用连接池、这个连接时有限的、如果不关闭会导致其它程序无法连接甚至数据库连接泄露

因为连接途中还有其它类比如ResultSet、StateMent、如果不关闭的话 会消耗系统的内存资源

还有在操作数据库时，可能会开启事务、需要调用commit提交事务、rollback回滚事务、如果不关闭、事务有可能会无法正确提交或者回滚

在有些情况、数据库会给查询或更新加锁、如果不关闭ResultSet和StateMent类、数据库一直保持锁状态、影响其它事务执行

用于传递命令行参数、允许在java程序运行时传递一些配置信息或者数据、在某些情况下，你可能需要将数据传递给程序，而不是在代码中硬编码。命令行参数可以用于传递数据、文件名、URL、账户、密码等等、还可以在不修改程序代码的情况下，动态地改变程序的行为、

我先说我们先发现问题需要调优说起吧、首先我们把Flink监控的东西全部都开了一个是End-to-EndExactly端到端的全链路追踪、还有一个就是Acquisition state delay获取状态延迟、先把这些开了 我们也可以在metrics看到它延迟的指标。像我们监控的话我们去看WebUI、我们首先去看有没有反压、那个框会变颜色、开始去排查哪个地方会产生反压（因为反压原因时生产速率大于消费速率嘛）、排查前需要先禁用掉操作链、方便排查、先看上游看是不是kafka速度太快、看是否需要加分区、下游的话看是不是CK扛不住了，需要加一个静态的流控、这是一个基本的情况。然后我们看是不是出现了数据倾斜、FLinkWebUI算子上的某一个SubTask看它的处理数据量特别多。有的话基本就出现数据倾斜了、数据倾斜的话可能会有几个通过的解决数据倾斜的方案、首先去看kafka里面是不是数据倾斜了、如果kafka数据源本身就数据倾斜了我们需要调整分区、不是的话我们就去排查flink里面的情况、flink里面分keyBy前和Key后的、如果KeyBy前的只能重新使用分区函数、如果是keyBy后造成数据倾斜了、可以先通过状态进行一个搜集 存入状态 然后在发送下午、如果是keyBy后窗口聚合造成数据倾斜了、我们会先UDF一个类找个BigKey进行一个加盐、后面在进行一个去盐。还有就是内存管理、FLink内存管理分推内跟推外、各自占多少百分比、如果一个占比比较大一个比较小的话可以把百分50%比例进行要给调整。还有就是flink任务里面提交的时候给他打上GC日志、然后通过GC工具对他进行一个GC的分析、看是不是又FUllGC、老年代卡着的话、可能会又大量的对象会进行回收。FLink还可以开启火焰图通过观察类的调用频率（a-b-c）有出现死循环的情况。一般的话基本不会有死循环的情况。还有就会分区数、一般要对应kafka的分区数、这样的话可能不会浪费资源、也不会说争抢并行度的问题。还有就是状态我们一般就是用RockDB状态、他是一个基于磁盘的存储引擎、底层使用了 LevelDB 和 Google 的 LevelDB Key-Value 存储库、它可以进行一个增量的检查点每次存储变化的部分、存储大状态。

我们处理的数据量平时的可能在每分钟20w左右、高峰的话能30多w左右、因为我们实时数据量不是太多、日活巅峰的时候打了300w日活量、但是我们的流失客户比较严重。

kafka的话可能是磁盘和内存、Flink的话可能是CPU和内存、CK的话可能会是磁盘和CPU

可以同时存在一个任务中

可以的、kafka在3.0版本准确的说2.8版本及以上、kafka引入了一个叫做 KRaft 的新控制器选项、替代了zookeeper简化了部署。kRaft将元数据信息存在内部主题里面。

HDFS 允许多个客户端同时打开并读取文件，因为读操作不会改变文件的内容，不会引起数据不一致、当一个客户端以写入模式打开文件时，HDFS 会以排他方式锁定该文件，不允许其他客户端同时以写入模式或追加模式打开同一个文件、多个客户端可以以追加模式打开同一个文件，这允许它们在文件末尾添加数据，而不会相互干扰。追加操作通常用于写入日志或事件数据

原因

如何建设

架构

优化的点