文档介绍：--------------------校验:_____________--------------------日期:_____________数据仓库建设方案数据仓库建设数据仓库总体架构专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据,经过一系列综合诊断分析,以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施,为车辆的故障根因修复提供必要的支持。根据专家系统数据仓库建设目标,结合系统数据业务规范,包括数据采集频率、数据采集量等相关因素,设计专家系统数据仓库架构如下:数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容:数据采集:负责从各业务自系统中汇集信息数据,系统支撑Kafka、Storm、Flume及传统的ETL采集工具。数据存储:本系统提供Hdfs、Hbase及RDBMS相结合的存储模式,支持海量数据的分布式存储。数据分析:数据仓库体系支持传统的OLAP分析及基于Spark常规机器学****算法。数据服务总线:数据系统提供数据服务总线服务,实现对数据资源的统一管理和调度,并对外提供数据服务。数据采集专家系统数据仓库数据采集包括两个部分内容:外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层(ODS);内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。外部数据汇集专家数据仓库数据源包括列车监控与检测系统(TCMS)、车载子系统等相关子系统,数据采集的内容分为实时数据采集和定时数据采集两大类,实时数据采集主要对于各项检测指标数据;非实时采集包括日检修数据等。根据项目信息汇集要求,列车指标信息采集具有采集数据量大,采集频率高的特点,考虑到系统后期的扩展,因此在数据数据采集方面,要求采集体系支持高吞吐量、高频率、海量数据采集,同时系统应该灵活可配置,可根据业务的需要进行灵活配置横向扩展。本方案在数据采集架构采用Flume+Kafka+Storm的组合架构,采用Flume和ETL工具作为Kafka的Producer,采用Storm作为Kafka的Consumer,Storm可实现对海量数据的实时处理,及时对问题指标进行预警。具体采集系统技术结构图如下:数据汇集架构功能Flume提供了从console(控制台)、RPC(Thrift-RPC)、text(文件)、tail(UNIXtail)、syslog(syslog日志系统,支持TCP和UDP等2种模式),exec(命令执行)等数据源上收集数据的能力。Flume的数据接受方,可以是console(控制台)、text(文件)、dfs(HDFS文件)、RPC(Thrift-RPC)和syslogTCP(TCPsyslog日志系统)等。在我们系统中由kafka来接收。Kafka分布式消息队列,支撑系统性能横向扩展,通过增加broker来提高系统的性能。Storm流处理技术,支撑Supervisor横向扩展以提高系统的扩展性和数据处理的实时性。采集架构优势解耦在项目中要平衡数据的汇集与数据的处理性能平衡,是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。冗余有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。在被许多消息队列所采用的“插入-获取-删除”范式中,在把一个消息从队列中删除之前,需要你的处理过程明确的指出该消息已经被处理完毕,确保你的数据被安全的保存直到你使用完毕。扩展性因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的;只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。灵活性&峰值处理能力在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。可恢复性当体系的一部分组件失效,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。送达保证消息队列提供的冗余机制保证了消息能被实际的处理,只要一个进程读取了该队列即可。在此基础上,IronMQ提供了一个”只送达一次”保证。无论有多少进程