选择太多,是一件好事情,不过也容易乱花渐欲迷人眼。倘若每个平台(技术)都去动手操练一下,似乎又太耗时间。通过阅读一些文档,可以帮我们快速做一次筛选。在将选择范围进一步缩小后,接下来就可以结合自己的应用场景去深入Spike,做深度的甄别,这是我做技术选型的一个方法。
技术没有最好,只有最适用。在做技术选型时,需要选择适合需求、适合项目类型、适合团队的技术。这是实用主义的判断,而非理想主义的追捧。若是在实用的技术选型中,再能点燃一些些技术上的情怀,那就perfect了!
我在《Apache下流处理项目巡览》一文中翻译了Janakiram的这篇文章,介绍了Apache基金会下最主流的流处理项目。巧的是,我在InfoQ上又发现了Ian Hellstrom的文章,他用一张图给出了非常棒的总结。
为了更好地阅读,我将这张图的内容转成一张矩阵表。由于Ian的文章是2016年撰写的,我对其内容做了适度更新。
注:由于微信排版关系,若要查看技术选型的矩阵表,请点击文末的“阅读原文”查看详情。
数据流模型
在进行流数据处理时,必然需要消费上游的数据源,并在处理数据后输出到指定的存储,以待之后的数据分析。站在流数据的角度,无论其对数据的抽象是什么,都可以视为是对消息的生产与消费。这个过程是一个数据流(data flow),那么负责参与其中的设计元素就可以称之为是“数据流模型(Data flow model)”。
不同流处理平台的数据流模型有自己的抽象定义,也提供了内建的支持。我针对Flume、Flink、Storm、Apex以及NiFi的数据流模型作了一个简单的总结。
Flume的数据流模型是在Agent中由Source、Channel与Sink组成。
内建的Source支持:
内建的Sink支持:
Flume还支持自定义Source、Sink与Channel。
Flink将数据流模型抽象为Connector。Connector将Source与Sink连接起来,一些特殊的connector则只有Source或Sink。Flink定义的connector包括:
Flink也支持用户自定义Connector。
Storm对数据流模型的抽象则形象地定义为Spout和Bolt。为了支持其他数据源的读取,并将数据存储到指定位置,Storm提供了与诸多外部系统的集成,并针对这些外部系统去定义对应的Spout与Bolt。
Storm集成的外部系统包括:
BrokerHosts
的ZKHosts
支持SpoutHBaseBolt
HdfsBolt
HiveBolt
SolrUpdateBolt
与对应的MapperCassandraWriterBolt
JdbcInsertBolt
与JdbcLookupBolt
等RedisLookupBolt
、RedisStoreBolt
与RedisFilterBolt
等EsIndexBolt
、EsPercolateBolt
与EsLookupBolt
等MongoInsertBolt
、MongoUpdateBolt
Storm和Storm Trident都支持用户自定义Spout和Bolt。
Apex将数据流模型称之为Operators,并将其分离出来,放到单独的Apex Malhar中。对于Source,它将其称之为Input Operators,对于Sink,则称为Output Operators,而Comput Operators则负责对流数据的处理。
Apex Malhar支持的Input/Output Operators包括:
毫无疑问,Apex也支持用户自定义Operator。除了可以用Java编写之外,还可以使用JavaScript、Python、R和Ruby。
NiFi对流模型的主要抽象为Processor,并且提供了非常丰富的数据源与数据目标的支持。
常用的数据采集方法包括:
发送数据的方法包括:
Nifi也支持用户自定义Processor,例如通过继承NiFi定义的AbstractProcessor
类。自定义的Processor可以和内建的Processor一样添加到NiFi定义Flow的GUI上,并对其进行配置。