淺析Apache Storm 0.10.0-beta發布：劍指Heron

寫在前面的話

在淺析Storm的發布版本之前，先吐槽一下Storm的版本號。

我是從0.8.0版本開始接觸Storm的，那時候Storm還是推特的開源項目，作為一個Storm的半個老鳥，看到Storm又推出了一個新版本，當然是有些想法的。

從2013年，Apache接手Storm之后版本號的發布繼續延續了以前的風格。說白了就是眾人期望了無數年，版本依然沒有過“1”。

對于這個淺析，不是單純的翻譯，夾雜了很多博客蟲(微信ID:blogchong)個人的看法，當然肯定存在誤差，歡迎指正以及交流。

淺析Storm 0.10.0-beta

//順序按照官網的要點順序，翻譯+個人見解

一、集群安全性以及多用戶調度部署。

我們先把官網列的點列出：

• Kerberos Authentication with Automatic Credential Push and Renewal

• Pluggable Authorization and ACLs

• Multi-Tenant Scheduling with Per-User isolation and configurable resource limits.

• User Impersonation

• SSL Support for Storm UI, Log Viewer, and DRPC (Distributed Remote Procedure Call)

• Secure integration with other Hadoop Projects (such as ZooKeeper, HDFS, HBase, etc.)

• User isolation (Storm topologies run as the user who submitted them)

在早期的Storm設計中，并沒有考慮系統安全性的問題。

其實大部分開源軟件的發展過程都差不多，早期的發展肯定是以功能以及性能為主，在發展到一定階段之后，系統安全才會被加以考慮。如今，隨著Storm的發展，以及當前實時業務需求的上漲，實際的集群部署也越來越多，安全性的需求也越來越高。

這次在安全性的支持方面，除了Storm的社區，雅虎、賽門鐵克還有Hortonworks作出了不小的貢獻。

主要改動點：

• (1)自動更新Kerberos身份驗證機制；

• (2)可插拔的訪問授權以及訪問控制機制；

• (3)支持多用戶調度，并且對于不同用戶可靈活配置資源；//這一點在向資源集中調度方向靠攏

• (4)模擬多用戶調度；

• (5)UI方面的改進，支持SSL協議的日志查看器、DRPC頁面監控；

• (6)優化了與Hadoop生態的集成，主要是安全性方面，包括Zookeeper、Hbase以及HDFS等等；//隨著大數據平臺一體化，Storm的推廣，越來越多的Hadoop生態組件會集成進去

• (7)多用戶的隔離，即每個用戶中允許操作自己提交的拓撲任務；//其實這點跟在引入多用戶的時候，必然是需要支持的

總結：

安全性方面，不多說，博客蟲(微信ID:blogchong)感覺這個點在一般的企業來說，其實優先級是不高的；

重點是對多用戶調度的支持，以及資源管理方面的優化，自從Hadoop2.0以后，資源的集中管理一直是一個熱門方向，所以，Storm在這方面的優化還是值得期待的。

二、版本升級以及持續改進的優化

在過去，升級Storm往往會出現很多問題，涉及到拓撲的變更、拓撲的重新部署等等。究其因，不同版本之間的數據結構往往是有所出入的。所以，升級的過程不是一個完全向下兼容的過程。

從storm 0.10.0開始，版本的升級方面將有很大的優化，甚至是可以在不停止拓撲任務的情況下進行版本升級，整個過程也可以實現自動化。

總結：

隨著Storm的實際部署節點越來越多，必然會面臨版本升級的情況，所以這一點的改進是很重要的，因為其對于用戶后續的持續使用是一個巨大的考驗。

三、任務以及拓撲部署上的改進優化

熟悉Storm的朋友可能知道，對于拓撲任務的部署，往往有任何的拓撲改動，我們都需要進行代碼的重新編譯。如果部署的拓撲規模較大，這將影響很大。

在新改進的方向中，希望通過外部配置文件的形式，去定義拓撲的布局以及相關的配置。

先列上官網改進點：

• Easily configure and deploy Storm topologies (Both Storm core and Micro-batch API) without embedding configuration in your topology code

• Support for existing topology code

• Define Storm Core API (Spouts/Bolts) using a flexible YAML DSL

• YAML DSL support for most Storm components (storm-kafka, storm-hdfs, storm-hbase, etc.)

• Convenient support for multi-lang components

• External property substitution/filtering for easily switching between configurations/environments (similar to Maven-style ${variable.name} substitution)

主要改動點：

• (1)優化拓撲的配置以及部署，在代碼中將拓撲結構相關的東西剝離；

• (2)依然支持現有的拓撲編碼；//向下兼容

• (3)使用靈活的YAML DSL去定義Spout以及Bolt；//說白了，還是在拓撲構建方面進行優化

• (4)依然支持現有的一些接口，比如storm-kafka、storm-hbase、storm-hdfs；//依然是向下兼容，不多說

• (5)多語言組件的支持；//以前雖然號稱支持多語言，其實除了python以及java以外的語言，開發難度還是挺大的

• (6)支持配置環境之間的切換，類似于Maven中${變量名}代替；

總結：

向下兼容的一些東西，咱就不多說了，這是版本升級的理所應當支持的功能；

