自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(25)
  • 收藏
  • 关注

原创 11111

5AYV1D1RE5-eyJsaWNlbnNlSWQiOiI1QVlWMUQxUkU1IiwibGljZW5zZWVOYW1lIjoiaHR0cHM6Ly93d3cuaml3ZWljaGVuZ3podS5jb20iLCJhc3NpZ25lZU5hbWUiOiIiLCJhc3NpZ25lZUVtYWlsIjoiIiwibGljZW5zZVJlc3RyaWN0aW9uIjoiIiwiY2hlY2tDb25jdXJyZW50VXNlIjpmYWxzZSwicHJvZHVjdHMiOlt7ImNvZGUiOiJJS

2025-04-14 17:16:30 356

原创 Flink回撤流详解 代码实例

在 Flink 中,回撤流主要出现在使用 Table API 或 SQL 进行聚合或更新操作时。对于那些结果并非单纯追加(append-only)的查询,Flink 会采用“回撤流”模式来表达更新。回撤流一般以元组形式输出,格式为。其中:true表示这是一条新的记录(添加),false表示这条记录是对先前结果的撤回。第二个元素是具体的记录数据(Row)。当一个聚合或窗口计算的结果发生更新时,Flink 会先发送一条撤回消息(撤回旧的计算结果),然后发送一条新的添加消息。

2025-04-10 10:57:59 1253

原创 Spark的shuffle史上最详细解析 , 应用场景等多维度

Shuffle 是 Spark 计算的核心环节通过分区重分配把相同 Key 或需要同一分区的数据集中在一起,为后续的聚合和连接提供可能。同时也带来了大量的磁盘 IO、网络 IO 和序列化开销,需要在设计与调优中重点考虑。合理的分区与良好的数据分布是关键常见的调优手段包括:减少数据倾斜、优化分区数、利用外部 Shuffle Service、选择合适的 join 方式、开启 Push-Based Shuffle 等。多场景需求、多方式应对。

2025-03-31 11:18:27 1014

原创 Flink的Look Up Join详解

