1. 程式人生 > >大資料生態系統基礎:Apache Kafka基礎(一):介紹和安裝

大資料生態系統基礎:Apache Kafka基礎(一):介紹和安裝

http://blog.csdn.net/zhy_yz/article/details/5905637

一、 Apache kafka基礎介紹      

    1、kafka 是什麼?      

       首先一句話: Apache Kafka 是一個分散式的訊息流平臺。其模式就是我們在設計模式中常用的出版-訂閱模式。

      一個流平臺有三個核心關鍵:

       1)能夠出版和訂閱資料流記錄。 這個和訊息佇列以及企業訊息系統是一樣的。

       2)容錯方式儲存流記錄

       3對產生的流記錄可以進行處理

      哪 kafka 會做什麼咧?

        1)在系統或者應用間建立可靠的實時的流資料管道

        2)建立實時流APP,可以對資料流進行轉換或者處理

    所以,Kafka 是執行在一個叢集上的,能夠分類儲存流記錄,這個流記錄叫 topic,不是 storm 的元組。事實,這其實也是一個鍵值對,key-value,哈,還加上一個時間戳!

         kafka 有四個核心 API 哦。如下圖所示

       1)生產者(或者出版者)API:一個 App 能出版一個流記錄給一個或者更多 Kafka topic。

       2) 消費者(後者訂閱者)API: 一個 APP能訂閱一個或者更多的主題/話題(topic),並且可以處理更多的流記錄

       3) 流 API: 一個 APP 可以作為一個流處理器,消費一個來自一個或者更多話題的輸入流,並且產生一個輸出流給一個或者更多的輸出流,能夠有效地將輸入流轉換為輸出流。

      4)聯結器 (connector)API:能夠建立和執行可複用的生產者或者消費者,他們能連線 Kafka 話題到一個存在的 APP 或者資料系統。比如,連線到一個關係型資料庫,獲取一張表格的變化。

          

      2、主題和日誌(topics and logs)

         主題就是出版者記錄的分類或者供給名。Kafka 中的話題一直有多個訂閱者;一個話題能有0,1,或者訂閱裡面資料的許多消費者。

        一個話題,kafka 叢集維護一個這樣的分割槽 log。

              

         每個分割槽都是有序的、不變的記錄序列,能夠持續追加的一個結構化的日誌 log。

           分割槽裡的記錄每個都被分配了一個唯一的序列號,稱之為 偏移量(offset)。

           kafka叢集在一個儲存期裡維護所有的已經出版的記錄,不管他們有沒有被消費。如果儲存期設定為2天,2天內所有的記錄都會被出版,客戶都能訂閱使用,但是2天后,就會被丟失,釋放空間。kafka 叢集的效能不會受資料長度和儲存期的影響。

         

        消費者可以根據偏移量去使用資料, 這個偏移量消費者可以隨時自己設定。

        分割槽的目的:一是允許日誌能超過一定的大小,單個伺服器都可以用;單個分割槽也適合叢集伺服器,當然,一個話題也可以有很多的分割槽。二是在某點上可以作為並行單位。

      3、分散式

      日誌的分割槽在 kafak 叢集上可以分佈到各個伺服器上,每個伺服器處理資料和分割槽的共享請求。每個分割槽可以複製到可配置的伺服器上,提高了容錯性。

      每個分割槽有一個伺服器作為 leader 和 zero ,其它的伺服器扮作 follower 。

       leader處理讀寫分割槽的請求,follower 被動地複製 leader。 如果 leader 失效,一個 follower 將自動成為 leader。

     每一個伺服器可以為它的者一部分分割槽作為 leader,一部分分割槽作為 follower,所以,負載能夠在叢集中達到很好的平衡。

    4、生產者

       生產者為他們所選的話題釋出資料。

       生產者負責在話題裡選擇記錄分配給那個分割槽。這可以以迴圈的方式進行,只是為了平衡負載,或者可以根據一些語義分割槽功能(根據記錄中的一些鍵)來完成。

     5、消費者

      消費者給自己貼上一個消費者組的標籤,每一個釋出到一個主題的記錄都被交付給每個訂閱消費者組中的一個消費者例項。消費者例項可以在單獨的程序中,也可以在單獨的機器上。
       如果所有的消費者例項都有相同的消費者組,那麼這些記錄將有效地在消費者例項上負載平衡。
       如果所有的消費者例項都有不同的消費者組,那麼每個記錄將被廣播到所有的消費者程序。

       

                上圖是兩個服務組成的叢集,擁有4個分割槽 P0-P3,A消費者組有2個消費者例項,B 組有4個。

      二、安裝

           6月28日釋出了最新的版本0.11.0.0。國內下載地址:

     解壓到 home 的根目錄下面。 ~/kafka_2.12-0.11.0.0

          1、修改.bash_profile 或者 etc/profile

               增加路徑尋找:

             ###setup kafka
             export KAFKA_HOME=$HOME/kafka_2.12-0.11.0.0
             export PATH=$KAFKA_HOME/bin:$PATH    

             然後,source ~/.bash_profile 生效即可。在每一臺服務上都需要配置。

        2、配置檔案在 config 中

              1)Server.properties

                   host.name=mymac
                  zookeeper.connect=mymac:2181,master:2181,slave1:2181,slave2:2181

                  log.dirs=/usr/local/var/log/kafka

                 關鍵是要配置和 zookeeper 的連線。

                   # The id of the broker. This must be set to a unique integer for each broker.設定唯一的值
                        broker.id=0

                 2)  其它引數的解釋如下:

