kafka編程實例_發現公司里的大數據開發掙得很多想轉行

『壹』 kafka中的topic為什麼要進行分區

若沒有分區，一個topic對應的消息集在分布式集群服務組中，就會分布不均勻，即可能導致某台伺服器A記錄當前topic的消息集很多，若此topic的消息壓力很大的情況下，伺服器A就可能導致壓力很大，吞吐也容易導致瓶頸。有了分區後，假設一個topic可能分為10個分區，kafka內部會根據一定的演算法把10分區盡可能均勻分布到不同的伺服器上，比如：A伺服器負責topic的分區1，B伺服器負責topic的分區2，在此情況下，Procer發消息時若沒指定發送到哪個分區的時候，kafka就會根據一定演算法上個消息可能分區1，下個消息可能在分區2。當然高級API也能自己實現其分發演算法。

『貳』大型的PHP應用，通常使用什麼應用做消息隊列

一、消息隊列概述
消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，非同步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。
二、消息隊列應用場景
以下介紹消息隊列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和消息通訊四個場景。
2.1非同步處理
場景說明：用戶注冊後，需要發注冊郵件和注冊簡訊。傳統的做法有兩種1.串列的方式；2.並行方式。
（1）串列方式：將注冊信息寫入資料庫成功後，發送注冊郵件，再發送注冊簡訊。以上三個任務全部完成後，返回給客戶端。（架構KKQ：466097527，歡迎加入）
（2）並行方式：將注冊信息寫入資料庫成功後，發送注冊郵件的同時，發送注冊簡訊。以上三個任務完成後，返回給客戶端。與串列的差別是，並行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鍾，不考慮網路等其他開銷，則串列方式的時間是150毫秒，並行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。
小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？
引入消息隊列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：
按照以上約定，用戶的響應時間相當於是注冊信息寫入資料庫的時間，也就是50毫秒。注冊郵件，發送簡訊寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串列提高了3倍，比並行提高了兩倍。
2.2應用解耦
場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的介面。如下圖：
傳統模式的缺點：
1）假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；
2）訂單系統與庫存系統耦合；
如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：
訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。
庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。
假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。
2.3流量削鋒
流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。
可以控制活動的人數；
可以緩解短時間內高流量壓垮應用；
用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；
秒殺業務根據消息隊列中的請求信息，再做後續處理。
2.4日誌處理
日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下：
日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列；
Kafka消息隊列，負責日誌數據的接收，存儲和轉發；
日誌處理應用：訂閱並消費kafka隊列中的日誌數據；
以下是新浪kafka日誌處理應用案例：
(1)Kafka：接收用戶日誌的消息隊列。
(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch。
(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。
(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。
2.5消息通訊
消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。
點對點通訊：
客戶端A和客戶端B使用同一隊列，進行消息通訊。
聊天室通訊：
客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。
以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。模型為示意圖，供參考。
三、消息中間件示例
3.1電商系統
消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）
（2）擴展流程（發簡訊，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。
（3）消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。比如主數據寫入資料庫，擴展應用根據消息隊列，並結合資料庫方式實現基於消息隊列的後續處理。
3.2日誌收集系統
分為Zookeeper注冊中心，日誌收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。
Zookeeper注冊中心，提出負載均衡和地址查找服務；
日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列；
四、JMS消息服務
講消息隊列就不得不提JMS 。JMS（java Message Service,Java消息服務）API是一個消息服務的標准/規范，允許應用程序組件基於JavaEE平台創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及非同步性。
在EJB架構中，有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。
4.1消息模型
在JMS標准中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。
4.1.1 P2P模式
P2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到他們被消費或超時。
P2P的特點
每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)
發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之後，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列
接收者在成功接收消息之後需向隊列應答成功
如果希望發送的每個消息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）
4.1.2 Pub/sub模式
包含三個角色主題（Topic），發布者（Publisher），訂閱者（Subscriber）。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
Pub/Sub的特點
每個消息可以有多個消費者
發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發布者的消息。
為了消費消息，訂閱者必須保持運行的狀態。
為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。
如果希望發送的消息可以不被做任何處理、或者只被一個消息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。
4.2消息消費
在JMS中，消息的產生和消費都是非同步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。
（1）同步
訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時之前）將一直阻塞；
（2）非同步
訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之後，系統自動調用監聽器的onMessage方法。
JNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查找和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪問發送目標或消息來源的作用。（架構KKQ：466097527，歡迎加入）
4.3JMS編程模型
(1) ConnectionFactory
創建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查找ConnectionFactory對象。
(2) Destination
Destination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。對於消息生產者來說，它的Destination是某個隊列（Queue）或某個主題（Topic）;對於消息消費者來說，它的Destination也是某個隊列或主題（即消息來源）。
所以，Destination實際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。
(3) Connection
Connection表示在客戶端和JMS系統之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。
(4) Session
Session是操作消息的介面。可以通過session創建生產者、消費者、消息等。Session提供了事務的功能。當需要使用session發送/接收多個消息時，可以將這些發送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。
(5) 消息的生產者
消息生產者由Session創建，並用於將消息發送到Destination。同樣，消息生產者分兩種類型：QueueSender和TopicPublisher。可以調用消息生產者的方法（send或publish方法）發送消息。
(6) 消息消費者
消息消費者由Session創建，用於接收被發送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創建。當然，也可以session的creatDurableSubscriber方法來創建持久化的訂閱者。
(7) MessageListener
消息監聽器。如果注冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。
深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，消息中間件也是大型分布式系統必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學習，實踐，總結，領會。
五、常用消息隊列
一般商用的容器，比如WebLogic，JBoss，都支持JMS標准，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。
5.1 ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息匯流排。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，盡管JMS規范出台已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。
ActiveMQ特性如下：
⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4規范（持久化，XA消息，事務)
⒊ 對spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支持Spring2.0的特性
⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業伺服器上
⒌ 支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通過JDBC和journal提供高速的消息持久化
⒎ 從設計上保證了高性能的集群，客戶端-伺服器，點對點
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 可以很容易得調用內嵌JMS provider，進行測試
5.2 RabbitMQ
RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標准實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。
幾個重要概念：
Broker：簡單來說就是消息隊列伺服器實體。
Exchange：消息交換機，它指定消息按什麼規則，路由到哪個隊列。
Queue：消息隊列載體，每個消息都會被投入到一個或多個隊列。
Binding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。
Routing Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。
vhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的許可權分離。
procer：消息生產者，就是投遞消息的程序。
consumer：消息消費者，就是接受消息的程序。
channel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。
消息隊列的使用過程，如下：
（1）客戶端連接到消息隊列伺服器，打開一個channel。
（2）客戶端聲明一個exchange，並設置相關屬性。
（3）客戶端聲明一個queue，並設置相關屬性。
（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。
（5）客戶端投遞消息到exchange。
exchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。
5.3 ZeroMQ
號稱史上最快的消息隊列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網路編程更為簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。
引用官方的說法：「ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成為標准網路協議棧的一部分，之後進入linux內核」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」BSD套接字之上的一層封裝。ZMQ讓編寫高性能網路應用程序極為簡單和有趣。」
特點是：
高性能，非持久化；
跨平台：支持Linux、Windows、OS X等。
多語言支持； C、C++、Java、.NET、Python等30多種開發語言。
可單獨部署或集成到應用中使用；
可作為Socket通信庫使用。
與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、進程通訊和線程通訊抽象為統一的API介面。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。
ZeroMQ高性能設計要點：
1、無鎖的隊列模型
對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列演算法CAS；在pipe兩端注冊有非同步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。
2、批量處理的演算法
對於傳統的消息處理，每個消息在發送和接收的時候，都需要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，可以批量的接收和發送消息。
3、多核下的線程綁定，無須CPU切換
區別於傳統的多線程並發模式，信號量或者臨界區， zeroMQ充分利用多核的優勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。
5.4 Kafka
Kafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。
Kafka是一種高吞吐量的分布式發布訂閱消息系統，有如下特性：
通過O(1)的磁碟數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。（文件追加的方式寫入數據，過期的數據定期刪除）
高吞吐量：即使是非常普通的硬體Kafka也可以支持每秒數百萬的消息。
支持通過Kafka伺服器和消費機集群來分區消息。
支持Hadoop並行數據載入。
Kafka相關概念
Broker
Kafka集群包含一個或多個伺服器，這種伺服器被稱為broker[5]
Topic
每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）
Partition
Parition是物理上的概念，每個Topic包含一個或多個Partition.
Procer
負責發布消息到Kafka broker
Consumer
消息消費者，向Kafka broker讀取消息的客戶端。
Consumer Group
每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於默認的group）。
一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。

『叄』為什麼kafka 用scala

Kafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。
Scala是一門多範式的編程語言，一種類似java的編程語言，設計初衷是實現可伸縮的語言、並集成面向對象編程和函數式編程的各種特性。用Scala比較簡單而且實用

『肆』 kafka配置更改了需要重啟嗎

我覺得應該是需要的，一般來說任何的電子設備進行了一些重大的更改都是需要重啟的，特別是你的這個還是更改了設備的這個樣子的。下面是關於配置的(4)kafka編程實例擴展閱讀。

硬體方面
1．CPU，這個主要取決於頻率和二級緩存，三級緩存，核心數量。頻率越高、二級緩存越大，三級緩存越大，核心越多，運行速度越快。速度越快的CPU只有三級緩存影響響應速度。
2．內存，內存的存取速度取決於介面、顆粒數量多少與儲存大小（包括內存的介面，如：SDRAM133，DDR333，DDR2-533，DDR2-800,DDR3-1333、DDR3-1600、DDR4-2133），一般來說，內存越大，處理數據能力越強，而處理數據的速度主要看內存屬於哪種類型（如DDR就沒有DDR3處理得快）。一般大型游戲（PUBG、戰地5、俄羅斯釣魚、使命召喚16等）與大型軟體（pr、ae等）都會佔用很多內存，因此，對於游戲玩家來說，越高的內存可以玩越多的游戲。
3．主板，主要還是處理晶元，如：筆記本i965比i945晶元處理能力更強，i945比i910晶元在處理數據的能力又更強些，依此類推。並且更好的主板還可以適配更強大的CPU（中央處理器）。
4．硬碟，硬碟分為固態硬碟（SSD）、機械硬碟（HDD）、混合硬碟（SSHD），固態硬碟速度最快，混合硬碟次之，機械硬碟最差。越大的硬碟存的文件就多，（如存放電影，音樂等）首先硬碟的數據讀取與寫入的速度和硬碟的轉速（分：高速硬碟和低速硬碟，高速硬碟一般用在大型伺服器中，如：10000轉，15000轉；低速硬碟用在一般電腦中，包括筆記本電腦），台式機電腦一般用7200轉，筆記本電腦一般用5400轉，這主要是考慮到高速硬碟在筆記本電腦中由於電腦移動振動意外刮傷硬碟碟片以及功耗和散熱原因。
硬碟速度又因介面不同，速率不同，一般而言，分IDE和SATA（也就是常說的串口）介面，早前的硬碟多是IDE介面，相比之下，存取速度比SATA介面的要慢些。

『伍』在java企業級編程中kafka有什麼用

public static void consumer(){ Properties props = new Properties(); props.put("zk.connect", "hadoop-2:2181"); props.put("zk.connectiontimeout.ms", "1000000"); props.put("groupid", "fans_group"); // Create the connection to the cluster ConsumerConfig consumerConfig = new ConsumerConfig(props); ConsumerConnector consumerConnector = Consumer.createJavaConsumerConnector(consumerConfig); Map map = new HashMap(); map.put("fans", 1); // create 4 partitions of the stream for topic 「test」, to allow 4 threads to consume Map>> topicMessageStreams = consumerConnector.createMessageStreams(map); List> streams = topicMessageStreams.get("fans"); // create list of 4 threads to consume from each of the partitions ExecutorService executor = Executors.newFixedThreadPool(1); long startTime = System.currentTimeMillis(); // consume the messages in the threads for(final KafkaStream stream: streams) { executor.submit(new Runnable() { public void run() { ConsumerIterator it = stream.iterator(); while (it.hasNext()){ log.debug(byteBufferToString(it.next().message().payload())); } } }); log.debug("use time="+(System.currentTimeMillis()-startTime)); } }

『陸』發現公司里的大數據開發掙得很多，想轉行，

轉行這個詞彙，一直是職場上此起彼伏的一個熱門話題，相信很多朋友都想過或已經經歷過轉行。工作可謂是我們生存乃至生活的主要收入來源，誰都希望擁有一份高薪又穩定的工作，以此來改善自己的生活和實現自己的大大小小的夢想!但又擔心轉行後的工作待遇達不到自己的預期，顧慮重重……

不少想進入大數據分析行業的零基礎學員經常會有這樣一些疑問：大數據分析零基礎應該怎麼學習?自己適合學習大數據分析嗎?人生，就是在不斷地做選擇，然後在這個選擇過程中成長，讓自己從一棵小樹苗變成參天大樹。就是我們每個對大數據充滿幻想終於下定決心行動的學員的選擇，我們給了自己4個月的時間，想要在大數據分析這個領域汲取養分，讓自己壯大成長。

【明確方向】

通過國家的戰略規劃，看到BAT的大牛們都在大數據行業布局，新聞媒體追捧這大數據分析行業的項目和熱點，我想如果我還沒有能力獨立判斷的時候，跟著國家政策和互聯網大佬們的步調走，這應該是錯不了的。

【付諸行動】

明確了方向之後，我就整裝待發，剛開始是在網路上購買了很多的視頻教程，也買了很多書籍，但是最大的問題就在於，我不知道怎麼入手，沒關系，有信心有耐心肯定能戰勝困難，我堅持了一個月，學習的節奏越來越亂，陸陸續續出現了很多的問題，沒人指導，請教了幾個業內的朋友，但對方工作繁忙，問了幾次之後就不好意思了，自學陷入了死循環。

意識到我學習效率的低下，以及無人指導的問題想想未來的康莊大道，咬咬牙告訴自己，一定好好好學，不然就浪費太多時間最後還會是一無所獲。最後找到組織(AAA教育)一起學習進步!

大數據分析零基礎學習路線，有信心能堅持學習的話，那就當下開始行動吧!

一、大數據技術基礎

1、linux操作基礎

linux系統簡介與安裝

linux常用命令–文件操作

linux常用命令–用戶管理與許可權

linux常用命令–系統管理

linux常用命令–免密登陸配置與網路管理

linux上常用軟體安裝

linux本地yum源配置及yum軟體安裝

linux防火牆配置

linux高級文本處理命令cut、sed、awk

linux定時任務crontab

2、shell編程

shell編程–基本語法

shell編程–流程式控制制

shell編程–函數

shell編程–綜合案例–自動化部署腳本

3、內存資料庫redis

redis和nosql簡介

redis客戶端連接

redis的string類型數據結構操作及應用-對象緩存

redis的list類型數據結構操作及應用案例-任務調度隊列

redis的hash及set數據結構操作及應用案例-購物車

redis的sortedset數據結構操作及應用案例-排行榜

4、布式協調服務zookeeper

zookeeper簡介及應用場景

zookeeper集群安裝部署

zookeeper的數據節點與命令行操作

zookeeper的java客戶端基本操作及事件監聽

zookeeper核心機制及數據節點

zookeeper應用案例–分布式共享資源鎖

zookeeper應用案例–伺服器上下線動態感知

zookeeper的數據一致性原理及leader選舉機制

5、java高級特性增強

Java多線程基本知識

Java同步關鍵詞詳解

java並發包線程池及在開源軟體中的應用

Java並發包消息隊里及在開源軟體中的應用

Java JMS技術

Java動態代理反射

6、輕量級RPC框架開發

RPC原理學習

Nio原理學習

Netty常用API學習

輕量級RPC框架需求分析及原理分析

輕量級RPC框架開發

二、離線計算系統

1、hadoop快速入門

hadoop背景介紹

分布式系統概述

離線數據分析流程介紹

集群搭建

集群使用初步

2、HDFS增強

HDFS的概念和特性

HDFS的shell(命令行客戶端)操作

HDFS的工作機制

NAMENODE的工作機制

java的api操作

案例1：開發shell採集腳本

3、MAPREDUCE詳解

自定義hadoop的RPC框架

Maprece編程規范及示例編寫

Maprece程序運行模式及debug方法

maprece程序運行模式的內在機理

maprece運算框架的主體工作流程

自定義對象的序列化方法

MapRece編程案例

4、MAPREDUCE增強

Maprece排序

自定義partitioner

Maprece的combiner

maprece工作機制詳解

5、MAPREDUCE實戰

maptask並行度機制-文件切片

maptask並行度設置

倒排索引

共同好友

6、federation介紹和hive使用

Hadoop的HA機制

HA集群的安裝部署

集群運維測試之Datanode動態上下線

集群運維測試之Namenode狀態切換管理

集群運維測試之數據塊的balance

HA下HDFS-API變化

hive簡介

hive架構

hive安裝部署

hvie初使用

7、hive增強和flume介紹

HQL-DDL基本語法

HQL-DML基本語法

HIVE的join

HIVE 參數配置

HIVE 自定義函數和Transform

HIVE 執行HQL的實例分析

HIVE最佳實踐注意點

HIVE優化策略

HIVE實戰案例

Flume介紹

Flume的安裝部署

案例：採集目錄到HDFS

案例：採集文件到HDFS

三、流式計算

1、Storm從入門到精通

Storm是什麼

Storm架構分析

Storm編程模型、Tuple源碼、並發度分析

Storm WordCount案例及常用Api分析

Storm集群部署實戰

Storm+Kafka+Redis業務指標計算

Storm源碼下載編譯

Strom集群啟動及源碼分析

Storm任務提交及源碼分析

Storm數據發送流程分析

Storm通信機制分析

Storm消息容錯機制及源碼分析

Storm多stream項目分析

編寫自己的流式任務執行框架

2、Storm上下游及架構集成

消息隊列是什麼

Kakfa核心組件

Kafka集群部署實戰及常用命令

Kafka配置文件梳理

Kakfa JavaApi學習

Kafka文件存儲機制分析

Redis基礎及單機環境部署

Redis數據結構及典型案例

Flume快速入門

Flume+Kafka+Storm+Redis整合

四、內存計算體系Spark

1、scala編程

scala編程介紹

scala相關軟體安裝

scala基礎語法

scala方法和函數

scala函數式編程特點

scala數組和集合

scala編程練習(單機版WordCount)

scala面向對象

scala模式匹配

actor編程介紹

option和偏函數

實戰：actor的並發WordCount

柯里化

隱式轉換

2、AKKA與RPC

Akka並發編程框架

實戰：RPC編程實戰

3、Spark快速入門

spark介紹

spark環境搭建

RDD簡介

RDD的轉換和動作

實戰：RDD綜合練習

RDD高級運算元

自定義Partitioner

實戰：網站訪問次數

廣播變數

實戰：根據IP計算歸屬地

自定義排序

利用JDBC RDD實現數據導入導出

WorldCount執行流程詳解

4、RDD詳解

RDD依賴關系

RDD緩存機制

RDD的Checkpoint檢查點機制

Spark任務執行過程分析

RDD的Stage劃分

5、Spark-Sql應用

Spark-SQL

Spark結合Hive

DataFrame

實戰：Spark-SQL和DataFrame案例

6、SparkStreaming應用實戰

Spark-Streaming簡介

Spark-Streaming編程

實戰：StageFulWordCount

Flume結合Spark Streaming

Kafka結合Spark Streaming

窗口函數

ELK技術棧介紹

ElasticSearch安裝和使用

Storm架構分析

Storm編程模型、Tuple源碼、並發度分析

Storm WordCount案例及常用Api分析

7、Spark核心源碼解析

Spark源碼編譯

Spark遠程debug

Spark任務提交行流程源碼分析

Spark通信流程源碼分析

SparkContext創建過程源碼分析

DriverActor和ClientActor通信過程源碼分析

Worker啟動Executor過程源碼分析

Executor向DriverActor注冊過程源碼分析

Executor向Driver注冊過程源碼分析

DAGScheler和TaskScheler源碼分析

Shuffle過程源碼分析

Task執行過程源碼分析

五、機器學習演算法

1、python及numpy庫

機器學習簡介

機器學習與python

python語言–快速入門

python語言–數據類型詳解

python語言–流程式控制制語句

python語言–函數使用

python語言–模塊和包

phthon語言–面向對象

python機器學習演算法庫–numpy

機器學習必備數學知識–概率論

2、常用演算法實現

knn分類演算法–演算法原理

knn分類演算法–代碼實現

knn分類演算法–手寫字識別案例

lineage回歸分類演算法–演算法原理

lineage回歸分類演算法–演算法實現及demo

樸素貝葉斯分類演算法–演算法原理

樸素貝葉斯分類演算法–演算法實現

樸素貝葉斯分類演算法–垃圾郵件識別應用案例

kmeans聚類演算法–演算法原理

kmeans聚類演算法–演算法實現

kmeans聚類演算法–地理位置聚類應用

決策樹分類演算法–演算法原理

決策樹分類演算法–演算法實現

時下的大數據分析時代與人工智慧熱潮，相信有許多對大數據分析師非常感興趣、躍躍欲試想著轉行的朋友，但面向整個社會，最不缺的其實就是人才，對於是否轉行大數據分析行列，對於能否勇敢一次跳出自己的舒適圈，不少人還是躊躇滿志啊!畢竟好多決定，一旦做出了就很難再回頭了。不過如果你已經轉行到大數據分析領域，就不要後悔，做到如何脫穎而出才是關鍵。因此本文給出一些建議，針對想要轉行大數據分析行列且是零基礎轉行的小夥伴們，希望對你們有所裨益，也希望你們將來學有所成，不後悔，更不灰心!

導航:首頁 > 編程語言 > kafka編程實例

kafka編程實例

與kafka編程實例相關的資料