02 搭建訂閱轉換網站鏈接提取(抖音運營方面的工具有哪些)

· Spout：位于拓撲邊緣的數據流來源，例如可以是API或查詢等，從這里可以產生待處理的數據。

· Bolt：Bolt代表需要消耗流數據，對其應用操作，并將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連接，隨后相互連接以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連接的其他系統的輸入。

Storm背后的想法是使用上述組件定義大量小型的離散操作，隨后將多個組件組成所需拓撲。默認情況下Storm提供了“至少一次”的處理保證，這意味著可以確保每條消息至少可以被處理一次，但某些情況下如果遇到失敗可能會處理多次。Storm無法確保可以按照特定順序處理消息。

為了實現嚴格的一次處理，即有狀態處理，可以使用一種名為Trident的抽象。嚴格來說不使用Trident的Storm通常可稱之為Core Storm。Trident會對Storm的處理能力產生極大影響，會增加延遲，為處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。

為避免這些問題，通常建議Storm用戶盡可能使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些情況下也比較有用，例如系統無法智能地處理重復消息時。如果需要在項之間維持狀態，例如想要計算一個小時內有多少用戶點擊了某個鏈接，此時Trident將是你唯一的選擇。盡管不能充分發揮框架與生俱來的優勢，但Trident提高了Storm的靈活性。

Trident拓撲包含：

· 流批（Stream batch）：這是指流數據的微批，可通過分塊提供批處理語義。

· 操作（Operation）：是指可以對數據執行的批處理過程。

優勢和局限

目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用于希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。

Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然借此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。

Core Storm無法保證消息的處理順序。Core Storm為消息提供了“至少一次”的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重復。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。

在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。

總結

對于延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條消息都被處理，可配合多種編程語言使用。由于Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟件。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。

Apache Samza

Apache Samza是一種與Apache Kafka消息系統緊密綁定的流處理框架。雖然Kafka可用于很多流處理系統，但按照設計，Samza可以更好地發揮Kafka獨特的架構優勢和保障。該技術可通過Kafka提供容錯、緩沖，以及狀態存儲。

Samza可使用YARN作為資源管理器。這意味著默認情況下需要具備Hadoop集群（至少具備HDFS和YARN），但同時也意味著Samza可以直接使用YARN豐富的內建功能。

流處理模式

Samza依賴Kafka的語義定義流的處理方式。Kafka在處理數據時涉及下列概念：

· Topic（話題）：進入Kafka系統的每個數據流可稱之為一個話題。話題基本上是一種可供消耗方訂閱的，由相關信息組成的數據流。

· Partition（分區）：為了將一個話題分散至多個節點，Kafka會將傳入的消息劃分為多個分區。分區的劃分將基于鍵（Key）進行，這樣可以保證包含同一個鍵的每條消息可以劃分至同一個分區。分區的順序可獲得保證。

· Broker（代理）：組成Kafka集群的每個節點也叫做代理。

· Procer（生成方）：任何向Kafka話題寫入數據的組件可以叫做生成方。生成方可提供將話題劃分為分區所需的鍵。

· Consumer（消耗方）：任何從Kafka讀取話題的組件可叫做消耗方。消耗方需要負責維持有關自己分支的信息，這樣即可在失敗后知道哪些記錄已經被處理過了。

由于Kafka相當于永恒不變的日志，Samza也需要處理永恒不變的數據流。這意味著任何轉換創建的新數據流都可被其他組件所使用，而不會對最初的數據流產生影響。

優勢和局限

乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。

例如Kafka已經提供了可以通過低延遲方式訪問的數據存儲副本，此外還可以為每個數據分區提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，并可被下游步驟獨立使用。

這種對Kafka的緊密依賴在很多方面類似于MapRece引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的性能問題，但也避免了流處理遇到的很多其他問題。

Samza與Kafka之間緊密的關系使得處理步驟本身可以非常松散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對于有多個團隊需要訪問類似數據的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的數據話題，或任意訂閱其他團隊對數據進行過某些處理后創建的話題。這一切并不會對數據庫等負載密集型基礎架構造成額外的壓力。

直接寫入Kafka還可避免回壓（Backpressure）問題。回壓是指當負載峰值導致數據流入速度超過組件實時處理能力的情況，這種情況可能導致處理工作停頓并可能丟失數據。按照設計，Kafka可以將數據保存很長時間，這意味著組件可以在方便的時候繼續進行處理，并可直接重啟動而無需擔心造成任何后果。

Samza可以使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza即可獲得“至少一次”的交付保障，但面對由于數據可能多次交付造成的失敗，該技術無法對匯總后狀態（例如計數）提供精確恢復。

Samza提供的高級抽象使其在很多方面比Storm等系統提供的基元（Primitive）更易于配合使用。目前Samza只支持JVM語言，這意味著它在語言支持方面不如Storm靈活。

總結

對于已經具備或易于實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用（但相互之間并不一定緊密協調）不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的性能。如果部署需求與當前系統不兼容，也許并不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。

混合處理系統：批處理和流處理

一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數據，借此讓不同的處理需求得以簡化。

如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在于兩種不同處理模式如何進行統一，以及要對固定和不固定數據集之間的關系進行何種假設。

雖然側重于某一種處理類型的項目會更好地滿足具體用例的要求，但混合框架意在提供一種數據處理的通用解決方案。這種框架不僅可以提供處理數據所需的方法，而且提供了自己的集成項、庫、工具，可勝任圖形分析、機器學習、交互式查詢等多種任務。

Apache Spark

Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapRece引擎基于各種相同原則開發而來的Spark主要側重于通過完善的內存計算和處理優化機制加快批處理工作負載的運行速度。

Spark可作為獨立集群部署（需要相應存儲層的配合），或可與Hadoop集成并取代MapRece引擎。

批處理模式

與MapRece不同，Spark的數據處理工作全部在內存中進行，只在一開始將數據讀入內存，以及將最終結果持久存儲時需要與存儲層交互。所有中間態的處理結果均存儲在內存中。

雖然內存中處理方式可大幅改善性能，Spark在處理與磁盤有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現更完善的整體式優化。為此Spark可創建代表所需執行的全部操作，需要操作的數據，以及操作和數據之間關系的Directed Acyclic Graph（有向無環圖），即DAG，借此處理器可以對任務進行更智能的協調。

為了實現內存中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分布式數據集），即RDD的模型來處理數據。這是一種代表數據集，只位于內存中，永恒不變的結構。針對RDD執行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，并最終回溯至磁盤上的數據。Spark可通過RDD在無需將每個操作的結果寫回磁盤的前提下實現容錯。

流處理模式

流處理能力是由Spark Streaming實現的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特征方面的差異，Spark實現了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將數據流視作一系列非常小的“批”，借此即可通過批處理引擎的原生語義進行處理。

Spark Streaming會以亞秒級增量對流進行緩沖，隨后這些緩沖會作為小規模的固定數據集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。

優勢和局限

使用Spark而非Hadoop MapRece的主要原因是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark可以用更快速度處理相同的數據集。

Spark的另一個重要優勢在于多樣性。該產品可作為獨立集群部署，或與現有Hadoop集群集成。該產品可運行批處理和流處理，運行一個集群即可處理不同類型的任務。

除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態系統，可為機器學習、交互式查詢等任務提供更好的支持。相比MapRece，Spark任務更是“眾所周知”地易于編寫，因此可大幅提高生產力。

為流處理系統采用批處理的方法，需要對進入系統的數據進行緩沖。緩沖機制使得該技術可以處理非常大量的傳入數據，提高整體吞吐率，但等待緩沖區清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。

由于內存通

很赞哦!（86338）