引數

說明(解釋)

broker.id =0

每一個broker在叢集中的唯一表示,要求是正數。當該伺服器的IP地址發生改變時,broker.id沒有變化,則不會影響consumers的訊息情況

log.dirs=/data/kafka-logs

kafka資料的存放地址,多個地址的話用逗號分割,多個目錄分佈在不同磁碟上可以提高讀寫效能  /data/kafka-logs-1/data/kafka-logs-2

port =9092

broker server服務埠

message.max.bytes =6525000

表示訊息體的最大大小,單位是位元組

num.network.threads =4

broker處理訊息的最大執行緒數,一般情況下數量為cpu核數

num.io.threads =8

broker處理磁碟IO的執行緒數,數值為cpu核數2倍

background.threads =4

一些後臺任務處理的執行緒數,例如過期訊息檔案的刪除等,一般情況下不需要去做修改

queued.max.requests =500

等待IO執行緒處理的請求佇列最大數,若是等待IO的請求超過這個數值,那麼會停止接受外部訊息,應該是一種自我保護機制。

host.name

broker的主機地址,若是設定了,那麼會繫結到這個地址上,若是沒有,會繫結到所有的介面上,並將其中之一發送到ZK,一般不設定

socket.send.buffer.bytes=100*1024

socket的傳送緩衝區,socket的調優引數SO_SNDBUFF

socket.receive.buffer.bytes =100*1024

socket的接受緩衝區,socket的調優引數SO_RCVBUFF

socket.request.max.bytes =100*1024*1024

socket請求的最大數值,防止serverOOMmessage.max.bytes必然要小於socket.request.max.bytes,會被topic建立時的指定引數覆蓋

log.segment.bytes =1024*1024*1024

topic的分割槽是以一堆segment檔案儲存的,這個控制每個segment的大小,會被topic建立時的指定引數覆蓋

log.roll.hours =24*7

這個引數會在日誌segment沒有達到log.segment.bytes設定的大小,也會強制新建一個segment會被 topic建立時的指定引數覆蓋

log.cleanup.policy = delete

日誌清理策略選擇有:deletecompact主要針對過期資料的處理,或是日誌檔案達到限制的額度,會被 topic建立時的指定引數覆蓋

log.retention.minutes=300

log.retention.hours=24

資料檔案保留多長時間, 儲存的最大時間超過這個時間會根據log.cleanup.policy設定資料清除策略

log.retention.byteslog.retention.minutes或log.retention.hours任意一個達到要求,都會執行刪除

有2刪除資料檔案方式:

      按照檔案大小刪除:log.retention.bytes

  按照2中不同時間粒度刪除:分別為分鐘,小時

log.retention.bytes=-1

topic每個分割槽的最大檔案大小,一個topic的大小限制 = 分割槽數*log.retention.bytes-1沒有大小限log.retention.byteslog.retention.minutes任意一個達到要求,都會執行刪除,會被topic建立時的指定引數覆蓋

