大数据框架选型存储、计算、查询怎么搭大数据系列第 11 篇前面聊了这么多框架实际项目中怎么选型、怎么组合这篇给你一份选型地图。选型前先问自己三个问题面对一堆大数据框架很多人第一反应是“哪个最新、最火就用哪个”但选型不是追新是匹配需求。在动手之前先想清楚这三个问题问题 1你的数据是什么规模数据规模特征技术选型GB 级单机能处理MySQL/PostgreSQL Python 脚本就够了TB 级单机吃力需要分布式开始考虑 Hadoop/SparkPB 级必须分布式HDFS Spark/Flink 分布式查询引擎EB 级超大规模需要专门的存储和计算架构优化别过度设计。数据量只有几百 GB 就上 Hadoop纯属给自己找麻烦。问题 2你的场景是 OLTP 还是 OLAP维度OLTP事务处理OLAP分析查询典型操作增删改查单条记录扫描大量数据做聚合数据量当前数据GB-TB历史数据TB-PB响应时间毫秒级秒级/分钟级用户业务系统、终端用户数据分析师、报表系统代表系统MySQL、Redis、HBaseHive、ClickHouse、Doris大部分大数据场景是 OLAP。如果你的需求是查单条记录用 HBase 或关系型数据库如果是分析统计才需要 Hive/ClickHouse 这些。问题 3你需要实时还是离线时效性延迟技术选型离线T1小时/天级Hive Spark/MR近实时分钟级Spark Streaming实时秒级Flink低延迟实时毫秒级Flink Kafka实时性要求越高技术复杂度越高。不要为了实时而实时很多场景 T1 完全够用。数据分层架构ODS → DWD → DWS → ADS在实际项目中数据通常会分多层处理每层用不同的技术┌─────────────────────────────────────────────────────────────────┐ │ 数据分层架构经典模型 │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ ADSApplication Data Store │ │ │ │ 应用数据层面向业务的数据产品 │ │ │ │ • 报表系统、BI 大屏、推荐结果 │ │ │ │ • 技术ClickHouse、Doris、MySQL、Redis │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↑ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ DWSData Warehouse Summary │ │ │ │ 数据汇总层轻度聚合的汇总数据 │ │ │ │ • 按天/按周/按月的统计指标 │ │ │ │ • 技术Hive、Spark SQL、ClickHouse │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↑ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ DWDData Warehouse Detail │ │ │ │ 数据明细层清洗后的明细数据 │ │ │ │ • 数据清洗、格式统一、去重 │ │ │ │ • 技术Hive、Spark、Flink │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↑ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ ODSOperational Data Store │ │ │ │ 操作数据层原始数据几乎不做处理 │ │ │ │ • 业务数据库的同步数据、日志数据 │ │ │ │ • 技术HDFS、Kafka、Hive 外部表 │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ↑ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 数据源业务数据库、日志、埋点、IoT 设备、第三方 API │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘分层的意义ODS原始数据备份出了问题可以从这里恢复DWD统一数据口径后续所有层都基于这一层DWS预计算常用指标减少重复计算ADS面向具体应用数据结构为应用优化典型场景的技术选型场景 1离线数据仓库最经典需求每天把业务数据同步到数仓生成各种报表。技术栈 业务数据库MySQL │ │ Sqoop / DataX / CDCCanal/Debezium ▼ ODSHDFS Hive 外部表 │ │ Hive / Spark SQLETL 清洗 ▼ DWDHive 内部表ORC/Parquet │ │ Spark SQL / Hive聚合计算 ▼ DWSHive 表预聚合指标 │ │ 同步到 MySQL / ClickHouse ▼ ADS报表系统查询选型要点数据同步Sqoop批量、DataX阿里开源、CDC实时同步存储HDFS HiveORC/Parquet 格式计算Spark SQL推荐或 Hive on Tez报表ClickHouse 或 Doris查询快场景 2实时数仓需求数据产生后几分钟内报表就能看到最新数据。技术栈 业务系统 / 日志 │ │ 埋点上报 / Filebeat / Flume ▼ Kafka数据总线 │ ├──────→ Flink实时计算──────→ HBase / Redis实时查询 │ ↑ │ │ └──────→ Flink实时写入──────→ ClickHouse实时分析选型要点数据采集Kafka 作为统一数据入口实时计算Flink exactly-once 语义状态管理完善实时存储HBase随机读写、Redis缓存、ClickHouse分析查询实时查询ClickHouse 或 Doris支持实时写入和查询场景 3用户画像系统需求给每个用户打标签支持实时查询用户画像。技术栈 用户行为日志 ──→ Kafka ──→ Flink实时计算标签──→ HBase存储画像 ↑ 业务系统查询 ──────────────────────────────────────────────────┘ 查用户 12345 的标签选型要点标签计算Flink 实时计算用户行为更新标签标签存储HBase海量 KV 查询毫秒级延迟标签查询HBase API 或 PhoenixSQL on HBase场景 4日志分析平台需求收集全链路日志支持检索和分析。技术栈 应用日志 ──→ Filebeat ──→ Kafka ──→ Flink清洗──→ ClickHouse / ES ↑ Kibana / Grafana 查询 ────────────────────────────────────────┘选型要点日志收集Filebeat轻量、Flume功能丰富日志存储Elasticsearch全文检索强、ClickHouse聚合分析快日志查询KibanaES 生态、Grafana通用常见选型误区误区 1追求一套技术栈搞定所有没有银弹。存储用 HDFS、计算用 Spark、查询用 ClickHouse、消息用 Kafka——每个场景选最合适的而不是强行统一。误区 2为了实时而实时很多场景 T1 完全够用上 Flink 反而增加复杂度。先问自己业务真的需要实时吗延迟从 1 小时降到 1 分钟能带来多少价值误区 3忽视运维成本Kafka 集群、Flink 集群、HBase 集群……每个都需要专人维护。小团队不要盲目堆技术栈能用云服务EMR、云 Kafka、云 ClickHouse就用云服务。误区 4忽视数据质量技术栈搭好了数据是错的一切都白搭。数据治理质量监控、血缘追踪、元数据管理和架构同等重要。一份懒人选型速查表场景存储计算查询消息离线数仓HDFS HiveSpark SQLClickHouse/Doris-实时数仓Kafka ClickHouseFlinkClickHouse/DorisKafka用户画像HBaseFlinkHBase APIKafka日志分析ClickHouse / ESFlinkKibana / GrafanaKafka实时推荐Redis HBaseFlink Spark MLRedisKafkaIoT 数据处理HBase / TDengineFlinkGrafanaKafka / MQTT小结今天咱们聊了大数据框架选型选型三问数据规模OLTP 还是 OLAP实时还是离线数据分层ODS → DWD → DWS → ADS每层职责清晰典型场景离线数仓、实时数仓、用户画像、日志分析选型误区不要追新、不要过度实时、不要忽视运维和数据质量速查表常见场景的技术组合参考选型的核心原则是匹配需求、控制复杂度、预留扩展空间。不要一上来就搭一套完美架构先让数据跑起来再逐步优化。你们公司的大数据架构是什么样的选型过程中踩过哪些坑欢迎聊聊