選擇太多，是一件好事情，不過也容易亂花漸欲迷人眼。倘若每個平臺（技術）都去動手操練一下，似乎又太耗時間。通過閱讀一些文件，可以幫我們快速做一次篩選。在將選擇範圍進一步縮小後，接下來就可以結合自己的應用場景去深入Spike，做深度的甄別，這是我做技術選型的一個方法。

技術沒有最好，只有最適用。在做技術選型時，需要選擇適合需求、適合專案型別、適合團隊的技術。這是實用主義的判斷，而非理想主義的追捧。若是在實用的技術選型中，再能點燃一些些技術上的情懷，那就perfect了！

屬性矩陣(Attributes Matrix)

我在《Apache下流處理專案巡覽》一文中翻譯了Janakiram的這篇文章，介紹了Apache基金會下最主流的流處理專案。巧的是，我在InfoQ上又發現了Ian Hellstrom的文章，他用一張圖給出了非常棒的總結。

為了更好地閱讀，我將這張圖的內容轉成一張矩陣表。由於Ian的文章是2016年撰寫的，我對其內容做了適度更新。

注：由於微信排版關係，若要檢視技術選型的矩陣表，請點選文末的“閱讀原文”檢視詳情。

資料流模型

在進行流資料處理時，必然需要消費上游的資料來源，並在處理資料後輸出到指定的儲存，以待之後的資料分析。站在流資料的角度，無論其對資料的抽象是什麼，都可以視為是對訊息的生產與消費。這個過程是一個數據流（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包括：

• Kafka（支援Source/Sink）
• Elasticsearch（僅為Sink）
• HDFS（僅為Sink）
• RabbitMQ（支援Source/Sink）
• Amazon Kinesis Streams（支援Source/Sink）
• Twitter（僅為Source）
• NiFi（支援Sink/Source）
• Cassandra（僅為Sink）
• Redis、Flume和ActiveMQ（僅為Sink）

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上，並對其進行配置。