选择太多,是一件好事情,不过也容易乱花渐欲迷人眼。倘若每个平台(技术)都去动手操练一下,似乎又太耗时间。通过阅读一些文档,可以帮我们快速做一次筛选。在将选择范围进一步缩小后,接下来就可以结合自己的应用场景去深入Spike,做深度的甄别,这是我做技术选型的一个方法。
技术没有最好,只有最适用。在做技术选型时,需要选择适合需求、适合项目类型、适合团队的技术。这是实用主义的判断,而非理想主义的追捧。若是在实用的技术选型中,再能点燃一些些技术上的情怀,那就perfect了!
属性矩阵(Attributes Matrix)
为了更好地阅读,我将这张图的内容转成如下的矩阵表。由于Ian的文章是2016年撰写的,我对其内容做了适度更新。
表一:流平台的质量属性
流平台
当前版本
主要推动者
Event Size
消息传递保证
状态管理
|
|
|
|
|
|
Flume | 1.8.0 | Apple, Cloudera | single | at least once | 事务型更新 |
NiFi | 1.5.0 | Hortonworks | single | at least once | 本地及分布式快照 |
Gearpump | 0.8.4 | single | Intel, Lightbend | exactly once,若不需要支持容错,则为at least once | checkpoints |
Apex | Apex Core 3.6.0, Apex Malhar 3.8.0 | Data Torrent | single | exactly once | checkpoints |
Kafka Streams | 1.0 | Confluent | single | at least once | 本地及分布式快照 |
Spark Streaming | 2.2.1 | AMPLab, Databricks | micro-batch | exactly once,若不需要支持容错,则为at least once | checkpoints |
Storm | 1.1.1 | Backtype, Twitter | single | at least once | record acknowledgements |
Samza | 0.14.0 | Linkedin | single | at least once | 本地快照,分布式快照则支持容错 |
Flink | 1.4.0 | dataArtisans | single | exactly once | 分布式快照 |
Ignite Streaming | 2.3.0 | GridGain | single | at least once | checkpoints |
Beam | 2.2.0 | Google | single | exactly once | 事务型更新 |
表一(续):流平台的质量属性
流平台
容错
处理顺序
事件的优先级
Windowing
Back-pressure(背压)
|
|
|
|
|
|
Flume | yes(只针对file channel) | no | no | no | no |
NiFi | yes | no | yes | no | yes |
Gearpump | yes | yes | programmable | time-based | yes |
Apex | yes | no | programmable | time-based | yes |
Kafka Streams | yes | yes | programmable | time-based | N/A |
Spark Streaming | yes | no | programmable | time-based | yes |
Storm | yes | yes | programmable | time-based, count-based | yes |
Samza | yes | yes(单分区情况则不支持) | programmable | time-based, count-based | yes |
Flink | yes | yes | programmable | time-based, count-based | yes |
Ignite Streaming | yes | yes | programmable | time-based, count-based | yes |
Beam | yes | yes | programmable | time-based | yes |
表一(再续):流平台的质量属性
流平台
数据抽象
数据流
延迟
资源管理
Auto-scaling
|
|
|
|
|
|
Flume | Event | agent | low | native | no |
NiFi | FlowFile | flow | configurable | native | no |
Gearpump | Message | streaming application | very low | YARN | no |
Apex | Tuple | streaming application | very low | YARN | yes |
Kafka Streams | KafkaStream | process topology | very low | YARN, Mesos, Chef, Puppet, Salt, Kubernetes等 | yes |
Spark Streaming | DStream | application | medium | YARN, Mesos | yes |
Storm | Tuple | topology | very low | YARN, Mesos | no |
Samza | Message | job | low | YARN | no |
Flink | DataStream | streaming dataflow | low(configurable) | YARN | no |
Ignite Streaming | IgniteDataStreamer | job | very low | YARN, Mesos | no |
Beam | PCollection | pipeline | low | integrated | yes |
表一(终):流平台的质量属性
流平台
热修改
API
主要开发语言
API语言
|
|
|
|
|
Flume | no | declarative | Java | text files, Java |
NiFi | yes | compositional | Java | REST(GUI) |
Gearpump | yes | declarative | Scala | Scala, Java |
Apex | yes | declarative | Java | Java |
Kafka Streams | yes | declarative | Java | Java |
Spark Streaming | no | declarative | Scala | Scala, Java, Python |
Storm | yes | compositional | Clojure | Scala, Java, Clojure, Python, Ruby |
Samza | no | compositional | Scala | Java |
Flink | no | declarative | Java | Java, Scala, Python |
Ignite Streaming | no | declarative | Java | Java, .NET, C++ |
Beam | no | declarative | Java | Java |
数据流模型
在进行流数据处理时,必然需要消费上游的数据源,并在处理数据后输出到指定的存储,以待之后的数据分析。站在流数据的角度,无论其对数据的抽象是什么,都可以视为是对消息的生产与消费。这个过程是一个数据流(data flow),那么负责参与其中的设计元素就可以称之为是“数据流模型(Data flow model)”。
不同流处理平台的数据流模型有自己的抽象定义,也提供了内建的支持。我针对Flume、Flink、Storm、Apex以及NiFi的数据流模型作了一个简单的总结。
Flume
Flume的数据流模型是在Agent中由Source、Channel与Sink组成。
内建的Source支持:
Avro
Thrift
JMS
Taildir
Exec
Spooling Directory
Twitter
Kafka
NetCat
Sequence Generator
Syslog
HTTP
内建的Sink支持:
HDFS
Hive
Logger
Avro
Thrift
IRC
File Roll
HBase
Solr
Elasticsearch
Kite Dataset
Kafka
HTTP
Flume还支持自定义Source、Sink与Channel。
Flink
Flink将数据流模型抽象为Connector。Connector将Source与Sink连接起来,一些特殊的connector则只有Source或Sink。Flink定义的connector包括:
Flink也支持用户自定义Connector。
Storm
Storm对数据流模型的抽象则形象地定义为Spout和Bolt。为了支持其他数据源的读取,并将数据存储到指定位置,Storm提供了与诸多外部系统的集成,并针对这些外部系统去定义对应的Spout与Bolt。
Storm集成的外部系统包括:
Kafka:通过BrokerHosts的ZKHosts支持Spout
HBase:提供HBaseBolt
HDFS:提供HdfsBolt
Hive:提供HiveBolt
Solr:提供SolrUpdateBolt与对应的Mapper
Canssandra:提供CassandraWriterBolt
JDBC:提供JdbcInsertBolt与JdbcLookupBolt等
JMS:提供JMS Spout与JMS Bolt
Redis:提供RedisLookupBolt、RedisStoreBolt与RedisFilterBolt等
Event Hubs:提供了Event Hubs Spout
Elasticsearch:提供EsIndexBolt、EsPercolateBolt与EsLookupBolt等
MQTT:MQTT主要用于物联网应用的轻量级发布/订阅协议,提供了对应的Spout
MongoDB:提供了MongoInsertBolt、MongoUpdateBolt
OpenTSDB
Kinesis
Druid
Kestrel
Storm和Storm Trident都支持用户自定义Spout和Bolt。
Apex
Apex将数据流模型称之为Operators,并将其分离出来,放到单独的Apex Malhar中。对于Source,它将其称之为Input Operators,对于Sink,则称为Output Operators,而Comput Operators则负责对流数据的处理。
Apex Malhar支持的Input/Output Operators包括:
文件系统:支持存储到HDFS、S3,也可以存储到NFS和本地文件系统
关系型数据库:支持Oracle、MySQL、Sqlite等
NoSQL数据库:支持HBase、Cassandra、Accumulo、Aerospike、MongoDB和CouchDB
消息系统:支持对Kafka、JMS、ZeroMQ和RabbitMQ消息的读写
通知系统:支持通过SMTP发送通知
内存数据库和缓存:支持Memcached和Redis
社交媒体:支持Twitter
协议:支持HTTP、RSS、Socket、WebSocket、FTP和MQTT
毫无疑问,Apex也支持用户自定义Operator。除了可以用Java编写之外,还可以使用JavaScript、Python、R和Ruby。
NiFi
NiFi对流模型的主要抽象为Processor,并且提供了非常丰富的数据源与数据目标的支持。
常用的数据采集方法包括:
GetFile
GetFtp
GetSFtp
GetJMSQueue
GetJMSTopic
GetHTTP
ListenHTTP
ListenUDP
GetHDFS
ListHDFS / FetchHDFS
FetchS3Objet
GetKafka
GetMongo
GetTwitter
发送数据的方法包括:
PutEmail
PutFile
PutFTP
putSFTP
PutJMS
PutSQL
PutKafka
PutMongo
Nifi也支持用户自定义Processor,例如通过继承NiFi定义的AbstractProcessor类。自定义的Processor可以和内建的Processor一样添加到NiFi定义Flow的GUI上,并对其进行配置。
CIO之家 www.ciozj.com 公众号:imciow