大数据实时计算及可视化相关组件介绍_数据采集组件 大数据 apache

大数据实时计算及可视化相关组件介绍

1.实时数据平台架构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KHp2HTV8-1591611234730)(实时数据采集、分析及可视化.assets/实时数据平台架构.png)]

大数据实时计算平台的支撑技术主要包含7个方面：

• 日志数据实时采集：Flume、Fluentd、Logstash、Scribe等

• 消息中间件：Kafka、RabbitMQ、Active MQ

• 实时数据流计算框架：Spark Streaming、Flink、Storm

• 数据实时存储：列族数据库Hbase、缓存数据库

• 数据持久化：Mysql、Hbase

• Web服务：将数据推送到前端

• 可视化展示（实时数据应用，实时大屏）：DataV（阿里云）、Echarts组件等。

实时计算的典型特征：

• **无边界：**实际的系统运行过程中，随着时间的推移，日志数据以及监控数据是源源不断的在产生的，就像河水一样不停的流过来。

• **触发：**不同于Hadoop离线任务是定时调度触发，流计算任务的每次计算是由源头数据触发的。触发是流计算的一个非常重要的概念，在某些业务场景下，触发消息的逻辑比较复杂，对流计算挑战很大。

• **延迟：**很显然，流计算必须能高效地、迅速地处理数据。不同于Hadoop任务至少以分组甚至小时计的处理延迟，流计算的延迟通常在秒甚至毫秒级，分组级别的延迟只有在特殊情况下才能被接受。

• **历史数据：**Hadoop离线任务如果发现历史某天的数据有问题，通常很容易修复问题而且重运行任务，但是对于流计算任务基本不可能或代价非常大，以为首先实时流消息不会保存很久（一般几天），而且保存历史的完全现场基本不可能，所以实时流计算一般只能从问题发现的时刻修复数据，历史数据是无法通过流式方式来补的。

2 日志数据实时采集

任何完整的大数据平台，一般包括以下的几个过程：

• 数据采集
• 数据存储
• 数据处理
• 数据展现（可视化，报表和监控）

其中，数据采集作为大数据系统体系的第一环节尤为重要。随着大数据越来越被重视，如何有效的正确的收集数据才能最大限度的避免信息孤岛，让数据产出更多的价值，这使得数据采集的挑战变的尤为突出，这其中包括：

• 数据源多种多样

• 数据量大，变化快

• 如何保证数据采集的可靠性的性能

• 如何避免重复数据

• 如何保证数据的质量

下面对当前可用的六款数据采集的产品进行介绍，进行深入了解

2.1 Apache Flume原理简介

Apache Flume 是开源日志系统。作为一个分布式、可靠性和高可用的海量日志聚合系统，它不仅支持在系统中定制各类数据发送方，用于收集数据；而且，也提供对数据进行简单处理，并写到各种数据接收方（可定制）的能力。Flume支持将集群外的日志文件采集并归档到HDFS、HBase、Kafka上，供上层应用对数据分析、清洗数据使用，如下图所示：

下面对Flume 的核心概念进行介绍

• Client：Client生产数据，运行在一个独立的线程。
• Event： 一个数据单元，消息头和消息体组成。（Events可以是日志记录、 avro 对象等。）
• Flow： Event从源点到达目的点的迁移的抽象。
• Agent： 一个独立的Flume进程，包含组件Source、 Channel、 Sink。（Agent使用JVM 运行Flume。每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks）
• Source： 数据收集组件。（source从Client收集数据，传递给Channel）
• Channel： 中转Event的一个临时存储，保存由Source组件传递过来的Event。（Channel连接 sources 和 sinks ，类似于一个队列。）
• Sink： 从Channel中读取并移除Event， 将Event传递到FlowPipeline中的下一个Agent（如果有的话）（Sink从Channel收集数据，运行在一个独立线程）

2.1.1 Agent结构

Flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息。Flume运行的核心是agent，Flume以agent为最小的独立运行单位。它是一个完整的数据收集工具，含有三个组件，分别是source、channel、sink。这些Event由Agent外部的Source生成。通过这些组件，Event可以从一个地方流向另一个地方。
当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。一个 Flume 事件被定义为一个数据流单元。Flume agent 其实是一个 JVM 进程，该进程中包含完成任务所需要的各个组件，其中最核心的三个组件是 Source、Chanel 以及 Slink。

2.1.2 基本概念(Source、Channel、Sink)

• Source

Source负责接收events或通过特殊机制产生events，并将events批量放到一个或多个Channels（Source必须至少和一个channel关联）。有驱动和轮询两种类型的Source：

• 1）驱动型Source：是外部主动发送数据给Flume，驱动Flume接收数据。
• 2）轮询source：是FLume周期性主动去获取数据。

source类型：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GavJl6Ic-1591611234746)(实时数据采集、分析及可视化.assets/Source类型.png)]

• channel

Channel位于Source和Sink之间，Channel的作用类似队列，用于临时缓存进来的events，当Sink成功地将events发送到下一跳的channel或最终目的，events从Channel移除。

不同的Channel提供的持久化水平也是不一样的：

• Memory Channel：不会持久化。消息存放在内存中，提供高吞吐，但提供可靠性；可能丢失数据。
• File Channel：对数据持久化；基于WAL（预写式日志Write-Ahaad Log）实现。但是配置较为麻烦，需要配置数据目录和checkpoint目录；不同的file channel均需要配置一个checkpoint目录。
• JDBC Channel：基于嵌入式Database实现。内置derby数据库，对event进行了持久化，提供高可靠性；可以取代同样持久特性的file channel。

Channels支持事物，提供较弱的顺序保证，可以连接任何数量的Source和Sink。

• Sink
  Sink负责将events传输到下一跳或最终目的，成功完成后将events从channel移除。
  必须作用于一个确切的channel。
  Sink类型：

  

2.1.3 Flume关键特性

• 支持多级级联和多路复制

  Flume支持将多个Flume级联起来，同时级联节点内部支持数据复制。

  这个场景主要应用于：收集FusionInsight集群外上的节点上的日志，并通过多个Flume节点，最终汇聚到集群当中。

• Flume级联消息压缩、加密

  Flume级联节点之间的数据传输支持压缩和加密，提升数据传输效率和安全性。

  在同一个Flume内部进行传输时，不需要加密，为进程内部的数据交换。

  

• Flume数据监控

  Source接收的数据量，Channel缓存的数据量，Sink写入的数据量，这些都可以通过Manager图形化界面呈现出来。

  

• Flume传输可靠性

  

  Flume在传输数据过程中，采用事物管理方式，保证数据传输过程中数据不会丢失，增强了数据传输的可靠性，同时缓存在channel中的数据如果采用了file channel，进程或者节点重启数据不会丢失。

• Flume传输过程中数据过滤
  Flume在传输数据过程中，可以见到的对数据简单过滤、清洗，可以去掉不关心的数据，同时如果需要对复杂的数据过滤，需要用户根据自己的数据特殊性，开发过滤插件，Flume支持第三方过滤插件调用
  

2.2 Fluentd

Fluentd从各方面看都很像Flume，区别是使用Ruby开发，Footprint会小一些，但是也带来了跨平台的问题，并不能支持Windows平台。另外采用JSON统一数据／日志格式是它的另一个特点。相对于Flume，它配置也相对简单一些。

2.3 Logstash

Logstash是一个应用程序日志、事件的传输、处理、管理和搜索的平台。可以用它来统一对应用程序日志进行收集管理，提供了Web接口用于查询和统计。它是著名的开源数据栈ELK （ElasticSearch, Logstash, Kibana）中的那个L，几乎在大部分的情况下ELK作为一个栈是被同时使用的，只有当的数据系统使用ElasticSearch的情况下，logstash才是首选。

2.4 Chukwa

Apache Chukwa是apache旗下另一个开源的数据收集平台，上一次github的更新事7年前，该项目应该已经不活跃了。

2.5 Scribe

