数据数据仓库建设方案

数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容

数据采集负责从各业务自系统中汇集信息数据 系统支撑Kafka、 Storm、 Flume

数据存储本系统提供Hdfs、 Hbase及RDBMS相结合的存储模式支持海量数据的分布式存储。

数据分析数据仓库体系支持传统的 OLAP分析及基于Spark常规机器学习算法。

数据服务总线数据系统提供数据服务总线服务实现对数据资源的统一管理和调度并对外提供数据服务。

1 .2数据采集

专家系统数据仓库数据采集包括两个部分内容外部数据汇集、 内部各层数据的提取与加载。外部数据汇集是指从 TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层 ODS 内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。

1.2.1外部数据汇集

专家数据仓库数据源包括列车监控与检测系统 TCMS 、车载子系统等相关子系统数据采集的内容分为实时数据采集和定时数据采集两大类实时数据采集主要对于各项检测指标数据非实时采集包括日检修数据等。

根据项目信息汇集要求列车指标信息采集具有采集数据量大采集频率高的特点考虑到系统后期的扩展因此在数据数据采集方面要求采集体系支持高吞吐量、高频率、海量数据采集同时系统应该灵活可配置可根据业务的需要进行灵活配置横向扩展。

本方案在数据采集架构采用 Flume+Kafka+Storm的组合架构采用Flume和ETL工具作为Kafka的Producer 采用Storm作为Kafka的Consumer Storm可实现对海量数据的实时处理及时对问题指标进行预警。具体采集系统技术结构图如下 :

有些情况下处理数据的过程会失败。 除非数据被持久化否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理通过这一方式规避了数据丢失风险。在被许多消息队列所采用的“插入 -获取-删除”范式中在把一个消息从队列中删除之前需要你的处理过程明确的指出该消息已经被处理完毕确保你的数据被安全的保存直到你使用完毕。

扩展性

因为消息队列解耦了你的处理过程所以增大消息入队和处理的频率是很容易的只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。

灵活性&峰值处理能力

在访问量剧增的情况下应用仍然需要继续发挥作用但是这样的突发流量并不常见如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力而不会因为突发的超负荷的请求而完全崩溃。

可恢复性

当体系的一部分组件失效不会影响到整个系统。消息队列降低了进程间的耦合度所以即使一个处理消息的进程挂掉加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。

送达保证

消息队列提供的冗余机制保证了消息能被实际的处理只要一个进程读取了该队列即可。在此基础上 IronMQ提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据每一个消息只能被处理一次。这之所以成为可能是因为获取一个消息只是”预定”了这个消息暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息否则这个消息会被放回队列中去在一段可配置的时间之后可再次被处理。

缓冲

在任何重要的系统中都会有需要不同的处理时间的元素。 例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行—写入队列的处理会尽可能的快速而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。

异步通信

很多时候你不想也不需要立即处理消息。消息队列提供了异步处理机制

允许你把一个消息放入队列但并不立即处理它。你想向队列中放入多少消

息就放多少然后在你乐意的时候再去处理它们。

1.2.2内部各层数据提取与加载

数据汇集将数据储存于操作型数据存储层 ODS 在数据仓库各层次间数据转换提取加载采用传统的 ETL工具进行采集数据仓库间的各层次的数据采集的实效性根据具体的数据需求而定具体 ETL建模界面如图

1 .3数据加工与处理

对于数据仓库平台应该建立一套标准化、规范化的数据处理流程例如如何采集内部和外部数据、结构化和非结构化数据如何清洗采集来的脏数据和无效数据如何对不同来源的数据进行打通如何对非结构化的数据进行结构化加工如何在结构化数据的基础上进行商业建模和数据挖掘等等。

大数据管理层在一条数据总线上构建了一条完整的大数据处理流水线。这条流水线从数据的采集、清洗到加工处理把原始杂乱无章的数据加工成结构化的数据组件供上层的大数据应用来拼装调用让企业拥有创造数据资产的能力。

1.4.1数据量估算

按每列列车平均500毫秒通过车地通信采集监测数据100条每天运营时间18小时按每条记录160字节计算(监测数据的数据项相对简单) 初步按照67列列车计算。

单列列车日监测数据=3600*2*160*100*18/1024/1024/1024≈2G

67列列车年数据量=2*67*365/1024≈48T

10年总数据量(乘上增长系数10%)≈530T (含操作系统)

数据规划 10年加上系统用户信息、系统日志信息、专家信息、业务数据及其它不可预测类数据数据总量预估 530T。

1.4.2数据存储

专家系统数据采用混合存储模式进行存储 RDBMS存储专家系统业务基本数据及最近1年的监测数据 10年内历史监测数据采用 NoSQLHBase数据库进行存储以方便查询 HBase基于Hdfs分布式文件系统搭建具体存储模式如下图。

1 . RDBMS数据库支持专家库的核心业务存储列车最近 1年的监测数据为保证专家系统安全、稳定运行在数据库系统上支撑各种统计分析及传统的BI业务。考虑到操作系统存储、缓存存储、数据库系统存储、 日志存储等因素 RDBMS数据库服务器预计每台 60T存储考虑数据安全及系统稳定因素RDBMS采用双机热备技术互备。

2. 大数据平台规划存储最近10年监测数据 日志文件备份及历史数据采用大数据Hadoop和HBase存储大数据平台数据采用节点间冗余备份预设数据2倍冗余存储

考虑平台提供的压缩技术压缩存储可以节省30-55%的空间 。

10年数据量=530T*1 .5≈800T (2倍冗余存储)

1.4.3分层存储

专家数据分三个层次进行汇集与存储分别为 ODS层、数据仓库层、主题数据

ODS层数据来源于各生产系统通过ETL工具对接口文件数据进行编码替换和数据清洗转换不做关联操作。未来也可用于准实时数据查询。

数据仓库层数据深度汇集层根据业务有选择的对 ODS层的数据进行提取通过对数据的加工处理将单一的数据信息转换成体系信息将点信息数据变成面信息数据。

主题数据层将数据信息体系根据各主题进行提取与转换主题域内部进行拆分、关联。是对 ODS操作型数据按照主题域划分规则进行的拆分及合并。

1 .5数据分析建模

伴随着大数据时代的悄然来临 ,数据的价值得到人们的广泛认同 ,对数据的重视提到了前所未有的高度。数据已经作为企业、事业单位的重要资产被广泛应用于盈利分析与预测、客户关系管理、合规性监管、运营风险管理等业务当中。 如何建立

图 10-7hadoop算法模型图

大数据平台提供数据挖掘模型、分布式计算引擎、高性能机器学习算法库包含分类、聚类 、预测、推荐等机器学习算法 、即席查询功能可以帮助决策者快速建立数据分析模型立方体便于决策者进行 OLAP分析。

常用算法模型

分类算法

分类是找出数据库中的一组数据对象的共同特点并按照分类模式将其划分为不同的类其目的是通过分类模型将数据库中的数据项映射到某个给定的类别中。如政务网中将用户在一段时间内的网上办理所遇到的问题划分成不同的类根据情况向用户推荐关联类的问题解决方案从而方便用户快速解决网上办事审批中遇到的各类问题。

回归算法

回归分析反映了数据库中数据的属性值的特性通过函数表达数据映射的关系来发现属性值之间的依赖关系。在回归算法中通常将数值结果转化为了 0到1之间的概率数值越大函数越逼近 1 数值越小函数越逼近 0 它可以应用到对数据序列的预测及相关关系的研究中去。如我们根据这个概率可以做垃圾邮件预测