重點在于拓撲結構的革命性改變，其實我們可以發現，Storm 0.10.0在靈活性使用方面做了很多的該進，包括了這個拓撲結構

四、提供新的分組策略：局部關鍵詞分組

現有的Storm分組策略，在0.8版本到現在一直沒有改變，如今引入了一個新的分組策略：局部關鍵詞分組策略。

局部關鍵詞分組與按字段分組(Grouping)一樣，不同之處在于，其考慮了下游Bolt的負載情況，更好的利用了剩余資源，盡量達到了節點間的負載均衡。

總結：

從這點我們可以發現，Storm的革命性改進除了在靈活性方面，在資源調度方面也是不余余力啊。

五、優化了日志框架

調試分布式程序是一件很困難的事，通常我們會通過一個主要的信息來源去分析，那就是程序產生的日志文件。

但是這同樣會產生矛盾，Storm是實時級別的架構系統，對于日志的記錄層級難以掌控：多了，容易刷爆磁盤；少了，難以發現問題。

在Storm 0.10.0中，使用了log4j v2，這是一個具有更高的吞吐量以及更低的延遲的日志架構。并且更有效的利用資源，對于業務邏輯，我們可以輕松的追蹤到。

同樣，列上E文關鍵點：

• Rolling log files with size, duration, and date-based triggers that are composable

• Dynamic log configuration updates without dropping log messages

• Remote log monitoring and (re)configuration via JMX

• A Syslog/RFC-5424-compliant appender.

• Integration with log aggregators such as syslog-ng

主要關鍵點：

• (1)通過日志文件大小、時間日期組合的方式，觸發日志的滾動；

• (2)動態的修改日志配置，不會丟失日志數據；

• (3)支持日志的遠程監控，以及JMX的遠程配置；

• (4)支持RFC-5424協議；

• (5)Syslog-ng的整合以及支持日志聚合；//未來很有可能使用syslog-ng完全替代syslog，不過需要時間驗證

總結：

日志這一塊的話，其實沒什么多說的地方，現有日志其實也足夠用了，問題不是很大，當然如果有更好的支持優化，肯定是大贊的。

六、支持Hive數據的接入

這個特性將會在0.13中引入，提供數據從Hive接入Storm的API，以及數據Hive落得的API，讓數據從Storm到Hive的流程更加的合理以及方便，一旦數據在源頭被提交，在Hive即可查詢。

實現Storm到Hive的一體化，在微批處理以及事務處理中支持Hive。

總結：

依然是大數據平臺一體化的改進，Storm與Hadoop生態的進一步“合體”。

七、Microsoft Azure Event Hubs的整合

在Azure云計算平臺上支持Storm的部署執行，這個不多說。只能說Storm的影響力越來越大了，很多云平臺已經主動和Storm“聯姻”了。

八、對于Redis的支持

除了Hadoop生態，對于大行其道的Nosql，Storm也開始整合。跟其他組件的支持類似，提供了一些使用案例，同樣是Storm大融合的趨勢。

九、JDBC/RDBMS的整合集成

Storm 0.10.0支持高靈活可定制的集成，幾乎兼容任何類型的JDBC。甚至允許拓撲元組數據與數據庫數據在拓撲進行靈活的交互。

總結：

在Hadoop盛行之前，其實Storm的數據落地方式很單調，其中將Storm處理過后的數據存入數據庫中是一種主流，所以，這一方面的優化可以說解決了很多歷史遺留問題。

十、依賴沖突的優化

直接總結吧：在以往的Storm歷史版本中，其實經常會出現依賴版本沖突的現象。在Storm 0.10.0中，對這方面作了優化。好吧，又是一個歷史遺留問題，說明Storm在進一步規范化。

我們來梳理一下總結

在推特發布Heron后沒幾天，Apache就發布了Storm的0.10.0，不可謂不及時。

也難怪，Heron號稱顛覆性的設計，雖然它暫時沒有開源，雖然Storm已經占據了數據實時處理領域的半壁江山，但是依然危機感十足啊。

OK，還是回到正題，說說我的感想：

(1)大數據平臺統一融合趨勢

我在《DT時代變革的反思》一文中，曾經說到：支撐大數據得以發展的核心是數據平臺。

在Hadoop大規模離線數據處理技術日漸成熟的今天，實時業務的需求逐漸在上升，這也是Storm得以快速發展的原因之一。

實時處理平臺以及我們現在盛行的Hadoop生態平臺，是兩個不同的方向，邏輯上是分離的。

隨著大數據處理的需求多樣化，數據在不同平臺上流通的需求很迫切。

如今，不管是現在版本Storm對Hive的支持、對redis的支持，還是以往中對HDFS、Hbase、Zookeeper的支持等，這都是Storm對于數據平臺一體化做的努力。

在大數據平臺方面，無論是實時處理，還是以Hadoop為代表的批量離線處理或者Nosql存儲等幾個方面，平臺的統一融合將會是一個趨勢。

(2)資源的集中管理

Storm在資源拓撲任務資源分配方面，一直以來都是一個硬傷。隨著Hadoop2.0之后，Hadoop的資源統一交給Yarn管理，在分布式方面基本算是掀起了一股資源管理優化的風潮。

來自博客蟲(www.blogchong.com)。