大数据架构
目录
1 传统数据处理系统的问题
1.1 传统数据库的数据过载问题
传统应用的数据系统架构设计时，应用直接访问数据库系统。当用户访问量增加时，数据库无法支撑日益增长的用户请求的负载，从而导致数据库服务器无法及时响应用户请求，出现超时的错误。
关于该问题的常用解决方法如下：
- 增加异步处理队列
- 建立数据库水平分区
- 建立数据库分片或重新分片
- 引入读写分离技术
- 引入分库分表技术
1.2 大数据的特点
大数据（Big Data）的4V：数据量（Volume）、速度（Velocity）、多样性（Variety）、值（Value）
与传统数据的对比：
| 比较维度 | 传统数据 | 大数据 |
|---|---|---|
| 数据量 | GB或TB级 | PB级或以上 |
| 数据分析需求 | 现有数据的分析与检测 | 深度分析（关联分析、回归分析等） |
| 硬件平台 | 高端服务器 | 集群平台 |
大数据处理系统应该具有的重要特征：
- 高度可扩展性
- 高性能
- 高度容错
- 支持异构环境
- 较短的分析延迟
- 易用且开放的接口
- 较低成本
- 向下兼容性
1.3 大数据分层架构
大数据架构如下所示（了解即可），从上往下依次为：
- 数据应用层：营销支撑、客户洞察、风险管控、运营优化、历史数据查询、指标应用、报表应用、主题分折、专题分折
- 数据结构层：数据统一服务和开放SQL、FTP、WS、MDX、 API等。基础分析、多维分析、数据挖掘、实时分析、自助分折、数据共享。
- 数据层：数据仓库、分布式数据、Hadoop平台
- 数据采集层：数据采集（批量采集、实时采集），方法有数据探头、流数据处理、爬虫等
- 数据源：结构化、半结构化、非结构化数据
1.4 大数据处理技术及利用过程
现代大数据处理技术主要分为以下几种：
- 基于分布式文件系统Hadoop。
- 使用Map/Reduce或Spark数据处理技术。
- 使用Kafka数据传输消息队列及Avro二进制格式。
大数据的利用过程：采集、清洗、统计、挖掘
2 大数据处理系统架构分析
2.1 大数据处理系统面临的挑战
大数据处理系统面临的挑战主要有：
- 如何利用信息技术等手段处理非结构化和半结构化数据。
- 如何探索大数据的复杂性、不确定性特征描述的刻画方法及大数据的系统建模。
- 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。
2.2 大数据处理系统的特征
大数据处理系统应具有的属性和特征包括：
- 鲁棒性和容错性
- 低延迟性
- 横向扩展（通过增强机器性能扩展）
- 通用
- 可扩展
- 即席查询（用户按照自己的要求进行查询）
- 最少维护和可调试。
3 典型的大数据架构
3.1 Lambda架构
Lambda架构是一种用于同时处理离线和实时数据的、可容错性、可扩展性的分布式系统。
Lambda架构分为以下3层：
- 批处理层（Batch Layer）：存储数据集， 该层核心功能是存储主数据集，Batch Layer在数据集上预先计算查询函数，并构建查询所对应的View。Batch Layer可以很好地处理离线数据，但有很多场景数据是不断实时生成且需要实时查询处理，对于这种情况， Speed Layer更为适合。
- 加速层（Speed Layer）：Batch Layer处理的是全体数据集，该层核心功能是处理增量实时数据，而 Speed Layer处理的是最近的增量数据流。 Speed Layer 为了效率，在接收到新的数据后会不断更新Real-time View, 而Batch Layer 是根据全体离线数据集直接得到Batch View。
- 服务层（Serving Layer）：该层核心功能是响应用户请求，Serving Layer用于合并Batch View和 Real-time View中的结果数据集到最终数据集。
优点：
- 容错性好：为大数据系统提供了更友好的容错能力，一旦发生错误，可以修复算法或从头开始重新计算视图。
- 查询灵活度高：批处理层允许针对任何数据进行临时查询。
- 易伸缩：所有的批处理层、加速层和服务层都很容易扩展（因为均为完全分布式的系统），可以通过增加新机器来轻松地扩大规模。
- 易扩展：添加视图容易，只需给主数据集添加新的函数。
缺点：
- 全场景覆盖带来的编码开销。
- 针对具体场景重新离线训练一遍益
3.2 Kappa架构
Kappa架构在Lamada架构的基础上进行了优化，删除了Batch Layer，将数据通道以消息队列进行替代。
从使用场景上来看， Kappa架构与Lambda相比的主要区别：
- Kappa不是Lambda的替代架构，而是其简化版本。Kappa放弃了对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求，例如各种时序数据场景，天然存在时间窗口的概念，流式计算直接满足其实时计算和历史补偿任务需求。
- Lambda直接支持批处理，因此更适合对历史数据分析查询的场景，比如数据分析师需要按任意条件组合对历史数据进行探索性的分析，并且有一定的实时性需求，期望尽快得到分析结果，批处理可以更直接高效地满足这些需求。
优点：
- 将实时和离线代码统一起来，方便维护且统一了数据口径的问题，避免了Lambda架构中与离线数据合并的问题，查询历史数据的时候只需要重放存储的历史数据即可。
缺点也很明显：
- 消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。
- 在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。
- Kappa在抛弃了离线数据处理模块的同时，也抛弃了离线计算更加稳定可靠的特点。Lambda虽然保证了离线计算的稳定性，但双系统的维护成本高且两套代码带来后期运维困难。
对于以上Kappa框架存在的几个问题，目前也存在一些解决方案：对于消息队列缓存数据性能的问题，Kappa+框架提出使用HDFS来存储中间数据。针对Kappa框架展示层能力不足的问题，也有人提出了混合分析系统的解决方案。
3.3 两种架构对比与选择
对比：
| 对比内容 | Lambda框架 | Kappa框架 |
|---|---|---|
| 复杂度与开发、维护成本 | 需要维护两套系统(引擎),复杂度高，开发、维护成本高 | 只需要维护1套系统(引擎),复杂度低，开发、维护成本低 |
| 计算开销 | 需要一直运行批处理和实时计算，计算开销大 | 必要时进行全量计算，计算开销相对较小 |
| 实时性 | 满足实时性 | 满足实时性 |
| 历史数据处理能力 | 批式全量处理，吞吐量大，历史据处理能力强 | 流式全量处理，吞吐量相对较低，历史数据处理能力相对较弱 |
根据两种架构对比分析，将业务需求、技术要求、系统复杂度、开发维护成本和历史数据处理能力作为选择考虑因素。而计算开销虽然存在一定差别，但是相差不是很大，所以不作为考虑因素。
- 业务需求与技术要求：用户需要根据自己的业务需求来选择架构，如果业务对于Hadoop、Spark、Strom等关键技术有强制性依赖，选择Lambda架构可能较为合适；如果处理数据偏好于流式计算，又依赖Flink计算引擎，那么选择Kappa架构可能更为合适。
- 复杂度：如果项目中需要频繁地对算法模型参数进行修改， Lambda架构需要反复修改两套代码，则显然不如 Kappa架构简单方便。同时，如果算法模型支持同时执行批处理和流式计算，或者希望用一份代码进行数据处理，那么可以选择Kappa架构。在某些复杂的案例中，其实时处理和离线处理的结果不能统一，比如某些机器学习的预测模型，需要先通过离线批处理得到训练模型，再交由实时流式处理进行验证测试，那么这种情况下，批处理层和流处理层不能进行合并，因此应该选择Lambda架构。
- 开发维护成本：Lambda架构需要有一定程度的开发维护成本，包括两套系统的开发、部署、测试、维护，适合有足够经济、技术和人力资源的开发者。而Kappa架构只需要维护一套系统，适合不希望在开发维护上投入过多成本的开发者。
- 历史数据处理能力：有些情况下，项目会频繁接触海量数据集进行分析，比如过往十年内的地区降水数据等，这种数据适合批处理系统进行分析，应该选择Lambda架构。如果始终使用小规模数据集，流处理系统完全可以使用，则应该选择Kappa架构。
4 大数据架构的实践
大规模视频网络、广告平台、电商智能决策大数据系统