log.retention.check.interval.ms=5minutes

檔案大小檢查的週期時間,是否處罰 log.cleanup.policy中設定的策略

log.cleaner.enable=false

是否開啟日誌清理

log.cleaner.threads = 2

日誌清理執行的執行緒數

log.cleaner.io.max.bytes.per.second=None

日誌清理時候處理的最大大小

log.cleaner.dedupe.buffer.size=500*1024*1024

日誌清理去重時候的快取空間,在空間允許的情況下,越大越好

log.cleaner.io.buffer.size=512*1024

日誌清理時候用到的IO塊大小一般不需要修改

log.cleaner.io.buffer.load.factor =0.9

日誌清理中hash表的擴大因子一般不需要修改

log.cleaner.backoff.ms =15000

檢查是否處罰日誌清理的間隔

log.cleaner.min.cleanable.ratio=0.5

日誌清理的頻率控制,越大意味著更高效的清理,同時會存在一些空間上的浪費,會被topic建立時的指定引數覆蓋

log.cleaner.delete.retention.ms =1day

對於壓縮的日誌保留的最長時間,也是客戶端消費訊息的最長時間,同log.retention.minutes的區別在於一個控制未壓縮資料,一個控制壓縮後的資料。會被topic建立時的指定引數覆蓋

log.index.size.max.bytes =10*1024*1024

相關推薦

apache ignite系列 簡介