- 定义主流订单表(从 Kafka/Socket 等)) WITH ('connector' = 'kafka', -- 示例,这里仅做说明-- 定义 MySQL 维表) WITH ('lookup.cache.max-rows' = '5000', -- 启用缓存,最多缓存 5000 条'lookup.cache.ttl' = '60s', -- 缓存条目的 TTL 为 60 秒'lookup.max-retries' = '3' -- 遇到网络或其他错误时最多重试 3 次。

2025-03-18 09:16:15 839

原创 Flink的addsource和formsource的区别

核心区别:面向老版,简单易上手,适合快速开发或兼容历史遗留项目,但在大规模分区管理、批流一体等高级功能上略显不足。:基于新 Source API(FLIP-27),面向批流统一、更强的容错与分区管理能力,官方推荐在新项目中使用。应用场景老项目兼容或自定义简单数据源场景;需要快速实现类似 Socket / 自定义队列 / 读取小规模文件等。新项目、新连接器(KafkaSource、FileSource、PulsarSource、IcebergSource等),需要批流统一或更强大容错;

2025-03-18 09:11:17 434

原创 Spark常用算子详细解析

在 Spark RDD 的编程模型中,算子(Operator)分为(转换)和(行动)两大类。代表对 RDD 进行转换并返回新的 RDD(惰性执行),则会触发实际作业执行并返回结果(或写出到外部存储)。下面列举 Spark RDD 常用的算子,并给出简要示例及说明。

2025-03-15 09:38:40 486

原创 Flink的广播流最详解

【代码】Flink的广播流最详解。

2025-03-13 20:10:56 818

原创 Hive窗口函数用法

排名函数偏移函数(lag、lead)值提取函数聚合窗口函数(sum、avg、min、max、count 等)通过结合 PARTITION BY、ORDER BY 以及适当的窗口范围定义,你可以轻松实现分组累计、移动统计、行间比较和分组排序等高级分析任务。这些函数使得在不改变原始行数的前提下,为每一行附加额外的分析信息成为可能,大大提高了数据处理和报告生成的效率。

2025-03-13 09:26:36 689 1

原创 Hive函数用法详解

字符串函数用于字符串的拼接、截取、大小写转换、替换、正则匹配、JSON 解析、URL 解析等操作。数学函数包括基本的加减乘除、取整、随机数、对数、幂运算、平方根、进制转换以及求最大值、最小值等。日期函数实现日期和时间的格式转换、计算(加减天数、月份、比较、间隔计算)和提取(年、月、日、周等)。条件函数用于实现 if(三元表达式)、nvl、coalesce、CASE 判断等逻辑判断操作。聚合函数如 COUNT、SUM、AVG、MIN、MAX、以及统计分布、直方图、近似中位数等,用于汇总统计。

2025-03-13 08:50:19 1114

原创 Hbase的Region自定义阀值

HBase 默认使用或类似的策略来根据进行自动分裂。若需要更灵活的分裂逻辑(比如按时间分裂、按行数分裂等),可以通过自定义 SplitPolicy编写自定义类继承在表属性或全局配置中设置为你自己的类全路径HBase 在分裂判断时会调用该策略这通常只在对分裂行为有特殊需求时才使用。Region 可以通过阈值()进行自动分裂,该阈值既能全局设置,也能在建表/改表时为单张表独立设置。达到阈值后,Region 会自动 split 成两个更小的 Region。

2025-03-12 21:52:16 342

原创 Hbase架构以及组件

HBase是基于设计理念构建的一种分布式、面向列(Column-Oriented)的 NoSQL 数据库,运行在Hadoop生态之上,主要依赖HDFS进行底层存储。它可以为海量数据提供随机读写能力,支持高吞吐、低延迟的实时查询与更新,特别适合大规模半结构化/非结构化数据的存储与管理。客户端向相应的 RegionServer 发送写请求将数据先写入WAL(保证持久化),再写入MemStore(内存)当 MemStore 达到一定阈值时,触发flush将数据刷到 HDFS,形成新的HFile。

2025-03-12 21:45:35 525

原创 Hbase组件及作用详解

作为集群协调者,管理各节点及 Region 分布;负责具体数据的读写和存储操作;ZooKeeper保证了集群内的协调、选举和状态管理;Region实现了数据的水平切分和动态扩展;MemStore与WAL共同构成了数据写入的缓存和恢复机制;HFile提供了高效的数据持久化存储;同时,丰富的客户端接口以及辅助优化组件(如 Compaction、Block Cache、Bloom Filter)确保了 HBase 的高性能和扩展性。

2025-03-12 21:31:30 762

原创 MR的yarn工作流程

在 MR 的 YARN 工作流程中,YARN 主要负责资源的统一管理与调度,而 MRAppMaster 则作为作业的协调者,将 MR 作业拆分为多个 Map 和 Reduce 任务,向 RM 申请资源,并通过与各 NodeManager 的协同来启动、监控和重启任务,从而实现高效、容错的分布式计算。

2025-03-12 09:04:15 338

原创 Hive Spark Flink Hdfs数据倾斜解决方案优化

综合以上分析,我们针对不同框架的数据倾斜问题提出以下最佳实践和可操作的优化策略:Hive 离线计算设计健壮的SQL:尽量避免产生倾斜的查询模式。大表Join尽量先过滤无关数据,或者拆分步骤处理。适当使用MAPJOIN/广播小表,减少需要shuffle的数据量.启用倾斜优化参数:在Hive on MR/Tez上开启和)等,让Hive自动检测并处理倾斜键.充分利用分区和桶:数据导入Hive时设计合理分区键,避免单分区数据过于悬殊。

2025-03-11 20:45:19 1390

原创 Flink的三种键控状态详解

ValueState提供了最简单的状态管理方式,每个 key 对应一个值,适合简单、单一状态存储。ListState允许存储一系列数据,适合需要保存多个同类型事件或记录的场景,并支持对这些数据的迭代和批处理。MapState提供了键值对存储能力,可以在单个 key 下管理多个子状态,适合存储结构化、维度较多的数据。选择哪种状态类型需要根据你的业务逻辑、数据量、更新频率和查询需求来决定。在实际开发中,合理设计和管理状态不仅能提高处理效率,还能有效控制资源消耗和容错恢复能力。

2025-03-11 19:15:11 757

原创 原子指标,派生指标,衍生指标 详解及区别

在数据仓库和指标体系设计中,我们常常将业务统计指标分为三大类:原子指标、派生指标和衍生指标。它们之间既有层次关系,也各自承担着不同的功能和计算逻辑,下面详细讲解它们的含义、特点与区别。

2025-03-11 08:55:22 840

原创 Flink on yarn 的三种模式分别详细讲解 及区别

模式集群生命周期作业隔离性提交速度适用场景Session长期运行较弱,共享资源快多作业共享、资源复用要求高、提交频繁Per-Job作业独立启动和关闭强,资源独占慢(启动有延时)对作业隔离要求高、独立任务较多的场景作业独立启动和关闭强,资源独占慢(启动有延时)简化部署、一次性打包提交、利用 Yarn 应用管理Session 模式适合需要快速提交、资源共享和持续运行的场景;Per-Job 模式则适用于单个作业需要独立运行且对隔离性要求较高的情况;

2025-03-11 08:53:12 651

原创 Flink反压最经典处理方式之一 基于 Credit 的流量控制机制

