⬆︎
×
TOC
Hyplus目录

系统架构设计理论与实践(8):大数据架构

案例分析专题——大数据架构、云计算、边缘计算

大数据架构主要面向大数据的容量体量、类型多样、高速实时、客观真实、价值可观、变化多样和复杂多源的特性,既要构建高质量属性的架构解决方案,又受制于成本、性能、可扩展性等诸多条件。同时,云计算、物联网以及边缘计算等客观环境的发展,也对大数据架构的设计提出了弹性、容器化等新的要求。

伴随多年的研究,当前主要技术实践中以Lambda架构、Kappa架构和IOTA架构较为典型,但新版考试大纲中主要考查Lambda架构、Kappa架构在设计中的理论、理解及实践。

1 传统数据处理系统的问题

1.1 传统数据库的数据过载问题

传统应用的数据系统架构设计时,应用直接访问数据库系统。当用户访问量增加时,数据库无法支撑日益增长的用户请求的负载,从而导致数据库服务器无法及时响应用户请求,出现超时的错误。

关于该问题的常用解决方法如下:

  1. 增加异步处理队列:通过工作处理层批量处理异步处理队列中的数据修改请求。
  2. 建立数据库水平分区:通常建立Key分区,以主键/唯一键Hash值作为Key。
  3. 建立数据库分片或重新分片:通常专门编写脚本来自动完成,且要进行充分测试。
  4. 引入读写分离技术:主数据库处理写请求,通过复制机制分发至从数据库。
  5. 引入分库分表技术:按照业务上下文边界拆分数据组织结构,拆分单数据库压力。

1.2 大数据的特点

大数据(Big Data)具有体量大、时效性强的特点,并非构造单调,而是类型多样;处理大数据时,传统数据处理系统因数据过载,来源复杂,类型多样等诸多原因性能低下,需要采用以新式计算架构和智能算法为代表的新技术;大数据的应用重在发掘数据间的相关性,而非传统逻辑上的因果关系;因此,大数据的目的和价值就在于发现新的知识,洞悉并进行科学决策。

大数据的4V:数据量(Volume)、速度(Velocity)、多样性(Variety)、值(Value)

与传统数据的对比:

比较维度 传统数据 大数据
数据量 GB或TB级 PB级或以上
数据分析需求 现有数据的分析与检测 深度分析(关联分析、回归分析等)
硬件平台 高端服务器 集群平台

大数据处理系统应该具有的重要特征:

  • 高度可扩展性
  • 高性能
  • 高度容错
  • 支持异构环境
  • 较短的分析延迟
  • 易用且开放的接口
  • 较低成本
  • 向下兼容性

1.3 大数据分层架构

大数据架构如下所示(了解即可),从上往下依次为:

  1. 数据应用层:营销支撑、客户洞察、风险管控、运营优化、历史数据查询、指标应用、报表应用、主题分折、专题分折
  2. 数据结构层:数据统一服务和开放SQL、FTP、WS、MDX、API等。基础分析、多维分析、数据挖掘、实时分析、自助分折、数据共享。
  3. 数据层:数据仓库、分布式数据、Hadoop平台
  4. 数据采集层:数据采集(批量采集、实时采集),方法有数据探头、流数据处理、爬虫等
  5. 数据源:结构化、半结构化、非结构化数据

大数据分层架构

1.4 大数据处理技术及利用过程

现代大数据处理技术主要分为以下几种:

  1. 基于分布式文件系统Hadoop。
  2. 使用Map/Reduce或Spark数据处理技术。
  3. 使用Kafka数据传输消息队列及Avro二进制格式。

大数据的利用过程:采集、清洗、统计、挖掘


2 大数据处理系统架构分析

2.1 大数据处理系统面临的挑战

大数据处理系统面临的挑战主要有:

  1. 如何利用信息技术等手段处理非结构化和半结构化数据。
  2. 如何探索大数据的复杂性、不确定性特征描述的刻画方法及大数据的系统建模。
  3. 数据异构性与决策异构性的关系对大数据知识发现与管理决策的影响。

