⑴ storm好像比Hadoop好用多了，現在有哪些平台在用
在Storm開源之前，由於Hadoop的數據處理能力，讓整個業界為之瘋狂。不過，Hadoop的缺點也逐漸暴露，運行起來延遲、緩慢，程序復雜。有需求自然就有創造，在業界不斷探尋更高效的計算系統時，Storm橫空出世。
Storm是一個分布式的、容錯的實時計算系統，可用於：實時分析、在線機器學習、連續計算。快速可靠、運維簡單、高度容錯、無數據丟失、多語言等等，這些優點足以讓業內雀躍。
目前，storm被廣泛應用於實時分析，那麼國內哪家公司將storm運用的比較好呢？
一．分析更快速
基於Storm實時框架進行二次開發，布爾財經實現了適合產品級推薦引擎的實時分析系統，保證每步分析在50ms內完成，單篇文章抓取結束後在秒級以內即可完成全部分析、並實現個性化推薦，推送到適合的人群面前。
布爾財經結合大數據的實施流式框架，這種增量學習可以在毫秒級別完成，相比其他使用推薦引擎的競爭對手還處在日級別的更新速度，有了數量級上的絕對優勢。
二．分析更全面
在storm框架基礎上，布爾財經進行了更精細的擴展。可以看到，布爾財經APP上每一篇文章後都有相關股票、個股熱度、情感傾向等模塊。用戶在閱讀完每一篇文章後，無須過多操作，就能獲取更多准確信息。也就是說，較其他軟體，布爾財經的用戶在相同時間內獲取最快最多最全的資訊。
三．與NLP語義模型完美結合
布爾財經是昊讀數據基於十數年的非結構化大數據&NLP數據、演算法積累所研發出的專業投資工具。將NLP語義模型應用在storm上的研發公司，在量化投資界，也算是屈指可數，布爾財經正是該模式的領航者。
而NLP中的多因子模型類型更全、維度更廣。二者的完美結合讓投資者能夠在布爾財經獲取更快、更准、更真實的數據。
⑵ 下面哪些是storm計算模型的使用場景
Storm是一個分布式的、可靠的、容錯的數據流處理系統（流式計算框架，可以和maprece的離線計算框架對比理解）。整個任務被委派給不同的組件，每個組件負責一個簡單的特定的處理任務。Storm集群的輸入流是一個叫spout的組件負責接入處理。spout把數據傳給bolt組件，bolt組件可以對數據完成某種轉化。bolt組件可以把數據持久化，或者傳送到其他的bolt。可以把Storm集群想像成一個bolt組件鏈，每個組件負責對spout流入的數據（也可以是其他bolt流入的數據）進行某種形式的處理。
有個簡單的例子可以說明這個概念。昨晚我看新聞，節目中發言人在談論政治家以及他們在不用領域的立場。他們不停地在重復一些不同的名字，這時我想知道他們提到的每個名字出現的次數是否一樣，還是在某些名字被提及次數更多。
把發言人的言語想像成數據的輸入流。我們可以定義一個spout從文件（通過socket、HTTP或者其他方式）讀取這些輸入。當幾行文本到來時，spout把它們傳送給bolt，bolt負責把文本分詞。接著數據流被傳送到另外一個bolt，這個bolt負責在一個已經定義好的政治家名單進行比對。如果匹配到了，將資料庫中對應的名字的計數加1。任何時候你想看結果，只要從資料庫中查詢就可以，因為當數據到達時整個過程都是實時更新的。這過程中所有的組件（spout和bolt）以及他們之間的連接被稱為拓撲（topology）（見圖表 1-1）。
現在很容易想像定義每個bolt和spout並行度，這樣可以無限地擴展整個拓撲。很神奇，對吧？盡管前面講的只是一個簡單的例子，不過你大概已經隱約感覺到Storm的強大了。
那麼，Storm適用什麼應用場景呢？
數據流處理：正如上述的例子，Storm不像其他流處理系統，因為Storm不需要中間隊列。
持續計算：持續地向客戶端發送數據，它們可以實時的更新以及展現數據，比如網站指標。
分布式遠程過程調用：輕松地並行化CPU密集型操作。
（補充）從業務場景上，舉例說明Storm的可以處理的具體業務（這部分是黃崇遠總結的，覺得比較全面，摘抄在此）
條件過濾：這是Storm最基本的處理方式，對符合條件的數據進行實時過濾，將符合條件的數據保存下來，這種實時查詢的業務需求再實際應用中很常見。
中間計算：我們需要改變數據中某一個欄位（例如是數值），我們需要利用一個中間值經過計算（值比較、求和、求平均等等）後改變該值，然後將數據重新輸出。
求TopN：相信大家對TopN類的業務需求也比較熟悉，在規定時間窗口內，統計數據出現的TopN，該類處理在購物及電商業務需求中，比較常見。
推薦系統：有時候在實時處理時會從mysql及hadoop中獲取資料庫中的信息，例如在電影推薦系統中，傳入數據為：用戶當前點播電影信息，從資料庫中獲取的是該用戶之前的一些點播電影信息統計，例如點播最多的電影類型、最近點播的電影類型，及其社交關系中點播信息，結合本次點擊及從資料庫中獲取的信息，生成推薦數據，推薦給該用戶。並且該次點擊記錄將會更新其資料庫中的參考信息，這樣就是實現了簡單的智能推薦。
分布式RPC：Storm有對RPC進行專門的設計，分布式RPC用於對Storm上大量的函數進行並行計算，最後將結果返回給客戶端。
批處理：所謂批處理就是數據積攢到一定觸發條件，就批量輸出，所謂的觸發條件類似事件窗口到了，統計數量夠了即檢測到某種數據傳入等等。
熱度統計：熱度統計實現依賴於Storm提供的TimeCacheMap數據結構，現在可能推薦用RotatingMap，關於這兩個數據結構的源碼分析，移步Storm TimeCacheMap RotatingMap源碼分析，該結構能夠在內存中保存近期活躍的對象。我們可以使用它來實現例如論壇中熱帖排行計算等。
⑶ Storm入門容易嗎
Storm有很多應用場景，如實時分析、在線機器學習、持續計算、分布式RPC、ETL，等等。具體的還是去知數學院系統學習更好。
⑷ 有了spark的streaming，還有必要學習storm嗎
你再把它和hadoop比較快慢。
兩個框架都用於處理大量數據的並行計算。
所以這是把過程傳遞給數據,metaQ、hadoop：Hadoop使用磁碟作為中間交換的介質.容錯性，再小的話hdfs上會一堆小文件），而是比較的吞吐了，在於rece任務通過網路拖過去運算：
1，只需實現一個簡單的Storm通信協議即可，數據直接通過網路導入內存，產生一行就通過一個傳輸系統發給流式計算系統。Storm保證每個消息至少能得到一次完整處理、多份復制等。二者在延時和吞吐上沒太大區別。但是吞吐也低於maprece，可以在處理過程中完全模擬Storm集群，基於流，facebook的puma就是基於hadoop做的流計算系統。而maprece一般需要整個運算結束後將結果批量導入到結果集中，而storm的數據是一直在內存中流轉的，目前典型的處理處理策略，盡管並非完全一樣。類似於MapRece降低了並行批處理復雜性，資料庫，Hadoop可以看作是純凈水.Storm為什麼被稱之為流式計算系統
3；而Storm是用水管、Ruby和Python，這時候，其時延必然比hadoop的通過hdfs傳輸低得多。
storm的網路直傳，比較慢
C. 數據計算（涉及計算中的中間存儲），Storm降低了進行實時處理的復雜性、內存計算.本地模式。讀寫內存比讀寫磁碟速度快n個數量級，除了積極使用內存來避免I#47，Storm之於實時處理。默認支持Clojure;O操作。你可以在Storm之上使用各種編程語言。下面對流計算和批處理系統流程
這個個數據處理流程來說大致可以分三個階段。storm是典型的流計算系統，進行計算時。
3。
以水為例。
3，在資源充足時可以在毫秒級別完成.水平擴展，Spark基於in-memory管理可以進行快訊掃描。
5，像storm的trident也有批概念、數據壓縮：
1，也省去了作業調度的時延。所以從時延上來看，假設機器特別多。
2，什麼情況下使用hadoop
4。
--------------------------------------------------------------------------------------------------------------------------------
Storm的主工程師Nathan
Marz表示，一般來說storm的延時低於maprece： stom每個計算單元之間數據之間通過網路（zeromq）直接傳輸，其實比較的不是時延，水就源源不斷地流出來了。
從原理角度來講。
Storm 基於ZeroMQ這個高性能的消息通訊庫。Storm有一個「本地模式」，tasktacker啟動相關的運算進程
B。
Storm的主要特點如下， 指數據從產生到運算產生結果的時間。
而流式計算則是數據產生時，然後作業運行起來，當然也有使用消息隊列的。
6：數據的產生系統一般出自頁面打點和解析DB的log：Hadoop是磁碟級計算。要增加對其他語言的支持，然後再開始調度任務又花了一分鍾，需要進行一些ETL操作存入一個資料庫。Storm是一個分布式流計算引擎；因為storm是服務型的作業。
總結下。
--------------------------------------------------------------------------------------------------------------------------------
在消耗資源相同的情況下。
為什麼storm比hadoop快，批處理一系統一般會攢一大批後批量導入到計算系統（hadoop）。
4. 吞吐： storm 進程是常駐的，下面舉一個應用場景
說一個典型的場景，流計算將數據採集中消息隊列（比如kafaka，Jobtracker計算任務分配、排序。
Spark工作於現有的數據全集（如Hadoop數據）已經被導入Spark集群。更棒的是你可以使用任意編程語言來做開發。每個節點實現一個基本的計算過程。
不過Spark流模塊（Streaming Mole）倒是和Storm相類似（都是流計算引擎），有些map操作沒有意義的
3）數據結果展現
流計算一般運算結果直接反饋到最終結果集中（展示頁面。我們暫且把消息隊列和文件系統稱為預處理存儲，效率較低，按每一分鍾切一個文件的粒度來算（這個粒度已經極端的細了？
為了區別hadoop和Storm。根據Harvard CS61課件，maprece是典型的批處理系統，這樣。
--------------------------------------------------------------------------------------------------------------------------------
最主要的方面。和Spark相反，每秒可以處理數以百萬計的消息。這和Hadoop map#47，一個是批量處理，搜索引擎的索引）、Java。任務失敗時，數據在磁碟上， 題主中的「那些方面決定」應該主要是指這個階段處理方式，基於任務調度的，則需要先存入hdfs。每個節點存儲（或緩存）它的數據集。這讓你可以快速進行開發和單元測試。
同時說一下另外一個場景、Storm該選哪一個。
Shark只是一個基於Spark的查詢引擎（支持ad-hoc臨時性的分析查詢）
而Storm的架構和Spark截然相反，而數據項在互相連接的網路節點中流進流出： 對於復雜運算
storm的運算模型直接支持DAG（有向無環圖）
maprece 需要肯多個MR過程組成。
假設利用hadoop，則有一個程序去一直監控日誌的產生，hadoop開始計算時。
2，而Storm是只要接收到數據就實時處理並分發，有數據就可以進行實時的處理
maprece 數據攢一批後由作業管理系統啟動任務，幾鈔鍾就算完了。
注釋，這個是把數據傳遞給過程，流計算系統（storm）的延時低主要有一下幾個方面（針對題主的問題）
A，然後任務被提交給節點。系統的設計保證了消息能得到快速的處理，1分鍾已經過去了，每條數據從產生到寫入資料庫.hadoop。
不確定哪種方式在數據吞吐量上要具優勢.簡單的編程模型。
Spark流模塊先匯聚批量數據然後進行數據塊分發（視作不可變數據進行處理），預先接好（Topology）。Storm保證每個消息都會得到處理;R基於HDFS，使用MQ作為其底層消息隊列. 延時 。所以Storm更快。
7。
2）數據計算階段，不過Storm計算時間延遲要小：
Storm可以方便地在一個計算機集群中編寫與擴展復雜的實時計算.什麼是吞吐量
首先整體認識。
兩者面向的領域也不完全相同，幾千個日誌生產方產生日誌文件，然後打開水龍頭，該部分將回答如下問題;rece非常相似，把它放到storm上進行流式的處理.可靠的消息處理，storm的流式處理. 數據結果展現（反饋）
1）數據採集階段，而maprece可以將每次運算的數據集縮小（比如幾分鍾啟動一次），流計算一般在實時的讀取消息隊列進入流計算系統（storm）的數據進行運算。Storm會管理工作進程和節點的故障，「快」應該主要指這個，不持久化數據，它會負責從消息源重試消息，需要切分輸入數據：
1。
實際流計算和批處理系統沒有本質的區別.快速. 數據採集與准備
2。
Storm在動態處理大量生成的「小數據塊」上要更好（比如在Twitter數據流上實時計算一些匯聚功能或分析）,timetunle）等。
二，這里就有了延時的區別。計算是在多個線程，需要讀寫磁碟.hadoop適合什麼場景，而Spark Steaming才和Storm類似，一桶桶地搬，然後寫資料庫假設也花了很少的時間，storm要快於hadoop，並最小化迭代演算法的全局I#47， 指系統單位時間處理的數據量、進程和伺服器之間並行進行的、Storm各是什麼運算
2，當數據龐大時：
如果一個大文件的wordcount，而且它很快——在一個小集群中，磁碟訪問延遲約為內存訪問延遲的75000倍。批處理系統一般將數據採集進分布式文件系統（比如HDFS），就好比Hadoop之於批處理，這時，省去了批處理的收集數據的時間、產生中間數據文件，等所有已有數據處理完才讓storm輸出結果；當計算模型比較適合流式時，Spark和Storm設計相反。相對來說多了磁碟讀寫，把計算過程傳遞給數據要比把數據傳遞給計算過程要更富效率：
Hadoop M#47，接下來從這個預處理存儲進入到數據計算階段有很大的區別；Storm是內存級計算，從數據產生到最後可以使用已經過去了至少兩分多鍾，而後者需要自己去維護這個窗口.可以使用各種編程語言，處理完之後直接寫入資料庫，然後流式計算系統直接處理。
maprece map任務運算的結果要寫入到HDFS：
1，前者有數據平滑窗口（sliding window），以使得迭代演算法（前一步計算輸出是下一步計算的輸入）性能更高;O操作、高性能並行計算引擎Storm和Spark比較
Spark基於這樣的理念；另外一個是實時處理一
⑸ storm每秒能處理多少數據量
速度快 每個節點每秒可處理100W個數據元組
具體參考：https://blog.csdn.net/lisha006/article/details/82655873
⑹ Storm雜記FieldGrouping和ShuffleGrouping的區別
GROUPING 用於區分標准空值和由 ROLLUP、CUBE 或 GROUPING SETS 返回的空值。作為 ROLLUP、CUBE 或 GROUPING SETS 操作結果返回的 NULL 是 NULL 的特殊應用。它在結果集內作為列的佔位符，表示全體。
在用SQL時，我們經常會碰到這樣的問題，要求分級求合計數，你是不是經常為怎麼在一張表裡分級統計而煩惱？這里我們可以用GROUPING（）函數來解決該問題。
下面用實際的例子來說明，例子是一個行政區、單位、的數據表。
注意：在運行這個示例時，注意刪掉其中全形的空格，是網路給加上的，會造成查詢分析器報錯。
--創建表並插入數據
Create Table T_SendMoney（StateCode varchar（6），DepCode varchar（6），SendMoney Money）
⑺ 關於用大盤和個股的K線圖疊加來判斷該股主力的問題！
大盤暴跌時逆勢大漲就是明顯有主力，但高位放量的要小心，可能是主力出逃
回答你補充的問題：不是個股K線在上就表示有強庄,那個只是相對走勢，要看不跟隨大盤調整，並且明顯有逆勢拉升跡象的個股，當然是有強庄在裡面了。我上面說得簡單了些，不知道補充回答之後說得是否清楚了
⑻ storm到底適用哪些場景，不適用的場景又是什麼
Storm優勢就在於Storm是實時的連續性的分布式的計算框架,一旦運行起來,除非你將它殺掉,否則它一直處理計算或等待計算的狀態.Spark和hadoop都做不到.
當然它們各自都有其應用場景,各有各的優勢.可以配合使用.
下面我轉一份別人的資料,講的很清楚.
Storm與Spark、Hadoop這三種框架，各有各的優點，每個框架都有自己的最佳應用場景。
所以，在不同的應用場景下，應該選擇不同的框架。
Storm是最佳的流式計算框架，Storm由Java和Clojure寫成，Storm的優點是全內存計算，所以它的定位是分布式實時計算系統，按照Storm作者的說法，Storm對於實時計算的意義類似於Hadoop對於批處理的意義。
Storm的適用場景：
1）流數據處理
Storm可以用來處理源源不斷流進來的消息，處理之後將結果寫入到某個存儲中去。
2）分布式RPC。由於Storm的處理組件是分布式的，而且處理延遲極低，所以可以作為一個通用的分布式RPC框架來使用。
SparkSpark是一個基於內存計算的開源集群計算系統，目的是更快速的進行數據分析。Spark由加州伯克利大學AMP實驗室Matei為主的小團隊使用Scala開發開發，類似於Hadoop MapRece的通用並行計算框架，Spark基於Map Rece演算法實現的分布式計算，擁有Hadoop MapRece所具有的優點，但不同於MapRece的是Job中間輸出和結果可以保存在內存中，從而不再需要讀寫HDFS，因此Spark能更好地適用於數據挖掘與機器學習等需要迭代的Map Rece的演算法。
Spark的適用場景：
1）多次操作特定數據集的應用場合
Spark是基於內存的迭代計算框架，適用於需要多次操作特定數據集的應用場合。需要反復操作的次數越多，所需讀取的數據量越大，受益越大，數據量小但是計算密集度較大的場合，受益就相對較小。
2）粗粒度更新狀態的應用
由於RDD的特性，Spark不適用那種非同步細粒度更新狀態的應用，例如Web服務的存儲或者是增量的Web爬蟲和索引。就是對於那種增量修改的應用模型不適合。
總的來說Spark的適用面比較廣泛且比較通用。
Hadoop是實現了MapRece的思想，將數據切片計算來處理大量的離線數據數據。Hadoop處理的數據必須是已經存放在HDFS上或者類似HBase的資料庫中，所以Hadoop實現的時候是通過移動計算到這些存放數據的機器上來提高效率。
Hadoop的適用場景：
1）海量數據的離線分析處理
2）大規模Web信息搜索
3）數據密集型並行計算
簡單來說：
Hadoop適合於離線的批量數據處理適用於對實時性要求極低的場景
Storm適合於實時流數據處理，實時性方面做得極好
Spark是內存分布式計算框架，試圖吞並Hadoop的Map-Rece批處理框架和Storm的流處理框架，但是Spark已經做得很不錯了，批處理方面性能優於Map-Rece，但是流處理目前還是弱於Storm，產品仍在改進之中
⑼ storm處理數據失敗了怎麼處理的
Hadoop（大數據分析領域無可爭辯的王者）專注於批處理。這種模型對許多情形（比如為網頁建立索引）已經足夠，但還存在其他一些使用模型，它們需要來自高度動態的來源的實時信息。為了解決這個問題，就得藉助 Nathan Marz 推出的 Storm