实时数仓建设方案详细（一）：数据仓库建设（上）

问题导读：
1、数据仓库的总体架构是怎样的？
2、如何进行数据采集？
3、数据是如何进行加工和处理的？

1.1    数据仓库总体架构
专家系统接收增购项目车辆TCMS或其他子系统通过车地通信传输的实时或离线数据，经过一系列综合诊断分析，以各种报表图形或信息推送的形式向用户展示分析结果。针对诊断出的车辆故障将给出专家建议处理措施，为车辆的故障根因修复提供必要的支持。
根据专家系统数据仓库建设目标，结合系统数据业务规，包括数据采集频率、数据采集量等相关因素，设计专家系统数据仓库架构如下：

数据仓库架构从层次结构上分为数据采集、数据存、数据分析、数据服务等几个方面的容：
数据采集：负责从各业务自系统中汇集信息数据，系统支撑Kafka、Storm、Flume及传统的ETL采集工具。
数据存储：本系统提供Hdfs、Hbase及RDBMS相结合的存储模式，支持海量数据的分布式存储。
数据分析：数据仓库体系支持传统的OLAP分析及基于Spark常规机器学习算法。
数据服务总线：数据系统提供数据服务总线服务，实现对数据资源的统一管理和调度，并对外提供数据服务。

1.2    数据采集
专家系统数据仓库数据采集包括两个部分容：外部数据汇集、部各层数据的提取与加载。外部数据汇集是指从TCMS、车载子系统等外部信息系统汇集数据到专家数据仓库的操作型存储层（ODS）；部各层数据的提取与加载是指数据仓库各存储层间的数据提取、转换与加载。
1.2.1    外部数据汇集
专家数据仓库数据源包括列车监控与检测系统（TCMS）、车载子系统等相关子系统，数据采集的容分为实时数据采集和定时数据采集两大类，实时数据采集主要对于各项检测指标数据；非实时采集包括日检修数据等。
根据项目信息汇集要求，列车指标信息采集具有采集数据量大，采集频率高的特点，考虑到系统后期的扩展，因此在数据数据采集方面，要求采集体系支持高吞吐量、高频率、海量数据采集，同时系统应该灵活可配置，可根据业务的需要进行灵活配置横向扩展。
本方案在数据采集架构采用Flume+Kafka+Storm的组合架构，采用Flume和ETL工具作为Kafka的Producer，采用Storm作为Kafka的Consumer，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分布式消息队列，支撑系统性能横向扩展，通过增加broker来提高系统的性能。
Storm流处理技术，支撑Supervisor横向扩展以提高系统的扩展性和数据处理的实时性。
1.2.1.2    采集架构优势
(一)    解耦
在项目中要平衡数据的汇集与数据的处理性能平衡，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

• 冗余

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

• 扩展性

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

• 灵活性 & 峰值处理能力

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

• 可恢复性

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

• 送达保证

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

• 缓冲

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

• 异步通信

很多时候，你不想也不需要立即处理消息。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。

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

1.3    数据加工与处理
对于数据仓库平台，应该建立一套标准化、规化的数据处理流程，例如：如何采集部和外部数据、结构化和非结构化数据；如何清洗采集来的脏数据和无效数据；如何对不同来源的数据进行打通；如何对非结构化的数据进行结构化加工；如何在结构化数据的基础上进行商业建模和数据挖掘等等。
大数据管理层在一条数据总线上构建了一条完整的大数据处理流水线。这条流水线从数据的采集、清洗到加工处理，把原始杂乱无章的数据加工成结构化的数据组件，供上层的大数据应用来拼装调用，让企业拥有创造数据资产的能力。


1.4    存储设计
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年历史监测数据采用NoSQL HBase数据库进行存储，以方便查询，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操作型数据按照主题域划分规则进行的拆分及合并。