气象大数据技术架构思路.docx
《气象大数据技术架构思路.docx》由会员分享,可在线阅读,更多相关《气象大数据技术架构思路.docx(29页珍藏版)》请在冰豆网上搜索。
气象大数据技术架构思路
气象大数据应用技术架构
设计思路
二〇一五年五月
文档信息
客户单位:
内部技术机密心
项目:
文档:
.docx
版本:
0.9(150521)
发布日期:
未发布
编者:
姓名
公司
项目职称
日期
邱承国
高级技术经理
2015-05-11
批准:
姓名
公司
项目职称
日期
修订历史
主要修订记录
版本号
修改人
修改内容
修改日期
1.
V0.9_150511
邱承国
初稿
2015-0-1-1
2.
3.
4.
1引言
在气象行业内部,气象数据的价值已经和正在被深入挖掘着。
但是,不能将气象预报产品的社会化推广简单地认为就是“气象大数据的广泛应用”。
大数据实际上是一种混杂数据,气象大数据应该是指气象行业所拥有的以及锁接触到的全体数据,包括传统的气象数据和对外服务提供的影视音频资料、网页资料、预报文本以及地理位置相关数据、社会经济共享数据等等。
传统的”气象数据“,地面观测、气象卫星遥感、天气雷达和数值预报产品四类数据占数据总量的90%以上,基本的气象数据直接用途是气象业务、天气预报、气候预测以及气象服务。
“大数据应用”与目前的气象服务有所不同,前者是气象数据的“深度应用”和“增值应用”,后者是既定业务数据加工产品的社会推广应用。
“大数据的核心就是预测”,这是《大数据时代》的作者舍恩伯格的名言。
天气和气候系统是典型的非线性系统,无法通过运用简单的统计分析方法来对其进行准确的预报和预测。
人们常说的南美丛林里一只蝴蝶扇动几下翅膀,会在几周后引发北美的一场暴风雪这一现象,形象地描绘了气象科学的复杂性。
运用统计分析方法进行天气预报在数十年前便已被气象科学界否决了——也就是说,目前经典的大数据应用方法并不适用于天气预报业务。
现在,气象行业的公共服务职能越来越强,面向政府提供决策服务,面向公众提供气象预报预警服务,面向社会发展,应对气候发展节能减排。
这些决策信息怎么来依赖于我们对气象数据的处理。
气象大数据应该在跨行业综合应用这一“增值应用”价值挖掘过程中焕发出的新的光芒。
2大数据平台的基本构成
2.1概述
“大数据”是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。
大数据技术的战略意义不在于掌握庞大的数据信息,而在于对这些含有意义的数据进行专业化处理。
换言之,如果把大数据比作一种产业,那么这种产业实现盈利的关键,在于提高对数据的“加工能力”,通过“加工”实现数据的“增值”。
从技术上看,大数据与云计算的关系就像一枚硬币的正反面一样密不可分。
大数据必然无法用单台的计算机进行处理,必须采用分布式架构。
它的特色在于对海量数据进行分布式数据挖掘(SaaS),但它必须依托云计算的分布式处理、分布式数据库(PaaS)和云存储、虚拟化技术(IaaS)。
大数据可通过许多方式来存储、获取、处理和分析。
每个大数据来源都有不同的特征,包括数据的频率、量、速度、类型和真实性。
处理并存储大数据时,会涉及到更多维度,比如治理、安全性和策略。
选择一种架构并构建合适的大数据解决方案极具挑战,因为需要考虑非常多的因素。
气象行业的数据情况则更为复杂,除了“机器生成”(可以理解为遥测、传感设备产生的观测数据,大量参与气象服务和共享的信息都以文本、图片、视频等多种形式存储,符合“大数据”的4V特点:
Volume(大量)、Velocity(高速)、Variety(多样)、veracity(真实性)。
这些信息长期存储于气象各部门的平台上未能加以合理利用。
另一方面,这些数据本身就是分散存储于多个服务器平台上,急需应用分布式平台统一管理。
因此,我们亟需一种结构化和基于模式的方法来简化定义完整的大数据架构的任务。
因为评估一个业务场景是否存在大数据问题很重要,所以我们包含了一些线索来帮助确定哪些业务问题适合采用大数据解决方案。
2.2数据基础决定平台框架
2.2.1从分类大数据到选择大数据解决方案
RDBMS:
关系型数据库;
ETL:
数据清晰、转换、装载的过程;
ELT:
数据清晰、装载、转换的过程;
CDC:
增量数据复制。
有同步和异步两种模式。
数据种类
结构
示例
量
安全性
建模
存储和检索
集成
使用
主数据
事务
分析数据
元数据
结构化
观测数据
中-高
数据库、应用程序和用户访问
预定义的关系建模或维度建模
RDBMS/SQL
ETL/ELT、CDC
应用程序、BI和统计程序
参考数据
结构化和半结构化
交换数据
中-低
平台安全性
灵活可扩展
XML/xQuery
ETL/ELT、消息
使用基于系统
文档和内容
非结构化
预报文件
高
基于文件系统
随意
文件系统/搜索
操作系统级文件移动
内容管理
大数据
-网页
-物联网
-卫星/雷达等传感器
结构化、半结构化、非结构化
云图
视频
语音
网志
高
文件系统和数据库
灵活(键值)
分布式文件系统/noSQL
Hadoop、MapReduce、ETL/ELT、消息
BI和统计工具
结构化数据
半结构化数据“
非结构化数据
非结构化数据
2.2.2依据大数据类型对业务问题进行分类
根据气象服务需要,业务问题可分类为不同的大数据问题类型。
以后,我们将使用此类型确定合适的分类模式(原子或复合)和合适的大数据解决方案。
但第一步是将业务问题映射到它的大数据类型。
下表列出了常见的业务问题并为每个问题分配了一种大数据类型。
业务问题
大数据问题
描述
公用事业:
临近天气预报
机器生成数据
依据站点观测数据汇总和国家局下发文件、全球交换数据只做的预报信息
政府决策:
区域天气预警
机器生成的数据
地理信息数据
政府交换数据
图片视频资料
语音播报数据
历史灾害汇总
微博等网页数据
政府机构通过“智慧都市”等平台整合IS关联天气预警产品、预警通知反馈、城区建筑布局与灾害易发分析结果预测预判辖区内的灾情险情,做好防灾避险工作
保险业:
气象相关险种
气象预报
Web与社交媒体数据
依据气象预报信息以及网络媒体调查反馈,开辟“中暑险”、“赏月险”等多个险种
医疗保健:
流行病监控
气象预报生活指数
根据历史气象资料和流行病历史资料结合分析,预判流行病发展趋势,对流行病监控、地区流行病学、药物发明、临床试验数据分析、病人病情分析等起着至关重要的作用
此类分析也可以为医药企业的销售行为提供参考
期货:
农产品灾害预测
气象灾害预警
历史气候对农产品影响分析
-用于气象灾害提醒、农产品价格变化预测
-用于期货市场预测分析
2.2.3使用大数据类型对大数据特征进行分类
按特定方向分析大数据的特征会有所帮助,例如以下特征:
数据如何收集、分析和处理。
对数据进行分类后,就可以将它与合适的大数据模式匹配:
●分析类型—对数据执行实时分析还是批量分析。
请仔细考虑分析类型的选择,因为这会影响一些有关产品、工具、硬件、数据源和预期的数据频率的其他决策。
一些用例可能需要混合使用两种类型:
⏹临近分析;分析必须实时或近实时地完成。
⏹历史分析针对战略性业务决策的趋势分析;分析可采用批量模式。
●处理方法—要应用来处理数据的技术类型(比如预测、分析、临时查询和报告)。
业务需求确定了合适的处理方法。
可结合使用各种技术。
处理方法的选择,有助于识别要在您的大数据解决方案中使用的合适的工具和技术。
●数据频率和大小—预计有多少数据和数据到达的频率多高。
知道频率和大小,有助于确定存储机制、存储格式和所需的预处理工具。
数据频率和大小依赖于数据源:
⏹按需分析,与社交媒体数据一样
⏹实时、持续提供(天气数据、交易数据)
⏹时序(基于时间的数据)
●数据类型—要处理数据类型—交易、历史、主数据等。
知道数据类型,有助于将数据隔离在存储中。
●内容格式(传入数据的格式)结构化(例如RDMBS)、非结构化(例如音频、视频和图像)或半结构化。
格式确定了需要如何处理传入的数据,这是选择工具、技术以及从业务角度定义解决方案的关键。
●数据源—数据的来源(生成数据的地方),比如Web和社交媒体、机器生成、人类生成等。
识别所有数据源有助于从业务角度识别数据范围。
该图显示了使用最广泛的数据源。
●数据使用者—处理的数据的所有可能使用者的列表:
⏹业务流程
⏹业务用户
⏹企业应用程序
⏹各种业务角色中的各个人员
⏹部分处理流程
⏹其他数据存储库或企业应用程序
●硬件—将在其上实现大数据解决方案的硬件类型,包括商用硬件或最先进的硬件。
理解硬件的限制,有助于指导大数据解决方案的选择。
2.3数据分类决定应用方案
将不同的数据类型集成后,统一按照大数据进行处理,如下图:
2.4大数据平台的逻辑层次
逻辑构成从框架上展示了各个组件的组织方式。
这些层提供了一种方法来组织执行特定功能的组件。
这些层只是逻辑结构;这并不意味着支持每层的功能在独立的机器或独立的进程上运行。
大数据平台通常由以下逻辑层组成:
1.数据集成层
2.数据存储层
3.数据分析层
4.数据使用层
2.4.1大数据集成层
要全面考虑来自所有渠道的,所有可用于分析的数据。
要求团队中的数据专家阐明执行需求所需的数据。
这些信息包括:
●格式—结构化、半结构化或非结构化。
●速度和数据量—数据到达的速度和传送它的速率因数据源不同而不同。
●收集点—收集数据的位置,直接或通过数据提供程序,实时或以批量模式收集数据。
数据可能来自某个主要来源,比如天气条件,也有可能来自一个辅助来源,比如媒体赞助的天气频道。
●数据源的位置—数据源可能位于企业内或外部。
识别您具有有限访问权的数据,因为对数据的访问会影响可用于分析的数据范围。
2.4.2大数据存储层
此层负责从数据源获取数据,并在必要时,将它转换为适合符合分析方式的格式。
例如,可能需要转换一幅图,才能将它存储在HadoopDistributedFileSystem(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应用程序和其他数据来源扩