Kafka，storm，Zookeeper，flume，Dubbo，Spark简介及应用

朱雀 2022-06-16 14:19 136阅读 0赞

Kafka简介：  
  
    Kafka是由LinkedIn开发的一个分布式基于发布/订阅的消息系统，使用Scala编写，它以可水平扩展和高吞吐率而被广泛使用。Kafka是一个消息系统，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。活动流数据是几乎所有站点在对其网站使用情况做报表时都要用到的数据中最常规的部分。活动数据包括页面访问量（Page View）、被查看内容方面的信息以及搜索情况等内容。这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析。运营数据指的3是服务器的性能数据（CPU、IO使用率、请求时间、服务日志等等数据)。运营数据的统计方法种类繁多。  
  
参考地址：http://blog.csdn.net/code52/article/details/50475511  
  
storm简介  
  
storm其实就是做实时流式处理的，而hadoop做的一般是批处理，实时性跟不上。当你需要实时就可以用storm来处理你的数据，当然实时流式计算还有spark之类的可以做。  
  
1：用storm时间滑片统计系统错误，超过设定的警戒值则触发告警，之后再低于警戒值则警告解除  
  
2：用storm统计我司全网用户地理分布，将ip转换为国家代码可以在地图上做出很炫的效果，可以  
     清楚看到世界各地的实时请求。  
3：实时分析用户的行为数据，计算针对用户的实时推荐结果。  
  
链接：https://www.zhihu.com/question/29595489/answer/133069537  
  
  
Zookeeper简介：  
  
Zookeeper是针对大型分布式系统的高可靠的协调系统。由这个定义我们知道zookeeper是个协调系统，作用的对象是分布式系统。为什么分布式系统需要一个协调系统了？理由如下：  
  
　　开发分布式系统是件很困难的事情，其中的困难主要体现在分布式系统的“部分失败”。“部分失败”是指信息在网络的两个节点之间传送时候，如果网络出了故障，发送者无法知道接收者是否收到了这个信息，而且这种故障的原因很复杂，接收者可能在出现网络错误之前已经收到了信息，也可能没有收到，又或接收者的进程死掉了。发送者能够获得真实情况的唯一办法就是重新连接到接收者，询问接收者错误的原因，这就是分布式系统开发里的“部分失败”问题。  
  
　　Zookeeper就是解决分布式系统“部分失败”的框架。Zookeeper不是让分布式系统避免“部分失败”问题，而是让分布式系统当碰到部分失败时候，可以正确的处理此类的问题，让分布式系统能正常的运行。  
  
参考地址：http://blog.csdn.net/clz1314521/article/details/51176208  
  
  
flume简介：  
  
flume是cloudera公司的一款高性能、高可能的分布式日志收集系统。  
  
flume的核心是把数据从数据源收集过来，再送到目的地。为了保证输送一定成功，在送到目的地之前，会先缓存数据，待数据真正到达目的地后，删除自己缓存的数据。  
  
flume传输的数据的基本单位是event，如果是文本文件，通常是一行记录，这也是事务的基本单位。  
  
flume运行的核心是agent。它是一个完整的数据收集工具，含有三个核心组件，分别是source、channel、sink。通过这些组件，event可以从一个地方流向另一个地方，如下图所示。  
  
image  
  
source可以接收外部源发送过来的数据。不同的source，可以接受不同的数据格式。比如有目录池(spooling directory)数据源，可以监控指定文件夹中的新文件变化，如果目录中有文件产生，就会立刻读取其内容。  
  
channel是一个存储地，接收source的输出，直到有sink消费掉channel中的数据。channel中的数据直到进入到下一个channel中或者进入终端才会被删除。当sink写入失败后，可以自动重启，不会造成数据丢失，因此很可靠。  
  
sink会消费channel中的数据，然后送给外部源或者其他source。如数据可以写入到HDFS或者HBase中。  
  
flume允许多个agent连在一起，形成前后相连的多级跳。  
  
应用：  
    Flume+Kafka+Storm+Redis实时分析系统基本架构  
    •基于flume-ng抓取mysql数据到kafka  
    •实战Apache-Flume采集DB数据到kafka  
    •基于Flume+Kafka+Spark-Streaming的实时流式处理完整流程  
    •kafka和flume的对比  
  
    •nginx ----flume -----kafka ---- storm ----- hdfs  
    •日志采集系统比较scribechukwakafkaflume比较  
    •flume+kafka+Druid 流数据查询聚合工具  
    •Flume+Kafka+SparkStreaming整合  
    •flume读取日志数据写入kafka  
  
参考地址：http://www.superwu.cn/2013/12/04/870/  
  
  
  
  
  
Dubbo简介：  
  
Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容，详见后面描述。  
  
