常见分布式基础设施系统设计图解(七):分布式实时流处理系统

今天这篇是关于实时流处理(real-time stream processing)的,这一类的系统这几年比较多了,但相对而言并没有之前提到的几类基础设施系统常见。为什么说这类系统如今更为常见呢?因为一般说来,或者说曾经有一个普遍的认知,就是 throughput 和 latency 难以兼得的事实:

  • 同步系统适用于响应实时性要求高的请求,处理实时性要求高的数据,速度快,处理过程中关注的数据粒度小,吞吐量也相对受限;
  • 异步系统适用于响应实时性要求低的请求,处理实时性要求低的数据,处理过程中关注的数据粒度大,但是吞吐量往往要大得多。

可是,越来越多的系统需要大量的数据处理,往往需要上面二者 “鱼和熊掌兼得”,或者说,至少能够达成一个很好的平衡。分布式实时流处理系统就是这样的一个典型。

总的来说,流处理系统,都可以视作从一个基于消息队列的 pub-sub 系统演进而来的。实际应用方面,其实有很多例子。比如实时的数据分析,带有机器学习的日志分析。通用框架的话,像 Apache Storm 和 Spark Streaming 都属于这一大类。

  • 上面这张图简单表示了其中的一种典型的组件分布,上半部分属于实时性高的 streaming processing,而下半部分则是 batch processing。
  • 从左往右看,最左边是数据源部分。用户通过不同的渠道访问产生了相应的数据,有一些是直接来自用户的操作数据,有一些是日志数据,还有一些来自其他 feed system 的数据。
  • 这些数据通过不同方式收集,比如 Data Ingestor 用于集成到系统中去实时地获取数据,它可以是以被动的被调用的方式来收集数据,数据被即时发送到一个队列中;也可以以一个 agent 的形式在宿主机上工作,异步地完成数据收集(图中的 log 上传到某分布式文件系统中)的过程。
  • 之后是数据处理的步骤,如果是 Real-time Processor,那就是即时处理的,当然,可以有多个这样的组件,通过 data stream 的方式连接起来;如果是 Batch Processor,那就是定时、批量处理的。
  • 再就是数据存储部分,值得注意的是,某些实时数据处理可能跳过这一步,直接和再右边的 Consuming System 连接起来——这其实就是系统之间的耦合方式,可以通过数据流的形式耦合(包括简单 API 的形式),也可以通过 data store 来耦合,前者的实时性更高。
  • 最右边是下游系统,比如日志分析的 UI,比如数据监控系统,比如报表系统等等。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

167 次阅读

Leave a Reply

Your email address will not be published.

back to top