2.2 大数据处理系统的特征

大数据处理系统应具有的属性和特征包括:

  • 鲁棒性和容错性
  • 低延迟性
  • 横向扩展(通过增强机器性能扩展)
  • 通用
  • 可扩展
  • 即席查询(用户按照自己的要求进行查询)
  • 最少维护和可调试。

3 典型的大数据架构

3.1 Lambda架构

Lambda架构是一种用于同时处理离线和实时数据的、可容错性、可扩展性的分布式系统。

Lambda

Lambda架构分为以下3层:

  1. 批处理层(Batch Layer):核心功能为存储主数据集,主数据集数据具有原始、不可变、真实的特征。批处理层周期性地将增量数据转储至主数据集,并在主数据集上执行批处理,生成批视图。
    • 架构实现:可以使用Hadoop HDFS或HBase存储主数据集,再利用Spark或MapReduce执行周期批处理,之后使用MapReduce创建批视图。
  2. 加速层(Speed Layer):核心功能为处理增量实时数据,生成实时视图,快速执行即席查询
    • 架构实现:可以使用Hadoop HDFS或HBase存储实时数据,利用Spark或Storm实现实时数据处理和实时视图。
  3. 服务层(Serving Layer):核心功能为响应用户请求合并批视图和实时视图中的结果数据集得到最终数据集。即接收用户请求,通过索引加速访问批视图,直接访问实时视图,然后合并两个视图的结果数据集生成最终数据集,响应用户请求。
    • 架构实现:可以使用HBase或Cassandra作为服务层,通过Hive创建可查询的视图。

优点:

  1. 容错性好:为大数据系统提供了更友好的容错能力,一旦发生错误,可以修复算法或从头开始重新计算视图。
  2. 查询灵活度高:批处理层允许针对任何数据进行临时查询。
  3. 易伸缩:所有的批处理层、加速层和服务层都很容易扩展(因为均为完全分布式的系统),可以通过增加新机器来轻松地扩大规模。
  4. 易扩展:添加视图容易,只需给主数据集添加新的函数。

缺点:

  1. 编码量大
  2. 持续处理成本高
  3. 重新部署和迁移成本高

3.2 Kappa架构

Kappa架构在Lamada架构的基础上进行了优化,删除了Batch Layer,将数据通道以消息队列进行替代。

Kappa架构

Kappa架构分为以下2层:

  1. 实时层:核心功能为处理输入数据,生成实时视图。具体来说是采用流式处理引擎逐条处理输入数据,生成实时视图。
    • 架构实现:采用Apache Kafka回访数据,然后采用Flink或Spark Streaming进行处理。
  2. 服务层:核心功能为使用实时视图中的结果数据集响应用户请求。
    • 架构实现:实践中使用数据湖中的存储作为服务层。

因此Kappa架构本质上是通过改进Lambda架构中的加速层,使其既能够进行实时数据处理,同时也有能力在业务逻辑更新的情况下重新处理以前处理过的历史数据。

优点:

  • 将实时和离线代码统一起来,方便维护;且统一了数据口径的问题,避免了Lambda架构中与离线数据合并的问题,查询历史数据的时候只需要重放存储的历史数据即可。

缺点:

  1. 消息中间件性能瓶颈:消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据,如果都存在消息中间件,无疑有非常大的压力。同时,一次性回溯订正180天级别的数据,对实时计算的资源消耗也非常大。
  2. 数据关联时处理开销大:在实时数据处理时,遇到大量不同的实时流进行关联时,非常依赖实时计算系统的能力,很可能因为数据流先后顺序问题,导致数据丢失。
  3. 抛弃了离线计算的可靠性:Kappa在抛弃了离线数据处理模块的同时,也抛弃了离线计算更加稳定可靠的特点。Lambda虽然保证了离线计算的稳定性,但双系统的维护成本高且两套代码带来后期运维困难。

