大数据架构与关键技术Word格式文档下载.docx
《大数据架构与关键技术Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《大数据架构与关键技术Word格式文档下载.docx（33页珍藏版）》请在冰豆网上搜索。
件被划分为三个层级，从高到低依次为角色、活动和功能组件。
最顶层级的逻辑构件是角
色，包括系统协调者、数据提供者、大数据应用提供者、大数据框架提供者、数据消费者、
安全和隐私、管理。
第二层级的逻辑构件是每个角色执行的活动。
第三层级的逻辑构件是
执行每个活动需要的功能组件。
大数据参考架构图的整体布局按照代表大数据价值链的两个维度来组织，即信息价值链
（水平轴）和
价值链（垂直轴）。
在信息价值链维度上，大数据的价值通过数据的收集、
预处理、分析、可视化和访问等活动来实现。
在
价值链维度上，大数据价值通过为大数
据应用提供存放和运行大数据的网络、基础设施、平台、应用工具以及其他
服务来实现。
大数据应用提供者处在两个维的交叉点上，表明大数据分析及其实施为两个价值链上的大
数据利益相关者提供了价值。
五个主要的模型构件代表在每个大数据系统中存在的不同技术角色：
系统协调者、数据提
供者、大数据应用提供者、大数据框架提供者和数据消费者。
另外两个非常重要的模型构
件是安全隐私与管理，代表能为大数据系统其他五个主要模型构件提供服务和功能的构件。
这两个关键模型构件的功能极其重要，因此也被集成在任何大数据解决方案中。
参考架构可以用于多个大数据系统组成的复杂系统（如堆叠式或链式系统），这样其中一
个系统的大数据使用者可以作为另外一个系统的大数据提供者。
参考架构逻辑构件之间的关系用箭头表示，包括三类关系：
“数据”、“软件”和“服务
使用”。
“数据”表明在系统主要构件之间流动的数据，可以是实际数值或引用地址。
“软件”表明在大数据处理过程中的支撑软件工具。
“服务使用”代表软件程序接口。
虽
然此参考架构主要用于描述大数据实时运行环境，但也可用于配置阶段。
大数据系统中涉
及的人工协议和人工交互没有被包含在此参考架构中。
（1）系统协调者
系统协调者角色提供系统必须满足的整体要求，包括政策、治理、架构、资源和业务需求，
以及为确保系统符合这些需求而进行的监控和审计活动。
系统协调者角色的扮演者包括业
务领导、咨询师、数据科学家、信息架构师、软件架构师、安全和隐私架构师、网络架构
师等。
系统协调者定义和整合所需的数据应用活动到运行的垂直系统中。
系统协调者通常
会涉及到更多具体角色，由一个或多个角色扮演者管理和协调大数据系统的运行。
这些角
色扮演者可以是人，软件或二者的结合。
系统协调者的功能是配置和管理大数据架构的其
他组件，来执行一个或多个工作负载。
这些由系统协调者管理的工作负载，在较低层可以
是把框架组件分配或调配到个别物理或虚拟节点上，在较高层可以是提供一个图形用户界
面来支持连接多个应用程序和组件的工作流规范。
系统协调者也可以通过管理角色监控工
作负载和系统，以确认每个工作负载都达到了特定的服务质量要求，还可能弹性地分配和
提供额外的物理或虚拟资源，以满足由变化/激增的数据或用户/交易数量而带来的工作负
载需求。
（2）数据提供者
数据提供者角色为大数据系统提供可用的数据。
数据提供者角色的扮演者包括企业、公共
代理机构、研究人员和科学家、搜索引擎、Web/FTP
和其他应用、网络运营商、终端用户
等。
在一个大数据系统中，数据提供者的活动通常包括采集数据、持久化数据、对敏感信
息进行转换和清洗、创建数据源的元数据及访问策略、访问控制、通过软件的可编程接口
接口实现推或拉式的数据访问、发布数据可用及访问方法的信息等。
数据提供者通常需要为各种数据源（原始数据或由其它系统预先转换的数据）创建一个抽
象的数据源，通过不同的接口提供发现和访问数据功能。
这些接口通常包括一个注册表，
使得大数据应用程序能够找到数据提供者、确定包含感兴趣的数据、理解允许访问的类型、
了解所支持的分析类型、定位数据源、确定数据访问方法、识别数据安全要求、识别数据
保密要求以及其他相关信息。
因此，该接口将提供注册数据源、查询注册表、识别注册表
中包含标准数据集等功能。
针对大数据的
4V
特性和系统设计方面的考虑，暴露和访问数据的接口需要根据变化的复
杂性采用推和拉两种软件机制。
这两种软件机制包括订阅事件、监听数据馈送、查询特定
数据属性或内容，以及提交一段代码来执行数据处理功能。
由于需要考虑大数据量跨网络
移动的经济性，接口还可以允许提交分析请求（例如，执行一段实现特定算法的软件代码）
，只把结果返回给请求者。
数据访问可能不总是自动进行，可以让人类角色登录到系统提
供新数据应传送的方式（例如，基于数据馈送建立订阅电子邮件）。
（3）大数据应用提供者
大数据应用提供者在数据的生命周期中执行一系列操作，以满足系统协调者建立的系统要
求及安全和隐私要求。
大数据应用提供者通过把大数据框架中的一般性资源和服务能力相
结合，把业务逻辑和功能封装成架构组件，构造出特定的大数据应用系统。
大数据应用提
供者角色的扮演者包括应用程序专家、平台专家、咨询师等。
大数据应用提供者角色执行
的活动包括数据的收集、预处理、分析、可视化和访问。
大数据应用程序提供者可以是单个实例，也可以是一组更细粒度大数据应用提供者实例的
集合，集合中的每个实例执行数据生命周期中的不同活动。
每个大数据应用提供者的活动
可能是由系统协调者、数据提供者或数据消费者调用的一般服务，如
Web
服务器、文件服
务器、一个或多个应用程序的集合或组合。
每个活动可以由多个不同实例执行，或者单个
程序也可能执行多个活动。
每个活动都能够与大数据框架提供者、数据提供者以及数据消
费者交互。
这些活动可以并行执行，也可以按照任意的数字顺序执行，活动之间经常需要
通过大数据框架提供者的消息和通信框架进行通信。
大数据应用提供者执行的活动和功能，
特别是数据收集和数据访问活动，需要与安全和隐私角色进行交互，执行认证/授权并记录
或维护数据的出处。
收集活动用于处理与数据提供者的接口。
它可以是一般服务，如由系统协调者配置的用于
接收或执行数据收集任务的文件服务器或
服务器；
也可以是特定于应用的服务，如用
来从数据提供者拉数据或接收数据提供者推送数据的服务。
收集活动执行的任务类似于
ETL
的抽取（extraction）环节。
收集活动接收到的数据通常需要大数据框架提供者的处理
框架来执行内存队列缓存或其他数据持久化服务。
预处理活动执行的任务类似于
的转换（transformation）环节，包括数据验证、清洗、
去除异常值、标准化、格式化或封装。
预处理活动也是大数据框架提供者归档存储的数据
来源，这些数据的出处信息一般也要被验证并附加到数据存储中。
预处理活动也可能聚集
来自不同的数据提供者的数据，利用元数据键来创建一个扩展的和增强的数据集。
分析活动的任务是实现从数据中提取出知识。
这需要有特定的数据处理算法对数据进行处
理，以便从数据中得出能够解决技术目标的新洞察。
分析活动包括对大数据系统低级别的
业务逻辑进行编码（更高级别的业务流程逻辑由系统协调者进行编码），它利用大数据框
架提供者的处理框架来实现这些关联的逻辑，通常会涉及到在批处理或流处理组件上实现
分析逻辑的软件。
分析活动还可以使用大数据框架提供者的消息和通信框架在应用逻辑中
传递数据和控制功能。
可视化活动的任务是将分析活动结果以最利于沟通和理解知识的方式展现给数据消费者。
可视化的功能包括生成基于文本的报告或者以图形方式渲染分析结果。
可视化的结果可以
是静态的，存储在大数据框架提供者中供以后访问。
更多的情况下，可视化活动经常要与
数据消费者、大数据分析活动以及大数据提供者的处理框架和平台进行交互，这就需要基
于数据消费者设置的数据访问参数来提供交互式可视化手段。
可视化活动可以完全由应用
程序实现，也可以使用大数据框架提供者提供的专门的可视化处理框架实现。
访问活动主要集中在与数据消费者的通信和交互。
与数据收集活动类似，访问活动可以是
由系统协调者配置的一般服务，如
服务器或应用服务器，用于接受数据消费者请求。
访问活动还可以作为可视化活动、分析活动的界面来响应数据消费者的请求，并使用大数
据框架提供者的处理框架和平台来检索数据，向数据消费者请求作出响应。
此外，访问活
动还要确保为数据消费者提供描述性和管理性元数据，并把这些元数据作为数据传送给数
据消费者。
访问活动与数据消费者的接口可以是同步或异步的，也可以使用拉或推软件机
制进行数据传输。
（4）大数据框架提供者
大数据框架提供者角色为大数据应用提供者在创建特定的大数据应用系统时提供一般资源
和服务能力。
大数据框架提供者的角色扮演者包括数据中心、云提供商、自建服务器集群
大数据框架提供者执行的活动和功能包括提供基础设施（物理资源、虚拟资源）、数
据平台（文件存储、索引存储）、处理框架（批处理、交互、流处理）、消息和通信框架、
资源管理等。
基础设施为其他角色执行活动提供存放和运行大数据系统所需要的资源。
通常情况下，这
些资源是物理资源的某种组合，用来支持相似的虚拟资源。
资源一般可以分为网络、计算、
存储和环境。
网络资源负责数据在基础设施组件之间的传送；
计算资源包括物理处理器和
内存，负责执行和保持大数据系统其他组件的软件；
存储资源为大数据系统提供数据持久
化能力；
环境资源是在考虑建立大数据系统时需要的实体工厂资源，如供电、制冷等。
数据平台通过相关的应用编程接口（API）或其他方式，提供数据的逻辑组织和分发服务。
它也可能提供数据注册、元数据以及语义数据描述等服务。
逻辑数据组织的范围涵盖从简
单的分隔符平面文件到完全分布式的关系存储或列存储。
数据访问方式可以是文件存取
API
或查询语言（如
SQL）。
通常情况下，实现的大数据系统既能支持任何基本的文件系统
存储，也支持内存存储、索引文件存储等方式。
处理框架提供必要的基础软件以支持实现的应用能够处理具有
特征的大数据。
处理框
架定义了数据的计算和处理是如何组织的。
大数据应用依赖于各种平台和技术，以应对可
扩展的数据处理和分析的挑战。
处理框架一般可以分为批处理（batch）、流处理
（streaming）和交互式（interactive）三种类型。
消息和通信框架为可水平伸缩的集群的结点之间提供可靠队列、传输、数据接收等功能。
它通常有
2
种实现模式，即点对点（point-to-point）模式和存储-转发（store-and-
forward）模式。
点对点模式不考虑消息的恢复问题，数据直接从发送者传送给接收者。
存
储-转发模式提供消息持久化和恢复机制，发送者把数据发送给中介代理，中介代理先存储
消息然后再转发给接收者。
资源管理活动负责解决由于大数据的数据量和速度特征而带来的对
CPU、内存、I/O
等资源
管理问题。
有两种不同的资源管理方式，分别是框架内（intra-framework）资源管理和框
架间（inter-framework）资源管理。
框架内资源管理负责框架自身内部各组件之间的资源
分配，由框架负载驱动，通常会为了最小化框架整体需求或降低运行成本而关闭不需要的
资源。
框架间资源管理负责大数据系统多个存储框架和处理框架之间的资源调度和优化管
理，通常包括管理框架的资源请求、监控框架资源使用，以及在某些情况下对申请使用资
源的应用队列进行管理等。
特别的，针对大数据系统负载多变、用户多样、规模较大的特
点，应采用更加经济有效的资源构架和管理方案。
目前的大数据软件框架，其亮点在于高
可扩展性，而本质诉求仍然是如何实现并行化，即对数据进行分片、并为每一个分片分配
相应的本地计算资源。
因此，对于基础架构而言，为了支持大数据软件框架，最直接的实
现方式就是将一份计算资源和一份存储资源进行绑定，构成一个资源单位（如，服务器），
以获得尽可能高的本地数据访问性能。
但是，这种基础架构由于计算同存储之间紧耦合且
比例固定，逐渐暴露出资源利用率低、重构时灵活性差等问题。
因此，未来应通过硬件及
软件各方面的技术创新，在保证本地数据访问性能的同时，实现计算与存储资源之间的松
耦合，即：
可以按需调配整个大数据系统中的资源比例，及时适应当前业务对计算和存储
的真实需要；
同时，可以对系统的计算部分进行快速切换，真正满足数据技术（DT）时代
对“以数据为中心、按需投入计算”的业务要求。
（5）数据消费者
数据消费者角色接收大数据系统的输出。
与数据提供者类似，数据消费者可以是终端用户
或者其它应用系统。
数据消费者执行的活动通常包括搜索/检索、下载、本地分析、生成报
告、可视化等。
数据消费者利用大数据应用提供者提供的界面或服务访问他感兴趣的信息，
这些界面包括数据报表、数据检索、数据渲染等。
数据消费者角色也会通过数据访问活动与大数据应用提供者交互，执行其提供的数据分析
和可视化功能。
交互可以是基于需要（demand-based）的，包括交互式可视化、创建报告，
或者利用大数据提供者提供的商务智能（BI）工具对数据进行钻取（drill-down）操作等。
交互功能也可以是基于流处理（streaming-based）或推（push-based）机制的，这种情况下
消费者只需要订阅大数据应用系统的输出即可。
（6）安全和隐私
在大数据参考架构图中，安全和隐私角色覆盖了其它五个主要角色，即系统协调者、数据
提供者、大数据框架提供者、大数据应用提供者、数据消费者,表明这五个主要角色的活动
都要受到安全和隐私角色的影响。
安全和隐私角色处于管理角色之中，也意味着安全和隐
私角色与大数据参考架构中的全部活动和功能都相互关联。
在安全和隐私管理模块，通过
不同的技术手段和安全措施，构筑大数据系统全方位、立体的安全防护体系，同时应提供
一个合理的灾备框架，提升灾备恢复能力，实现数据的实时异地容灾功能。
大数据安全和隐私的详细讨论见
4.3。
（7）管理
管理角色包括二个活动组：
系统管理和大数据生命周期管理。
系统管理活动组包括调配、
配置、软件包管理、软件管理、备份管理、能力管理、资源管理和大数据基础设施的性能
管理等活动。
大数据生命周期管理涵盖了大数据生命周期中所有的处理过程，其活动和功
能是验证数据在生命周期的每个过程是否都能够被大数据系统正确地处理。
由于大数据基础设施的分布式和复杂性，系统管理依赖于两点：
使用标准的协议如
SNMP
把资源状态和出错信息传送给管理组件；
通过可部署的代理或管理连接子（connector）允
许管理角色监视甚至控制大数据处理框架元素。
系统管理的功能是监视各种计算资源的运
行状况，应对出现的性能或故障事件，从而能够满足大数据应用提供者的服务质量
（QoS）需求。
在云服务提供商提供能力管理接口时，通过管理连接子对云基础设施提供
的自助服务、自我调整、自我修复等能力进行利用和管理。
大型基础设施通常包括数以千
计的计算和存储节点，因此应用程序和工具的调配应尽可能自动化。
软件安装、应用配置
以及补丁维护也应该以自动的方式推送到各结点并实现自动地跨结点复制。
还可以利用虚
拟化技术的虚拟映像，加快恢复进程和提供有效的系统修补，以最大限度地减少定期维护
时的停机时间。
系统管理模块应能够提供统一的运维管理，能够对包括数据中心、基础硬
件、平台软件（存储、计算）和应用软件进行集中运维、统一管理，实现安装部署、参数
配置、系统监控等功能。
应提供自动化运维的能力，通过对多个数据中心的资源进行统一
管理，合理的分配和调度业务所需要的资源，做到自动化按需分配。
同时提供对多个数据
中心的
基础设施进行集中运维的能力，自动化监控数据中心内各种
设备的事件、告警、
性能，实现从业务维度来进行运维的能力。
大数据生命周期管理活动负责验证数据在生命周期中的每个过程是否都能够被大数据系统
正确地处理，它覆盖了数据从数据提供者那里被摄取到系统，一直到数据被处理或从系统
中删除的整个生命周期。
由于大数据生命周期管理的任务可以分布在大数据计算环境中的
不同组织和个体，从遵循政策、法规和安全要求的视角，大数据生命周期管理包括以下活
动或功能：
政策管理（数据迁移及处置策略）、元数据管理（管理数据标识、质量、访问
权限等元数据信息）、可访问管理（依据时间改变数据的可访问性）、数据恢复（灾难或
系统出错时对数据进行恢复）、保护管理（维护数据完整性）。
从大数据系统要应对大数
据的
特征来看，大数据生命周期管理活动和功能还包括与系统协调者、数据提供者、
大数据框架提供者、大数据应用提供者、数据消费者以及安全和隐私角色之间的交互。
4.2
大数据关键技术
4.2.1
数据收集
大数据时代，数据的来源极其广泛，数据有不同的类型和格式，同时呈现爆发性增长的态
势，这些特性对数据收集技术也提出了更高的要求。
数据收集需要从不同的数据源实时的
或及时的收集不同类型的数据并发送给存储系统或数据中间件系统进行后续处理。
数据收
集一般可分为设备数据收集和
数据爬取两类，常常用的数据收集软件有
Splunk、Sqoop、Flume、Logstash、Kettle
以及各种网络爬虫，如
Heritrix、Nutch
4.2.2
数据预处理
数据的质量对数据的价值大小有直接影响，低质量数据将导致低质量的分析和挖掘结果。
广义的数据质量涉及许多因素，如数据的准确性、完整性、一致性、时效性、可信性与可
解释性等。
大数据系统中的数据通常具有一个或多个数据源，这些数据源可以包括同构/异构的（大）数
据库、文件系统、服务接口等。
这些数据源中的数据来源现实世界，容易受到噪声数据、
数据值缺失与数据冲突等的影响。
此外数据处理、分析、可视化过程中的算法与实现技术
复杂多样，往往需要对数据的组织、数据的表达形式、数据的位置等进行一些前置处理。
数据预处理的引入，将有助于提升数据质量，并使得后继数据处理、分析、可视化过程更
加容易、有效，有利于获得更好的用户体验。
数据预处理形式上包括数据清理、数据集成、
数据归约与数据转换等阶段。
数据清理技术包括数据不一致性检测技术、脏数据识别技术、数据过滤技术、数据修正技
术、数据噪声的识别与平滑技术等。
数据集成把来自多个数据源的数据进行集成，缩短数据之间的物理距离，形成一个集中统
一的（同构/异构）数据库、数据立方体、数据宽表与文件等。
数据归约技术可以在不损害挖掘结果准确性的前提下，降低数据集的规模，得到简化的数
据集。
归约策略与技术包括维归约技术、数值归约技术、数据抽样技术等。
经过数据转换处理后，数据被变换或统一。
数据转换不仅简化处理与分析过程、提升时效
性，也使得分析挖掘的模式更容易被理解。
数据转换处理技术包括基于规则或元数据的转
换技术、基于模型和学习的转换技术等。
4.2.3
数据存储
分布式存储与访问是大数据存储的关键技术，它具有经济、高效、容错好等特点。
分布式
存储技术与数据存储介质的类型和数据的组织管理形式直接相关。
目前的主要数据存储介
质类型包括内存、磁盘、磁带等；
主要数据组织管理形式包括按行组织、按列组织、按键
值组织和按关系组织；
主要数据组织管理层次包括按块级组织、文件级组织以及数据库级
组织等。
不同的存储介质和组织管理形式对应于不同的大数据特征和应用特点。
（1）分布式文件
系统
分布式文件系统是由多个网络节点组成的向上层应用提供统一的文件服务的文件系统。
分
布式文件系统中的每个节点可以分布在不同的地点，通过网络进行节点间的通信和数据传
输。
分布式文件系统中的文件在物理上可能被分散存储在不同的节点上，在逻辑上仍然是
一个完整的文件。
使用分布式文件系统时，无需关心数据存储在哪个节点上，只需像本地
文件系统一样管理和存储文件系统的数据。
分布式文件系统的性能与成本是线性增长的关系，它能够在信息爆炸时代有的效解决数据
的存储和管理。
分布式文件系统在大数据领域是最基础的，最核心的功能组件之一，如何
实现一个高扩展，高性能，高可用的分布式文件系统是大数据领域最关键的问题之一。
目
前常用的分布式磁盘文件系统有HDFS（Hadoop
分布式文件系统）、GFS（Goolge
文件系统）、KFS（Kosmos
distributed
file
system）等；
常用的分布式内存文件系统有
Tachyon
（2）文档存储
文档存储支持对结构化数据的访问，不同于关系模型的是，文档存储没有强制的架构。
事
实上，文档存储以封包键值对的方式进行存储。
在这种情况下，应用对要检索的封包采取
一些约定，或者利用存储引擎的能力将不同的文档划分成不同的集合，以管理数据。
与关系模型不同的是，文档存储模型支持嵌套结构。
例如，文档存储模型支持
XML
和
JSON
文档，字段的“值”又可以嵌套存储其它文档。
文档存储模型也支持数组和列值键。
与键值存储不同的是，文档存储关心文档的内部结构。
这使得存储引擎可以直接支持二级
索引，从而允许对任意字段进行高效查询。
支持文档嵌套存储的能力，使得查询语言具有
搜索嵌套对象的能力，XQuery
就是一个例子。
主流的文档数据库有
MongoDB、CouchDB、Terrastore、RavenDB
（3）列式存储
列式存储将数据按行排序，按列存储，将相同字段的数据作为一个列族来聚合存储。
当只
查询少数列族数据时，列式数据库可以减少读取数据量，减少数据装载和读入读出的时间，
提高数据处理效率。
按列存储还可以承载更大的数据量，获得高效的垂直数据压缩能力，
降低数据存储开销。
使用列式存储的数据库产品有传统的数据仓库产品，如
Sybase
IQ、InfiniDB、Vertica
等，也有开源的数据库产品，如
Hadoop
Hbase、Infobright
（4
升级会员 