(工业)大数据
2020-07-03 12:11:10 0 举报AI智能生成
登录查看完整内容
工业大数据知识普及
作者其他创作
大纲/内容
1.概念/原理/工具
大数据定义
特征
Volume(大量)
海量规模
Velocity(高速)
高速流转
Variety(多样)
种类多，维度复杂
Value(低价值密度)
大量、重复、杂乱、非结构化、偏离度高
Veracity(真实性)
从实际情况中获得
价值
经过分类/聚类整理过的数据才有价值
软件技术水平体现在对大数据的加工和使用能力
基本知识
http://cloud.idcquan.com/yjs/115806.shtml
大数据的处理和应用工具
要解决的问题
收集
工业传感器/互联网爬虫等
推送
由分布在网络上的程序推送数据到服务器
拉取
由服务器上的程序主动到网络上下载数据
工具或技术
IOT
爬虫
传输
消息队列
Kafka
基于硬盘的分布式队列
延伸
各种MQ的区别
可靠的分布式日志存储服务
日志是数据库的核心，是对数据库的所有变更的严格有序记录，“表”是变更的结果
了解MYSQL核心概念
可以随时倒带，快进到需要的点从而获取数据
优点
高速写入
流式处理
高可靠性
通过zookeeper做分布式一致性管理
可同步到任意多个磁盘上
自主切换，自主选举主节点
分支主题
高容量
可横向扩展
类似加宽了数据通道
以日志为中心的方法
日志都是相同的
索引各自不同
对标，传统数据库的缺点
慢
不适应持续数据流的处理
不能水平scale
现在的方法
读写分离
一主多备
RabbitMQ
Erlang编写
多协议
AMQP
XMPP
SMTP
STOMP
重量级
Broker构架
较好支持
路由
负载均衡
持久化
Redis？？？
是一个K-V的NoSQL Database
本身也有MQ功能，可轻量级地应用为MQ
多用作缓存
ZeroMQ
并非MQ
不能实现AMQ
号称最快的MQ
能实现高级/复杂队列
需自己组合多种框架
提供非持久性队列
Sotrm中使用其作为数据流传输工具
Apache ActiveMQ
少量代码实现高级应用
以代理人实现点对点技术支持队列
Java优先
MQ的用途
解耦-不同的服务
在生产者和消费者之间搭建通道，实现解耦
储存
海量存储
Hadoop体系的HDFS
对象储存
管理
结构化数据
数据表格
元数据
有固定格式或有限长度的数据
非结构化数据
邮件
文档
不定长或无固定格式的数据
半结构化数据
XML
HTML
可按结构化数据来处理，也可抽取出纯文本按非结构化数据来处理
分析
清洗
AI
机器人
语言识别
图像识别
自然语言处理
专家系统
流程
BI和大数据分析
https://www.sohu.com/a/227887005_487103
检索和挖掘
搜索
海量分析结果，搜索引擎
挖掘
分类
聚类
关系
应用
可视化
预警警报
推荐系统
自动交易
技术
实时处理
批处理
Apache Hadoop
HDFS
分布式文件系统
Ext:硬盘
类似的技术
Hive
YARN
Yet Another Resource Negotiator
充当Hadoop堆栈的集群协调组件
协调并管理底层资源和调度作业的运行
Ext:Windows
MapReduce
Hadoop的原生批处理引擎
MAP
Reduce
Ext：Virtual Studio
工作流程
从HDFS文件系统读取数据集
将数据集拆分成小块并分配给所有可用节点
针对每个节点上的数据子集进行计算(计算的中间态结果会重新写入HDFS)
重新分配中间态结果并按照键进行分组
通过对每个节点计算的结果进行汇总和组合对每个键的值进行“Reducing”
将计算而来的最终结果重新写入 HDFS
体系
HIVE
类SQL，统计分析
不适合实时性要求高的场景
数据仓库
HBase
适合非结构化数据存储
基于列
高可靠性、高性能、面向列、可伸缩的分布式存储系统
Pig
高级过程语言
查询大型半结构化数据集
分布式
flume
海量日志采集
收集数据
新版本Flume-ng
Flume-og已淘汰
适合处理的数据
有界
持久
大量
特点
处理速度慢，耗费时间长，适合离线处理
多次读取和写入
从储存器中读取数据
流处理
Apache Storm
低延迟处理
功能
Stream
持续抵达的数据流
Spout
拓扑边缘的数据流来源，产生待处理数据
Bolt
消耗流数据
对数据进行处理
以流的形式输出结果
拓扑尾部
与每个Spout建立连接
Trident
抽象
为处理提供状态
微批模式代替逐项处理
用途
系统无法智能地处理重复消息时
包含
流批(Stream batch)
操作(Operation)
是指可以对数据执行的批处理过程
能保证至少一次处理
完全实时
Apache Samza
Samza依赖Kafka的语义定义流的处理方式
Topic(话题)：进入Kafka系统的每个数据流可称之为一个话题。话题基本上是一种可供消耗方订阅的，由相关信息组成的数据流。
Partition(分区)：为了将一个话题分散至多个节点，Kafka会将传入的消息划分为多个分区。分区的划分将基于键(Key)进行，这样可以保证包含同一个键的每条消息可以划分至同一个分区。分区的顺序可获得保证。
Broker(代理)：组成Kafka集群的每个节点也叫做代理。
Producer(生成方)：任何向Kafka话题写入数据的组件可以叫做生成方。生成方可提供将话题划分为分区所需的键。
Consumer(消耗方)：任何从Kafka读取话题的组件可叫做消耗方。消耗方需要负责维持有关自己分支的信息，这样即可在失败后知道哪些记录已经被处理过了。
互操作
Storm可以与Hadoop的YARN资源管理器进行集成
无界
实时
小型
实时性要求高
必须对变动或峰值做出响应，且关注一段时间内变化趋势的数据
适用需求Ex：要将大数据处理结果直接提供给访客打开的网站页面
随时进入处理
同一时间只能处理一条或少量
完整数据集只能代表截至目前已经进入到系统中的数据总量
工作数据集也许更相关，在特定时间只能代表某个单一数据项
处理工作是基于事件的，除非明确停止否则没有“尽头”；处理结果立刻可用，并会随着新数据的抵达继续更新
混合处理
Apache Spark
一种包含流处理能力的下一代批处理框架
侧重于通过完善的内存计算和处理优化机制加快批处理工作负载的运行速度
内存中进行也可在磁盘中进行
内存分布数据集
样化工作负载处理任务的最佳选择
准实时
生态链
Shark
类HIVE
SparkR
为R提供轻量级Spark前端的R包
Apache Flink
可以处理批处理任务的流处理框架
Kappa架构
流处理为先的方法
另一种以批处理为先的方法
Lambda架构
处理方式
Stream(流)是指在系统中流转的，永恒不变的无边界数据集
Operator(操作方)是指针对数据流执行操作以产生其他数据流的功能
Source(源)是指数据流进入系统的入口点
Sink(槽)是指数据流离开Flink系统后进入到的位置，槽可以是数据库或到其他系统的连接器
也含有批处理模式
仅是对流处理模型的扩展
模型不再从持续流中读取数据
从持久存储中以流的形式读取有边界的数据集
流处理为先
可提供低延迟，高吞吐率，近乎逐项处理的能力
说明
Apache Hadoop可以看作一种以MapReduce作为默认处理引擎的处理框架。引擎和框架通常可以相互替换或同时使用。例如另一个框架Apache Spark可以纳入Hadoop并取代MapReduce。组件之间的这种互操作性是大数据系统灵活性如此之高的原因之一
数据储存
消息管理
虚拟化管理
OpenStack
计算池化模块Nova
OpenStack的计算虚拟化主要使用KVM，然而到底在那个物理机上开虚拟机呢，这要靠nova-scheduler
网络池化模块Neutron
OpenStack的网络虚拟化主要使用Openvswitch
Neutron可以通过SDN的方式进行配置
每一个Openvswitch的虚拟网络，虚拟网卡，VLAN，带宽的配置
存储池化模块Cinder
将多台机器的硬盘打成一个池
在Ceph层完成调度的过程
Hadoop和Spark
Hadoop
分布式储存
海量数据存储在廉价集群上
Map和Reduce来对持久储存的分布式数据进行批处理式分析
适合超大规模数据储存和离线分析场景
pageRank
Hadoop另一种用法
离线数据ETL
Spark
对持久储存的分布式数据进行处理
对传输而来的数据进行流式出处理
数据对象储存在RDD
弹性分布式数据集
RDD可放在内存上(常见)也可以放在磁盘上
适合迭代运算较多的场景
淘宝
各自有体系
Spark可以依附与Hadoop之上进行数据处理(默认方式)
Spark也可以与其他分布式系统结合
应用场景
批量计算
LogTail + LogHub + LogShipper + OSS + Hive + SparkSQL
批量计算，重在采集
使用LogTail配置好采集规则
通过LogShipper自动投递到OSS
使用Hive直接加载形成数据仓库
在Zeppelin界面上通过SparkSQL直接查询Hive中的数据
整个ETL的过程十分流畅，几乎不用写任何代码
交互式计算
LogTail + LogHub + Storm + HBase + Phoenix
响应时间要求更严格-OLAP业务
以HBase为中心构建OLAP数据库
使用LogTail采集
将LogHub中的数据对接到Storm上
使用Storm进行转换并写入HBase
然后在Zeppelin的界面上使用Phoenix进行查询
实时计算
Servlet + ONS + Spark Streaming + Redis
实时竞价等实时计算业务
利用ONS的超快响应（1ms以内），超大并发的特性
通过Spark Streaming进行计算
最后存储到Redis中
2.技术路线
思路
搭建Apache Spark体系为主，根据实际需求使用Apache Hadoop组件
兼顾流式数据的处理
同时利用大数据处理方法解决海量生产数据收集和传输问题
PLC
工控机
传感器
9.我们能做的
1.初级阶段-BI
解决传统BI的问题
数据量大
性能低
传统大数据架构
BI系统基本思想无变化
进化了技术架构
解决了因数据量、性能导致的问题
缺点
大数据架构缺点（与Cube架构相比）
灵活性低
稳定性低
对报表、钻取需手工定制
业务场景决定，需以批处理为主，无实时性支撑
保留ETL，增加复杂度
1.初级阶段-可视化管理
与大数据处理本身偏离较大
着重应用层面
2.中级阶段-适量利用大数据解决企业实际运作(数据处理方面)过程中的痛点
说明：BI到大数据不能平滑过渡
完全流式处理
数据通道取代ETL
经加工过的数据以消息形式推送给消费者
无ETL，效率高
无批处理，无法支撑历史统计
离线分析只对窗口内数据有效
场景
预警
警报
实时监控
对数据有效性、及时性要求高
数据通道
实时流
离线批处理
实时和离线并重
覆盖常用数据分析场景
需为实时流和离线批处理分别编写处理逻辑
冗余和重复模块多
实时流只能处理当前窗口的信息
Lambda架构的进化版本
不分实时和离线
数据通道以消息队列为主
以流处理为主
数据在数据湖层面存储
需离线或再次计算时，只要重播消息队列即可
解决Lambda架构模块冗余的问题
架构简洁，思想层次高
看着简洁，实施难度高
数据重播部分依赖使用者的水平
Unifield架构
描述
不在以围绕海量数据处理为主
将机器学习和数据处理综合在一起
核心以Lambda架构为主
流处理层上增加了机器学习层
数据进过数据通道，不光使用模型还对模型进行持续训练
为机器学习和数据平台相结合提供了一种架构
架构复杂度高
实施难度巨大
适用于既有大量数据需处理又有大量机器学习的场景
3.建设海量、迅速、高效的现场数据采集通道
自定义传感器
物联网关
4.建立、训练模型
制造管理模型
工艺模型
材料性能模型
5.反哺现场制造和管理过程
提升工艺水平
提升生产效率
改善不良
提升生产组织和管理能力
发现隐藏问题
(工业)大数据
0 条评论
回复 删除
下一页