help ica tst 簡單使用 orm 監控 地址 客戶端訪問 tor apache-ignite簡介(一) 1,簡介 ? ignite是分布式內存網格的一種實現,其基於java平臺,具有可持久化,分布式事務,分布式計算等特點,此外還支持豐富的鍵值存儲以及SQL語法(基

張量分解基礎知識

[原地址]https://blog.csdn.net/Flying_sfeng/article/details/80817904 前段時間在組裡分享了張量分解相關的知識,現在想把它整理成一個系列,供有需要的同學閱讀。 下文根據Tensor Decomposition

資料開發工程師面試題以及答案整理

kafka的message包括哪些資訊 一個Kafka的Message由一個固定長度的header和一個變長的訊息體body組成 header部分由一個位元組的magic(檔案格式)和四個位元組的CRC32(用於判斷body訊息體是否正常)構成。當magic的值為1的時候,會

【深入Java基礎】HashMap高階用法排序

HashMap高階用法(一):排序 根據key排序 HashMap是無序的,我們可以根據key進行升序或降序。 1.利用List和Collections來實現排序 先獲取HashMap的keySet,然後將keySet放入List,在由Collectio

天池資料競賽——糖尿病遺傳風險預測賽後總結

天池大資料競賽——天池精準醫療大賽人工智慧輔助糖尿病遺傳風險預測賽後總結 天池大資料競賽官方網址(連結)   天池精準醫療大賽是我第一次正式參加與學習的資料競賽,在這十幾天的過程中,學習到很多參與這些資料競賽的技巧和知識,雖然結果並不理想,但是總歸是

Kafka總結Kafka概述

Kafka是什麼? KafKa是一個高吞吐量、分散式的釋出——訂閱訊息系統。據KafKa官網介紹,當前的KafKa已經定位為一個分散式流式處理平臺(a distributed streaming platform),它以可水平擴充套件和具

關於系統架構,專案設計案例抽獎系統概率設計

        上面一篇文章說的只是一些想法,我想很多人看到了比較空洞,從這篇文章開始我會把我設計過的一些專案拿出來把我的設計的相關思路給大家作為一些參考。         其實抽獎系統的設計,我在前面的文章有說明,今天又來回顧一下吧。         首先我們看需求:我們

Ubuntu16.04CUDA學習筆記GPU背景知識

host:CPU,記憶體 device:GPU,視訊記憶體 我是純粹小白,裡面的一些圖是根據我自己的理解畫的,可能並不一定對 一,GPU和CPU執行程式的區別 (圖片來源:CUDA_C_Programming-Guide) 可以看到GPU有跟多的cores,你可以先把cores理

岡薩雷斯數字影象處理第一章緒論

一、影象處理基本步驟 圖片來源:數字影象處理 第三版 岡薩雷斯 1.影象獲取與給出一幅數字形式的影象一樣簡單。通常,影象獲取截斷包括影象預處理,譬如影象縮放 2.影象增強是對一幅影象進行某種擦歐洲哦,使其結果在特定應用匯總比原始影象更適合進行處理。 3.影象復原也是改進影象外觀的一個處

python手記requests寫爬蟲爬蟲簡介

上次將python的圖片處理庫簡單寫了下,也就基本處於玩的地步。哈哈,蠻嘲諷的,這次我嘗試著寫下爬蟲,有多深肯定是不敢保證的,畢竟能力有限。但是我會盡量去從原理上把爬蟲的東西說明白一些。讓大家有個直觀的認識,最後能自己寫出個簡單的定向小爬蟲,爬個小說,爬個圖片,爬首歌曲什麼的

資料生態系統基礎Apache Kafka基礎介紹安裝

http://blog.csdn.net/zhy_yz/article/details/5905637 一、 Apache kafka基礎介紹           1、kafka 是什麼?              首先一句話: Apache Kaf

資料生態系統基礎 HBASEHBASE 介紹安裝、配置

一、介紹        Apache HBase是Hadoop資料庫,一個分散式的、可伸縮的大型資料儲存。        當您需要隨機的、實時的讀/寫訪問您的大資料時,請使用Apache HBase。這個專案的目標是承載非常大的表——數十億行X百萬列的列——執行在在商用硬體

資料入門基礎系列之初步認識資料生態系統博主推薦

  不多說,直接上乾貨!   之前在微信公眾平臺裡寫過 大資料入門基礎系列之初步認識hadoop生態系統圈 http://mp.weixin.qq.com/s/KE09U5AbFnEdwht44FGrOA 大資料入門基礎系列之初步認識大資料生態系統圈 1.概述

SODBASE實時資料基礎實時同步Mysql資料庫到Kafka

在實際大資料工作中,常常有實時監測資料庫變化或實時同步資料到大資料儲存,解決大資料實時分析的需求。同時,增量同步資料庫資料相比全量查詢也減少了網路頻寬消耗。本文以Mysql的bin-log到Kafka為例,使用Canal Server,通過SODBASE引擎不用寫程式就可以

Kafka資料生態系統中的價值

作者: Jun Rao(為ODBMS撰寫文章的轉載) 譯者: Brian Ling,專注於三高(高效能、高穩定性、高可用性)的碼農。 投稿人:董飛,本科畢業於南開大學,碩士畢業於杜克大學計算機系畢業。在攻讀碩士期間,先後在VLDB,SOCC等頂尖資料庫大會

canal實戰canal連線kafka實現實時同步mysql資料

前面已經介紹過了canal-kafka的應用。canal-kafka是把kafka作為客戶端,嵌入到canal中,並且在canal基礎上對原始碼進行了修改,以達到特定的實現canal到kafka的傳送。 canal-kafka是阿里雲最近更新的一個新的

Pandas基礎資料的存取檢視

使用pandas做資料分析,首先匯入pandas庫: import pandas as pd pandas的資料結構有兩種:Series和DataFrame。前者可以理解為陣列,後者可以理解為表格。我們主要講解DataFrame。 1.建立DataFrame: 由等長列表構成。

《Python資料分析與挖掘實戰》筆記資料探勘基礎

一、資料探勘的基本任務 利用分類與預測、聚類分析、關聯規則、時序模式、偏差檢測、智慧推薦等方法,幫助企業提取資料中蘊含的商業價值,提升企業的競爭力。 二、資料探勘建模過程 定義挖掘目標:任務目標和完

資料探勘十演算法決策樹演算法 pythonsklearn實現

學完到第三章——決策樹,python程式碼實現的僅是ID3演算法,sklearn為優化過的C4.5,這裡做一個詳細的總結包括(原理、程式碼、視覺化、scikit-learn實現),皆為親自實踐後的感悟。以下進入正文。 早前簡單瞭解了決策樹的原理,然後為了儘快使用便沒有深究直

資料探勘十演算法——支援向量機SVM線性支援向量機

首先感謝“劉建平pinard”的淵博知識以及文中詳細準確的推導!!! 本文轉自“劉建平pinard”,原網址為:http://www.cnblogs.com/pinard/p/6097604.html。 支援向量機原理SVM系列文章共分為5部分: (一)線性支援向量機