你是否曾好奇，海量数据如何被高效处理并转化为商业价值？今天，让我们一起揭开大数据技术架构的神秘面纱，探索其核心逻辑与多样战术！
大数据整体架构概述
大数据5V特征Volume（体量）：数据规模庞大，从TB到PB级别起步，涵盖采集、存储与计算的全链路挑战。
Variety（多样）：数据类型与来源极为丰富，包括结构化、半结构化及非结构化的日志、图片、音频、视频等。
Value（价值）：信息海量但价值密度低，需借助机器学习等深度挖掘技术提炼高价值洞察。
Velocity（速度）：数据增长、获取与处理均追求极速，以满足实时或准实时分析需求。
Veracity（真实）：聚焦数据质量，确保准确性、可信赖度，为决策打下坚实基础。
数据分析的核心在于从数据中提炼隐藏信息，总结规律，以支撑管理者的精准判断与决策。
在企业经营中，数据分析主要聚焦三大方向，应对不同业务场景：
现状分析：聚焦当下，解析实时数据，秒级或毫秒级监控业务状态、构成与变动，实现运营即时洞察。
原因分析：回顾历史，通过批处理（如T+1、T+7）诊断问题根源，驱动业务优化与调整。
预测分析：融合历史与实时数据，运用分类、聚类、预测等机器学习算法，前瞻趋势，抢占先机。
分布式存储、资源调度与计算，支撑海量数据的高效处理。
分布式和集群的概念分布式：多台机器协同，各部署不同组件，实现功能分工。
集群：多台机器协作，各部署相同组件，提升可用性与性能。
数据分析模型 星型模型
星型模型的组合体，支持复杂多主题分析。
功能
数据库
数据仓库
数据范围
当前状态数据
存储历史、完整、反应历史变化数据
数据变化
支持频繁的增删改查操作
可增加、查询，无更新、删除操作
应用场景
面向业务交易流程
面向分析、支持侧重决策分析
处理数据量
频繁、小批次、高并发、低延迟
非频繁、大批量、高吞吐、有延迟
设计理论
遵循数据库三范式、避免冗余
违范式、适当冗余
建模方式
ER实体关系建模（范式建模）
范式建模+维度建模
OLTP
OLAP
数据源
仅包含当前运行日常业务数据
整合来自多个来源的数据，包括OLTP和外部来源
目的
面向应用、面向业务、支撑事务
面向主题、面向分析、支撑分析决策
焦点
当下
主要面向过去、面向历史，实时数仓除外
任务
读写操作
大量读而很少写操作
响应时间
毫秒
秒、分钟、小时或者天取决于数据量和查询复杂性
数据量
小数据，MB/GB
大数据，TP/PB
主要应用
数据库
数据仓库
OLAP引擎分类OLAP按存储器的数据存储格式分为MOLAP（多维OLAP）、ROLAP（关系型OLAP）和HOLAP（混合OLAP）。
MOLAP：基于多维数组预计算，以空间换时间，适合高性能查询，但Cube构建成本高，代表如Kylin、Druid。
ROLAP：基于关系模型即时查询，灵活性强，但性能依赖优化，明细与汇总数据均存于事实表。
HOLAP：混合模型，细节用ROLAP，聚合用MOLAP，平衡性能与灵活性。
开源OLAP引擎
优点
缺点
技术融合成本
易用性
使用场景
运维成本
引擎类型
ClickHouse
1.列式存储<br />2.单机性能彪悍<br />3.保留明细数据<br />4.向量化引擎
1.分布式集群在线扩展支持不佳<br />2.运维成本极高
高
非标协议接口
全面
高
纯列存OLAP
Druid
1.实时数据摄入<br />2.列式存储和位图索引<br />3.多租户和高并发
1.OLAP性能分场景表现差异大<br />2.使用门槛高3.仅支持聚合查询
高
非标协议接口
局限
高
MOLAP
TiDB
1.HTAP混合数据库<br />2.同时支持明细和聚合查询<br />3.高度兼容MySQL
1.非列存储<br />2.OLAP能力不足
低
SQL标准
全面
低
纯列存OLAP
Kylin
1.预计算引擎，可以对数据一次聚合多次查询<br />2.支持数据规模超大<br />3.易用性强，支持标准sql<br />4.性能强，查询数据快（预聚合结果）
1.需要依赖Hadoop生态<br />2.仅支持聚合查询<br />3.不支持ad-hoc查询<br />4.不支持join以及对数据的更新
高
SQL标准
局限
高
MOLAP
Doris
1.GoogleMesa+ApacheImpa+ORCFlle/Parquet<br />2.主键更新<br />3.支持RollupTable<br />4.高并发和高吞吐的Ad-hoc查询<br />5.支持聚合+明细数据查询<br />6.无外部系统依赖
成熟度不足
低
兼容MySQL访问协议
全面
低
ROLAP
大数据架构演变 传统离线大数据架构
Lambda架构缺点：
需维护两套代码，资源消耗大；离线与实时结果可能不一致；批处理可能无法按时完成；存储需求高。
Kappa架构
Kappa架构缺点：
Kafka难以支撑海量数据存储与高效OLAP；缺乏数据血缘管理；不支持数据更新操作。
湖仓一体实时数仓架构
湖仓一体解决方案：
统一存储，突破Kafka容量限制；支持任意分层OLAP分析；复用数据血缘体系；实现实时数据更新。
公司架构选择
对比项
传统离线大数据架构
Lambda架构
Kappa架构
实时性
离线（无法处理实时业务）
离线+实时
实时（批流一体）
计算资源
只有批处理
批和流同时运行，资源消耗大
只有流处理，资源开销小
重新计算时吞吐量
批处理全量处理，吞吐量大
批处理全量处理，吞吐量大
流式全量处理，吞吐较批处理全量要低一些
开发、测试难度
批处理一套代码，开发、测试、上线难度小
批处理和流处理相同逻辑两条代码，开发、测试、上线难度大
只需实现一套代码，开发、测试、上线难度相对较小
运维成本
维护一套引擎，运维成本小
维护两套引擎，运维成本大
维护一套引擎，运维成本小
注：针对特定场景（如3、4）的架构选择需结合业务实际，此处保留探讨空间。
网易实时数仓实践
批式模型依托MapReduce、Hive、Spark等引擎，以小时或天任务形式处理数据，实现高吞吐离线计算。
延迟：小时或天级别，实际延迟可能达2-3小时，适合对实时性要求不高的场景。
数据完整度：高，通常涵盖批次内全部数据，但对事件时间敏感的业务支持有限。
成本：资源占用间歇性，成本较低，但数据变更可能触发全量重算，增加隐性开销。
流式模型以Flink为代表，进行实时数据计算，支持毫秒级响应，但需权衡数据完整性。
延迟：极低，近乎实时，适用于监控、预警等即时场景。
数据完整度：相对较差，受watermark机制影响，可能丢弃延迟数据，常用于数据大盘等容忍度高的场景。
成本：高，因常驻运行及状态存储需求，在资源与IO上开销显著。
增量模型以mini batch形式实现准实时处理，Hudi等工具支持Upsert与增量查询，平衡成本与时效。
Upsert：解决批处理中数据更新难题，允许增量写入Hive，避免全量覆盖。
增量查询：仅处理新增数据，大幅降低计算量，如在Uber的司机-乘客流Join中效率提升显著。
相关问答
传统大数据的三种架构?
在数据爆炸时代，移动互联、社交网络与云服务等兴起，对数据中心架构提出新需求。存储基础架构已成为IT核心，广泛应用于政府、军工、科研等领域。
大数据架构思维?
大数据架构思维是处理海量数据时的关键设计理念，通过合理架构应对存储、计算与分析的挑战，提升效率与扩展性。
百度资深大数据架构师如何零基础搭建大数据hadoop生态圈?
首先了解Hadoop生态组件，根据需求选型并规划集群规模，小集群推荐从官网直接部署，逐步搭建完整环境。
大数据开发和架构开发区别?
大数据开发聚焦数据采集、处理与分析；架构开发侧重系统设计与优化，两者在职责与技能上各有侧重。
大数据架构师要学什么专业?
大数据架构师专业背景多元，涵盖计算机科学、软件工程、数据科学等，需具备跨学科的数据处理与系统设计能力。
马鞍山学院腾讯大数据学院怎么样?设有哪些专业?申请方
马鞍山学院腾讯大数据学院开设计算机科学与技术、软件工程、物联网工程等专业，融合产业资源培养大数据人才。
学架构师好还是大数据好?
互联网架构师通常为资深技术领袖，前景广阔；大数据领域则重数据价值挖掘，两者均可根据兴趣与规划选择。
大数据未来发展方向是什么?-ZOL问答
大数据并未过时，而是门槛提高，需深度理解与应用。结合AI、实时计算与湖仓一体等技术，持续赋能企业智能决策。
大数据技术为何不再热门?-ZOL问答
大数据技术已进入成熟期，核心从概念普及转向落地实践。企业更关注短期回报，但技术在传输、存储与分析领域仍至关重要。
如何使用大数据技术为企业创造更大的价值?-ZOL问答
作为大数据工程师，我认为需聚焦业务场景，通过精准分析驱动决策。结合实时与离线处理，挖掘数据潜力，助力企业降本增效。
探索大数据架构的旅程从未止步！现在，你是否对如何选择架构有了新思路？欢迎在评论区分享你的观点或挑战，一起推动数据技术的边界！