气象大数据资料

更新时间:2024-05-25 12:06:01 阅读量: 综合文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

1 引言

在气象行业内部,气象数据的价值已经和正在被深入挖掘着。但是,不能将气象预报产品的社会化推广简单地认为就是“气象大数据的广泛应用”。

大数据实际上是一种混杂数据,气象大数据应该是指气象行业所拥有的以及锁接触到的全体数据,包括传统的气象数据和对外服务提供的影视音频资料、网页资料、预报文本以及地理位置相关数据、社会经济共享数据等等。

传统的”气象数据“,地面观测、气象卫星遥感、天气雷达和数值预报产品四类数据占数据总量的90%以上,基本的气象数据直接用途是气象业务、天气预报、气候预测以及气象服务。“大数据应用”与目前的气象服务有所不同,前者是气象数据的“深度应用”和“增值应用”,后者是既定业务数据加工产品的社会推广应用。

“大数据的核心就是预测”,这是《大数据时代》的作者舍恩伯格的名言。天气和气候系统是典型的非线性系统,无法通过运用简单的统计分析方法来对其进行准确的预报和预测。人们常说的南美丛林里一只蝴蝶扇动几下翅膀,会在几周后引发北美的一场暴风雪这一现象,形象地描绘了气象科学的复杂性。运用统计分析方法进行天气预报在数十年前便已被气象科学界否决了——也就是说,目前经典的大数据应用方法并不适用于天气预报业务。

现在,气象行业的公共服务职能越来越强,面向政府提供决策服务,面向公众提供气象预报预警服务,面向社会发展,应对气候发展节能减排。这些决策信息怎么来依赖于我们对气象数据的处理。

气象大数据应该在跨行业综合应用这一“增值应用”价值挖掘过程中焕发出的新的光芒。

2 大数据平台的基本构成 2.1 概述

“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

大数据技术的战略意义不在于掌握庞大的数据信息,而在于对这些含有意义的数据进行专业化处理。换言之,如果把大数据比作一种产业,那么这种产业实现盈利的关键,在于提高对数据的“加工能力”,通过“加工”实现数据的“增值”。

从技术上看,大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理,必须采用分布式架构。它的特色在于对海量数据进行分布式数据挖掘(SaaS),但它必须依托云计算的分布式处理、分布式数据库(PaaS)和云存储、虚拟化技术(IaaS)。

大数据可通过许多方式来存储、获取、处理和分析。每个大数据来源都有不同的特征,包括数据的频率、量、速度、类型和真实性。处理并存储大数据时,会涉及到更多维度,比如治理、安全性和策略。选择一种架构并构建合适的大数据解决方案极具挑战,因为需要考虑非常多的因素。