背景：  
互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，Dubbo是一个分布式服务框架，在这种情况下诞生的。现在核心业务抽取出来，作为独立的服务，使前端应用能更快速和稳定的响应。大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。  
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。  
此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。  
并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover，降低对F5硬件负载均衡器的依赖，也能减少部分成本。  
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。  
这时，需要自动画出应用间的依赖关系图，以帮助架构师理清理关系。  
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？  
为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。  
其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阀值，记录此时的访问量，再以此访问量乘以机器数反推总容量。  
Dubbo的简介  
  
Dubbo是一个分布式服务框架,解决了上面的所面对的问题，Dubbo的架构如图所示：  
  
节点角色说明：  
  
Provider: 暴露服务的服务提供方。  
  
Consumer: 调用远程服务的服务消费方。  
  
Registry: 服务注册与发现的注册中心。  
  
Monitor: 统计服务的调用次调和调用时间的监控中心。  
  
Container: 服务运行容器。  
  
  
调用关系说明：  
  
0. 服务容器负责启动，加载，运行服务提供者。  
  
1. 服务提供者在启动时，向注册中心注册自己提供的服务。  
  
2. 服务消费者在启动时，向注册中心订阅自己所需的服务。  
  
3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。  
  
4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。  
  
5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。  
  
  
  
 Dubbo提供了很多协议，Dubbo协议、RMI协议、Hessian协议，我们查看Dubbo源代码，有各种协议的实现，如图所示：  
  
我们之前没用Dubbo之前时，大部分都使用Hessian来使用我们服务的暴露和调用，利用HessianProxyFactory调用远程接口。  
  
上面是参考了Dubbo官方网介绍，接下来我们来介绍SpringMVC、Dubbo、Zookeeper整合使用。  
  
参考：http://doc.okbase.net/congcong68/archive/112508.html  
  
  
spark 简介  
  
Spark与Hadoop的对比  
  
    Spark的中间数据放到内存中，对于迭代运算效率更高。  
  
  
Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的抽象概念。  
  
    Spark比Hadoop更通用  
  
  
Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Reduce两种操作。比如map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多种操作类型，Spark把这些操作称为Transformations。同时还提供Count, collect, reduce, lookup, save等多种actions操作。  
这些多种多样的数据集操作类型，给给开发上层应用的用户提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名，物化，控制中间结果的存储、分区等。可以说编程模型比Hadoop更灵活。  
不过由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。  
  
  
    容错性。  
  
  
在分布式数据集计算时通过checkpoint来实现容错，而checkpoint有两种方式，一个是checkpoint data，一个是logging the updates。用户可以控制采用哪种方式来实现容错。  
  
    可用性。  
  
  
Spark通过提供丰富的Scala, Java，Python API及交互式Shell来提高可用性。  
  
Spark与Hadoop的结合  
  
Spark可以直接对HDFS进行数据的读写，同样支持Spark on YARN。Spark可以与MapReduce运行于同集群中，共享存储资源与计算，数据仓库Shark实现上借用Hive，几乎与Hive完全兼容。  
  
Spark的适用场景  
  
Spark是基于内存的迭代计算框架，适用于需要多次操作特定数据集的应用场合。需要反复操作的次数越多，所需读取的数据量越大，受益越大，数据量小但是计算密集度较大的场合，受益就相对较小（大数据库架构中这是是否考虑使用Spark的重要因素）  
由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。  
总的来说Spark的适用面比较广泛且比较通用。  
  
运行模式  
  
本地模式  
Standalone模式  
Mesoes模式  
yarn模式  
  
Spark生态系统  
  
Shark ( Hive on Spark): Shark基本上就是在Spark的框架基础上提供和Hive一样的H iveQL命令接口，为了最大程度的保持和Hive的兼容性，Shark使用了Hive的API来实现query Parsing和 Logic Plan generation，最后的PhysicalPlan execution阶段用Spark代替Hadoop MapReduce。通过配置Shark参数，Shark可以自动在内存中缓存特定的RDD，实现数据重用，进而加快特定数据集的检索。同时，Shark通过UDF用户自定义函数实现特定的数据分析学习算法，使得SQL数据查询和运算分析能结合在一起，最大化RDD的重复使用。  
Spark streaming: 构建在Spark上处理Stream数据的框架，基本的原理是将Stream数据分成小的时间片断（几秒），以类似batch批量处理的方式来处理这小部分数据。Spark Streaming构建在Spark上，一方面是因为Spark的低延迟执行引擎（100ms+）可以用于实时计算，另一方面相比基于Record的其它处理框架（如Storm），RDD数据集更容易做高效的容错处理。此外小批量处理的方式使得它可以同时兼容批量和实时数据处理的逻辑和算法。方便了一些需要历史数据和实时数据联合分析的特定应用场合。  
Bagel: Pregel on Spark，可以用Spark进行图计算，这是个非常有用的小项目。Bagel自带了一个例子，实现了Google的PageRank算法。  
  
参考网址：http://www.cnblogs.com/cxzdy/p/5138756.html