架构
关注
分享
扫一扫
文章平均质量分 92
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 评论 -
万亿级数据洪流如何驯服？深度解密RocketMQ的架构设计与“三国杀”胜出密码
RocketMQ作为阿里开源的高性能消息中间件，成功驯服了万亿级数据洪流。其核心架构由NameServer、Broker、Producer和Consumer组成，采用主从架构与Commit Log设计，实现了高吞吐、高可用和弹性扩展。在消息中间件"三国杀"中，RocketMQ以事务消息、延迟消息等复杂业务场景支持能力脱颖而出，成为电商、金融等领域的首选解决方案。相比Kafka和Pulsar，RocketMQ在性能、稳定性与功能完备性上找到了最佳平衡点，展现了国产技术在大数据领域的强大实力原创 2025-10-03 22:25:38 · 801 阅读 · 0 评论 -
大数据面试终极命题：从0到1搭建大数据平台，我会这样回答惊艳面试官！
本文系统解析大数据平台架构设计方法论，从需求分析、技术选型到平台治理，提供完整解决方案。首先强调业务需求理解的重要性，提出分层架构设计思路；然后详细讲解数据采集、存储、计算等核心组件的选型策略，特别关注数据质量与一致性保障；最后探讨数据治理、成本优化和技术演进。文章不仅适用于面试场景，更为实际工作提供可落地的架构指导，涵盖批流融合、湖仓一体等前沿趋势，帮助读者建立系统化的大数据平台建设思维。原创 2025-09-30 21:08:38 · 1565 阅读 · 0 评论 -
卷疯了！大数据面试必问的分布式锁，到底怎么选才不踩坑？
分布式锁方案对比与选型指南 在大数据高并发场景下，分布式锁是确保数据一致性的关键组件。本文对比了三种主流实现方案： 1. Redis分布式锁 优点：性能最佳，实现简单，适合高并发场景 缺点：可靠性依赖Redis可用性，主从切换可能丢锁 2. ZooKeeper分布式锁 优点：强一致性保证，临时节点自动释放防死锁 缺点：性能较低，部署维护复杂 3. 数据库分布式锁 优点：实现简单，强一致性 缺点：性能差，容易成为系统瓶颈 选型建议： 超高并发场景选择Redis 金融等强一致性场景选择ZooKeeper 简单系原创 2025-09-29 22:59:22 · 1052 阅读 · 0 评论 -
面试必问：大数据缓存如何选型？Spark、Flink、Alluxio还是Redis？一文彻底讲透！
在大数据开发中，你是否经常遇到这些困扰？* 数据查询越来越慢，S3/HDFS的I/O成了瓶颈？* Spark作业反复读取同一数据，集群资源和时间白白浪费？* 流处理任务状态巨大，内存撑不住，性能不稳定？* 多个计算引擎（如Spark和Presto）需要争抢同一份“热数据”？这些问题，很大程度上是因为**没有用好缓存**。大数据领域的缓存，远不止Redis那么简单。今天，我们就来彻底拆解四大主流缓存方案，帮你做出最优技术选型！原创 2025-09-28 21:06:03 · 1394 阅读 · 0 评论 -
基于Flink Interval Join实现游戏对战实时判定系统
本文介绍了基于Flink Interval Join实现游戏对战实时判定系统的技术方案。针对MOBA、FPS等游戏中的技能命中、伤害计算等核心需求，系统采用Flink的Interval Join特性，能够精确关联时间窗口内的事件流（如技能释放与玩家移动），实现毫秒级延迟的实时判定。文章详细阐述了系统架构设计、数据模型定义以及核心实现逻辑，重点展示了技能命中判定的算法处理流程，包括时间对齐校验、网络延迟补偿和多种技能范围判定方法。该方案有效解决了传统批处理延迟高、简单窗口无法处理时间偏差等技术挑战。原创 2025-09-11 16:10:25 · 1133 阅读 · 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 · 784 阅读 · 0 评论 -
从阅兵式洞悉Flink分布式设计：大数据处理的精密协作艺术
统一指挥体系：Dispatcher（总指挥部）接收作业、JobMaster（方阵指挥官）管理作业生命周期、TaskExecutor（方阵士兵）执行任务，三层架构确保指令自上而下的高效传递；精密时序控制：基于 Pekko 的 RPC 通信（无线电系统）确保节点间指令同步，屏障机制（同步口令）确保任务快照时序一致，避免 "指令混乱"；容错保障机制：检查点协调器（应急指挥中心）实现分布式快照，非对齐检查点（灵活应急方案）应对流量突发，确保系统 "故障可恢复、数据不丢失"；资源弹性管理。原创 2025-08-24 01:00:58 · 696 阅读 · 0 评论 -
大数据组件的WAL机制的架构设计原理对比
HBase 的 HLog 滚动清理 vs 长时间保留（增加恢复选项但占用存储）ZooKeeper 同步刷盘（强一致） vs Flink 异步刷盘（高性能）增量快照（如 Flink 的 Changelog）可能部分替代传统 WAL。：通过“日志先行”在性能与可靠性之间取得平衡，但需根据场景优化配置。：选择 ZooKeeper 或 HBase（同步 WAL）。存储硬件（如 NVMe）提升 WAL 的写入性能瓶颈。：优先考虑 Redis 或 Kafka（异步刷盘）。Kafka 的日志分段删除策略（按时间/大小）原创 2025-04-20 00:36:03 · 979 阅读 · 0 评论 -
Doris SQL 原理解析
本文主要介绍了Doris SQL解析的原理。重点讲述了生成单机逻辑计划，生成分布式逻辑计划，生成分布式物理计划的过程。对应于代码实现是Analyze，SinglePlan，DistributedPlan，Schedule四个部分。Analyze负责对AST进行前期的一些处理，SinglePlan根据AST进行优化生成单机查询计划，DistributedPlan将单机的查询计划拆成分布式的查询计划，Schedule阶段负责决定查询计划下发到哪些机器上执行。由于SQL类型有很多，本文侧重介绍查询SQL的解转载 2023-03-02 23:42:48 · 1216 阅读 · 1 评论 -
彻底搞清分库分表（垂直分库，垂直分表，水平分库，水平分表）
分库分表是什么下边以电商系统中的例子来说明，下图是电商系统卖家模块的表结构：通过以下SQL能够获取到商品相关的店铺信息、地理区域信息：SELECT p.*,r.[地理区域名称],s.[店铺名称],s.[信誉]FROM [商品信息] p LEFT JOIN [地理区域] r ON p.[产地] = r.[地理区域编码]LEFT JOIN [店铺信息] s ON p.id = s.[所属店铺]WHERE p.id = ?随着公司业务快速发展，数据库中的数据量猛增，访问性能也变慢了，优化转载 2021-02-02 22:11:17 · 461 阅读 · 0 评论 -
数据库Sharding的基本思想和切分策略
本文着重介绍sharding的基本思想和理论上的切分策略，关于更加细致的实施策略和参考事例请参考我的另一篇博文：数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示一、基本思想Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这...转载 2019-11-29 09:47:50 · 213 阅读 · 0 评论 -
Why Should HBase RegionServer & Hadoop DataNode Colocate?
Some basic background information first, HBase, as a distributed NoSQL database, its slave (worker) node is named “RegionServer”, all data reading, writing or scanning workloads are on these RegionSer...转载 2019-11-29 09:43:49 · 276 阅读 · 0 评论