Scribe是Facebook开发的数据（日志）收集系统。它能够从各种日志源上收集日志，存储到一个中央存储系统（可以是NFS，分布式文件系统等）上，以便于进行集中统计分析处理。但是已经多年不维护。

2.6 对比分析

Flume，Fluentd是两个被使用较多的产品。如果使用ElasticSearch，Logstash也许是首选，因为ELK栈提供了很好的集成。Chukwa和Scribe由于项目的不活跃，不推荐使用。

3 消息队列

一发一存一消费，没有最好的消息队列中间件(简称消息中间件)，只有最合适的消息中间件。
消息队列常用的使用场景：

• 非实时性：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。主要解决了应用耦合、异步处理、流量削锋等问题。

• 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；（如：订单->库存）

• 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间；(点对多场景，广播场景(注册发短信，发邮件)等等)

• 限流削峰：应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况；(根据服务承受度设置队列大小，超过了就返回活动结束了，咱们经常各大商城秒杀，心里还没有点B数吗)减少压力,避免服务挂掉。

• 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理；(分工处理(各自对应相应的队列)，灵活应用(收到就处理/定时处理))

几种常用的消息队列比较

比较有代表性的就是kafka与rabbitMQ，下面分别对两者进行介绍：

3.1 Kafka原理简介

Kafka是由LinkedIn开发的一个高产出的分布式消息系统(A high-throughput distributed messaging system)，采用Scala编写。它是一个高吞吐、分布式、基于发布订阅的消息系统，同时支持离线和在线日志处理。利用Kafka技术可以在廉价的PC Server上搭建起大规模消息系统。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark、Flink都支持与Kafka集成。

在kafka中根据对消息保存时的Topic，将消息的发布者描述为producer，消息的订阅者描述为consumer，将中间的存储阵列称作broker(代理)，这三者都通过Zookeeper进行协调。

3.1.1 Kafka架构与功能

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S3969YXk-1591611234776)(C:\Users\lee\Desktop\实时数据采集、分析及可视化\Kafka图片\Kafka架构.png)]

基本概念：

• Broker：Kafka集群包含一个或多个服务实例，这些服务实例被称为Broker。是Kafka当中具体处理数据的单元。Kafka支持Broker的水平扩展。一般Broker数据越多，集群的吞吐力就越强。
• Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
• Partition：Kafka将Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件下存储这个Partition的所有消息。
• Producer：负责发布消息到Kafka Broker。
• Consumer：消息消费者，从Kafka Broker读取消息的客户端。
• Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name）。
• ZooKeeper：Kafka与Zookeeper级联，通过Zookeeper管理级联配置，选举Leader。

3.1.2 Kafka的特性

• 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作；
• 可扩展性：kafka集群支持热扩展；
• 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；
• 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）；
• 高并发：支持数千个客户端同时读写；
• 支持实时在线处理和离线处理：可以使用Storm、Spark、Flink等实时流处理系统对消息进行实时进行处理，同时还可以使用Hadoop这种批处理系统进行离线处理；

3.1.3 Kafka应用场景

Kafka和其他组件比较，具有消息持久化、高吞吐、分布式、多客户端支持、实时等特性，适用于离线和在线的消息消费，如常规的消息收集、网站活性跟踪、聚合统计系统运营数据（监控数据）、日志收集等大量数据的互联网服务的数据收集场景。具体应用场景如下：

1. 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如Hadoop、Hbase、Solr等；
2. 消息系统：解耦和生产者和消费者、缓存消息等；
3. 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到Hadoop、数据仓库中做离线分析和挖掘；
4. 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告；
5. 流式处理：比如spark streaming和storm；
6. 事件源；

3.2 rabbitMQ原理简介

采用Erlang语言实现的AMQP协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。RabbitMQ发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。

优点：

• 由于erlang语言的特性，mq性能较好，高并发；
• 健壮、稳定、易用、跨平台、支持多种语言、文档齐全；
• 有消息确认机制和持久化机制，可靠性高；
• 高度可定制的路由；
• 管理界面较丰富，在互联网公司也有较大规模的应用；
• 社区活跃度高；

缺点：

