1樓：浪尖
kafka是資料快取，儲存，也可以做簡單處理。
flume在企業裡一般都是資料採集，然後落地動作。比如flume採集nginx日誌，然後寫入kafka，然後再用flume消費kafka資料，入hdfs。
2樓：迷糊娃
前面應該還有個資料出產者，比方flume.flume擔任出產資料，傳送至kafka。spark streaming作為消費者，實時的從kafka中獲取資料進行核算。
核算結果儲存至redis，供實時推薦運用。flume kafka spark redis是實時資料蒐集與核算的一套經典架構。更多大資料相關技能，能夠查詢"lxw的大資料地步".
3樓：vivid
這兩個工作中都用過，談談自己的理解吧
kafka:目前專案中主要是用來做訊息推送中介軟體，訊息的處理完全由業務方自己定義，請求頻次單機吞吐量輕輕鬆鬆50W+/s，資料在集群不全掛的情況下是不會丟資料，消費也很靈活，可以指定分割槽和offset，可以當做成乙個資料庫
flume:主要是哪來做資料採集和落地，目前使用的是flume-ng，流程是source(kafka)->channel->hdfs 相比較kafka比較輕量級 ，就是乙個資料的流通管道，當乙個flume例項掛了資料會丟失
4樓：木洛
我偏愛Flume，因為架構簡單，依賴少。
但是同樣的，功能也簡單，但是夠靈活。
它的定位是資料通道，不是訊息佇列。
Flume和Kafka應該結合來使用，Flume作為日誌收集端，Kafka作為日誌消費端。
Flume的Source-Channel-Sink模型，非常適合作為日誌收集的模型。你可以想一下，如果你來做乙個日誌收集的Agent，如果做能盡量保證日誌資料的傳輸成功率，應對服務端的各種異常情況，以及如何靈活的接入各種不同的日誌型別。
Kafka就不必多說了，生產者消費者模型，看你怎麼去構建日誌消費的下游了。有了訊息佇列作為中介軟體，消費的下游和上游可以完美的解耦。
5樓：justin zhang
flume：日誌採集系統
kafka：訊息中介軟體
也用過樓上說的組合：
log->flume->kafka->hdfs(solr)
activemq和kafka有什麼區別？
凱德祁 目前我們公司同時在用amq和kafka兩種產品。但是也定下了以kafka為主，amq為輔的路線。就像第乙個回答所說，amq是乙個專門針對訊息場景的mq，而kafka現在的發展趨勢主要是流資料處理平台。amq的優勢是功能全，安裝簡單，需要的資源比kafka少，兩台amq就能滿足服務高可用。壞處...
京劇和崑曲有什麼區別和聯絡
是若錦啊 這個題目很大，區別我看其他答主都說了，我就說說聯絡吧。崑曲是百戲之祖，京劇的發展多多少少也有借鑑崑曲的成分，就這樣。補充一點區別吧，我看沒有人講到，早期京劇發展的時候，大多劇目是從崑曲中摘下來，但是多數是折子戲，到了現在，京劇中大多都是折子戲，而崑曲大多都是全本大戲。 比目魚 看了你的問題...
slam和smpl有什麼區別和聯絡？
Eternity 剛好看到這個問題，略知一些，僅代表個人觀點。簡單敘述一下slam和smpl是什麼？smpl是指2015 TOG的一篇文章 SMPL a skinned multi person linear model 中構建的人體三維模型，人體可以理解為是乙個基礎模型和在該模型基礎上進行形變的總...