气象行业的数据情况则更为复杂,除了“机器生成”(可以理解为遥测、传感设备产生的观测数据,大量参与气象服务和共享的信息都以文本、图片、视频等多种形式存储,符合“大数据”的4V特点:Volume(大量)、Velocity(高速)、

Variety(多样)、veracity(真实性) 。这些信息长期存储于气象各部门的平台上未能加以合理利用。另一方面,这些数据本身就是分散存储于多个服务器平台上,急需应用分布式平台统一管理。

因此,我们亟需一种结构化和基于模式的方法来简化定义完整的大数据架构的任务。因为评估一个业务场景是否存在大数据问题很重要,所以我们包含了一些线索来帮助确定哪些业务问题适合采用大数据解决方案。

2.2 数据基础决定平台框架

2.2.1 从分类大数据到选择大数据解决方案 RDBMS:关系型数据库;

ETL:数据清晰、转换、装载的过程; ELT:数据清晰、装载、转换的过程; CDC:增量数据复制。有同步和异步两种模式。 结构化数据 半结构化数据“ 非结构化数据 非结构化数据

2.2.2 依据大数据类型对业务问题进行分类

根据气象服务需要,业务问题可分类为不同的大数据问题类型。以后,我们将

使用此类型确定合适的分类模式(原子或复合)和合适的大数据解决方案。但第一步是将业务问题映射到它的大数据类型。下表列出了常见的业务问题并为每个问题分配了一种大数据类型。

2.2.3 使用大数据类型对大数据特征进行分类

按特定方向分析大数据的特征会有所帮助,例如以下特征:数据如何收集、分析和处理。

对数据进行分类后,就可以将它与合适的大数据模式匹配:

? 分析类型 — 对数据执行实时分析还是批量分析。请仔细考虑分析类型 的选择,因为这会影响一些有关产品、工具、硬件、数据源和预期的数据频率的其他决策。一些用例可能需要混合使用两种类型: ? 临近分析;分析必须实时或近实时地完成。

? 历史分析针对战略性业务决策的趋势分析;分析可采用批量模式。 ? 处理方法 — 要应用来处理数据的技术类型(比如预测、分析、临时查

询和报告)。业务需求确定了合适的处理方法。可结合使用各种技术。处理方法的选择,有助于识别要在您的大数据解决方案中使用的合适的工具和技术。

? 数据频率和大小 — 预计有多少数据和数据到达的频率多高。知道频率 和大小,有助于确定存储机制、存储格式和所需的预处理工具。数据频率和大小依赖于数据源:

? 按需分析,与社交媒体数据一样 ? 实时、持续提供(天气数据、交易数据) ? 时序(基于时间的数据)

? 数据类型 — 要处理数据类型 — 交易、历史、主数据等。知道数据类 型,有助于将数据隔离在存储中。

? 内容格式(传入数据的格式)结构化(例如 RDMBS)、非结构化(例如 音频、视频和图像)或半结构化。格式确定了需要如何处理传入的数据,这是选择工具、技术以及从业务角度定义解决方案的关键。

? 数据源 — 数据的来源(生成数据的地方),比如 Web 和社交媒体、 机器生成、人类生成等。识别所有数据源有助于从业务角度识别数据范围。该图显示了使用最广泛的数据源。

? 数据使用者 — 处理的数据的所有可能使用者的列表: ? 业务流程 ? 业务用户 ? 企业应用程序

? 各种业务角色中的各个人员 ? 部分处理流程

? 其他数据存储库或企业应用程序

? 硬件 — 将在其上实现大数据解决方案的硬件类型,包括商用硬件或最 先进的硬件。理解硬件的限制,有助于指导大数据解决方案的选择。

2.3 数据分类决定应用方案

将不同的数据类型集成后,统一按照大数据进行处理,如下图: 2.4 大数据平台的逻辑层次

逻辑构成从框架上展示了各个组件的组织方式。这些层提供了一种方法来组织执行特定功能的组件。这些层只是逻辑结构;这并不意味着支持每层的功能在独立的机器或独立的进程上运行。

大数据平台通常由以下逻辑层组成: 1. 数据集成层 2. 数据存储层 3. 数据分析层 4. 数据使用层 2.4.1 大数据集成层

要全面考虑来自所有渠道的,所有可用于分析的数据。要求团队中的数据专家阐明执行需求所需的数据。这些信息包括:

? 格式— 结构化、半结构化或非结构化。

? 速度和数据量— 数据到达的速度和传送它的速率因数据源不同而不同。 ? 收集点— 收集数据的位置,直接或通过数据提供程序,实时或以批量

模式收集数据。数据可能来自某个主要来源,比如天气条件,也有可能来自一个辅助来源,比如媒体赞助的天气频道。

? 数据源的位置— 数据源可能位于企业内或外部。识别您具有有限访问 权的数据,因为对数据的访问会影响可用于分析的数据范围。 2.4.2 大数据存储层

此层负责从数据源获取数据,并在必要时,将它转换为适合符合分析方式的格式。例如,可能需要转换一幅图,才能将它存储在 Hadoop Distributed File System (HDFS) 存储或关系数据库管理系统 (RDBMS) 仓库中,以供进一步处理。规范 1和治理策略要求为不同的数据类型提供合适的存储。

2.4.3 大数据分析层

分析层读取数据改动和存储层整理 (digest) 的数据。在某些情况下,分析层直接从数据源访问数据。设计分析层需要认真地进行事先筹划和规划。必须制定如何管理以下任务的决策:

? 生成想要的分析 ? 从数据中获取洞察 ? 找到所需的实体

? 定位可提供这些实体的数据的数据源 ? 理解执行分析需要哪些算法和工具。 2.4.4 大数据应用层

此层使用了分析层所提供的输出。使用者可以是可视化应用程序、人类、业务流程或服务。可视化分析层的结果可能具有挑战。

3 大数据平台的功能架构 3.1 组件构成 3.1.1 横向层

3.1.1.1 大数据集成层 大数据来源:

? 企业遗留系统— 这些系统是企业应用程序,执行业务需要的分析并获 取需要的洞察: ? 气象网络设备监测系统 ? 气象信息共享系统 ? MICAPS

? 网络通信系统CMA-Cast ? 突发应急系统 ? 气象预报系统 ? 气象服务系统 ? 办公自动化

? ?? ? Web 应用程序开发--Web 应用程序和其他数据来源扩充了企业 拥有的数据。这些应用程序可使用自定义的协议和机制来公开数据。 ? 数据管理系统 (DMS)— 数据管理系统存储逻辑数据、流程、策略和各 种其他类型的文档:

? Microsoft? Excel? 电子表格 ? Microsoft Word 文档

? 这些文档可以转换为可用于分析的结构化数据。文档数据 可公开为领域实体,或者数据改动和存储层可将它转换为

领域实体。 ? 数据存储— 数据存储包含企业数据仓库、操作数据库和事务数据库。

此数据通常是结构化数据,可直接使用或轻松地转换来满足需求。这些数据不一定存储在分布式文件系统中,具体依赖于所处的上下文。

? 智慧设备— 智慧设备能够捕获、处理和传输使用最广泛的协议和格式 的信息。这方面的示例包括智能电话、仪表和医疗设备。这些设备可用于执行各种类型的分析。绝大多数智慧设备都会执行实时分析,但从智慧设备传来的信息也可批量分析。

? 聚合的数据提供程序— 这些提供程序拥有或获取数据,并以复杂的格

式和所需的频率通过特定的过滤器公开它。每天都会产生海量的数据,它们具有不同的格式,以不同的速度生成,而且通过各种数据提供程序、传感器和现有企业提供。

? 其他数据源— 有许多数据来自自动化的来源: ? 地理信息: ? 地图

? 地区详细信息 ? 位置详细信息

? 经济热点详细信息(工农业旅游交通教育医疗金融等等) ? 人类生成的内容: ? 社交媒体 ? 电子邮件 ? 博客 ? 在线信息 ? 传感器数据:

? 环境:天气、降雨量、湿度、光线 ? 电气:电流、能源潜力等

? 导航装置

? 电离辐射、亚原子粒子等 ? 靠近、存在等

? 位置、角度、位移、距离、速度、加速度 ? 声音、声震动等 ? 汽车、运输等 ? 热量、热度、温度 ? 光学、光、成像、见光度 ? 化学 ? 压力

? 流动、流体、速度 ? 力、密度级别等

? 来自传感器供应商的其他数据 3.1.1.2 大数据存储层

因为传入的数据可能具有不同的特征,所以数据改动和存储层中的组件必须能够以各种频率、格式、大小和在各种通信渠道上读取数据:

? 数据获取— 从各种数据源获取数据,并将其发送到数据整理组件或存

储在指定的位置中。此组件必须足够智能,能够选择是否和在何处存储传入的数据。它必须能够确定数据在存储前是否应改动,或者数据是否可直接发送到业务分析层。

? 数据整理— 负责将数据修改为需要的格式,以实现分析用途。此组件 可拥有简单的转换逻辑或复杂的统计算法来转换源数据。分析引擎将会确定所需的特定的数据格式。主要的挑战是容纳非结构化数据格式,比如图像、音频、视频和其他二进制格式。

? 分布式数据存储— 负责存储来自数据源的数据。通常,这一层中提供 了多个数据存储选项,比如分布式文件存储 (DFS)、云、结构化数据源、 NoSQL 等。 3.1.1.3 分析层

这是从数据中提取业务洞察的层:

? 分析层实体识别— 负责识别和填充上下文实体。这是一个复杂的任务, 需要高效的高性能流程。数据整理组件应为这个实体识别组件提供补充,将数据修改为需要的格式。分析引擎将需要上下文实体来执行分析。

? 分析引擎— 使用其他组件(具体来讲,包括实体鉴别、模型管理和分 析算法)来处理和执行分析。分析引擎可具有支持并行处理的各种不同的工作流、算法和工具。

? 模型管理— 负责维护各种统计模型,验证和检验这些模型,通过持续

培训模型来提高准确性。然后,模型管理组件会推广这些模型,它们可供实体识别或分析引擎组件使用。

3.1.1.4 使用层

这一层使用了从分析应用程序获取的业务洞察。分析的结果由组织内的各个用户和组织外部的实体(比如客户、供应商、合作伙伴和提供商)使用。此洞察可用于针对客户提供产品营销信息。例如,借助从分析中获取的洞察,公司可以使用客户偏好数据和位置感知,在客户经过通道或店铺时向他们提供个性化的营销信息。

该洞察可用于检测欺诈,实时拦截交易,并将它们与使用已存储在企业中的数据构建的视图进行关联。在欺诈性交易发生时,可以告知客户可能存在欺诈,以便及时采取更正操作。

此外,可以根据在数据改动层完成的分析来触发业务流程。可以启动自动化的步骤 — 例如,如果客户接受了一条可自动触发的营销信息,则需要创建一个新订单,如果客户报告了欺诈,那么可以触发对信用卡使用的阻止。

分析的输出也可由推荐引擎使用,该引擎可将客户与他们喜欢的产品相匹配。 推荐引擎分析可用的信息,并提供个性化且实时的推荐。

使用层还为内部用户提供了理解、找到和导航企业内外的链锁信息的能力。对于内部使用者,为业务用户构建报告和仪表板的能力使得利益相关者能够制定精明的决策并设计恰当的战略。为了提高操作有效性,可以从数据中生成实时业务警告,而且可以监视操作性的关键绩效指标:

? 交易拦截器— 此组件可实时拦截高容量交易,将它们转换为一种容易

被分析层理解的实时格式,以便在传入数据上执行实时分析。事务拦截器应能够集成并处理来自各种来源的数据,比如传感器、智能仪表、麦克风、摄像头、GPS 设备、ATM 和图像扫描仪。可以使用各种类型的适配器和 API 来连接到数据源。也可以使用各种加速器来简化开发,比如实时优化和流分析,视频分析,银行、保险、零售、电信和公共运输领域的加速器,社交媒体分析,以及情绪分析。

? 业务流程管理流程— 来自分析层的洞察可供业务流程执行语言 (BPEL) 流程、API 或其他业务流程使用,通过自动化上游和下游 IT 应用程序、人员和流程的功能,进一步获取业务价值。

? 实时监视— 可以使用从分析中得出的数据来生成实时警告。可以将警 告发送给感兴趣的使用者和设备,比如智能电话和平板电脑。可以使用从分析组件生成的数据洞察,定义并监视关键绩效指标,以便确定操作有效性。实时数据可从各种来源以仪表板的形式向业务用户公开,以便监视系统的健康或度量营销活动的有效性。

? 报告引擎— 生成与传统商业智能报告类似的报告的能力至关重要。用 户可基于从分析层中得到的洞察,创建临时报告、计划的报告或自助查询和分析。

? 推荐引擎— 基于来自分析层的分析结果,推荐引擎可向购物者提供实 时的、相关的和个性化的推荐,提高电子商务交易中的转换率和每个订单的平均价值。该引擎实时处理可用信息并动态地响应每个用户,响应基于用户的实时活动、存储在 CRM 系统中的注册客户信息,以及非注册客户的社交概况。

? 可视化和发现— 数据可跨企业内外的各种联邦的数据源进行导航。数 据可能具有不同的内容和格式,所有数据(结构化、半结构化和非结构化)可组合来进行可视化并提供给用户。此能力使得组织能够将其传统的企业内容(包含在企业内容管理系统和数据仓库中)与新的社交内容(例如 tweet 和博客文章)组合到单个用户界面中。

3.1.2 垂直层

影响逻辑层(大数据来源、数据改动和存储、分析和使用层)的所有组件的各方面都包含在垂直层中:

? 信息集成 ? 大数据治理 ? 系统管理 ? 服务质量 3.1.2.1 信息集成

大数据应用程序从各种数据起源、提供程序和数据源获取数据,并存储在 HDFS、NoSQL 和 MongoDB 等数据存储系统中。这个垂直层可供各种组件使用(例如数据获取、数据整理、模型管理和交易拦截器),负责连接到各种数据源。集成将具有不同特征(例如协议和连接性)的数据源的信息,需要高质量的连接器和适配器。可以使用加速器连接到大多数已知和广泛使用的来源。这些加速器包括社交媒体适配器和天气数据适配器。各种组件还可以使用这一层在大数据存储

中存储信息,从大数据存储中检索信息,以便处理这些信息。大多数大数据存储都提供了服务和 API 来存储和检索该信息。

3.1.2.2 大数据治理

数据治理涉及到定义指南来帮助企业制定有关数据的正确决策。大数据治理有助于处理企业内或从外部来源传入的数据的复杂性、量和种类。在将数据传入企业进行处理、存储、分析和清除或归档时,需要强有力的指南和流程来监视、

构建、存储和保护数据。

除了正常的数据治理考虑因素之外,大数据治理还包含其他因素: ? 管理各种格式的大量数据。

? 持续培训和管理必要的统计模型,以便对非结构化数据和分析进行预处 理。请记住,设置处理非结构化数据时的重要一步。 ? 为外部数据设置有关其保留和使用的策略和合规性制度。 ? 定义数据归档和清除策略。

? 创建如何跨各种系统复制数据的策略。 ? 设置数据加密策略。 3.1.2.3 服务质量层

此层复杂定义数据质量、围绕隐私和安全性的策略、数据频率、每次抓取的数据大小和数据过滤器:

? 数据质量

? 完整地识别所有必要的数据元素 ? 以可接受的新鲜度提供数据的时间轴 ? 依照数据准确性规则来验证数据的准确性

? 采用一种通用语言(数据元组满足使用简单业务语言所表达的需求) ? 依据数据一致性规则验证来自多个系统的数据一致性

? 在满足数据规范和信息架构指南基础上的技术符合性 ? 围绕隐私和安全的策略

需要策略来保护敏感数据。从外部机构和提供程序获取的数据可能包含敏感数据(比如 Facebook 用户的联系信息或产品定价信息)。数据可以来源于不同的地区和国家,但必须进行相应的处理。必须制定有关数据屏蔽和这类数据的存储的决策。考虑以下数据访问策略:

? 数据可用性 ? 数据关键性 ? 数据真实性 ? 数据共享和发布

? 数据存储和保留,包括能否存储外部数据等问题。如果能够存储数 据,数据可存储多长时间?可存储何种类型的数据?

? 数据提供程序约束(政策、技术和地区) ? 社交媒体使用条款(参见 参考资料) ? 数据频率

提供新鲜数据的频率是多少?它是按需、连续还是离线的? ? 抓取的数据大小

此属性有助于定义可抓取的数据以及每次抓取后可使用的数据大小。 ? 过滤器

标准过滤器会删除不想要的数据和数据中的干扰数据,仅留下分析所需的数据。

3.1.2.4 系统管理

系统管理对大数据至关重要,因为它涉及到跨企业集群和边界的许多系统。对整个大数据生态系统的健康的监视包括:

? 管理系统日志、虚拟机、应用程序和其他设备 ? 关联各种日志,帮助调查和监视具体情形 ? 监视实时警告和通知

? 使用显示各种参数的实时仪表板 ? 引用有关系统的报告和详细分析

? 设定和遵守服务水平协议 ? 管理存储和容量 ? 归档和管理归档检索

? 执行系统恢复、集群管理和网络管理 ? 策略管理 3.2 功能应用

前面提到的技术架构的这些层定义了各种组件,并对它们进行分类,这些组件必须处理某个给定业务用例的功能性和非功能性需求。本文基于层和组件的概念,介绍了解决方案中所用的典型原子模式和复合模式。通过将所提出的解决方案映射到此处提供的模式,让用户了解需要如何设计组件,以及从功能角度考虑,应该将它们放置在何处。模式有助于定义大数据解决方案的架构。利用原子模式和复合模式可以帮助进一步完善大数据解决方案的每个组件的角色和责任。

3.3 原子模式

对于大数据上下文中经常出现的问题,原子模式 有助于识别数据如何是被使用、处理、存储和访问的。它们还有助于识别所需的组件。访问、存储和处理来自不同数据源的多种数据需要不同的方法。每种模式都用于满足特定的需求:例如,可视化、历史数据分析、社交媒体数据和非结构化数据的存储。可以将多种原子模式结合使用,组成一个复合模式。这些原子模式没有进行分层或排序。例如,可视化模式可以与社交媒体的数据访问模式直接交互,可视化模式还可以与高级分析处理模式进行交互。

3.3.1 数据使用组件

这种类型的模式处理使用数据分析结果的各种方式。数据使用模式可以满足几个需求。

3.3.1.1 可视化组件

可视化数据的传统方式以图表、仪表板和摘要报告为基础。这些传统的方法并不总是用来可视化数据的最佳方式。

大数据可视化的典型需求(包括新出现的需求)如下所示: ? 执行流数据的实时分析和显示 ? 基于上下文,以交互方式挖掘数据 ? 执行高级搜索,并获得建议 ? 并行可视化信息

? 获得先进的硬件,支持未来的可视化需求

? 正在进行研究,以确定人类和机器如何使用大数据洞察。这些挑战包括 所涉及的数据量,并且需要将数据与上下文相关联。必须在适当的上下文中显示洞察。

? 可视化数据的目的是为了更容易、更直观地使用数据,因此报告和仪表 板可能提供全高清的观看效果和 3-D 互动视频,并且可以为用户提供使用应用程序控制业务活动和结果的能力。

3.3.1.2 即席发现组件

创建满足所有业务需求的标准报告往往是不可行的,因为企业的业务数据查询会有不同的需求。用户在查找特定信息时,可能需要获得根据问题的上下文执行即席查询的能力。

即席分析可以帮助数据专家和关键业务用户了解业务数据的行为。即席处理中涉及的复杂性来自多种因素:

多个数据源可用于相同的域。 ? 单一的查询可以有多个结果。

? 输出可以是静态的,并具有多种格式(视频、音频、图形和文本)。 ? 输出可以是动态和交互式的。

3.3.1.3 数据转储组件

在大数据的初步探索中,许多企业选择使用现有的分析平台来降低成本,并依赖于现有的技能。加强现有的数据存储有助于拓宽可用于现有分析的数据的范围,包括驻留在组织边界内外的数据,比如社交媒体数据,它可以丰富主数据。通过拓宽数据范围,使之包含现有存储中的新事实表、维度和主数据,并从社交媒体获取客户数据,组织可以获得更深入的客户洞察。

但要牢记的是,新的数据集通常比较大,而现有的提取、转换和加载工具可能不足以处理它。您可能需要使用具有大规模并行处理能力的高级工具来解决数据的数量、多样性、真实性和速度特征。

3.3.1.4 信息推送/通知组件

大数据洞察使人类、企业和机器可以通过使用事件通知而立即采取行动。通知平台必须能够处理及时发送出去的预计数量的通知。这些通知与大量邮件或群发短信不同,因为内容一般是特定于使用者的。例如,推荐引擎可以提供有关世界各地的庞大客户群的洞察,而且可以将通知发送给这样的客户。

3.3.1.5 自动响应组件

从大数据获得的业务洞察,可用于触发或启动其他业务流程或事务 3.3.2 数据处理组件

无论数据是处于静止状态还是在运动中,都可以处理大数据。具体情况取决于分析的复杂性,有可能不需要对数据进行实时处理。这种模式解决了对大数据进行实时、近实时或批量处理的方式。

以下高级的大数据处理类别适用于大多数分析。这些类别通常也适用于基于 RDBMS 的传统系统。惟一的区别是庞大规模的数据、多样性和速度。在处理大数据时,要使用机器学习、复杂事件处理、事件流处理、决策管理和统计模型管理等技术。

3.3.2.1 历史数据分析组件

传统的历史数据分析仅限于预定义的数据时间段,这通常取决于数据保留策略。由于处理和存储的限制,超出此时间段的数据通常会被归档或清除。基于 Hadoop 的系统和其他等效的系统可以克服这些限制,因为它们具有丰富的存储以及分布式大规模并行处理能力。运营、业务和数据仓库的数据被移动到大数据存储,您通过使用大数据平台功能对它们进行处理。

历史分析包括分析给定时间段、季节组合和产品的历史趋势,并与最新的可用数据进行比较。为了能够存储和处理如此庞大的数据,您可以使用 HDFS、

NoSQL、SPSS? 和 InfoSphere? BigInsights?。 3.3.2.2 高级分析组件

大数据提供了很多实现创意洞察的机会。不同的数据集可以在多种上下文中存在关联。发现这些关系需要创新的复杂算法和技术。

高级分析包括预测、决策、推理过程、模拟、上下文信息标识和实体解析。高级分析的应用包括生物统计数据分析(例如,DNA 分析)、空间分析、基于位置的分析、科学分析、研究,等等。高级分析要求大量的计算来管理大量的数据。

数据专家可以指导您识别合适的技术、算法和数据集,以及在给定上下文中解决问题所需的数据源。比如 SPSS、InfoSphere Streams 和 InfoSphere BigInsights 等工具提供了这类功能。这些工具访问存储在大数据存储系统(比如 BigTable、HBase,等等)中的非结构化数据和结构化数据(例如,JSON 数据)。

3.3.2.3 预处理原始数据组件

大数据解决方案主要由基于 MapReduce 的 Hadoop 系统和技术组成,MapReduce 是开箱即用的分布式存储和处理解决方案。然而,从非结构化数据提取数据(例如,图像、音频、视频、二进制提要,甚至是文本)是一项复杂的任务,需要具有机器学习能力并掌握自然语言处理等技术。另一个主要挑战是如何验证这些技术和算法的输出的准确度和正确性。

要对任何数据执行分析,数据都必须是某种结构化格式。从多个数据源访问的非结构化数据可以按原样存储,然后被转化成结构化数据(例如 JSON),并

被再次存储到大数据存储系统中。非结构化文本可以转换成半结构化或结构化数据。同样,图像、音频和视频数据需要转换成可用于分析的格式。此外,使用预测和统计算法的高级分析的准确性和正确性取决于用来训练其模型的数据和算法的数量。

下面的列表显示了将非结构化数据转换成结构化数据所需的算法和活动: ? 文档和文本分类

? 特征提取 ? 图像和文本分割

? 关联特征、变量和时间,然后提取包含时间的值

? 输出的准确度检查使用了混淆矩阵(confusion matrix)等技术和其他手 动活动

? 数据专家可以帮助用户选择合适的技术和算法。 3.3.2.4 即席分析组件

处理大数据的即席查询所带来的挑战不同于对结构化数据执行即席查询时所面临的挑战,由于数据源和数据格式不是固定的,所以需要使用不同的机制来检索和处理数据。

虽然大数据供应商可以处理简单的即席查询,但在大多数情况下,查询是复杂的,因为必须在运行时动态地发现数据、算法、格式和实体解析。所以需要利用数据专家和业务用户的专业知识来定义下列任务所需的分析:

? 识别并发现计算和算法 ? 识别并发现数据源

? 定义所需的可以由计算使用的格式 ? 对数据执行并行计算 3.3.3 数据访问组件

在大数据解决方案中,有许多数据源,还有很多访问数据的方式,本节将介绍最常见的几种。

3.3.3.1 web和社交媒体访问组件

Internet 是提供许多目前可以获得的洞察的数据源。在几乎所有分析中,都会用到 Web 和社交媒体,但获得这种数据需要不同的访问机制。

在所有数据源中,因为 Web 和社交媒体的多样性、速度和数量,所以 Web 和社交媒体是最为复杂的。网站大约有 40-50 个类别,每一个类别都需要使用不同的方式来访问数据。本节将列出这些类别,并介绍一些访问机制。从大数据的角度讲,高级的类别是商业站点、社交媒体站点,以及具有特定和通用组件的站点。有关的访问机制见图 3。如果需要的话,在完成预处理后,可将所访问的数据存储在数据存储中。

Web 和社交媒体访问

需要执行以下步骤来访问 Web 媒体信息。 图 大数据访问步骤

非结构化数据存储中的 Web 媒体访问 步骤 A-1. 爬网程序读取原始数据。 步骤 A-2. 数据被存储在非结构化存储中。 Web 媒体访问为结构化存储预处理数据 步骤 B-1. 爬网程序读取原始数据。 步骤 B-2. 对数据进行预处理。

步骤 B-3. 数据被存储在结构化存储中。 Web 媒体访问预处理非结构化数据

步骤 C-1. 在极少数情况下,来自供应商的数据可以是非结构化数据。 步骤 C-2. 对数据进行预处理。

步骤 C-3. 数据被存储在结构化存储中。 非结构化或结构化数据的 Web 媒体访问

步骤 D-1. 数据供应商提供结构化或非结构化数据。 步骤 D-2. 数据被存储在结构化或非结构化存储中。 Web 媒体访问预处理非结构化数据

步骤 E-1. 不能使用在存储时未经过预处理的非结构化数据,除非它是结构化格式的数据。

步骤 E-2. 对数据进行预处理。

步骤 E-3. 经过预处理的结构化数据被存储在结构化存储中。

如图所示,数据可以直接存储在存储器中,或者可以对它们进行预处理,并将它们转换成一个中间格式或标准格式,然后再存储它们。

在可以分析数据之前,数据格式必须可用于实体解析或用于查询所需数据。这种经过预处理的数据可以存储在一个存储系统中。

虽然预处理通常被认为是微不足道的,但这项处理可能非常复杂和耗时。 3.3.3.2 物联网设备数据的访问组件

设备生成的内容包括来自传感器的数据数据是从天气信息、电气仪表和污染数据等数据来源检测到的,并且由传感器捕获。这些数据可以是照片、视频、文本和其他二进制格式。

下图说明了处理机器生成的数据的典型过程。 图 5. 设备生成的数据访问

图 5 说明了访问来自传感器的数据的过程。由传感器捕获的数据可以发送到设备网关,设备网关会对数据执行一些初始预处理,并缓冲高速数据。机器生成的数据大多为二进制格式(音频、视频和传感器读数)或文本格式。这样的数据最初可以存储在存储系统中,也可以对它们进行预处理,然后再存储它们。对于分析来说,要求执行预处理。

3.3.3.3 基础数据(观测数据和生产数据)的访问模式

可以存储现有的事务、运营和仓库数据,避免清除或归档数据(因为存储和处理的限制),或减少在数据被其他使用者访问时对传统存储的负载。

对于大多数企业而言,事务、运营、主数据和仓库信息都是所有分析的核心。如果用在 Internet 上,或者通过传感器和智能设备提供的非结构化数据以及外部数据来增强此数据,那么可以帮助组织获得准确的洞察,并执行高级分析。

使用由多个数据库厂商提供的标准连接器,事务和仓库数据可以被推入存储。预处理事务性数据要容易得多,因为数据大多是结构化的。可以使用简单的提取、转换和加载流程将事务数据移动到存储中。事务数据可以很容易地转换成 JSON 和 CSV 等格式。使用 Sqoop 等工具可以更容易将事务数据推入存储系统,如 HBase 和 HDFS。

3.3.4 数据存储组件

存储模式有助于确定适当的存储各种数据的类型和格式。数据可以按原样存储,根据键值对存储,或者以预定义的格式存储。

分布式文件系统(如 GFS 和 HDFS)都能够存储任何类型的数据。但是,高效地检索或查询数据的能力会影响性能。技术的选择很重要。

3.3.4.1 分布式非结构化数据存储组件

大部分大数据是非结构化数据,而且可以通过不同的方式针对不同的上下文提取它所拥有的信息。大多数时候,非结构化数据必须按原样并以其原始格式进行存储。

这样的数据可以存储在分布式文件系统(如 HDFS)和 NoSQL 文档存储(如 MongoDB)中。这些系统提供了检索非结构化数据的有效方法。

3.3.4.2 分布式结构化数据存储组件

结构化数据包括从数据源到达的已经是结构化格式的数据,以及经过预处理,被转换为 JSON 数据等格式的非结构化数据。必须存储已经过转换的数据,避免从原始数据到结构化数据的频繁数据转换。

可以使用 Google 的 BigTable 等技术来存储结构化数据。BigTable 是一个大规模容错式自我管理系统,包括 TB 级的内存和 PB 级的存储。

Hadoop 中的 HBase 可媲美 BigTable。它使用了 HDFS 作为底层存储。 3.3.4.3 传统数据存储组件

对于存储大数据而言,传统的数据存储并不是最佳选择,但在企业执行初步数据探索的情况下,企业可能会选择使用现有的数据仓库、RDBMS 系统和其他内容存储。这些现有的存储系统可用来存储使用大数据平台消化和过滤的数据。不要认为传统的数据存储系统适用于大数据。

3.3.4.4 云存储组件

许多云计算基础架构供应商都有分布式结构化、非结构化的存储能力。从传统的配置、维护、系统管理、编程和建模角度讲,大数据技术有点不同。此外,实现大数据解决方案所需的技能既罕见又昂贵。探索大数据技术的企业可以使用云解决方案来提供大数据的存储、维护和系统管理。

要存储的数据往往是敏感数据,这些数据包括医疗记录和生物特征数据。您需要考虑数据安全性、数据共享、数据治理,以及有关数据的其他政策,在考虑将云作为大数据存储库的时候尤其如此。传输大量数据的能力也是云存储的另一个重要考虑因素。

3.4 复合模式

原子模式 侧重于提供执行各项功能所需的能力。但是,复合模式 是基于 端到端的解决方案进行分类的。每个复合模式都要考虑一个或多个维度。在将复合模式应用到每个模式时,会有许多变化。可以将复合模式映射到一个或多个原子模式,以解决某个给定的业务问题。本文所述的复合模式列表是基于经常发生的典型业务问题,但这不是复合模式的完整列表。

3.4.1 存储和探索复合组件

如果业务问题需要存储大量新数据和现有数据,而且先前由于缺乏足够的存储和分析能力而一直未使用这些数据,那么这种模式就非常有用。该模式旨在缓解对现有数据存储的负载。所存储的数据可用于初始勘探和即席发现。用户可以推演报告,通过进一步的处理来分析数据的质量和价值。您可以使用 ETL 工具来预处理和净化原始数据,然后再进行任何类型的分析。

图 6. 存储和探索复合模式

图 6 说明了这种模式的多个维度。数据的使用目的可能只是存储它,或处理和使用它。

仅存储的示例是,数据的获取和存储只是为了将来能够满足合规性或法律的要求。在处理和使用的情况下,分析的结果可以被处理和使用。可以从最近发现的来源或从现有的数据存储访问数据。

3.4.2 专业分析和预测分析组件

使用此模式的情况是,使用多种处理技术执行分析,因此,

可以用新洞察丰

富现有数据,或创建可由各种用户使用的输出。该分析可以在事件发生的同时实时发生,或使用批量模式,根据收集到的数据获得洞察。作为可以分析的静态数据的示例,某电信公司可能构建客户流失模型,包括分析呼叫数据记录、社交数据和事务数据。作为分析运动数据的示例,预测某个给定事务正在经历欺诈的需求必须实时或近实时地发生。

图 7. 专用和预测分析复合模式

图 7 说明了这种模式的多个维度。所执行的处理可以是标准的或预测性的,并且可以包括决策。

此外,可以将通知发送给与特定任务或消息有关的系统或用户。该通知可以使用可视化功能。该处理可实时发生或以批量模式发生。

3.4.3 OLAP在线分析

大数据解决方案的最高级形式是,对数据集执行分析,并且基于可重复的过去的行动或行动矩阵来暗示行动。该操作可以是手动、半自动或全自动的。基础分析需要高度准确。行动是预定义的,分析的结果被映射到行动。可操作分析中所涉及的典型步骤是:

分析数据以获得洞察。 ? 制定决策。

? 激活相应的渠道,对正确的使用者采取行动。 图 8. 可操作的分析复合模式

图 8 说明该分析可以是手动、半自动或全自动的。如图中的说明所示,它使用了原子模式。

手动操作 意味着系统基于分析的结果来提供建议操作,并由人类决定和执行操作。半自动 意味着,分析建议操作,但不需要通过人类干预来启动操作,或从一组建议的操作中进行选择。全自动 表示在决策之后,系统立即执行操作。例如,在设备被预测会发生故障之后,系统可以自动创建一个工作订单。

3.4.4 原子模式和符合模式的映射

下面的矩阵显示了如何将原子模式映射到复合模式,复合模式是原子模式的组合。每个复合模式都被设计为针对具有一组特定特征的数据在特定情况下使用。矩阵显示了模式的典型组合。必须对模式进行调整,以满足特定的情况和需求。在矩阵中,按照从最简单到最复杂的顺序列出了复合模式。“store and explore(存储和探索)”模式是最简单的。

图 9. 复合模式对原子模式的映射

3.4.4.1.1 图 10. 将原子模式映射到架构层 3.5 解决方案模式(模拟应用场景) 4 技术架构实现方案 4.1 概述

4.2 技术架构的关键问题 4.2.1 hadoop

此方案基于开源Apache Hadoop的框架实现。因此它维护多个工作数据副本,确保能够针对失败的节点重新分布处理。Hadoop实现了一个分布式文件系统(Hadoop Distributed File System),简称HDFS。HDFS有着高容错性的特点,并且设计用来部署在低廉的(low-cost)硬件上

4.2.2 数据库

此方案实际上是综合利用传统数据库/数据仓库、NOSQL等多种数据库组合。 传统的数据库/数据仓库用于存储结构化和半结构化的数据,NOSQL数据库用于存储非结构化的数据。

之所以选择组合的多数据库并存方案,主要是考虑到气象行业的数据存储现状比较复杂,在大叔据项目实施过程中很多分析是需要传统数据和文件分析同时进行的。另外,从NOSQL数据到数据仓库需要一个缓冲处理。当然,这种混合使用的方案会要求大量的ETL过程来进行数据的转换和存储。

4.2.3 流计算

在传统的数据分析策略中,数据被收集到一个数据库中,并被搜索或查询答案。这种分析方法更多地依赖于数据库平台的资源。

Streams 计算软件,这是一个突破性的移动数据分析平台。流计算动态收集多个数据流,使用先进的算法来提供近乎瞬时的分析。,流计算颠覆了这种策略,可用于需要立即作出决定的复杂动态情况

4.2.4 数据治理

4.2.5 分布式存储与分布式应用

4.3 服务平台的硬件架构与调整 4.4 数据库与数据仓库 4.5 NOSQL数据库 4.6 数据集成工具 4.7 数据分析软件

4.8 Web应用以及Web开发的关键问题 5 我们的研发策略 5.1 效益 5.2 目前的形势

5.3 针对目前直接的应用需求 5.4 技术储备与项目应用 5.5 如何保证将来的扩展

本文来源:https://www.bwwdw.com/article/mqa7.html

Top