• 尽管结合erlang语言本身的并发优势，性能较好，但是不利于做二次开发和维护；
• 实现了代理架构，意味着消息在发送到客户端之前可以在中央节点上排队。
• 此特性使得RabbitMQ易于使用和部署，但是使得其运行速度较慢，因为中央节点增加了延迟，消息封装后也比较大；
• 需要学习比较复杂的接口和协议，学习和维护成本较高；

3.3 对比分析

应用方面：

• RabbitMQ,遵循AMQP协议，由内在高并发的erlanng语言开发，用在实时的对可靠性要求比较高的消息传递上。
• kafka它主要用于处理活跃的流式数据,大数据量的数据处理上。

架构模型方面：

• RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心；有消息的确认机制。
• kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据；无消息确认机制。

吞吐量：

• rabbitMQ在吞吐量方面稍逊于kafka，他们的出发点不一样，rabbitMQ支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以采用内存或者硬盘。
• kafka具有高的吞吐量，内部采用消息的批量处理，zero-copy机制，数据的存储和获取是本地磁盘顺序批量操作，具有O(1)的复杂度，消息处理的效率很高。

可用性方面：

• rabbitMQ支持miror(镜像)的queue，主queue失效，miror queue接管。
• kafka的broker支持主备模式。

集群负载均衡方面：

• rabbitMQ的负载均衡需要单独的loadbalancer进行支持。

• kafka采用zookeeper对集群中的broker、consumer进行管理，可以注册topic到zookeeper上；通过zookeeper的协调机制，producer保存对应topic的broker信息，可以随机或者轮询发送到broker上；并且producer可以基于语义指定分片，消息发送到broker的某分片上。

总结
Kafka 目前已成为大数据系统在异步和分布式消息之间的最佳选择。

4 纯/准实时计算

4.1 Spark原理简介

Spark最初由美国加州伯克利大学（UCBerkeley）的AMP实验室于2009年开发，Spark是一个基于内存的分布式批处理引擎，可用于构建大型的、低延迟的数据分析应用程序。Spark是一站式解决方案，集批处理、实时流计算、交互式查询、图计算与机器学习与一体。它的架构图如下图所示：

Spark SQL：Spark中用于结构化数据处理的模块。
Structured Streaming：构建在Spark SQL引擎上的流式数据处理引擎。
Spark Streaming：实时计算框架。
Mlib：是用于机器学习的框架
GraphX：图计算
Spark R：R语言分析

4.1.1 Spark特点：

Spark具有如下几个主要特点：

• 运行速度快：使用DAG执行引擎以支持循环数据流与内存计算。
• 容易使用：支持使用Scala、Java、Python和R语言进行编程，可以通过Spark Shell进行交互式编程。
• 通用性：Spark提供了完整而强大的技术栈，包括SQL查询、流式计算、机器学习和图算法组件。
• 运行模式多样：可运行于独立的集群模式中，可运行于Hadoop中，也可运行于Amazon EC2等云环境中，并且可以访问HDFS、Cassandra、HBase、Hive等多种数据源。

4.1.2 Spark适用场景：

• 数据处理,ETL（抽取、转换、加载）
• 机器学习。如：可用于自动判断淘宝买家的评论是好评还是差评。
• 交互式分析：可用于查询Hive数据仓库。
• 特别使用与迭代计算，数据重复利用场景。
• 流计算：流处理可用于页面点击浏览分析，推荐系统，舆情分析等实时业务。

4.1.3 Spark Streaming介绍：

Spark Streaming是Spark核心API的一个扩展，一个实时计算框架。具有可扩展性、高吞吐量、可容错性等特定。

Spark Streaming计算基于DStream，将流式计算分解成一系列短小的批处理作业。Spark引擎将数据生成最终结果数据。使用DStream从Kafka和HDFS等源获取连续的数据流，DStreams由一系列连续的RDD组成，每个RDD包含确定时间间隔的数据，任何对DStreams的操作都转换成对RDD的操作。

4.2 Flink原理简介

