第4章數(shù)據(jù)采集數(shù)據(jù)采集系統(tǒng)組成與架構數(shù)據(jù)采集系統(tǒng)維護和流程優(yōu)化數(shù)據(jù)采集系統(tǒng)維護和流程優(yōu)化數(shù)據(jù)采集與數(shù)據(jù)處理的性能問題一直是被關注的重點，尤其是對流式數(shù)據(jù)采集和流計算的要求，因此對于數(shù)據(jù)采集流程特別是流式數(shù)據(jù)采集流程，通常需要進行調整從而優(yōu)化性能。優(yōu)化的方式修改程序進行優(yōu)化；通過修改任務的配置參數(shù)優(yōu)化任務；修改集群的配置參數(shù)對運行環(huán)境進行調整。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Event在Agent中的傳輸流程圖包括Source（數(shù)據(jù)源）、Interceptor（攔截器）、Selector（選擇器）、Channel（緩沖區(qū)）、SinkProcessor（Sink處理器）、Sink（接收器）。因此對于Flume數(shù)據(jù)采集流程的優(yōu)化，通常從優(yōu)化這6個組成部分入手。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Source性能優(yōu)化適當增加Source個數(shù)；首選Flume內(nèi)置的RPCSink和RPCSource進行數(shù)據(jù)傳輸。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Source的類型多種多樣，適當增加Source個數(shù)可以增強Source讀取數(shù)據(jù)的能力。例如，當某一個目錄產(chǎn)生的文件過多時，需要將這個文件目錄拆分成多個文件目錄，同時配置多個Source以保證Source有足夠的能力獲取新產(chǎn)生的數(shù)據(jù)。batchSize參數(shù)決定Source一次批量運輸?shù)紺hannel的Event條數(shù)，適當調大這個參數(shù)可以提高Source搬運Event到Channel時的性能。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化對于Agent-to-Agent通信，首選Flume內(nèi)置的RPCSink和RPCSource進行數(shù)據(jù)傳輸。在上一個Agent中，使用AvroSink或者ThriftSink等RPCSink存儲數(shù)據(jù)，在下一個Agent通過AvroSource或ThriftSource等RPCSource接收數(shù)據(jù)。因為RPCSink或RPCSource是高擴展性的，所以單個RPCSource可以接收大量的Sink或者RPC客戶端發(fā)出的數(shù)據(jù)。盡管每個RPCSink只能發(fā)送數(shù)據(jù)給一個RPCSource，但是每個Agent可以配置使用Sink組或Sink處理器解決這個問題。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Interceptor性能優(yōu)化在一個Agent中，可添加任意數(shù)量的攔截器用于一個Source到一個Channel間刪除或轉換事件，多個攔截器的運行可采用串行方式，最后一個攔截器的結果會寫入Channel。Flume提供了常用的攔截器類型，并支持自定義攔截器。常用攔截器包括時間戳攔截器、主機攔截器、靜態(tài)攔截器、正則過濾攔截器等數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化根據(jù)實際需要選擇合適的攔截器能夠對事件進行有效的處理。攔截器需要在事件寫入Channel前成功完成轉換操作，只有攔截器對應的Source才會響應發(fā)生事件的客戶端或Sink，因此重量級、耗時的處理操作不建議在攔截器中完成，其會嚴重影響數(shù)據(jù)采集與傳輸?shù)男省４藭r，可通過流式處理框架完成重量級、耗時、復雜的數(shù)據(jù)處理。如果需要在攔截器中完成，那么需要相應的調整超時時間屬性，以免耗時的計算運行時間超過Source與Channel的響應時間而報錯。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Selector性能優(yōu)化Source發(fā)送的事件通過Channel選擇器來選擇以哪種方式寫入Channel中。Flume提供了3種類型Channel選擇器：復制Channel選擇器、多路復用Channel選擇器、自定義Channel選擇器。提前通過Channel選擇器實現(xiàn)數(shù)據(jù)的劃分可以避免后期再對數(shù)據(jù)進行重復的處理，從而有效提高數(shù)據(jù)采集與處理的效率。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化復制Channel選擇器復制Channel選擇器是將Source發(fā)送的事件復制到所有Source指定的Channel中，不同的Sink可以從不同的Channel中讀取相同的事件。例如，同一份日志數(shù)據(jù)需要寫入Kafka用于實時計算，還需要在HDFS中備份用于校驗和校正結果數(shù)據(jù)，這就需要將一個事件同時寫入兩個Channel，然后被不同類型的Sink發(fā)送到不同的外部存儲。關鍵參數(shù)除類型type外，還需要optional參數(shù)，用于定義可選Channel列表。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化多路復用Channel選擇器多路復用Channel選擇器可以根據(jù)事件頭判斷事件寫入哪個Channel中，還可以配置3種級別的Channel，分別是必選Channel、可選Channel和默認Channel，并通過頭信息中的header值匹配是否符合條件寫入必選Channel和可選Channel，不符合則寫入默認Channel。一個Event不能同時被寫入必選和默認Channel。如需要將采集的日志數(shù)據(jù)根據(jù)日期分別存入不同的位置，則可以將日期加入事件頭信息，并設置條件對事件進行劃分以寫入不同的Channel，再通過不同的Sink將Channel的數(shù)據(jù)寫入不同的外部存儲。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化自定義Channel選擇器自定義Channel選擇器則是根據(jù)用戶需要自定義事件寫入Channel的規(guī)則，并根據(jù)用戶定義的選擇器決定事件寫入Channel的方式。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Channel性能優(yōu)化Channel的優(yōu)化主要先根據(jù)業(yè)務需要以及不同Channel的特點選擇合適的Channel，如MemoryChannel、FileChanne等。MemoryChannel讀寫速度快但容量小、出現(xiàn)故障時數(shù)據(jù)易丟失。FileChannel可持久化緩存大量數(shù)據(jù)，但是讀寫速度比MemoryChannel慢。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化除了常用的MemoryChannel和FileChannel，還有其他的Channel，如JDBCChannel、KafkaChannel等，均需根據(jù)實際需要選擇，再對選擇的Channel進行相關參數(shù)的調整。MemoryChannel的參數(shù)設置參數(shù)說明capacityChannel可容納最大的Event條數(shù)，默認值為100transactionCapacity決定每次Source向Channel寫入的最大Event條數(shù)和每次Sink從Channel里面讀取的最大Event條數(shù)，默認值為100keep-alive在Channel中寫入或讀取Event等待完成的超時時間，默認值為3秒byteCapacityChannel占用內(nèi)存的最大容量，默認值為Flume堆內(nèi)存的80%，若參數(shù)設置為0，則強制設置Channel占用內(nèi)存200GBbyteCapacityBufferPercentage緩沖空間占Channel容量（byteCapacity）的百分比，為Event中的頭信息保留了空間，默認值為20%數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化單個Channel通過調整參數(shù)可以實現(xiàn)大量事件的緩存和事件的讀寫操作，如果一個Channel無法支撐數(shù)據(jù)的緩存和讀寫操作，那么可以考慮通過設置多個Channel共同分擔事件緩存和讀寫。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化SinkProcessor性能優(yōu)化Sink處理器的應用與Sink組緊密關聯(lián)。Sink組指的是包含任意多個Sink的組合，每個Sink組會有一個Sink運行器，Sink運行器負責持續(xù)向Sink組發(fā)送請求，其中一個Sink向Sink對應的Channel讀取事件。Sink組通常應用于RPCSink，在層之間實現(xiàn)負載均衡和故障轉移。負載均衡指的是將事件均衡分布到不同Sink組，故障轉移指的是將失敗Sink的任務轉移給其他Sink組。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Sink運行器與Sink處理器是不同的Sink運行器用于運行Sink；Sink處理器決定了哪個Sink可以從自己的Channel中拉取數(shù)據(jù)。當Sink運行器要求Sink告知要用組中的哪一個Sink拉取Channel的事件時，幫助完成這個選擇過程的就是Sink處理器。Flume自帶的兩類Sink處理器load-balancingSinkfailoverSink數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化Load-balancingSink處理器均衡分布事件到一個Channel對應的所有Sink組，每個Sink組選擇其中的一個Sink拉取Channel的事件。Sink組選擇Sink的方式有random和round-robin兩種。如果Sink寫入失敗或寫入速度太慢，那么Sink處理器會再選擇一個Sink寫數(shù)據(jù)，并將失敗或速度太慢的Sink寫入黑名單，設置駐留時間，黑名單中的Sink不再接收數(shù)據(jù)直到駐留時間結束。若還無法提供服務，則駐留時間將以指數(shù)倍增長。Random：隨機選擇一個。round-robin：循環(huán)選擇一個。Load-balancingSink處理器數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化FailoverSink處理器FailoverSink處理器需要給每個Sink組設置優(yōu)先級，優(yōu)先級高的先使用，優(yōu)先級相同的隨機使用。當優(yōu)先級高的Sink組故障時，會轉移事件到下一個優(yōu)先級的Sink組中。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Sink性能優(yōu)化通常一個線程運行一個Sink，且大多數(shù)Sink傾向于I/O密集，可能會造成一種情況：當Sink等待I/O完成時，Channel中沒有將要移除的事件。在大多數(shù)情況下，如果出現(xiàn)個別Sink寫入數(shù)據(jù)到存儲系統(tǒng)的速度比Source寫入數(shù)據(jù)到Channel的速度慢很多的情況，那么需要考慮添加多個Sink用來寫入數(shù)據(jù)到相同的目的地和從相同的Channel讀取事件。這對于HDFSSink和HBaseSink尤其有用，能用來提升寫入到HDFS和HBase的速率。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化性能優(yōu)化所需的Sink數(shù)量取決于多個因素正在被使用的Sink、Sink目的地；網(wǎng)絡吞吐量；Channel、Channel使用的磁盤I/O性能等。當增加Sink數(shù)量提升性能時，必須確保資源不會因過度使用而結束。數(shù)據(jù)采集流程優(yōu)化——Flume采集流程優(yōu)化Sink的類型也比較多，通常會根據(jù)需要去選擇。對于其他的Sink，如HBaseSink、HDFSSink等，可進一步根據(jù)不同Sink提供的配置參數(shù)，結合實際業(yè)務需要，調整參數(shù)的值。如Agent-to-Agent的可以選擇RPCSink，在下一個Agent采用RPCSource接收數(shù)據(jù)，傳輸性能好。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化不同系統(tǒng)對于性能的訴求不同，如對于數(shù)據(jù)庫而言，最重要的性能是請求的響應時間。對于Kafka這樣的分布式消息系統(tǒng)、流處理平臺而言，性能一般指的是吞吐量和延時兩個方面。吞吐量吞吐量指的是Broker（代理）或Client（客戶端）應用程序每秒能處理的字節(jié)或消息。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化吞吐量和延時的關系可以通過一個例子說明延時延時指的是從Producer端發(fā)送消息到Broker端持久化保存消息之間的時間間隔。該概念也用于統(tǒng)計端到端（End-to-End，E2E）的延時，如從Producer端發(fā)送一條消息到Consumer端消費這條消息的時間間隔。如果從Producer發(fā)送一條消息到Broker持久化保存需要2毫秒（即延時是2毫秒），那么Producer的吞吐量就是500條/秒，吞吐量與延時的關系TPS=1/0.002=500條/秒。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化調優(yōu)吞吐量提高Kafka任務吞吐量的方式多分區(qū)批量發(fā)送數(shù)據(jù)壓縮Ack機制數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化多分區(qū)Kafka基本的并行單位是分區(qū)。Producer在設計時就被要求能夠向多個分區(qū)發(fā)送消息，這些消息也要能夠被寫入多個Broker供多個Consumer同時消費。Kafka一個主題可以設置多個分區(qū)，主題數(shù)據(jù)分布在多個分區(qū)中存儲。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化理論上分區(qū)數(shù)越多，并發(fā)處理能力越強，系統(tǒng)整體吞吐量越高。在實際情況下并不是分區(qū)數(shù)越多越好。Broker內(nèi)部維護了很多分區(qū)級別的元數(shù)據(jù)，過多的分區(qū)會占用內(nèi)存資源。每個分區(qū)都會有相應的線程處理該分區(qū)的數(shù)據(jù)讀寫，線程的啟動需要占用一部分資源，過多的分區(qū)反而會增加系統(tǒng)負擔。當Broker宕機時，Partition重新選擇Leader也會因為分區(qū)過多而導致耗時太久。因此，在創(chuàng)建主題時，可以通過增加分區(qū)數(shù)提高吞吐量，但是分區(qū)數(shù)量的選擇需要根據(jù)具體使用場景，經(jīng)過多次測試后設置一個合理的分區(qū)數(shù)，從而提高系統(tǒng)性能。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化批量發(fā)送KafkaProducer發(fā)送消息時，可以通過配置“batch.size”和“timeout.ms”兩個配置項分別設置批量發(fā)送消息的數(shù)據(jù)量和等待發(fā)送延遲時間來啟動批量發(fā)送消息功能。KafkaProducer在等待發(fā)送期間會在內(nèi)存中不斷積累消息，當消息達到一定的數(shù)量或等待時間到達時，批量將消息發(fā)送到Kafka。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化可見，批量加入是有效提高吞吐量的一種方式，批量發(fā)送策略能夠降低Producer端發(fā)送消息的網(wǎng)絡I/O，有效提高Producer發(fā)送消息的效率。通過增加4倍的延遲就可以增加近200倍的吞吐量，然而延遲的增加也是事實，吞吐量和延時處于一種相互制約的關系。例如，Producer每發(fā)送一條消息到Broker持久化保存需要2毫秒（即延時是2毫秒），那么1秒就只能發(fā)送500條消息，吞吐量為500條/秒，若設置發(fā)送延遲為8毫秒，在8毫秒內(nèi)將1000條數(shù)據(jù)緩存到內(nèi)存中，8毫秒后批量寫入緩存的數(shù)據(jù)到Kafka，共花費了10毫秒（8毫秒+2毫秒）就寫入了1000條數(shù)據(jù)，吞吐量為1000/0.01=100000條/秒。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化數(shù)據(jù)壓縮如果寫入Kafka的數(shù)據(jù)量比較龐大，那么網(wǎng)絡帶寬可能會成為主要制約因素，這時可以考慮采用數(shù)據(jù)壓縮的方式。在Producer端對數(shù)據(jù)進行壓縮，壓縮雖然會增加CPU的開銷，但是在網(wǎng)絡帶寬性能瓶頸的場景下，能夠有效提高Kafka的吞吐量。目前支持的壓縮格式有Gzip、Snappy等。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化Ack機制Ack機制用于設置Producer發(fā)送消息到Broker后是否等待Broker返回成功送達的信息。0：表示Producer發(fā)送消息到Broker后不需要等待Broker返回成功送達信號，這種方式能有效地提高吞吐量，但是存在數(shù)據(jù)丟失風險，可通過“retries”配置項配置發(fā)送消息失敗后的重試次數(shù)。1：表示Broker接收到信息并成功寫入分區(qū)Leader副本的本地log文件后，向Producer返回成功接收信息，不需要等待所有Follower副本全部同步完成，這種方式在數(shù)據(jù)丟失風險和吞吐量間做了平衡。all（或者-1）：表示Broker接收到信息并成功寫入分區(qū)Leader副本和Follower副本的本地log文件后，再向Producer返回成功接收的信息，這種方式最安全，性能卻最差。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化調優(yōu)延時

