设计原理
关注
分享
扫一扫
文章平均质量分 91
RunningShare
微信公众号为：跑享网，博主有近多年工作经验，近8年大数据开发、运维和架构设计经验，将与您探讨Flink/Spark、StarRocks/Doris、Clickhouse、Hadoop、Kudu、Hive、Impala等大数据组件的架构设计原理，以及大数据、Java/Scala的面试题以及数据治理、大数据平台从0到1的实战经验等，也会与大家分享一些有正能量的名人故事，也包括个人成长、职业规划等的一些感悟，有探讨或感兴趣的话题，欢迎留言或私聊哈，如果文章对您有所启发，麻烦帮忙点赞+收藏+转发哈，若有大佬的打赏，更是感激不尽，小编将继续努力，打造更好的作品，与您一起进步~~
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
数据一致性危机！90%大数据团队都踩过的坑，你中招了吗？
大数据环境下的分布式事务一致性成为技术难点，本文深入剖析了Hadoop、Spark、Flink等主流大数据组件的解决方案。通过电商平台真实案例，展示了从0.5%不一致率降至0.001%的技术改造过程，包含HDFS写入机制、HBase事务、Spark检查点、Flink两阶段提交等核心代码实现。最后提供技术选型指南，帮助开发者根据实时风控、数据湖ETL等不同场景选择最佳方案，解决订单金额对不上、库存飘忽不定等典型数据一致性问题。原创 2025-11-03 22:57:58 · 372 阅读 · 0 评论 -
卷疯了！大数据面试必问的分布式锁，到底怎么选才不踩坑？
分布式锁方案对比与选型指南 在大数据高并发场景下，分布式锁是确保数据一致性的关键组件。本文对比了三种主流实现方案： 1. Redis分布式锁 优点：性能最佳，实现简单，适合高并发场景 缺点：可靠性依赖Redis可用性，主从切换可能丢锁 2. ZooKeeper分布式锁 优点：强一致性保证，临时节点自动释放防死锁 缺点：性能较低，部署维护复杂 3. 数据库分布式锁 优点：实现简单，强一致性 缺点：性能差，容易成为系统瓶颈 选型建议： 超高并发场景选择Redis 金融等强一致性场景选择ZooKeeper 简单系原创 2025-09-29 22:59:22 · 1052 阅读 · 0 评论 -
大数据存储的终极秘密：LSM树如何让Kafka、HBase、Flink等性能提升100倍？
本文通过图书馆的生动比喻，深入浅出地解析了LSM树的核心原理及其在大数据存储系统中的应用。文章从传统B+树的问题入手，详细阐述了LSM树的四大组件（WAL、MemTable、SSTable、Compaction）及其工作流程，并对比分析了HBase、Kafka、Flink和Cassandra等系统如何基于LSM思想实现各自独特优势。最后提供了技术选型指南和优化建议，指出LSM树未来的发展方向。全文以通俗易懂的方式揭示了大数据存储系统的架构智慧，帮助读者理解LSM树如何通过批处理和顺序写入实现高性能存储。原创 2025-09-07 11:47:54 · 752 阅读 · 0 评论 -
为什么HBase写入飞快，随机读却成性能瓶颈？深度解析LSM-Tree的取舍艺术
问题根源表现解决思路具体方案LSM-Tree读取放大一次读请求，多次I/O变随机为顺序；减少I/O优秀的RowKey设计；启用Bloom FilterBlockCache效率低缓存命中率低，内存浪费改进缓存架构使用BucketCache（堆外/SSD缓存）Compaction资源竞争读写延迟毛刺调整Compaction策略选择合适的Compaction算法（STCS, LCS）和时机架构不匹配极致随机读需求无法满足引入旁路系统，各司其职Redis/Memcached作缓存；原创 2025-09-05 09:56:07 · 787 阅读 · 0 评论 -
Flink、Kafka、Pulsar水位线机制对比：三大流处理组件的时序管理之道
Flink：强大的流处理引擎，提供完整的水位线机制和时间语义Kafka：可靠的消息存储，通过HW机制保证数据消费的安全性Pulsar：统一的消息平台，结合了两者的优点并提供更好的扩展性技术选型建议需要复杂事件处理→ Flink（丰富的时间语义和状态管理）需要高吞吐消息队列→ Kafka（成熟的生态系统和稳定性）需要统一消息平台→ Pulsar（多租户、低延迟、高吞吐）水位线机制虽在不同系统中形态各异，但本质都是管理数据处理进度。理解各组件的特点，才能构建出稳定高效的实时数据处理架构。原创 2025-08-27 00:21:59 · 946 阅读 · 0 评论 -
Flink通过重用对象缓解背压的核心原理介绍
在流处理系统中，数据记录（events/records）是以极高的速率流过的。如果一个算子（如map）为每一条输入数据都创建一个新的对象，那么就会在极短的时间内产生海量的、短命的（short-lived）对象实例。对象创建会在JVM的堆内存（Heap）的年轻代（Young Generation）中分配一块新内存。垃圾产生：一旦这个对象被下游算子处理完毕（例如，被序列化通过网络发送出去），它就不再被引用，变成了垃圾。GC触发：年轻代的内存空间是有限的。当海量的新对象迅速填满年轻代（Eden区）时，会频繁触发。原创 2025-08-22 14:05:43 · 880 阅读 · 0 评论 -
Flink背压：原理、定位与解决，一文搞定！
背压（Backpressure）是流处理系统中一种重要的流量控制机制。当数据流入速度大于处理速度时，系统会自动降低数据摄入速率，以避免数据积压和内存溢出。可以把这想象成水流管道：当出水口流速小于进水口时，管道内压力会增加，进而迫使进水口降低流速。Flink背压是流处理系统中的正常现象，但持续的高背压会影响作业性能。理解背压原理：基于信用值的流量控制掌握定位方法：Web UI、指标监控、日志分析应用解决方案：资源调优、作业优化、代码优化可以有效解决背压问题，保证Flink作业的稳定高效运行。记住。原创 2025-08-21 15:30:23 · 1100 阅读 · 0 评论 -
Flink RocksDBStateBackend设计原理及对比分析
在流处理中，"状态"是指算子(operator)在处理事件时需要记住的信息。比如在计算移动平均值时，需要记住之前的事件值；在去重操作中，需要记住已经出现过的元素。状态后端就是负责管理这些状态的组件。比喻：状态后端就像一个会计的账本系统。会计(算子)在处理每一笔交易(事件)时，都需要查阅和更新账本(状态)。不同的账本管理方式(如纸质账本、电子表格、专业会计软件)就相当于不同的状态后端实现。原创 2025-08-18 07:30:00 · 427 阅读 · 0 评论 -
Kafka的一条消息的写入和读取过程原理介绍
Kafka消息处理流程解析：生产者通过分区策略将消息写入Leader副本，经ISR机制同步后确认；消费者组通过Offset管理从分区拉取消息，支持不同投递语义。系统通过分区副本、顺序I/O和批量处理实现高吞吐，核心机制包括ISR同步、ACK确认和零拷贝优化，确保高可用与高性能。理解这些原理有助于优化集群配置和排查问题。原创 2025-08-12 17:24:44 · 945 阅读 · 0 评论 -
LSM、B 树、B+树、B*对比
参考B树、B+树、LSM树以及其典型应用场景B树和B+树的插入、删除图文详解BTree vs LSM0. 前言动态查找树主要有：二叉查找树、平衡二叉树、红黑树、B树、B+树。前面三种是典型的二叉查找树，查找的时间复杂度是O(log2N)。涉及到磁盘的读写（比如每个节点都需要从磁盘获取），读写的速度就与树的深度有关系，那么降低树的深度也就可以提升查找效率。这时就提出了平衡多路查找树，也就是B树以及B+树。B树和B+树非常典型的场景就是用于关系型数据库的索引(MySQL)1. B类树1.转载 2021-09-02 17:55:43 · 567 阅读 · 0 评论 -
HBase读取流程概述
1、根据rowkey定位到对应的RegionServer的目标region 1.1、通过客户端缓存的rowkey和RegionServer的映射信息定位目标RS和region 1.2、客户端找不到的话从zk上的/hbase-root/meta-region-server节点获取保存HBase元数据表hbase:meta所在的RegionServer 1.3、客户端与保存元数据的RS通讯，查找rowkey对应的RS和region信息 2、构造三层Scann...原创 2020-07-30 15:23:39 · 446 阅读 · 0 评论