Flink是一款分布式、高性能、高可用、高精确的为数据流应用而生的开源流式处理框架。Flink的核心是在数据流上提供数据分发、通信、具备容错的分布式计算。同时，Flink在流处理引擎上提供了批流融合计算能力，以及SQL表达能力。

4.2.1 Flink特点

• Streaming-first、流处理引擎。
• Fault-tolerant，容错，可靠性，checkpoint。
• Scalable，可扩展性，1000节点以上。
• Performance，性能，高吞吐量， 低延迟。

4.2.2 Flink关键特性

• 低延时：提供ms级时延的处理能力。
• Exactly Once：提供异步快照机制，保证所有数据真正处理一次。
• HA：JobManager支持主备模式，保证无单点故障。
• 水平扩展能力：TaskManager支持手动水平扩展。

4.2.3 Hadoop兼容性

• Flink能够支持Yarn，能够从HDFS和HBase中获取数据。
• 能够使用所有的Hadoop的格式化输入和输出。
• 能够使用Hadoop原有的Mappers和Reducers，并且能与FLink的操作混合使用。
• 能够更快的运行Hadoop作业。

4.2.4 Flink 应用场景

Flink最适合的应用场景是低延时的数据处理场景：高并发处理数据，实验毫秒级，且兼具可靠性。
典型应用场景有：

• 互联网金融业务。
• 点击流日志处理。
• 舆情监控。

4.3 对比分析

• Spark Streaming由于其底层的架构（基于批处理做流处理）依然是batch，batch的数据是有边界的，不是真正意义的流式处理，无法实现毫秒级的流计算（只能秒级），因此在追求实时的环境下，仍然需要采用流计算框架（如Storm或者Flink）
• 这几年Flink发展势头迅猛，在国内先是阿里巴巴在17年逐渐将实时处理转移至Flink，然后大量修改并回馈源码，阿里巴巴内部将Flink改为Blink。饿了么，美团也在大量使用Flink。
• Flink 大有替代Spark Streaming的趋势

5 可视化展示（插件介绍）

5.1 Echarts

ECharts 是一个使用 JavaScript 实现的开源可视化库。

特点

• ECharts 由百度研发，遵循 Apache-2.0 开源协议，免费商用

• 基于Canvas，适用于数据量比较大的情况。

• ECharts 兼容当前绝大部分浏览器（IE8/9/10/11，Chrome，Firefox，Safari等）及兼容多种设备，可随时随地任性展示。

• 创新的拖拽重计算、数据视图、值域漫游等特性大大增强了用户体验，赋予了用户对数据进行挖掘、整合的能力。

• 支持折线图（区域图）、柱状图（条状图）、散点图（气泡图）、K线图、饼图（环形图）、雷达图（填充雷达图）、和弦图、力导向布局图、地图、仪表盘、漏斗图、事件河流图等12类图表。

• 提供标题，详情气泡、图例、值域、数据区域、时间轴、工具箱等7个可交互组件，支持多图表、组件的联动和混搭展现。
  

5.2 DataV

DataV 是阿里云出品的拖拽式可视化工具。

特点：

• 收费，不支持二次开发。

• DataV`易于上手，能够满足会议展览、业务监控、风险预警、地理信息分析等多种业务的展示需求。

• 它是开发天猫双11、阿里云城市大脑同款数据可视化应用。

示例

5.3 D3.js

D3 的全称是（Data-Driven Documents），是一个 JavaScript的函数库，主要是用来做数据可视化。
特点

• D3 已经将生成可视化的复杂步骤精简到了几个简单的函数，大大简化了 JavaScript 操作数据的难度
• 本质上是 JavaScript，需要具备一些JavaScript基础，不适合初学者
• 开源免费

5.4 AntV

AntV是蚂蚁金服-体验技术部-数据图形组的开源项目，原名是G2 (The Grammar Of Graphics)

特点

• 收费
• 由纯 JavaScript 编写，集成了大量的统计工具，支持多种坐标系绘制

5.5 对比分析

• 如果希望开发脑海中任意想象到的图表，那就选择 D3.js。
• 如果希望开发几种固定种类的、十分大众化的图表，选择 Echarts等。

6 案例

待更新