利用Spark Streaming实现分布式采集系统

简介: 之前我在微信朋友圈发了一段话,说明Spark Streaming 不仅仅是流式计算,也是一类通用的模式,可以让你只关注业务逻辑而无需关注分布式相关的问题而迅速解决业务问题.

前言

前两天我刚在自己的一篇文章中鼓吹数据天生就是流式的,并且指出:
批量计算已经在慢慢退化,未来必然是属于流式计算的,数据的流动必定是由数据自己驱动流转的。
而Spark Streaming 在上层概念上,完美融合了批量计算和流式计算,让他们你中有我,我中有你,这种设计使得Spark Streaming 作为流式计算的一个载体,同时也能作为其他一些需要分布式架构的问题提供解决方案。

Spark Streaming 作为一些分布式任务系统基础的优势

  1. 天然就是分布式的,不用再为实现分布式协调而蛋疼
  2. 基于Task的任务执行机制,可随意控制Task数量
  3. 无需关注机器,是面向资源的,使得部署变得异常简单,申明资源,提交,Over
  4. 集成完善的输入输出,包括HDFS/Kafka/ElasticSearch/HBase/MySQL/Redis 等等,这些都无需自己去搞
  5. 成熟简单的算子让你对数据的处理变得异常简单
  6. StreamingPro 项目让申明式或者复杂的Spark Streaming程序更加简单,同时还可以通过StreamingPro提供的Rest 接口来增强Spark Streaming Driver的交互能力。
现在以标题中的采集系统为例,整个事情你只要实现采集逻辑,至于具体元数据读取,结果存储到哪都可能只要个简单配置或者利用现成的组件,最后部署也只要简单申明下资源就可以在一个可以弹性扩展的集群上。
关于这块的理念,可参考 

开发采集系统的动机

目前这个采集系统主要是为了监控使用。但凡一个公司,或者部门内部会有大量的开源系统,每个开源组件都会提供大致三类输出:
  1. 标准的metrics 输出,方便你集成到gangila等监控系统上
  2. Web UI,比如Spark,Storm,HBase 都提供了自己的Web界面等
  3. Rest 接口,主要是 JSon,XML,字符串

但是对于监控来说,前面两个直观易用,但是也都有比较大的问题:
  1. metrics 直接输出到监控系统,就意味着没办法定制,如果我希望把多个指标放在一块,这个可能就很难做到。
  2. Web UI 则需要人去看了
相反,Rest 接口最为灵活,但是需要自己做写逻辑,比如获取数据,处理,然后做自己的呈现 。问题来了,如果我现在有几千个Rest接口的数据要获取,并且需要一个很方便的手段抽取里面要的值(或者指标)。这便涉及到了两个问题:
  1. 收集的接口可能非常多,如何让收集程序是可很横向扩展的?
  2. 接口返回的数据形态各异,如何提供一个方便一致的模型,让用户简单通过一个配置就可以抽取出里面的内容?

系统处理结构

d835141c5354b37cb24b6da9984d317391699a75
QQ20160529-1@2x.png

  • 采集元数据源,目前存储在ES里
  • 采集系统会定时到ES里获取元数据,并且执行特定的收集逻辑
  • 通过采集系统的一定的算子,将数据格式化,接入Kafka
  • 通过标准(已经存在的)ETL系统完成数据的处理,供后续流程进一步处理

通用信息抽取方案

回到上面的一个问题,
接口返回的数据形态各异,如何提供一个方便一致的模型,让用户简单通过一个配置就可以抽取出里面的内容
Rest 接口返回的数据,无非四种:
  1. HTML
  2. JSON
  3. XML
  4. TEXT
对于1,我们先不探讨。对于JSON,XML 我们可以采用 XPATH,对于TEXT我们可以采用标准的正则或者ETL来进行抽取。
我们在定义一个需要采集的URL时,需要同时配置需要采集的指标以及对应的指标的XPATH路径或者正则。当然也可以交给后端的ETL完成该逻辑。不过我们既然已经基于Spark Streaming做采集系统,自然也可以利用其强大的数据处理功能完成必要的格式化动作。所以我们建议在采集系统直接完成。

采集系统

