数据仓库建设方案(DOC32页).docx
《数据仓库建设方案(DOC32页).docx》由会员分享,可在线阅读,更多相关《数据仓库建设方案(DOC32页).docx(32页珍藏版)》请在淘文阁 - 分享文档赚钱的网站上搜索。
1、第 16/2016/DAF/SA 号公开招标方案建议书第1章 数据仓库建设1.1 数据仓库总体架构专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据,经过一系列综合诊断分析,以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施,为车辆的故障根因修复提供必要的支持。根据专家系统数据仓库建设目标,结合系统数据业务规范,包括数据采集频率、数据采集量等相关因素,设计专家系统数据仓库架构如下:数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容:数据采集:负责从各业务自系统中汇集信息数据,系统支撑Kafka、S
2、torm、Flume及传统的ETL采集工具。数据存储:本系统提供Hdfs、Hbase及RDBMS相结合的存储模式,支持海量数据的分布式存储。数据分析:数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。数据服务总线:数据系统提供数据服务总线服务,实现对数据资源的统一管理和调度,并对外提供数据服务。1.2 数据采集专家系统数据仓库数据采集包括两个部分内容:外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层(ODS);内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。1.2.1 外部数
3、据汇集专家数据仓库数据源包括列车监控与检测系统(TCMS)、车载子系统等相关子系统,数据采集的内容分为实时数据采集和定时数据采集两大类,实时数据采集主要对于各项检测指标数据;非实时采集包括日检修数据等。根据项目信息汇集要求,列车指标信息采集具有采集数据量大,采集频率高的特点,考虑到系统后期的扩展,因此在数据数据采集方面,要求采集体系支持高吞吐量、高频率、海量数据采集,同时系统应该灵活可配置,可根据业务的需要进行灵活配置横向扩展。本方案在数据采集架构采用Flume+Kafka+Storm的组合架构,采用Flume和ETL工具作为Kafka的Producer,采用Storm作为Kafka的Cons
4、umer,Storm可实现对海量数据的实时处理,及时对问题指标进行预警。具体采集系统技术结构图如下:1.2.1.1 数据汇集架构功能Flume提供了从console(控制台)、RPC(Thrift-RPC)、text(文件)、tail(UNIX tail)、syslog(syslog日志系统,支持TCP和UDP等2种模式),exec(命令执行)等数据源上收集数据的能力。Flume的数据接受方,可以是console(控制台)、text(文件)、dfs(HDFS文件)、RPC(Thrift-RPC)和syslogTCP(TCP syslog日志系统)等。在我们系统中由kafka来接收。Kafka分
5、布式消息队列,支撑系统性能横向扩展,通过增加broker来提高系统的性能。Storm流处理技术,支撑Supervisor横向扩展以提高系统的扩展性和数据处理的实时性。1.2.1.2 采集架构优势(一) 解耦在项目中要平衡数据的汇集与数据的处理性能平衡,是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。 冗余有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。在被许多消息队列所
6、采用的“插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理过程明确的指出该消息已经被处理完毕,确保你的数据被安全的保存直到你使用完毕。 扩展性因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的;只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。 灵活性 & 峰值处理能力在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。 可恢复性当体系的一部分
7、组件失效,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。 送达保证消息队列提供的冗余机制保证了消息能被实际的处理,只要一个进程读取了该队列即可。在此基础上,IronMQ提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据,每一个消息只能被处理一次。这之所以成为可能,是因为获取一个消息只是”预定”了这个消息,暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息,否则这个消息会被放回队列中去,在一段可配置的
8、时间之后可再次被处理。 缓冲在任何重要的系统中,都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行写入队列的处理会尽可能的快速,而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。 异步通信很多时候,你不想也不需要立即处理消息。消息队列提供了异步处理机制,允许你把一个消息放入队列,但并不立即处理它。你想向队列中放入多少消息就放多少,然后在你乐意的时候再去处理它们。1.2.2 内部各层数据提取与加载数据汇集将数据储存于操作型数据存储层(ODS),在数据仓库各层次间数据转换提取加载,采用传统的ETL工
9、具进行采集,数据仓库间的各层次的数据采集的实效性根据具体的数据需求而定,具体ETL建模界面如图:1.3 数据加工与处理对于数据仓库平台,应该建立一套标准化、规范化的数据处理流程,例如:如何采集内部和外部数据、结构化和非结构化数据;如何清洗采集来的脏数据和无效数据;如何对不同来源的数据进行打通;如何对非结构化的数据进行结构化加工;如何在结构化数据的基础上进行商业建模和数据挖掘等等。大数据管理层在一条数据总线上构建了一条完整的大数据处理流水线。这条流水线从数据的采集、清洗到加工处理,把原始杂乱无章的数据加工成结构化的数据组件,供上层的大数据应用来拼装调用,让企业拥有创造数据资产的能力。1.4 存储
10、设计1.4.1 数据量估算按每列列车平均500毫秒通过车地通信采集监测数据100条,每天运营时间18小时,按每条记录160字节计算(监测数据的数据项相对简单),初步按照67列列车计算。单列列车日监测数据=3600*2*160*100*18/1024/1024/10242G67列列车年数据量=2*67*365/1024 48T10年总数据量(乘上增长系数10%)530T (含操作系统)数据规划10年,加上系统用户信息、系统日志信息、专家信息、业务数据及其它不可预测类数据,数据总量预估530T。1.4.2 数据存储专家系统数据采用混合存储模式进行存储,RDBMS存储专家系统业务基本数据及最近1年的
11、监测数据,10年内历史监测数据采用NoSQL HBase数据库进行存储,以方便查询,HBase基于Hdfs分布式文件系统搭建,具体存储模式如下图。1. RDBMS数据库,支持专家库的核心业务,存储列车最近1年的监测数据为保证专家系统安全、稳定运行,在数据库系统上支撑各种统计分析及传统的BI业务。考虑到操作系统存储、缓存存储、数据库系统存储、日志存储等因素, RDBMS数据库服务器预计每台60T存储,考虑数据安全及系统稳定因素RDBMS采用双机热备技术互备。2. 大数据平台规划存储最近10年监测数据,日志文件备份及历史数据采用大数据Hadoop和HBase存储,大数据平台数据采用节点间冗余备份,
12、预设数据2倍冗余存储,(考虑平台提供的压缩技术,压缩存储可以节省30-55%的空间)。10年数据量=530T*1.5 800T (2倍冗余存储)1.4.3 分层存储专家数据分三个层次进行汇集与存储,分别为ODS层、数据仓库层、主题数据层,各层次数据存储内容如下 ODS层:数据来源于各生产系统,通过ETL工具对接口文件数据进行编码替换和数据清洗转换,不做关联操作。未来也可用于准实时数据查询。 数据仓库层:数据深度汇集层,根据业务有选择的对ODS层的数据进行提取,通过对数据的加工处理,将单一的数据信息转换成体系信息,将点信息数据变成面信息数据。 主题数据层:将数据信息体系根据各主题进行提取与转换,
13、主题域内部进行拆分、关联。是对ODS操作型数据按照主题域划分规则进行的拆分及合并。1.5 数据分析建模伴随着大数据时代的悄然来临,数据的价值得到人们的广泛认同,对数据的重视提到了前所未有的高度。数据已经作为企业、事业单位的重要资产被广泛应用于盈利分析与预测、客户关系管理、合规性监管、运营风险管理等业务当中。如何建立大数据分析模型,以提供决策依据是很多用户所迫切解决的问题。专家数据仓库建立在Hadoop分布式系统之上,提供了多种丰富的算法模型,不同的应用通过借助不同的接口实现数据的多维呈现和结果展示,为用户提供科学的决策支持。图 10-7 hadoop算法模型图大数据平台提供数据挖掘模型、分布式
14、计算引擎、高性能机器学习算法库(包含分类 、聚类 、预测、推荐等机器学习算法)、即席查询功能,可以帮助决策者快速建立数据分析模型立方体,便于决策者进行OLAP分析。常用算法模型: 分类算法:分类是找出数据库中的一组数据对象的共同特点并按照分类模式将其划分为不同的类,其目的是通过分类模型,将数据库中的数据项映射到某个给定的类别中。如政务网中将用户在一段时间内的网上办理所遇到的问题划分成不同的类,根据情况向用户推荐关联类的问题解决方案,从而方便用户快速解决网上办事审批中遇到的各类问题。 回归算法回归分析反映了数据库中数据的属性值的特性,通过函数表达数据映射的关系来发现属性值之间的依赖关系。在回归算
15、法中通常将数值结果转化为了0到1之间的概率,数值越大,函数越逼近1,数值越小,函数越逼近0,它可以应用到对数据序列的预测及相关关系的研究中去。如我们根据这个概率可以做垃圾邮件预测,例如概率大于0.5,则这封邮件就是垃圾邮件。 聚类算法聚类类似于分类,但与分类的目的不同,是针对数据的相似性和差异性将一组数据分为几个类别。属于同一类别的数据间的相似性很大,但不同类别之间数据的相似性很小,跨类的数据关联性很低。分类算法中的一个显著特征就是训练数据中包含了标签,训练出的模型可以对其他未知数据预测标签。在聚类的算法中,训练数据都是不含标签的,而算法的目的则是通过训练,推测出这些数据的标签。以二维的数据来
16、说,一个数据就包含两个特征,可通过聚类算法,给他们中不同的种类打上标签,通过聚类算法计算出种群中的距离,根据距离的远近将数据划分为多个族群。 关联算法关联规则是隐藏在数据项之间的关联或相互关系,即可以根据一个数据项的出现推导出其他数据项的出现。关联规则的挖掘过程主要包括两个阶段:第一阶段为从海量原始数据中找出所有的高频项目组;第二极端为从这些高频项目组产生关联规则。 推荐算法推荐算法是目前业界非常火的一种算法,在电商界,如亚马逊,天猫,京东等得到了广泛的运用。推荐算法的主要特征就是可以自动向用户推荐他们最感兴趣的东西,从而增加购买率,提升效益。 神经网络模型神经网络模型,因其自身自行处理、分布
17、存储和高度容错等特性非常适合处理非线性的以及那些以模糊、不完整、不严密的知识或数据为特征的处理问题,它的这一特点十分适合解决数据挖掘的问题。典型的神经网络模型主要分为三大类:第一类是以用于分类预测和模式识别的前馈式神经网络模型;第二类是用于联想记忆和优化算法的反馈式神经网络模型。第三类是用于聚类的自组织映射方法。 Adaboost算法其核心思想是针对同一个训练集,训练不同的分类器(弱分类器),然后把这些弱分类器集合起来,构成一个更强的最终分类器 (强分类器)。其算法本身是通过改变数据分布来实现的,它根据每次训练集之中每个样本的分类是否正确,以及上次的总体分类的准确率,来确定每个样本的权值。将修
18、改过权值的新数据集送给下层分类器进行训练,最后将每次训练得到的分类器最后融合起来,作为最后的决策分类器。 深度学习深度学习算法是对人工神经网络的发展。在计算能力变得日益廉价的今天,深度学习试图建立大得多也复杂得多的神经网络,用来处理存在少量未标识数据的大数据集。1.6 数据资源管理专家系统数据具有数据量大、数据类别多、数据关联关系紧密等特点,随着数据的积累,数据资源的利用价值逐步体现,提高数据的管理,是对数据资源充分利用的前提条件。数据资源管了包括如下几部分内容:数据标准化管理、数据监测管理及元数据管理等。1.6.1 数据标准管理汇集整理数据资源管理所需的标准规范信息,建立数据标准数据库。利用
19、专家系统数据标准管理系统的接口同步更新标准信息。包括数据元标准以及信息代码标准。1. 建设数据资源库,实现专家系统发布标准数据元与本地扩展数据元标准的汇集。实现与车辆检修等数据源管理系统接口对接。2. 建设信息代码资源库,梳理国标、部标和本省定义的标准代码以及各业务信息系统需要使用的其它代码,建立字典代码实体数据库。应具备字典代码定期同步功能。并建设信息代码在线映射维护功能,以便对数据标准化转换提供支持。1.6.2 数据监控管理大数据运行监控通过对大数据资源库相关服务器、Oracle数据库、分布式存储系统、Hadoop平台等的运行状态、性能指标以及数据更新情况进行持续监控,及时发现存在的问题及
20、隐患,辅助系统管理员及时采取措施,提高大数据资源库的运行可靠性,保障大数据资源库稳定高效运行。发现异常问题时通过短信、邮件等方式通知系统管理员及时处理,实现通过自动、智能、持续的自动监控预警代替人工巡检,降低运维工作量,提高运维效率。通过可视化图表对监控结果进行统计分析直观展现平台运行各类运行指标,辅助管理员从宏观角度掌握平台运行情况。 性能指标监控可以对服务器CPU负载、Oracle数据库连接数、分布式存储IO负载、Hadoop负载等各类性能相关指标进行监控,以便掌握平台负载情况,及时发现性能问题,辅助平台优化。 大数据库日志监控自动采集大数据相关组件运行日志,并根据既定规则进行分析,发现异
21、常及时告警。提供日志查询检索功能,可以按组件类型、时间、关键字等进行过滤。 数据量监控数据量监控通过对数据总量以及增量进行定期监控,可以掌握数据量变化情况,也可以从数据增量角度发现数据入库异常。数据量监测结果可同步到数据台帐,以便数据台帐统计数据总量情况。1.6.3 元数据管理元数据是数据仓库中存储的基本单元,实现对元数据的管理,数据仓库的最基本功能之一。元数据管理包括元数据注册登记、元数据存储、元数据建模等多方面功能。1.7 数据服务大数据平台开放存储访问接口,提供基于 Hadoop 技术体系的 HDFS、HBase访问接口,以 OpenAPI 的方式,为应用提供大数据存储服务。数据服务层主
22、要由数据服务总线来建设,主要负责将大数据平台的能力接口注册进去,再以标准化接口开放给应用系统使用,支持多种协议转换、服务质量 控制、访问控制、规则引擎等。数据服务层将大数据平台的数据服务能力开放出去,供第三方平台使用。如上图:应用服务系统使用服务接口,来接入数据服务总线,经过数据服务 总线的接入端点,进行过滤。同时根据访问控制、服务质量、协议转换、策略调 度、规则引擎的处理,接出到大数据平台的能力接口。第2章 大数据平台2.1 大数据平台基础架构大数据基础平台基于烽火自主知识产权FitData产品,FitData主要集成了基础计算资源、网络资源、存储资源,在统一的安全体管理体系下,将这些资源再
23、进行深度加工、处理、关联,形成多种类型的基础服务能力,构建基础资源层,向应用提供基础资源的服务能力。数据服务总线通过服务治理来维护基础资源服务能力,并通过访 问控制、服务质量、协议转换等,对应用提供多协议支持。平台支撑体系的运维体系提供整体运维能力,保障平台的正常运行;安全体系提供整体安全能力,保障平台的数据安全和使用安全;平台采用分布式架构,支持巨量数据存储与分析, 保障专家管理系统的高性能、高可用性和易扩展性。FitData大数据基础平台结构如下图红线标出部分。n 数据计算与存储:是FitData 大数据平台的核心内容,提供分布式存储能力和分布式计算能力。提供的存储框架能力,包括基于结构化
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据仓库 建设 方案 DOC32
限制150内