降低延時的方式限制分區(qū)數(shù)不使用數(shù)據(jù)壓縮不緩存數(shù)據(jù)Ack設置為0或1Kafka吞吐量和延時存在著一種制約關系，降低延時可能會一定程度上影響吞吐量。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化限制分區(qū)數(shù)分區(qū)數(shù)越多，Broker就需要更多的時間實現(xiàn)Follower和Leader的數(shù)據(jù)同步。在同步完成前，Ack設置為all的Producer不會認為請求已完成，Consumer也獲取不到數(shù)據(jù)，同時影響了兩端的延遲性。要降低延遲，緩解的辦法有3種：不要創(chuàng)建分區(qū)數(shù)過多的Topic，增加Broker分散分區(qū)數(shù)，調整參數(shù)提高Broker的IO并行度。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化不使用數(shù)據(jù)壓縮數(shù)據(jù)壓縮是一種以時間換空間的方式，如果需要降低延遲，那么不推薦使用數(shù)據(jù)壓縮，但是需增加網(wǎng)絡帶寬。不緩存數(shù)據(jù)Producer端linger.ms參數(shù)設置為0，表示不在緩存區(qū)緩存數(shù)據(jù)，接收的數(shù)據(jù)不緩存直接發(fā)送到Broker，能夠有效降低延遲。數(shù)據(jù)采集流程優(yōu)化——Kafka性能優(yōu)化Ack設置為0或1Ack默認值1是一個相對安全的設置，如果能夠容忍數(shù)據(jù)丟失的情況發(fā)生，那么可將值設置為0，對于提高吞吐量和降低延時有很好的效果。提高吞吐量和降低延遲在很多情況下并不能兼顧，因此在調優(yōu)方面，需要明確調優(yōu)的目標，優(yōu)先考慮最需要提升的性能，對相關配置進行調整。數(shù)據(jù)采集流程優(yōu)化——SparkStreaming性能優(yōu)化在流式計算方面，性能優(yōu)化要求更高。為了適合不同的場景和不同的應用，SparkStreaming為用戶提供了很多可配置項來最大化地滿足用戶的自定義平臺的需求。這些配置項都被賦予默認值，但是默認值不一定能使系統(tǒng)的性能達到最優(yōu)，需要根據(jù)機器的性能、任務數(shù)據(jù)量等調節(jié)SparkStreaming的參數(shù)。數(shù)據(jù)采集流程優(yōu)化——SparkStreaming性能優(yōu)化合理的批處理時間間隔SparkStreaming創(chuàng)建流式數(shù)據(jù)處理任務時，需要設置一個批處理的時間間隔，每隔設置的時間間隔就會提交一個Job。在SparkStreaming中，Job之間可能存在依賴關系，后面的Job必須確保前面的Job執(zhí)行結束后才能提交。若前面的Job執(zhí)行時間超出了批處理時間間隔，則后面的Job就無法按時提交，這樣就會進一步拖延接下來的Job，造成后續(xù)Job的堵塞。因此，需要設置合理的批處理時間間隔確保作業(yè)在批處理時間間隔內(nèi)結束。數(shù)據(jù)采集流程優(yōu)化——SparkStreaming性能優(yōu)化批處理時間間隔的大小需要視情況而定如果本身定義的時間間隔比較大，那么不存在任務運行不完的情況則無須調整該項，否則需要多次調整并測試從而找到一個合適的時間間隔。數(shù)據(jù)采集流程優(yōu)化——SparkStreaming性能優(yōu)化增加并行化，充分利用資源并行化是大數(shù)據(jù)處理技術的核心，如何最大化地應用好并行化，是提升任務運行效率的關鍵。首先要增加Job的并行度，不能使部分節(jié)點處于運行狀態(tài)，而剩下的節(jié)點閑置。其次，可以從接收端增加并行度。如果Spark與外部系統(tǒng)通信，如Kafka，那么可以使用Kafka緩沖來優(yōu)化SparkStreaming到Kafka的寫入，達到負載均衡和及時處理數(shù)據(jù)的目的。通過多個任務共享一個生產(chǎn)者，可以顯著減少由Kafka集群建立的新TCP連接數(shù)。數(shù)據(jù)采集流程優(yōu)化——SparkStreaming性能優(yōu)化減少數(shù)據(jù)序列化、反序列化的負擔SparkStreaming默認使用Java內(nèi)置序列化列，將接收到的數(shù)據(jù)序列化后存儲，以減少內(nèi)存使用，但是序列化與反序列化需要更多的CPU時間，導致性能不佳。可以使用Kryo序列化類和自定義序列化接口更加高效地使用CPU。數(shù)據(jù)采集流程優(yōu)化——SparkStreaming性能優(yōu)化及時清除過期數(shù)據(jù)SparkStreaming會將接收的數(shù)據(jù)全部存儲到內(nèi)部可用的內(nèi)存區(qū)域中。隨著時間推移，有些數(shù)據(jù)已經(jīng)不需要了，但是仍然存儲在內(nèi)存中占用內(nèi)存資源。此時，可以通過設置數(shù)據(jù)清除時間，及時清理超時的無用數(shù)據(jù)，但是這個參數(shù)的設置需要小心，以免刪除有效數(shù)據(jù)。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化Storm的優(yōu)化通常是對StormTopology的性能優(yōu)化。整體來說，可通過4個步驟進行Storm的優(yōu)化：（1）硬件配置的優(yōu)化；（2）代碼層面的優(yōu)化；（3）Topology并行度的優(yōu)化；（4）Storm集群配置參數(shù)和Topology運行參數(shù)的優(yōu)化。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化第（1）步需要增加機器的硬件資源，提高機器的硬件配置等。第（2）步依賴用戶的編程能力。通常對Topology的優(yōu)化是通過增加并行性來實現(xiàn)性能提升，但同時要認識到工作者進程（Worker）和核心數(shù)量的協(xié)調，以避免盲目增加并行性的行為造成所有進程和線程都在競爭中死亡的后果。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化Topolopy并行度的設置可以從3個方面入手一個Topolopy指定多少個Worker進程并行運行。一個Worker進程指定多少個Executor線程并行運行。一個Executor線程指定多少個Task并行運行。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化配置工作進程數(shù)每個工作進程都會為它內(nèi)部的線程執(zhí)行一定數(shù)量的任務，因此這個參數(shù)應該結合Topology中每個組件的并行度來使用，以便調整Topology的性能。此外，還需要配置TOPOLOGY_WORKERS選項，可以通過調用Storm提供的API完成。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化配置Executor數(shù)Executor數(shù)描述每個component啟動Executor的數(shù)量，每個component的Executor都需要各自單獨配置。Executor數(shù)可通過TopologyBuilder類的setSpout和setBolt接口設置。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化配置任務數(shù)任務數(shù)描述了每個component創(chuàng)建的任務的數(shù)量，每個component啟動的任務數(shù)量都需要單獨配置。一個Executor會為相同的component運行一個或多個任務。在Topology的生命周期里，component的任務數(shù)總是相同的，但是component的Executor數(shù)量是可以修改的。這允許Topology可以調整使用更多或者更少的資源，而不用重新部署Topology或者違反Storm的約束。任務數(shù)可以通過ComponentConfigurationDeclarer接口的setNumTasks進行設置。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化Storm集群配置參數(shù)和Topolopy運行參數(shù)的優(yōu)化需要根據(jù)實際的任務運行情況進行調優(yōu)。topology.max.spout.pending用于設置同時活躍的batch數(shù)量一般Spout的發(fā)射速度會快于下游的Bolt的消費速度。當下游的Bolt超過topology.max.spout.pending個Tuple沒有消費完時，Spout會停下來等待。當Tuple的個數(shù)少于topology.max.spout.pending個數(shù)時，Spout會繼續(xù)從消息源讀取消息。該配置作用于Spout的每個Task，因此這個參數(shù)需要合理設置。數(shù)據(jù)采集流程優(yōu)化——Storm性能優(yōu)化topology.message.timeout.secs設置Spout發(fā)送的消息的最大處理超時時間在Spout發(fā)送消息之后，若在設置的超時時間內(nèi)未收到確認，則Storm將消息處理視為失敗。此參數(shù)的設置需要考慮的是需要數(shù)據(jù)的及時性或需要數(shù)據(jù)的失敗率小一些。若及時性高，則可以適當縮短元組的超時時間，數(shù)據(jù)的失敗率會可能高些。若需要降低失敗率，則可以適當延長元組的超時時間。數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化Flink是一個功能強大的流式數(shù)據(jù)處理組件，在性能優(yōu)化上，可以從Backpressure（反壓）、Checkpoint（檢查點）入手。Backpressure優(yōu)化反壓在流式系統(tǒng)中是一種非常重要的機制，主要作用是當系統(tǒng)中下游算子的處理速度下降，導致數(shù)據(jù)處理速率低于數(shù)據(jù)接入速率時，通過反向背壓的方式讓數(shù)據(jù)接入的速率下降，從而避免大量數(shù)據(jù)積壓在Flink系統(tǒng)中，最后導致系統(tǒng)無法正常運行。Flink具有天然的反壓機制，不需通過額外配置就能夠完成反壓處理。數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化web.backpresssure.cleanup-interval當啟動反壓數(shù)據(jù)采集后，需要等待頁面并獲取反壓數(shù)據(jù)的時間長度，默認為60s。web.backpresssure.delay-between-samplesStackTrace抽樣到確認反壓狀態(tài)之間的時延，默認為50ms。web.backpresssure.num-samples設定StackTrace抽樣數(shù)以確定反壓狀態(tài)，默認為100。針對反壓的優(yōu)化，可以調整以下參數(shù)。數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化Checkpointing優(yōu)化Flink中基于異步輕量級的分布式快照技術提供了Checkpoints容錯機制，分布式快照可以將統(tǒng)一時間點的Task/Operator的狀態(tài)數(shù)據(jù)全局統(tǒng)一快照處理。Checkpointing通過給程序快照的方式將歷史某些時刻的狀態(tài)保存下來，當任務失敗后，默認從最近一次保存的完整快照處進行恢復任務。Flink會在輸入的數(shù)據(jù)集上間隔性地生成Checkpointbarrier，通過柵欄（barrier）將間隔時間段內(nèi)的數(shù)據(jù)劃分到相應的Checkpoint中。當程序出現(xiàn)異常時，Operator能夠從上一次快照恢復所有算子之前的狀態(tài)，從而保證數(shù)據(jù)的唯一性。數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化如在KafkaConsumer算子中維護offerset狀態(tài)，當系統(tǒng)出現(xiàn)問題無法從Kafka讀取數(shù)據(jù)時，可以將offset記錄在狀態(tài)中，當任務重新恢復時就能夠從指定的偏移量開始消費數(shù)據(jù)。Checkpointing的優(yōu)化可以從最小時間間隔、狀態(tài)容量預估、異步Snapshot、狀態(tài)數(shù)據(jù)壓縮這4個方面入手。數(shù)據(jù)采集流程優(yōu)化——Flink性能優(yōu)化最小時間間隔當Flink開啟Checkpointing功能并設置時間間隔，應用會根據(jù)指定的時間間隔周期性對應用進行Checkpointing操作。默認情況下Checkpointing是同步進行的，即如果上一個Checkpointing沒有完成，那么下一個Checkpointing不會啟動。在這種情況下，若上一個Checkpointing的過程持續(xù)時間超過設置的時間間隔，則會出現(xiàn)排隊情況；若排隊Checkpointing比較多，則會占用系統(tǒng)資源，導致用于任務的資源減少，影響整個任務的執(zhí)行效率。因此，需要根據(jù)