某公司找我出交通大数据技术方案。我用一周时间完成了从需求调研，到掌握大数据知识点，了解算法知识点，设计方案的整个过程。
该公司生产铁路使用的某种设备。有的设备甚至部署在深山老林中。修复出故障的设备很耗时，在这期间相关的铁路只能暂停使用。如果修复时间过久，他们作为厂家要被上级问询。所以，他们希望做一个大数据平台实现
- 事中实时报警
- 事前故障预测
由事后擦屁股，变成事前处理掉故障。公司也想借机实现从设备提供商向服务提供商的转型。收入模式也从各铁路局一次性收费，延伸到长期收取软件服务费。
以下为方案介绍。
1 项目概况
1.1 项目特点
- 数据并发量大，总量大，保存时间久。400个站点，每个站点80个设备，每秒上传 401 B数据，每秒共12 M 的数据量，每天约 1T 的数据量。 数据要备份多年。
- 安全要求高。部分深山老林的传感器收集到的数据，通过DTU终端使用4G网络传到公司；部分传感器收集到的数据，使用铁路系统有线内网进行传输。需要注意，取有线网传输的数据时，又需要与外网做安全隔离。
1.2 项目目标
- 设备有实时报警功能，图形化展示。
- 有预警功能，提前发现故障隐患，提前处理。
- 设备全生命周期管理。
1. 2.1 安全目标
- 使用有线数据的铁路局N的内网保证安全不受侵害。
- 后台只有公司内网可以访问。
- 完善的权限控制。
- 完整的审计数据。
1. 2.2 数据存储目标
- 数据要及时、完整的存储。
- 数据要长期、可靠的存储。
1. 2.3 前台目标
- 细分化的权限控制，只能看见自己权限内的内容。
- 图形化的方式展示设备逻辑关系。
- 最新数据要实时显示。
- 过去的数据要能统计，报表展示。
1. 2.4 报警目标
- 现在发生的故障，要实时、准确报警。
- 未来可能的故障，要能预警提醒。预测在未来N个火车经过后是否需要会发生故障，预测设备举例下次故障的剩余寿命。
2 方案概况
该项目整体分为两部分：
- 大数据实时分析系统
-
维护平台（含前台、后台，下图绿色部分）
image.png
大数据系统，主要功能有
- 对于400个车站的设备、终端故障的实时报警。
- 设备未来出故障的预测预警（未来N次有火车经过后会出故障，或者未来寿命最多还有N天）。
- 有线、无线网络传输来的设备运行情况的安全、完成的存储。
- 系统本身的运行情况的监督、管理、报警、重启。
维护平台具有良好的用户体验，同时具有下面的主要功能
- 用户权限、身份控制。
- IP 地址的访问控制。
- 设备、车站、故障等信息的数据图表。
- 支持所有统计数据的导出。
- 可以添加天窗，并能按照要求自动重复添加未来的需要的天窗。（天窗指铁路局在维修铁路，此路无法使用）
- 设备、DTU实时报警通知、设备预警报警通知（短信 微信）。
- 浏览器内以拖拽的形式完成室内、室外设备布局的创作，并可以制作模板。
- DTU的配置文件都可以在线增改，并可以制作模板。
- 设备、车辆、路局、故障均采用图形化仿真布局，用彩色化的方式进行差异化展示。
- 设备、终端的后台管理状态查询。
- 平台本身的运行情况的监督、管理、报警、重启。
方案整体具有可视化、图形化、自动化、安全、注重用户体验的特点。
性能上满足每天2T的数据处理能力，满足1000个站机、2000个用户的使用要求，满足查询时间在5秒内的要求。
项目全部基于Linux系统开发。使用Java、Python、HTML、JavaScript、CSS等编程语言，Spring、Layui、Echarts、Ajax等前后端框架，Hadoop、Spark、Flume、Kafka、Storm等大数据框架，和Scikit-Learn、H2O 机器学习框架，还使用了数据压缩技术和VPN加密传输技术。
2.1 大数据实时分析系统
该系统负责故障报警、故障定位。
通过长期的设备运行情况、环境天气的积累，基于大数据的机器学习，完成故障预测。
通过完善的分布式存储和数据备份机制，并完成设备运行数据的实时、完整、安全的存储。
2.1.1 故障报警
- 将有线、无线终端传来的信息，进行实时的、图形化的展示。
- 发现设备、终端故障后，实时进行报警。
2.1.2 故障预测
积累故障数据，通过机器学习和深度学习的方式
- 预测每个设备在N次有火车经过后是否可能有故障。
- 预测每个设备在下次故障前，可以使用的寿命。
2.1.3 数据存储
将所有收到的数据保存N年（N的值需要机器学习完成后进行评估），依赖
- Flume、Kafka、Storm分布式系统完成数据收集、传输、处理。
- Hadoop分布式大数据存储框架，完成数据压缩存储和3重备份。
2.2 维护平台
日常，工作人员主要使用该系统查看系统运营情况，包含以下几项管理功能。
2.2.1 终端状态监测
终端上传设备的管理和工作状态的显示。
2.2.2 天窗计划管理
支持天窗的人工创建和后台上传、自动重新的月份天窗表，并在首页的地图中用特殊颜色区分出来。
2.2.3 数据分类统计
大数据系统中收集到的设备运行数据，在存储到分布式数据库时，同步完成了统计，记录到统计结果表里，在这里展示。这样可以提高统计的速度。
通过权限控制，让不同身份的人看不同的数据。
2.2.4 设备状态监测
DTU终端实时传输过来的设备状态将在这里做图形化的展示，并区分权限，根据用户所在的层级，展示相应的内容。
2.2.5 报警信息提示
故障报警发生后，会有微信、短信、网页闪烁、网页声音提示 的综合通知方式。
2.2.6 故障报警处理
报警信息生成后，状态是“待处理”，可以转成“已处理”，并记录处理人。
如果无人处理，将持续报警，每隔5分钟报警一次。
2.2.7 故障预警处理
仅在平台上有网页闪烁、网页声音提示的通知方式。也可以转成“已处理”，并记录处理人。
2.2.8 人员信息管理
创建工作人员的时候，除了个人信息外，还要输入所属的组织层级、角色。
2.2.9 群组信息管理
可以创建不同的群组，相当于组织架构。
2.2.10 角色信息管理
一个创建不同的角色，每个角色对应了一组权限。
2.2.11 权限信息管理
管理每个权限组的默认权限。也可以单独修改某个用户的权限。
2.2.12 车站信息管理
可以增加、修改路局、电务段、线段。可以管理车站的信息，及车站员工、设备、天窗、终端、DTU、设备的报警信息、选择设备的管理软件。
2.2.13 平台运维管理
用于推送管理软件给终端。可以设置推送时间和版本。
2.2.14 审计日志管理
完整的审计日志，记录所有人对平台的操作。
3 大数据实时分析系统方案
本章节介绍的大数据实时分析系统属于整体逻辑图中的黄色部分。
3.1 整体架构
数据流如图：
image.png
该系统采用经典解决方案：Flume -》Kafka-》Storm-》Redis/Hadoop/MySql。
3.2 方案介绍
先由终端将数据压缩后上传，然后使用Flume去监听数据，并实时把每一条数据信息抓取下来并存进Kafka消息系统中, Kafka持久化存储，接着由Storm系统消费Kafka中的消息。消费过程由Zookeeper集群管理，这样即使Kafka宕机重启后也能找到上次的消费节点，接着从上次宕机点继续从Kafka的Broker中进行消费。接下来就是使用Storm做数据解压缩，把二进制和ASCII文件进行解析，把进行设备信息的实时状态输出到Redis缓存数据库中；把设备运行的统计信息保存到MySql中；保存全部的数据到Hadoop集群中，完成3重备份。最后用Web APP去读取Redis和MySql中的数据，展示给用户。前端使用Ajax实时刷新数据。
可以使用机器学习和人工规则处理Hadoop中的数据，预测可能出故障的设备，并报警。
3.2.1 数据采集
image.png
每个车站内，各路段上传的设备信息保存先在车站内的PC机上，然后由采集数据客户端向外上传。
3.2.1.1 采集数据客户端
在每台装有终端软件的PC机上，安装采集客户端。该客户端具有两个功能
- 上传数据。监控终端收件收集的各路段发送的日志数据的变化，无论是二进制还是ASCII文件，当有变化时，完成数据的压缩上传。通过E2E模式，实现上传失败，可以重复上传直至成功。
- 下载数据。监听无线DTU串口收到的信息，终端软件的客户端是否有新的版本更新或者配置文件的更新。当有更新的时候，会自动下载新的客户端软件和配置文件，下载支持断点续传，节省流量，并不影响日志文件的上传。
日志文件的采集压缩上传，依赖于下面介绍的Flume框架中的 Flume agent 技术。客户端中会集成Flume Agent。后面详细介绍。
无论是二进制还是ASCII文件，文件的每条数据，在设备运行具体信息以外，建议记录
- 客户端版本
- 设备ID
客户端版本实时更新到维护后台，更真实地反应了客户端的现状。
3.2.1.2 终端软件管理
无线网络环境
image.png
- 对于使用无线网络的环境，使用“事件监听模式”监听串口引脚2。为串口注册一个事件监听类，当有新的版本信息和配置文件信息到达串口的时候就会触发下载，在事件的响应方法中读取串口接收到的数据。
- 监听该引脚的进程与上传数据的进程为同一进程。
有线网络环境
- 不需要DTU，和DTU终端管理软件。
- 有线网络的情况下，会穿透VPN来保障内网、外网数据间的安全传输。
- 在搭建VPN的服务器上，维护一张表，就是有线内网中每个终端PC对应的IP和设备编号。根据这个表，准确下发数据。
断点下载
- 在下发DTU终端管理软件时，如果碰到网络故障，可以从已经上传或下载的部分开始继续上传下载未完成的部分，而没有必要从头开始上传下载。用户可以节省时间、提高速度、节约金钱。
- 所谓断点下载，也就是要从文件已经下载的地方开始继续下载。所以在客户端浏览器传给 Web 服务器的时候要多加一条信息 -- 从哪里开始。 断点续传功能最核心的原理就是利用HTTP请求中的两个字段：客户端请求头中的Range，和服务端响应头的Content-Range。
软件替换 - 完整下载后，将解压安装。
- 如果该车站上传的数据中的软件版本字段，与升级计划不符，则将重新安装。
- 如果安装过程中断电，造成软件损坏。一段时间没有日志增加，将触发Flume agent的报警。
3.2.2 DTU的配置
过去的DTU设置无法调整，未来的DTU设置有下面几点需要注意
image.png
- 数据协议采用PROT协议。因为该协议用的TCP协议。而TCP提供可靠的服务。通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保 证可靠交付。
- PROT协议使用心跳包设置。帮助公司知道DTU是否在工作。当没有数据上传，但是DTU有心跳的情况出现时，公司可以知道是设备本身或终端软件或者数据采集客户端的问题。快速排除DTU的问题。
image.png
- 建议将DTU的激活方式设置为“自动激活”。工作在永远在线的状态，随时保持数据传输通道的畅通，及时传输应用数据。
image.png
- 发送数据的目标服务器填写多个。将下面Flume Collector的服务器IP都填写到主备服务器字段，保障在服务器A不好使的情况下，可以发送到服务器B。
以下所有的数据传输，均采用TCP协议。不再赘述。
3.2.3 Flume 集群收集数据方案
Flume是一个分布式的高效的日志采集系统，它能把分布在不同服务器上的海量日志文件数据统一收集到一个集中的存储资源中，Flume是Apache的一个顶级项目。
在Flume中整个系统分为三层：Agent层，Collector层和Store层。Agent层，即采集数据客户端，每个机器部署一个进程，通过Taildir source组件监控日志文件的方式，把新增的日志在压缩后通过DTU或者有线网络发送出去；Collector层负责接收Agent层发送的数据，并且将数据写到Store层，即Kafka集群中。
3.2.3.1 架构设计考虑
可用性
消除系统的单点，提高系统的冗余度。
Agent层
a. 传感器发来的数据先写入磁盘，Agent使用监控文件的方式获得最新的数据。
b. 当Collector变慢或者Agent/Collector网络变慢，Agent将监控到的Events缓存到FileChannel，保存在磁盘上。当Collector恢复正常以后，再将FileChannel中缓存的Events再发送给Collector。
c. 用Supervise进程管理工具监控Agent的进程，如果进程死掉会被系统立即重启。
d.一段时间没有日志增加，将触发Flume agent的报警。
e.为了提高发送数据成功率，Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Best effort（数据发送到接收方后，不会进行确认）。这里采用end-to-end模式，类似断点续传，保障在网速慢或者没有网无法上传数据情况下，可以等网络好时继续完成数据的传输。
Collector层
a. 需要2台Collector机器。有线网络下，Agent访问Collector做了负载均衡和重试机制。无线网络下，做了轮询访问，在某台服务器无法使用时，可以启动访问另一台。所以当某个Collector无法提供服务时，Agent的重试策略会将数据发送到其它可用的Collector上面。
b. 当Collector无法提供服务时，也会有相应的报警。
c. 用Supervise进程管理工具监控Collector的进程，如果进程死掉会被系统立即重启。
d.当Collector一段时间没有收到Agent的数据时，自动报警，告知是Agent的问题。
e. Flume写数据先生成tmp文件，系统会每10分钟左右检查各个Collector是否产生了tmp文件。这样可以及时发现Flume写数据的异常。
可靠性
保证Events的可靠传递。
image.png
a. 对Flume来说，当且仅当Agent的Channel中的Events被保存到下一个Agent的Channel中或者被保存到最终的存储服务中。该Events才会被删除。
image.png
b. 数据流中 Channel的持久性。Flume中提供FileChannel机制，保证数据不丢失。
当堆积在Channel中的Events数小于阈值时，所有的Events被保存在MemoryChannel中，Sink从MemoryChannel中读取数据； 当堆积在Channel中的Events数大于阈值时， 所有的Events被自动存放在FileChannel中，Sink从FileChannel中读取数据。这样当系统正常运行时，系统可以使用MemoryChannel的高吞吐特性；当系统有异常时，可以利用FileChannel的大缓存的特性。
c. 默认不支持断点续传功能。如果agent挂了，等agent的source再次开启的这段时间内，增加的日志内容，就没办法被source读取到了。安装会安装flume的execStream扩展，把增加的日志传送给agent。
可扩展性
当数据量增大时，系统能够以简单的增加机器来达到线性扩容的目的。
a. Agent层、 Collector层、Store层 都可以水平扩展。Agent到Collector有负载均衡机制，调节流量。
上面的报警信息，也是传输到Kafka。
3.2.3.2 数据压缩
Flume agent 在发送数据时，无论是采用DTU还是采用有线网络进行发送，都会使用zlib压缩格式进行压缩。
zlib是一种用来改进网络传输数据量的压缩技术，压缩比率在3到10倍左右，可以节省大量的流量。
Flume agent 的 Avro Sink提供了端到端的批量压缩数据传输。
3.2.3.3 Flume集群部署
除了在原有的终端软件所在的电脑上全部安装的收集客户端外，还需要4台机器部署Flume collector，2台位于有线内网，2台位于机房中。
Flume agent
- 所有路局的每台终端 PC机上，都安装数据收集客户端，Flume agent 集成在客户端内。
Flume collector - 若是在有线内网中，将把两台负责Collector的电脑安装在内网中。互为备份。此时，Agent到Collector使用负载均衡策略，将所有的数据均衡地发到两台collector。
- 若是无线网络，将把两台负责Collector的电脑安装在公司机房中。DTU只能将数据按照初始化时的优先级，先将数据发给A电脑，发送失败时，发给B电脑，互为备份。
3.2.3.4 VPN 加密保护链接内外网络
有线内网的Collector与公司机房之间使用VPN进行连接。并在Collector所在的机器上，安装防火墙，作为防护外部访问的第二道屏障。
VPN全称Virtual Private Network 虚拟专用网络，是在公共网络中建立专用的数据通信网络的技术，可以为企业之间或者个人与企业之间提供安全的数据传输隧道服务。常用于内网和外网之间的通信。
3.2.4 Kafka集群持久化传输数据方案
image.png
Flume collector 收集到的数据，将被发送给Kafaka集群。
Kafka是一种分布式的，高吞吐量的消息系统，基于发布/订阅的消息系统。Kafka起到一个数据缓冲池的作用，类似于Redis，但是更可靠。使用Kafka的原因是：
- 高吞吐量、低延迟：Kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
- 速度快。充分利用Linux系统的I/O提高读写速度，以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。
- 高并发：支持数千个客户端同时读写。
3.2.4.1 设计架构考虑
可用性
保证Kafka一直在传输数据。
a. 某个Kafaka node 没有传输数据，则报警。
b. 用Supervise进程管理工具监控kafaka的进程，如果进程死掉会被系统立即重启。
可靠性
保证数据能传输到下一个集群。
a. 消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。默认保存一周。Kafka充分利用硬盘速度，比如RAID-5 的磁盘阵列上线性写的速度大概是600M/秒，速度满足需求。
b. 能记录数据的消费位置并且用户还可以自定义消息消费的起始位置。断电后，可以继续消费消息。
c. 允许集群中节点失败，会使用其他节点发送数据。
d. Store层的Kafka存储最新的N天（默认为7）数据，并给Storm系统提供实时数据流。
e. 分布式集群，任何节点的宕机和动态扩容都不会影响整个集群的工作运行。
可扩展性。
Kafka 支持在线水平扩展。
3.2.4.2 Kafka集群部署
使用3台主机安装Kafka集群。与Flume Collector公用2台。
注意：为了提高性能，Kafka集群与后面Hadoop集群分开，无法公用。因为Kafka依赖磁盘读写和大的页面缓存，如果和Hadoop共享节点的话会影响其使用页面缓存的性能。
3.2.5 Storm 集群收集实时处理数据方案
image.png
image.png
Storm 是一个分布式的，可靠的，容错的数据流处理系统。它会把工作任务委托给不同类型的组件，每个组件负责处理一项简单特定的任务。
Strom是一个非常快的实时计算框架，官网首页给出的数据是每一个Storm集群上的节点每一秒能处理一百万条数据。
Storm集群任何节点的宕机和动态扩容都不会影响整个集群的工作运行。
在这里，系统把二进制文件和ASCII文件解压，进行数据解析，然后
- 数据字段进行整理。
- 记录故障信息、设备状态、终端状态到对应MySQL表中。
- 完成统计表中的各种统计，记录到对应MySQL中。
- 所有数据存储到Hadoop。
- 发送故障信息、最新的设备、终端状态至Redis。
Storm 集群的输入流由一个被称作 spout 的组件管理，spout 把数据传递给 bolt， bolt 要么把数据保存到某种存储器，要么把数据传递给其它的 bolt。
在Storm的业务处理代码中，使用三个bolt：
a. 将全部的数据传输给Hadoop集群，保留历史数据。
b. 更新每一个设备、终端的最新状态，输出到Redis 和MySQL。
c. 更新统计数据，比如历史数据量、今日数据量，每个传感器的数据量，传入MySQL。
3.2.5.1 设计架构考虑
可用性
保证Storm一直在工作。
a. 某个Storm node 一段时间没有传输数据，则报警。
b. 用Supervise进程管理工具监控Storm的进程，如果进程死掉会被系统立即重启。
可靠性
保证数据能传输到下一个集群。
a. 分布式集群，任何节点的宕机和动态扩容都不会影响整个集群的工作运行。
可扩展性
Storm支持在线水平扩展。
3.2.5.2 Strom的集群部署
Storm和上面的Kafka共用3台机器。
3.2.6 Hadoop 集群存储数据方案
image.png
Hadoop是常见的分布式大数据存储集群，在Hadoop中，HDFS解决了文件分布式存储的问题，MapReduce解决了数据处理分布式计算的问题。
本项目中，在Hadoop上，使用分布式数据库Hbase存储需要的数据。Hbase中数据被分散到多个节点存储，当客户端发起查询请求的时候，集群里面多个节点并行执行查询操作，最后将不同节点的查询结果进行合并返回给客户端。Hbase性能非常高，适合TB级数据的存储。
3.2.6.1设计架构考虑
可用性
保证Hadoop一直在工作
a. 设置两个主节点。
b. 某个主、从节点没有工作，则报警。
c. 用Supervise进程管理工具监控Hadoop的进程，如果进程死掉会被系统立即重启。
d. 每个小时都监控数据大小周同比是否有较大波动，则报警
e. 使用snappy算法进行压缩存入Hbase中的数据，来减少存储空间的占用。snappy算法是Google大数据推荐的压缩算法。
来自《Hbase: The Definitive Guide》中的一个对比：
image.png
可靠性
使用中不出问题
a. 设置3份备份副本，任何节点的宕机和硬盘的损坏都不会影响整个集群的工作运行。3份备份分别存放在本地机架的节点上，同一机架的另一个节点上，和不同机架的节点上。通过数据的冗余存储机制保证数据的高可靠性。
这样可以有以下优点：
- 提高系统可靠性：另外，系统可以通过其他完好的副本对发生错误的副本进行修复，从而提高了系统的容错性。
- 负载均衡：副本可以对系统的负载量进行扩展。多个副本存放在不同的服务器上，可有效的分担工作量，从而将较大的工作量有效的分布在不同的站点上。
- 提高访问效率：将副本创建在访问频度较大的区域，即副本在访问节点的附近，相应减小了其通信开销，从而提高了整体的访问效率。
可扩展性
Hadoop支持在线水平扩展。
3.2.6.2 Hadoop的集群部署
每天的原始数据是1T，压缩后有200M到500M之间。算上2份备份数据，每日需要1T左右的硬盘。每年365T的数据，37块 10T硬盘。建议每月中旬前，准备好下个月的硬盘，完成从节点的部署。
需要2台主节点，N 台从节点，N = 每年365 T * 10年 / 每个从节点的容量。内存在3G以上即可。
3.2.7 Redis缓存方案和MySql长期存储
image.png
Redis 高性能内存数据库，存储Storm传过来的每个传感器的最新数据。这些需要实时更新的数据，不适合保存在硬盘数据库中。
MySql数据库在数据少的时候，具有比Hbase更好的查询性能。适合存储不必实时展示，但是以后可能被经常查询的数据。包含
- 每个传感器的最新状态，比如最近一条数据更新时间。
- Storm计算出的统计数据，比如累计数据量，每个传感器的总数据量，每天的数据量。
- 所有传感器的故障信息。
MySql的数据都在Hadoop中有存储，不必再次备份。
3.2.8 天气数据的采集
天气作为影响设备运行的重要因素，也将被采集。采集来源是和风天气。每天400*24次的数据采集，可以使用他们的免费版本API。数据将被存储到天气中。
3.2.8 数据可视化
image.png
前端实时显示：Redis + SpringMVC + Layui + Echarts + HTML5 + CSS3 + Bootstrap + JavaScript + Ajax；
历史数据查询：Hive on Spark + Hbase；
统计数据展示：MySql；
前端使用以上广泛使用的的成熟框架，保证对打浏览器的兼容性，并充分利用最新的H5 CSS3技术，提高展现的效果。每秒向Redis中读取数据，完成实时数据的刷新。
当查询跨度较大的数据时，Hive on Spark + Hbase 的组合进行查询，比Hive on MapReduce 快百倍。
3.2.9 实时报警
当实时缓存Redis中内出现存在故障的传感器终端和设备，或者发觉可能有故障，会使用微信服务号和阿里大鱼短信向相关人进行报警通知。
3.2.10 机器学习 预测故障发生率
机器学习基本介绍
image.png
这个多项式是最简单的机器学习算法 。
所谓机器学习的过程，类似于解N元方程，已知了很多变量的值和对应的结果，求出参数。再用参数集合未来的变量的值，进行新的计算。
机器学习分为三个步骤
- 1.算法选择
- 2.特征工程
- 3.模型训练
3.2.10.1 算法选择
因为已知了特征以及结果是否有故障，所以这是一个监督学习的场景。将使用通过以下两种方法之一来实现预测：
- 分类：预测在接下来的n个火车经过后是否有可能发生故障。
- 回归：预测在下次故障发生之前的剩余时间。
候选分类算法
- LR算法
- 深度学习
候选回归算法
- 线性回归
- 随机森林
- 岭回归
- Lasso回归
- 深度学习
Scikit-Learn 是Python 中的机器学习框架；H2O是开源的，分布式的，基于内存的，可扩展的机器学习和预测分析框架，适合在企业环境中构建大规模机器学习模型。
我们将分别使用两种框架 ，完成上面的各种算法，分析比较出效果最好的算法，也就是预测结果和真实结果间均方根误差最小的回归算法和准确率、召回率最好的分类算法，当做线上算法。
3.2.10.2 特征工程
特征工程会反复迭代。
数据清洗
a. 特征抽象。将数据转换成算法可以理解的数据，非结构化数据转化为结构化数据，不同格式的数据统一格数。
b. 特征缩放。将变量数据经过处理之后限定到一定的范围之内。可以加快算法收敛的速度。
c. 处理缺失值。删除没有意义且缺失值较多的属性。
特征选择
a. 选出与目标变量相关性较高的特征。找到正常传感器与故障传感器之间有明显区别的特征。（猜测比如出厂时长、使用情况。）我们可以scikit-learn的 Wrapper方法，通过递归特征消除方法筛选出与故障相关性最强的特征，逐步剔除特征。如果存在不相关特征，可能会降低分类的准确率。
b. 去除冗余特征。不同特征之间会互相影响，或受到同根同源，进而影响到统计结果的真实性。可以通过scikit-learn的皮尔森相关性图谱找出冗余特征并将其剔除。去除不相关特征可以简化计算，更体现出问题的因果关系。
c. 对特征的权重进行排序。通过特征重要性排序来挖掘哪些变量是比较重要的，降低学习难度，最终达到优化模型计算的目的。这里，我们采用的是scikit-learn的随机森林算法判定特征的重要性。
3.2.10.3 模型训练
样本不平衡问题
故障数据具有故障数据，无故障数据多的特点，会对模型学习造成困扰。可以采用SMOTE方法解决。SMOET的基本过程是：采样最邻近算法，计算出每个少数类样本的K个近邻，从K个近邻中随机挑选N个样本进行随机线性插值，构造新的少数样本，同时将新样本与原数据合成，产生新的训练集。实现正负样本各50%。
进行训练
构建逻辑回归分类器，产生预测结果。
数据集划分
交叉验证法划分数据集，将数据划分为3部分：训练集、验证集和测试集。让模型在训练集进行学习，在验证集上进行参数调优，最后使用测试集数据评估模型的性能。
参数计算
采用网格搜索调优参数，通过构建参数候选集合，然后网格搜索会穷举各种参数组合，找到最好的那一组设置。
模型评估
第一评估标准：提前发现了多少有故障的传感器。也就是，模型运行一年后，一年内真实故障发生情况比去年同期减少的百分比。
准确率和召回率是一组矛盾的变量。我们认为应该是召回优先，准确率次之。发现有故障去提前修理，甚至多跑几趟；比漏发现故障，影响铁路运行要好。
模型优化
特征和数据决定了机器学习问题的上限，而模型和算法只是尽最大可能地逼近这个上限。
当然如果数据特别少，不太可能做出非常好的结果。不同的算法只是60分到61分的区别。
需要不断的通过真实数据，反复计算，才能优化优化模型。
3.2.10.4 机器学习硬件部署
image.png
需要配置一台专门用于机器学习的机器，这是推荐的配置。
3.3 整体硬件部署方案
和阿里云的BD沟通后，虽然可以打大折扣，但是每年的费用还是很高。最终决定本地存储。
3.3.1 硬件配置
机器A B： 位于铁路内网，安装Flume Collector
- 配置要求是 32G内存、10t HDD硬盘，这样满足将数据缓存7天。
机器C D E：位于机房，安装 Flume Collector、Kafka集群、Zookeeper集群、Storm集群 - 8核cpu 32G内存、10t HDD硬盘
机器F：位于机房， 安装Redis和非大数据分析需要的开发环境（java环境 mvc MySQL） - 8核cpu 32G内存、1t SSD硬盘、 10t HDD硬盘
机器G：位于机房，安装机器学习环境 - 需要的配置较高，具体见 3.2.10.4
其他机器：位于机房，安装Hadoop集群，数量N台。 - 配置要求随意，Hadoop的最大优点就是利用廉价电脑也能做成可靠的分布式存储系。
3.3.2 hadoop扩展
随着数据的增加，可能Hadoop的硬盘数据不足，需要在Hadoop集群中接入新的机器。我们会做一个脚本，实现一键安装，完成配置。你们只要实现物理机器的接入即可。
3.4风险
- 数据风险。由于网络问题，某个Agent无法上传数据，车站内的PC硬盘空间有限，硬盘写满后，存在未数据没有上传就被覆盖或者删除的可能，
- 预测风险。设备故障数据不足，大数据系统无法进行有效的机器学习，影响分析预测的准确性和开发时间。
4 维护平台
image.png
本章节介绍的维护平台系统属于整体逻辑图中的绿色部分。
对方对于功能已经有很详细的想法，本章节主要是补充部分实现细节，和我的新想法。
使用经典的控制层、数据层、展示层三层结构。使用分别是MySQL、Java Spring、Layui/Echarts/Ajax。
4.1 登陆页面
这个地方，我们重点强调安全，从几个方面进行安全防护
- 双因子验证控制，防密码泄露。登录时，需要密码 + 微信登录。微信平台也有使用微信登陆的日志。（微信后台就是这样的登陆设计）
- 被攻击有通知，防暴力破解。输入错误3次密码后，向该用户对应的手机号发短信通知，“连续登陆错误三次，请确认是否本人操作”。
- 登陆状态有效期只有1个小时，超时自动退出登录。
4.2 地图
根据每个访问用户的组织关系、身份角色，展示可以展示的地图。
此处的地图，我们使用百度开源的 ECharts 中的组件作为我们的技术工具。
全国地图中，我们还会采用图形化的方式，在地图中显示各车站此时此刻的天气状况。
4.3 主页
4.3.1 页面布局
页面布局，使用最新的后台框架Layui实现。使用左侧和顶部的导航，实现一键切换。
进行功能操作时，车站的选取方式应简便，易于操作，同时对已选车站应使用cookie的方式进行记录，具有记忆功能，方便操作。
4.3.2 终端状态监测
在大数据系统中，设备、终端的最新数据已经存储到Redis中，还会存储到MySQL中的终端状态表中。因为毕竟内存数据库只起到缓存的作用，空间有限。比如，一个设备一天没有数据了，想看最新数据，Redis中调取不到，就会从MySQL中读取。
4.3.3 天窗计划管理
在MySQL中设置月份天窗计划表。类似于常见的日历应用，可以设置重复规则。
不建议做excle导入。根据经验，人是靠不住的，总是会出问题，excel中写的东西会有会出问题的情况，比如错别字。
4.3.4 数据分类统计
大数据系统中的Storm和Redis中进行统计计算，存储到MySQL的统计结果表里，Java负责对统计结果表进行查询，前端展示页面使用Layui和Ajax作为主要的开发工具。
4.3.4.1 数据统计
历史统计数据从MySQL中的统计表中调取。
由于历史数据数以亿记，查询时当场统计太慢。所以，我们在大数据系统记录设备情况时，已经把需要的统计结果实时统计到专门的统计结果表中。每次查询的时候，不是当场进行计算，而是查询统计结果表，提高查询的速度。
4.3.4.2 数据展示
所有涉及可视化、图形化的地方， 我们使用百度开源的 ECharts 作为我们图形化报表的技术工具。
ECharts，是一个使用 JavaScript 实现的开源可视化库，可以流畅的运行在 PC 和移动设备上，兼容当前绝大部分浏览器（IE8/9/10/11，Chrome，Firefox，Safari等），底层依赖轻量级的矢量图形库 ZRender，提供直观，交互丰富，可高度个性化定制的数据可视化图表。
ECharts 提供了常规的折线图、柱状图、散点图、饼图、K线图，用于统计的盒形图，用于地理数据可视化的地图、热力图、线图，用于关系数据可视化的关系图、treemap、旭日图，多维数据可视化的平行坐标，还有用于 BI 的漏斗图，仪表盘，并且支持图与图之间的混搭。
4.3.5 设备状态监测
我们会在后台上提供一个浏览器内使用的绘图板，工作人员可以在浏览器内像做PPT似的以拖拽的形式，绘画、修改室内和室外的设备布置图，可以在图上标记上设备的位置，关联已经添加好的设备ID即可。这种方式具有灵活性、和可扩展性。
在图中，设备根据Redis中存储的最新状态和当时天窗的情况，显示对应的颜色和提示。
在有车辆经过时，还会如下图一样，动态地显示出火车经过的效果。
image.png
查看车站模拟量曲线时，支持随意拖拽时间范围。所有涉及时间的数据，都支持拖拽时间范围。
image.png
无线方式上传的数据，做到实时上传即可，各种格式、类型的数据互相转换都是很简单的。
通过多级索引提高查询速度。查询历史曲线时，因为历史数据数以亿计，为了提高查询速度，大数据系统会存储数据时，就在Hbase中为设备ID做索引，将设备ID作为查询条件的字段拼接到RowKey中。保障查询日、月、年详细曲线时的响应速度。其他常用查询字段也会做二级索引，来提供查询速度。
4.3.6 故障报警
故障定义：
- 大数据系统实时发现的设备故障。
- 若站机终端为有线连接，若连续 3 秒没有上传数据，则认为终端软件出现异常。
- 若站机终端为无线连接，如果没有开启心跳包，则根据每秒所需上传的设备运行状态数据量来设定数据上传的时间间隔，超过指定的时间间隔还未上传数据，则认为终端软件出现异常；如果有开启心跳包，则根据超过指定的时间间隔还未心跳包，认为终端软件出现异常。
- 大数据系统中Flume集群、Kafka集群、Storm集群报的报警。
报警方式： - 采用微信公众号消息和短信的形式给相关人发送报警信息。并记录到故障信息表。
- 微信中，点击后报警信息后，可以以H5网页的形式给出较详细的故障描述。
- 如果维护平台页面处于打开状态，也会有声音提示和页面闪烁提示。
协作分享： - 通过微信发送给某人的报警通知，他可以方便的分享到微信群中，微信群中的所有人可以不需要登陆就可以查看该报警通知。
- 但是该通知有时效性，已处理后则无法查看详情。
结果通知： - 故障被处理，记录处理信息后，也会给之前收到报警信息所有相关人再发一个已处理的微信通知。
报警统计： - 统计每天、每个人收到的报警短信、钉消息、微信通知的推送次数。
4.3.7 故障预警
大数据系统会从两个维度做预测分析：
- 未来N次火车通过后，设备是否会出故障。
- 该设备未来的寿命是多少。
故障预测： - 当怀疑20次火车通过后会出故障或者寿命短于7天，则认为需要预警。
预警方式： - 发出声光提示。
- 也可以随时选择开通微信或者短信通知
结果通知： - 预警被处理，记录处理信息后，也会给相关人发一个已处理的微信通知。
5 后台管理
公司自己梳理的很清楚了，本章节主要是补充部分实现细节，和我的新想法。
5.1 登录页
后台，从下面几方面做安全保护
- IP限制。只有内网IP可以访问后台，外网只能访问前台。
- 双因子验证控制，防密码泄露和暴力破解。登录时，需要密码 + 微信登录。微信平台也有使用微信登陆的日志。
- 被攻击有通知。输入错误3次密码后，向该用户对应的手机号发短信通知，“连续登陆错误三次，请确认是否本人操作”。
- 登陆状态有效期只有1个小时，超时自动退出登录。
5.2 主页
这里我们的补充的是：
绘图拖拽化
- 我们会为后台提供一个浏览器内使用的绘图板，工作人员可以在浏览器内像做PPT似的以拖拽的形式，绘画、修改室内和室外的设备布置图，可以在图上标记上设备的位置，配置上已经实现添加好的设备ID即可。
配置模板化
- 室内、室外设备的配置，也将在浏览器中在后台直接操作，配置结果保存到数据库。
- 现在设备的配置，可以设定为模板，保存到模板库中。再配置设备的时候，可以直接选择需要的模板，不用重新从零开始设置。不建议上传配置文件，避免人为失误。
- 模板也可以修改、拷贝成新的模板。
终端软件运维
- 软件更新方式在大数据部分介绍了。
通信协议管理
- 也建议使用后台创建，不采用上传的方式，减少失误。
6 系统运维解决方案
对于一个大型复杂系统来说，监控是必不可少的部分。我们会使用听云和Zabbix作为的运维监控工具。实现：
image.png
image.png
代码及数据库监控
- 应用代码、关系型数据库、NoSQL、外部服务和服务器本身的监控
- 分析url调用过程中性能消耗原因,抓取超过阈值url的详细数据
- 支持多种数据库类型的监测，定位并追踪慢SQL语句问题
- 记录错误发生时的详细信息，统计应用错误率，定位问题具体至代码行
- 可以监测所有服务端应用外部调用API的耗时，并进行汇总统计
- 可以实现生产环境下实时在线的线程剖析,可在运行时了解代码性能
- 实时监控Redis等NoSQL数据库的性能问题
服务器监控
- CPU使用率
- 硬盘使用率
- 网络IO
- 内存使用率
- 磁盘IO
实时运维性能警报
- 实时短信和邮件报警
- 自定义警报阈值
- 自定义警报策略
此外，补充Ambari作为Apache的顶级项目，是一个基于Web的工具，主要用来创建、管理、监控Hadoop集群。
image.png
7 性能、安全、接口、安装、可靠性
7.1 性能
支持同时与 500 个站机维护终端进行实时通信
- 按照1000个站机的标准进行开发。
支持 1000 个用户同时在线进行不同的平台操作，互不影响。 - 按照2000个用户的标准进行开发。
用户提交的功能请求响应时间不超过 5s。 - 通过统计数据实时保存到统计表、历史数据增加多级索引，提高查询速速，满足要求。
平台与站机维护终端通信，通信请求的响应时间都不应超过 5s。 - 没有问题，基本在1s内。
平台与单个站机维护终端之间传输 1MB 数据不应超过 6s - 主要取决于终端设备SIM卡的带宽、传输速度。不受后台影响的。
平台日均数据处理能力不小于 1.3TB - 大数据系统处理这些数据没有问题，重要的是硬盘得跟上。
可同时对 500 个车站(80 个区段/车站)进行实时的故障定位、故障风险 预测 - 没有问题。
7.2 安全
系统对可接入终端进行登记，未登记的终端不允许接入
- 将在Kafka集群处，进行管控，忽略未登记的终端传来的数据。
保证用户在平台上进行的任何操作都不会影响平台的正常运转
- 用户的操作会影响设备、终端，但是不会影响平台本身的运转。
防止数据丢失。例如，校正站机维护终端的时钟后，站机上的时间可能会 出现重叠或缺失，从而会影响上传平台的数据。如何避免这种情况的发生。 - 大数据系统在记录数据的时候，如果是某终端传来的两条相邻的完全相同的内容，则合并；
- 如果是某终端同一时刻传来的两条相不完全相同的内容，则按照随机顺序插入到数据库。
无论系统维护人员在什么地方，都能及时收到系统出现异常的安全提示
保证接收报警、预警通知的用户能接收到平台发出的每一条报警、预警
- 我们通过微信和短信的方式，进行通知。如果没有处理，则每过5分钟，再通知一次，直到处理完成。如果需要的话，我们也可以开发语音电话通知。
MySQL数据的定时备份
- 维护平台使用的数据库，即机器F中MySQL，我们每天24点进行自动备份，将数据库从机器F的SSD中备份到HDD中。
7.3 接口
与外部应用和终端的对接，将按照对方的文档进行开发。内部接口将写明文档。
7.4 安装
易于安装使用
- 单机安装简单，但是由于数据量较大，需要分布式系统，每台机器都需要安装相应的软件，总体还是有一定的工作量。
需配详细的安装配置说明文档 - 将提供完整的文档。
安装环境依赖较少 - 主要依赖于hadoop相关的大数据环境。
7.5 可靠性
具备应对各种网络异常的相关措施
- 内部网络异常时，因为Flume和Kafka 在传输数据时，都有记忆功能，可以在恢复网络时，继续传输。
- 外部网络异常时，如果终端有断点传输功能，Flume则可以继续收到数据；如果终端没有断点传输功能，则会损失部分数据。
具备应对各种功能异常的相关措施，避免因功能异常而导致系统不能正常 使用的情况发生
- 通过上面的运维系统，跟踪系统的内存、cpu、硬盘运行情况，不足或出现问题会报警。
- 数据有3份备份，机器故障不影响大数据系统工作。
- 重启服务器时，相关进程自动开启。
平台与站机维护终端之间通信数据丢包率不应超过 0.2%。
- 我们能保证全部接收。传输中，是否会丢包需要靠DTU服务商来解决。
系统上电自启
- 相关进程全部开机自启。
系统断电后，未完成处理的数据不丢失，恢复供电后，仍能继续处理。 - 断电时，进入Flume、Kafka、Storm，但是没有存储到Hbase的数据，会继续处理。但是没有进入Flume的数据是否会继续处理，需要取决于DTU是否有断点续传功能。
系统异常时，向系统维护人员发出异常告警短信 - 我们的运维系统跟踪系统的内存、cpu、硬盘运行情况，不足或出现问题会报警。
系统异常退出或崩溃后，在 60s 内恢复正常 - 系统将奔溃后自动重启，60秒内完成重启。
对于数据异常、功能异常、用户操作，系统提供可追溯日志查询。 - 所有用户的操作将记录审计日志，保证可以追溯。所有系统的运行记录日志将保存一周。
7.5 可用性
MTBF 大于 50000 小时
- 可以满足。出故障后，维护期内，我们会即时响应，48小时内解决。
7.6 可维护性
程序结构清晰，易于分析
- 基本要求。
程序易于修改 - 前端代码可以随意修改。
修改系统局部功能后，程序的稳定性不易受到影响 - 改动非核心部分，不易受影响。
程序易于测试 - 我们基于用户工作场景进行交互设计，注重用户体验，便于测试。
8 建议
8.1 大数据系统尽量多地收集数据
包括不限于温度、压力、振动。
8.2 可以建立生产大数据平台
生产中建立实时激光测量、等设备质量监控体系，并将这些数据统一汇总到后台中。
实现实时的统计、报警。
8.3 可以建立生产管理平台&App
电子化地跟踪销售订单、工人流转、采购物料、订单出库流程。实现：
- 任务工序可以创建成流转模板。
- 销售人员在APP上登记自己的订单。
- 订单被领导审核通过后，自动生成工作任务分配给生产负责人。
- 生产负责人选择好流转模板和每个环节负责人后自动开始流转。
- 工作流转中，每个任务的开始、截止时间前后有提醒。
- 工作流转中，每个人手动更新工作状态，通过上级审核后，进入下一个工作环节，自动提醒下一个环节的负责人。
- 任务中可以上传设计图、讨论。
- 生产完成，每个成品或者成品的箱子上打印二维码，出入库工作人员扫码登记。
- 采购人员可以根据工作任务模板中需要的物料进行采购。
- 库存中某个原料不足的时候，可以自动提醒采购人员。
整个流程，可以使用图表化的方式查看。方便管理、统计、监督、溯源、分析。
参考文献：
四信DTU使用文档 http://www.four-faith.com/uploadfile/2017/1130/20171130114203171.pdf
断点续传代码 https://www.ibm.com/developerworks/cn/java/joy-down/index.html
内网穿透VPN搭建 https://www.dbooodb.com/2016/09/28/Through-the-network-of-vpn/
Flume日志收集 详细介绍 https://www.cnblogs.com/oubo/archive/2012/05/25/2517751.html
美团使用fluem经验 https://tech.meituan.com/mt_log_system_arch.html
flume数据压缩 https://www.jianshu.com/p/1183139ed3a0
Hadoop、Spark、HBase与Redis的适用性讨论（全文）http://blog.51cto.com/datainsight/1426538
七牛是如何搞定每天500亿条日志的
https://blog.qiniu.com/archives/3928
猎聘日志方案 https://juejin.im/entry/5720397871cfe4006b2d5d82 三台机器搭建系统
Scikit-Learn Python 中的机器学习 http://sklearn.apachecn.org/
NASA机器学习技术之预测性维护 ！！ http://www.infoq.com/cn/articles/machine-learning-techniques-predictive-maintenance?utm_source=articles_about_Database&utm_medium=link&utm_campaign=Database
雅虎大规模时间序列数据自动异常检测架构 https://blog.csdn.net/justAStriver/article/details/76861532
结合Scikit-learn介绍几种常用的特征选择方法 https://www.cnblogs.com/hhh5460/p/5186226.html
TensorFlow的逻辑回归实现 https://blog.csdn.net/Gamer_gyt/article/details/80115299
TensorFlow之逻辑回归 http://suanfazu.com/t/tensorflow/13215
【机器学习算法实现】logistic回归__基于Python和Numpy函数库 https://blog.csdn.net/u012162613/article/details/41844495
百度智能磁盘故障预测 http://forum.huawei.com/enterprise/zh/thread-446957.html
基于多维时间序列的数控机床状态预测方法研究 http://jsuese.cnjournals.com/html/2018/1/201700435.html
机器学习 逻辑回归 做 金融诈骗预测 https://zhuanlan.zhihu.com/BecomingaDataScientist
Zabbix 3.0 从入门到精通(zabbix使用详解) https://www.cnblogs.com/clsn/p/7885990.html#auto_id_25
工作后，第一次出技术为主的方案，还算顺利。网络上资料如何丰富，学习能力跟得上就够了。
网友评论