数据源的一个可能的数据结构:
 appName      采集的应用名称,cluster1,cluster2
 appType       采集的应用类型,storm/zookeeper/yarn 等
 url                需要采集的接口
 params         可能存在例如post请求之类的,需要额外的请求参数
 method         Get/POST/PUT 等请求方法体
 key_search_qps :  $.store.book[0].author   定义需要抽取的指标名称以及在Response 对应的XPATH 路径
 key_.....  可以有更多的XPATH
 key_.....  可以有更多的XPATH
 extraParams  人工填写一些其他参数
采集系统通过我们封装的一个 DInputStream,然后根据batch(调度周期),获取这些数据,之后交给特定的执行逻辑去执行。采用StreamingPro,会是这样:
"RestCatch": {
    "desc": "RestCatch",
    "strategy": "....SparkStreamingStrategy",
    "algorithm": [],
    "ref": [],
    "compositor": [
      {
        "name": "....ESInputCompositor",
        "params": [
          {
            "es.nodes": "....",
            "es.resource": "monitor_rest/rest"
          }
        ]
      },
      {
        "name": ".....RestFetchCompositor",//发起http请求,获取response
        "params": [
          {
            "resultKey": "result",
            "keyPrefix": "key_"
          }
        ]
      },
      {
        "name": "....JSonExtractCompositor",//根据XPath获取response里的指标
        "params": [
          {
            "resultKey": "result",
            "keyPrefix": "key_"
          }
        ]
      },
      {
        "name": ".....ConsoleOutputCompositor",//输出结果
        "params": []
      }
    ],
    "configParams": {
    }
  }
通过上面的配置文件,可以很好看到处理流程。
  1. 输入采集源
  2. 采集结果
  3. 根据XPATH 抽取指标
  4. 输出结果

制作元数据管理系统

元数据管理系统是必要的,他可以方便你添加新的URL监控项。通过StreamingPro,你可以在Spark Streaming 的Driver中添加元数据管理页面,实现对元数据的操作逻辑。我们未来会为 如何通过StreamingPro 给Spark Streaming 添加自定义Rest 接口/Web页面提供更好的教程。

完结了么?

上面其实已经是试下了一个采集系统的雏形,得益于Spark Streaming天然的分布式,以及灵活的算子,我们的系统是足够灵活,并且可横向扩展。
然而你会发现,
  1. 如果我需要每个接口有不同的采集周期该如何?
  2. 如果我要实现更好的容错性如何?
  3. 如何实现更好的动态扩容?
第一个问题很好解决,我们在元数据里定义采集周期,而Spark Streaming的调度周期则设置为最小粒度。
第二个问题容错性属于业务层面的东西,但是如果有Task失败,Spark Streaming也会把你尝试重新调度和重试。我们建议由自己来完成。
第三个,只要开启了 Dynamic Resource Allocation,则能够根据情况,实现资源的伸缩利用。

文/祝威廉(简书作者)
原文链接:http://www.jianshu.com/p/694fda15b304
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。
目录
相关文章
|
1月前
|
消息中间件 分布式计算 NoSQL
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
大数据-104 Spark Streaming Kafka Offset Scala实现Redis管理Offset并更新
40 0
|
1月前
|
消息中间件 存储 分布式计算
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
大数据-103 Spark Streaming Kafka Offset管理详解 Scala自定义Offset
83 0
|
17天前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
69 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
19天前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。
|
10天前
|
分布式计算 流计算 Spark
【赵渝强老师】Spark Streaming中的DStream
本文介绍了Spark Streaming的核心概念DStream,即离散流。DStream通过时间间隔将连续的数据流转换为一系列不连续的RDD,再通过Transformation进行转换,实现流式数据的处理。文中以MyNetworkWordCount程序为例,展示了DStream生成RDD的过程,并附有视频讲解。
|
1月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
48 3
|
1月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
1月前
|
消息中间件 分布式计算 Kafka
大数据-102 Spark Streaming Kafka ReceiveApproach DirectApproach 附带Producer、DStream代码案例
大数据-102 Spark Streaming Kafka ReceiveApproach DirectApproach 附带Producer、DStream代码案例
55 0
|
1月前
|
SQL 分布式计算 大数据
大数据-101 Spark Streaming DStream转换 窗口操作状态 跟踪操作 附带多个案例(一)
大数据-101 Spark Streaming DStream转换 窗口操作状态 跟踪操作 附带多个案例(一)
29 0
|
消息中间件 分布式计算 Kafka
195 Spark Streaming整合Kafka完成网站点击流实时统计
195 Spark Streaming整合Kafka完成网站点击流实时统计
76 0