另一种经典的反压处理方案是,它在 Flink 1.5 及以后版本中得到了广泛应用。这种机制从应用层直接控制数据传输,避免了传统 TCP 层反压的局限性,能够更灵活、迅速地反馈下游的缓冲状况。下面详细介绍这种方案的原理、流程和实现细节。

2025-03-10 20:04:21 900

原创 Flink反压最经典的处理方式之一详解 基于有界缓冲池(LocalBufferPool)的阻塞队列模型

下面介绍 Flink 反压最经典、也是最核心的实现方式——,该机制天然融入了 Flink 的数据传输和内存管理中,实现了上下游流速自适应的动态反馈。下面将从原理、流程、以及具体实现细节三个方面详细说明这一经典机制。

2025-03-10 19:59:17 477

原创 Flink的数据倾斜,KeyBy之前和 KeyBy之后

在 Flink 的 DataStream API 中,keyBy是对流进行哈希分区相同 key的数据会被路由到同一个并行子任务(subtask)里;不同 key会分散到不同的 subtask,以实现分布式处理。典型场景:分组聚合()、KeyedProcessFunction、KeyedState 等需要根据 key 进行状态或窗口管理的场景。keyBy 之前尽量过滤无用数据、预聚合减少数据量;如果可行,使用rebalance或随机拆分将热点打散;提高上游并行度,减少单算子成为瓶颈。

2025-03-10 16:05:30 780

原创 Flink反压机制

​Flink中的反压(Backpressure)是指数据流处理过程中,下游任务的处理速度跟不上上游任务的数据发送速度,导致数据在系统中积压,可能引发系统性能下降、延迟增加,甚至资源耗尽等问题。监控反压状态:​Flink提供了Web UI,可以查看各个任务的反压状态。下游任务处理能力不足:​当下游任务的计算资源配置不足,或处理逻辑复杂度过高,导致其处理速度跟不上数据流入的速度,进而引发反压。优化资源配置:​根据分析结果,适当调整任务的并行度、资源配置,或优化任务的处理逻辑,以提高处理能力,缓解反压。

2025-03-10 15:56:42 1031

原创 HDFS读写流程总结

在数据写入过程中,如果某个DataNode发生故障,客户端会将数据包重新发送到其他可用的DataNode,确保数据的可靠存储。在数据读取过程中,如果发现某个副本不可用,客户端会自动切换到其他副本,保证数据的可用性。以下是对HDFS读写流程的详细解析:。:如果在读取过程中,客户端发现某个DataNode不可用,会尝试从其他DataNode读取该数据块的副本。客户端还会通过校验和验证数据的完整性,确保数据的准确性。:NameNode根据文件的元数据,返回每个数据块的存储位置(即DataNode的地址)。

2025-03-10 15:51:12 417

原创 Flink优化有史以来最详细版

我将为你提供最全面、最详细的 Flink 优化方案,包括性能优化、资源优化、状态管理优化、窗口和水位线优化、运维优化、SQL & Table API 优化等方面,并结合具体场景来说明优化策略。我会整理所有相关信息,并尽快反馈给你。1. 性能优化:优化Flink作业的吞吐和延迟需从数据流设计和算子配置入手。首先,在数据处理速度方面充分利用批流一体的架构:对于有历史数据和实时增量的数据分析场景,可采用“先批后流”的方式,即先用Flink批处理模式处理历史数据,再无缝切换到流模式处理实时数据,以减少重复计算和延迟

2025-03-10 15:02:14 1213

原创 Hive数据倾斜问题

数据倾斜指的是在 Hive 执行 MapReduce 作业时,部分 key 对应的数据量远超其他 key,导致大部分 reducer 很快完成,而少数 reducer 因为数据过多而拖慢整个作业进度,甚至出现内存溢出或任务失败的情况。这种现象常见于 Join、Group By、Count Distinct 等场景【citeturn0search0】【citeturn0search4】。参数调优:启用和参数,让 Hive 自动生成两个阶段的 MR Job 来负载均衡。SQL 层优化。

2025-03-10 14:59:59 808

原创 离线数仓_数据倾斜的优化

当 Hive 发现 Join 操作中某个 Key 数据量远超其他 Key 时,会自动将这些倾斜数据写入临时文件,然后通过 MapJoin 或单独任务来处理,避免单个 Reducer 成为瓶颈。当两张大表按某个 Key 进行 Join 时,如果其中一张表在某个 Key 上数据量异常大,则该 Key 会导致对应的 Reduce 任务处理数据量远超其他任务,进而引起整体作业延迟。如果某个 Key 数据量特别大,可以为该 Key 添加随机前缀,将一个大 Key 拆分为多个子 Key,再在最后聚合时恢复原始结果。

2025-03-10 14:56:12 906

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除