数据仓库建设方案

《数据仓库建设方案》由会员分享，可在线阅读，更多相关《数据仓库建设方案（44页珍藏版）》请在金锄头文库上搜索。

1、.第1章 数据仓库建设1.1 数据仓库总体架构专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。根据专家系统数据仓库建设目标，结合系统数据业务规范，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下：数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的内容：精品.数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume及传统的ETL采集工具。数

2、据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。1.2 数据采集专家系统数据仓库数据采集包括两个部分内容：外部数据汇集、内部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；内部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。1.2.1 外部数据汇集专家数据仓库数据源包括列车监控与检测系统

3、（TCMS）、车载子系统等相关子系统，数据采集的内容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，Storm可实现对海量数据的实时处理

4、精品.，及时对问题指标进行预警。具体采集系统技术结构图如下: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 存储设计1.4.1 数据量

10、估算按每列列车平均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年的监测数据，10年内历史

11、监测数据采用NoSQL HBase数据库进行存储，以方便查询，HBase基于Hdfs分布式文件系统搭建，具体存储模式如下图。精品.1. RDBMS数据库，支持专家库的核心业务，存储列车最近1年的监测数据为保证专家系统安全、稳定运行，在数据库系统上支撑各种统计分析及传统的BI业务。考虑到操作系统存储、缓存存储、数据库系统存储、日志存储等因素， RDBMS数据库服务器预计每台60T存储，考虑数据安全及系统稳定因素RDBMS采用双机热备技术互备。2. 大数据平台规划存储最近10年监测数据，日志文件备份及历史数据采用大数据Hadoop和HBase存储，大数据平台数据采用节点间冗余备份，预设数据2倍冗余

12、存储，（考虑平台提供的压缩技术，压缩存储可以节省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，则这封邮件就是垃圾邮件。 聚类算法聚类类似于分类，但与分类的目的不同，是针对数据的相似性和差异性将一组数据分为几个类别。属于同一类别的数据间的相似性很大，但不同类别之间数据的相似性很小，跨类的数据关联性很低。分类算法中的一个显著特征就是训练数据中包含了标签，训练出的模型可以对其他未知数据预测标签。在聚类的算法中，训练数据都是不含标签的，而算法的目的则是通过训练，推测出这些数据的标签。以二维的数据来说，一个数据就包含两个特征，可通过聚类算法，给他们中不同的种类打上标签，通过聚类算法计算出种群中的距离，根据距离的远近将数据划分为多个族群。 关联算法关联规则是隐藏在数据项之间的关联或相互关系，即可以根据一个数据项的出现推导出其他数据项的出现。关联规则的挖掘过程主要包括两个阶段：第一阶段为从海量原始数据中找出所有的高频项目组;第二极端为从这些高频项目组产生关联规则。 推荐算法推荐算法是目前业界非常火的一种算法，在电商界，如亚马逊，天猫，京东等得到了广泛的运用。推荐算法的主要特征就是可以自动向