对于以上Kappa框架存在的几个问题,目前也存在一些解决方案:对于消息队列缓存数据性能的问题,Kappa+框架提出使用HDFS来存储中间数据。针对Kappa框架展示层能力不足的问题,也有人提出了混合分析系统的解决方案。

3.3 两种架构对比与选择

Lambda架构与Kappa架构的特性对比:

对比内容 Lambda框架 Kappa框架
复杂度与开发、维护成本 需要维护两套系统(引擎),复杂度高,开发、维护成本高 只需维护一套系统(引擎),复杂度低,开发、维护成本低
计算开销 周期性批处理计算,持续实时计算;计算开销大 必要时进行全量计算;计算开销相对较小
实时性 满足实时性 满足实时性
历史数据处理能力 批式全量处理,吞吐量大;历史据处理能力强;批视图与实时视图存在冲突可能 流式全量处理,吞吐量相对较低;历史数据处理能力相对较弱

对于两种架构设计的选择可以从下表(影响Lambda架构和Kappa架构选择的决策因素)中的4个方面考虑:

设计考虑 Lambda架构 Kappa架构
业务需求与技术要求 依赖Hadoop、Spark、Storm技术 依赖Flink计算引擎,偏流式计算
复杂度 实时处理和离线处理结果可能不一致 频繁修改算法模型参数
开发维护成本 成本预算充足 成本预算有限
历史数据处理能力 频繁使用海量历史数据 仅使用小规模数据集

4 大数据架构的实践

大规模视频网络、广告平台、电商智能决策大数据系统


5 云计算

云计算(Cloud Computing)集合了大量计算设备和资源,对用户屏蔽底层差异的分布式处理架构,其用户与提供实际服务的计算资源是相分离的。云计算的运用十分普遍(如Hyperplasma)。

云计算的优点:超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低【前期投入低、综合使用成本也低】

分类:

  • 按服务类型分类(从下到上服务越来越到位):
    1. SaaS(Software as a Service,软件即服务):基于多租户技术实现,直接提供应用程序。(对应应用层
    2. PaaS(Platform as a Service,平台即服务):虚拟中间件服务器、运行环境和操作系统。(对应平台层
    3. laaS(Infrastructure as a Service,基础设施即服务):包括服务器、存储和网络等服务。(对应基础设施层
  • 按部署方式分类:
    1. 公有云:面向互联网用户需求,通过开放网络提供云计算服务
    2. 私有云:面向企业内部提供云计算服务
    3. 混合云:兼顾以上两种情况的云计算服务

云计算 按部署方式分类

云计算架构:

  • 管理层:提供对所有层次计算服务的管理功能。
    • 安全管理、服务组合、服务目录管理、服务使用计量、服务质量管理、部署管理、服务监控
  • 用户访问层:方便用户使用云计算服务所需的各种支撑服务,针对每个层次的云计算服务都需要提供相应的访问接口。
    • 服务目录、订阅管理、服务访问
  • 应用层:提供对外服务。
    • 企业应用服务、个人应用服务
  • 平台层:为用户提供对资源层服务的封装,使用户可以构建自己的应用。
    • 中间件服务、数据库服务
  • 资源层:提供虚拟化的资源,从而隐藏物理资源的复杂性。
    • 服务器服务(服务器集群)、网络服务(防火墙)、存储服务

云计算架构


6 边缘计算

边缘计算(Edge Computing)在靠近物或数据源头的一侧,采用网络、计算、存储、应用核心能力为一体的开放平台,就近提供最近端服务。

边缘计算的本质:计算处理职能的本地化。

边缘计算

与云计算、终端计算的联系与区别(按层级排列):

  • 云计算:擅长全局调度,进行非实时、长周期的大数据处理与分析
  • 边缘计算:侧重局部、小规模数据处理,适用于现场级、实时、短周期的智能分析与快速決策
  • 终端:侧重局部、小规模数据处理,适用于现场级、实时、短周期的智能分析与快速决策

边缘计算、云计算、终端

《系统架构设计理论与实践(8):大数据架构》有1条评论

发表评论