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