015、大数据平台架构与技术选型

张开发
• 2026/4/8 2:40:35 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

015、大数据平台架构与技术选型
015、大数据平台架构与技术选型：从一次深夜数据倾斜调试说起凌晨两点，集群告警炸了。某个Spark任务卡在最后两个Reducer上，其中一个节点负载99%，其余节点闲得发慌。日志里满是GC overhead和OOM异常。这场景太熟悉了——又是数据倾斜。我们团队自研的埋点分析平台，每天处理百亿级事件，这种问题每月总要遇上几回。那次我们调了三个通宵，试过各种repartition、加盐、两阶段聚合，最后发现是某个明星用户单日触发了几千万次事件，把key打爆了。这件事让我彻底明白：大数据平台的选型，本质是在为这类“意外”买保险。今天我们就聊聊，怎么从架构设计和技术选型阶段，就为未来的数据洪流和诡异异常埋好应对的伏笔。一、架构分层：别把鸡蛋放在一个篮子里大数据平台不是一套框架通吃，得分层处理。我们现在的生产架构分五层：接入层：用Kafka做缓冲太重要了。去年双十一，上游系统突发流量冲垮了Flink直接对接的HTTP接口，后来改走Kafka，背压问题迎刃而解。这里有个坑：Kafka分区数一开始别设太少，我们吃过亏，扩容分区得重启集群，业务得停。计算层：这是最头疼的选型。实时流用Flink，批处理用Spark，这是主流搭配。但注意，Flink的checkpoint机制对状态大的任务很友好，但状态后端选RocksDB还是Heap，性能差三倍不止。我们有个会话分析作业，状态几十GB，用Heap后端GC直接瘫痪，换RocksDB后稳定跑到现在。存储层：HDFS存原始数据，Hive做数仓，ES做索引查询，ClickHouse搞实时聚合。听起来杂，但各司其职。最近在试Iceberg，解决了Hive分区膨胀的小文件问题。存储格式选Parquet还是ORC？我们实测Parquet压缩比高，ORC读稍快，看你是省空间还是要速度。服务层：Presto做即席查询，但大join容易OOM。我们的经验是，超过5张表关联就走Spark SQL预计算，别硬扛。这里踩过坑：Presto连接Hive metastore超时，原因是元数据表没建索引，上千万分区扫不动。资源管理层：YARN和K8s怎么选？传统Hadoop生态用YARN省心，但容器化趋势下K8s更灵活。我们部分新业务跑在K8s上，但Spark on K8s调试成本不低，特别是网络和存储挂载。二、技术选型实战心法选型不看名气看场景。曾经跟风用Storm做实时，后来发现延迟要求没那么苛刻，换成Spark Streaming开发效率翻倍。现在Flink成熟了，但如果你

更多文章