phpzookeeper擴展

❶ it行業有哪些職位

IT行業的職業有以下幾種：

1、WEB前端

前端開發是創建Web頁面或app等前端界面呈現給用戶的過程，通過HTML，CSS及javaScript以及衍生出來的各種技術、框架、解決方案，來實現互聯網產品的用戶界面交互。

2、硬體工程師

硬體工程師要求熟悉計算機市場行情；主要工作為：制定計算機組裝計劃、選購組裝需要的硬體設備、合理配置和安裝計算機以及外圍設備、安裝和配置計算機軟體系統等。

3、硬體測試工程師

主要負責硬體產品的測試工作，保證測試質量及測試工作的順利進行；編寫測試計劃、測試用例；提交測試報告，撰寫用戶說明書；參與硬體測試技術和規范的改進和制定。

4、軟體工程師

軟體工程師是一個廣義的概念，包括軟體設計人員、軟體架構人員、軟體工程管理人員、程序員等一系列崗位，工作內容都與軟體開發生產相關，是IT行業中較為基礎的職業。

5、雲計算工程技術人員

雲計算是分布式計算的一種，指的是通過網路「雲」將巨大的數據計算處理程序分解成無數個小程序，然後，通過多部伺服器組成的系統進行處理和分析這些小程序得到結果並返回給用戶。

而雲計算工程技術人員是指從事雲計算技術研究，雲系統構建、部署、運維，雲資源管理、應用和服務的工程技術人員。

❷ 大型的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）。
一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。

❸ 如何在windows環境下編譯生成PHP的zookeeper擴展dll

1、創建編譯目錄「C:\php_sdk」
2、解壓php-sdk-binary-tools-20110915.zip裡面的文件到php_sdk目錄下
3、在開始菜單找到並打開Windows SDK CMD Shell （注意一定是SDK的shell ， 不是DOS操作的cmd窗口），然後執行
[plain] view plain
setenv /x86 /xp /release //這一句一定要執行成功，要不怎麼都不會編譯成功
cd php_sdk
bin\phpsdk_setvars.bat
bin\phpsdk_buildtree.bat phpdev
執行後，目錄下會生成phpdev文件夾
4、進入C:\php_sdk\phpdev\vc9\x86\，把deps-5.3-vc9-x86.7z解壓到該目錄下，覆蓋deps文件夾。(php sdk)
5、把php源代碼也解壓到x86目錄下。
6、把runkit壓縮包內容解壓到php解壓後源碼下的ext目錄下，並把文件夾名runkit-master改為runkit
7、在x86目錄下創建obj文件夾，用於保存編譯時生成的文件
8、執行以下命令，用於創建php編譯配置
[plain] view plain
cd phpdev\vc9\x86\php5.3-201308211030
buildconf
configure --help >..\configure_help.txt
configure --disable-all --enable-cli --enable-runkit=shared --enable-object-out-dir=..\obj
註：配置中的--enable-runkit=shared意思是 memcache 以 dll 形式生成，否則就和php集成在一起了。

❹ zookeeper怎麼實現分布式鎖

1. 利用節點名稱的唯一性來實現共享鎖
ZooKeeper抽象出來的節點結構是一個和unix文件系統類似的小型的樹狀的目錄結構。ZooKeeper機制規定：同一個目錄下只能有一個唯一的文件名。例如：我們在Zookeeper目錄/test目錄下創建，兩個客戶端創建一個名為Lock節點，只有一個能夠成功。
演算法思路: 利用名稱唯一性，加鎖操作時，只需要所有客戶端一起創建/test/Lock節點，只有一個創建成功，成功者獲得鎖。解鎖時，只需刪除/test/Lock節點，其餘客戶端再次進入競爭創建節點，直到所有客戶端都獲得鎖。
基於以上機制，利用節點名稱唯一性機制的共享鎖演算法流程如圖所示：

該共享鎖實現很符合我們通常多個線程去競爭鎖的概念，利用節點名稱唯一性的做法簡明、可靠。
由上述演算法容易看出，由於客戶端會同時收到/test/Lock被刪除的通知，重新進入競爭創建節點，故存在"驚群現象"。
使用該方法進行測試鎖的性能列表如下：

總結 這種方案的正確性和可靠性是ZooKeeper機制保證的，實現簡單。缺點是會產生「驚群」效應，假如許多客戶端在等待一把鎖，當鎖釋放時候所有客戶端都被喚醒，僅僅有一個客戶端得到鎖。

2. 利用臨時順序節點實現共享鎖的一般做法
首先介紹一下，Zookeeper中有一種節點叫做順序節點，故名思議，假如我們在/lock/目錄下創建節3個點，ZooKeeper集群會按照提起創建的順序來創建節點，節點分別為/lock/0000000001、/lock/0000000002、/lock/0000000003。
ZooKeeper中還有一種名為臨時節點的節點，臨時節點由某個客戶端創建，當客戶端與ZooKeeper集群斷開連接，則開節點自動被刪除。
利用上面這兩個特性，我們來看下獲取實現分布式鎖的基本邏輯：
客戶端調用create()方法創建名為「locknode/guid-lock-」的節點，需要注意的是，這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。
客戶端調用getChildren(「locknode」)方法來獲取所有已經創建的子節點，同時在這個節點上注冊上子節點變更通知的Watcher。
客戶端獲取到所有子節點path之後，如果發現自己在步驟1中創建的節點是所有節點中序號最小的，那麼就認為這個客戶端獲得了鎖。
如果在步驟3中發現自己並非是所有子節點中最小的，說明自己還沒有獲取到鎖，就開始等待，直到下次子節點變更通知的時候，再進行子節點的獲取，判斷是否獲取鎖。
釋放鎖的過程相對比較簡單，就是刪除自己創建的那個子節點即可。
上面這個分布式鎖的實現中，大體能夠滿足了一般的分布式集群競爭鎖的需求。這里說的一般性場景是指集群規模不大，一般在10台機器以內。
不過，細想上面的實現邏輯，我們很容易會發現一個問題，步驟4，「即獲取所有的子點，判斷自己創建的節點是否已經是序號最小的節點」，這個過程，在整個分布式鎖的競爭過程中，大量重復運行，並且絕大多數的運行結果都是判斷出自己並非是序號最小的節點，從而繼續等待下一次通知——這個顯然看起來不怎麼科學。客戶端無端的接受到過多的和自己不相關的事件通知，這如果在集群規模大的時候，會對Server造成很大的性能影響，並且如果一旦同一時間有多個節點的客戶端斷開連接，這個時候，伺服器就會像其餘客戶端發送大量的事件通知——這就是所謂的驚群效應。而這個問題的根源在於，沒有找准客戶端真正的關注點。
我們再來回顧一下上面的分布式鎖競爭過程，它的核心邏輯在於：判斷自己是否是所有節點中序號最小的。於是，很容易可以聯想的到的是，每個節點的創建者只需要關注比自己序號小的那個節點。

3、利用臨時順序節點實現共享鎖的改進實現
下面是改進後的分布式鎖實現，和之前的實現方式唯一不同之處在於，這里設計成每個鎖競爭者，只需要關注」locknode」節點下序號比自己小的那個節點是否存在即可。
演算法思路：對於加鎖操作，可以讓所有客戶端都去/lock目錄下創建臨時順序節點，如果創建的客戶端發現自身創建節點序列號是/lock/目錄下最小的節點，則獲得鎖。否則，監視比自己創建節點的序列號小的節點（比自己創建的節點小的最大節點），進入等待。
對於解鎖操作，只需要將自身創建的節點刪除即可。
具體演算法流程如下圖所示:

使用上述演算法進行測試的的結果如下表所示：

該演算法只監控比自身創建節點序列號小(比自己小的最大的節點)的節點，在當前獲得鎖的節點釋放鎖的時候沒有「驚群」。
總結 利用臨時順序節點來實現分布式鎖機制其實就是一種按照創建順序排隊的實現。這種方案效率高，避免了「驚群」效應，多個客戶端共同等待鎖，當鎖釋放時只有一個客戶端會被喚醒。

4、使用menagerie
其實就是對方案3的一個封裝，不用自己寫代碼了。直接拿來用就可以了。
menagerie基於Zookeeper實現了java.util.concurrent包的一個分布式版本。這個封裝是更大粒度上對各種分布式一致性使用場景的抽象。其中最基礎和常用的是一個分布式鎖的實現： org.menagerie.locks.ReentrantZkLock，通過ZooKeeper的全局有序的特性和EPHEMERAL_SEQUENTIAL類型znode的支持，實現了分布式鎖。具體做法是：不同的client上每個試圖獲得鎖的線程，都在相同的basepath下面創建一個EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要創建的是臨時znode，創建連接斷開時會自動刪除； SEQUENTIAL表示要自動在傳入的path後面綴上一個自增的全局唯一後綴,作為最終的path。因此對不同的請求ZK會生成不同的後綴，並分別返回帶了各自後綴的path給各個請求。因為ZK全局有序的特性，不管client請求怎樣先後到達，在ZKServer端都會最終排好一個順序，因此自增後綴最小的那個子節點，就對應第一個到達ZK的有效請求。然後client讀取basepath下的所有子節點和ZK返回給自己的path進行比較，當發現自己創建的sequential node的後綴序號排在第一個時，就認為自己獲得了鎖；否則的話，就認為自己沒有獲得鎖。這時肯定是有其他並發的並且是沒有斷開的client/線程先創建了node。

❺ 什麼是大數據技術大數據的概念

大數據技術是指大數據的應用技術，涵蓋各類大數據平台、大數據指數體系等大數據應用技術。

大數據是指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合。是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。

隨著雲時代的來臨，大數據也吸引了越來越多的關注。分析師團隊認為，大數據通常用來形容一個公司創造的大量非結構化數據和半結構化數據，這些數據在下載到關系型資料庫用於分析時會花費過多時間和金錢。

大數據分析常和雲計算聯繫到一起，因為實時的大型數據集分析需要像MapRece一樣的框架來向數十、數百或甚至數千的電腦分配工作。

(5)phpzookeeper擴展擴展閱讀：

大數據的三個層面：

1、理論，理論是認知的必經途徑，也是被廣泛認同和傳播的基線。在這里從大數據的特徵定義理解行業對大數據的整體描繪和定性；從對大數據價值的探討來深入解析大數據的珍貴所在；洞悉大數據的發展趨勢；從大數據隱私這個特別而重要的視角審視人和數據之間的長久博弈。

2、技術，技術是大數據價值體現的手段和前進的基石。在這里分別從雲計算、分布式處理技術、存儲技術和感知技術的發展來說明大數據從採集、處理、存儲到形成結果的整個過程。

3、實踐，實踐是大數據的最終價值體現。在這里分別從互聯網的大數據，政府的大數據，企業的大數據和個人的大數據四個方面來描繪大數據已經展現的美好景象及即將實現的藍圖。

參考資料來源：網路-大數據

❻ 盤點 35 個 Apache 頂級項目，我拜服了…

Apache軟體基金會，全稱為Apache Software Foundation（ASF），成立於1999年7月，是世界上最大的最受歡迎的開源軟體基金會，是一個非營利性組織，專門支持開源項目。
目前，ASF旗下有超過200+億美元的價值，為開發者提供免費的開源軟體和項目，惠及全球數十億用戶。
接下來，我們將盤點Apache軟體基金會旗下的35個頂級項目，這些項目在日常開發過程中常常遇到，有的可能已經使用過，而有的則值得學習了解，為未來項目提供參考。
1. Apache（httpd）：Apache HTTP Server，中文名阿帕奇，是一個開源的HTTP伺服器，支持在UNIX和Windows系統上運行。它自1996年4月起成為互聯網上最受歡迎的web伺服器，2020年2月慶祝了其25歲生日。適用於HTML、圖片等靜態資源服務，類似於Nginx，但Nginx功能更為強大。
2. Tomcat：Apache開源的Java應用伺服器，支持Java Servlet、JavaServer Pages、Java Expression Language和Java WebSocket技術。盡管近年來存在安全漏洞，但因其開源、免費的特性，仍被廣泛應用於Java領域，成為主流應用伺服器。
3. Commons：包含一系列Java公共組件的項目，提供Java核心API的額外組件，如StringUtils等。提供43個實用的類庫，極大地方便了Java開發。
4. POI：提供了一系列Java API對Microsoft Office格式文件進行讀寫處理，如Excel、Word、PowerPoint等文件的讀寫，功能強大。
5. HttpComponents：提供了HTTP及相關協議的Java組件和工具集，包括HttpCore、HttpClient、HttpAsyncClient，其中HttpClient是常用的HTTP客戶端。
6. Logging services：包含Apache的日誌服務，如Log4j，是使用最廣泛的日誌框架，還有Log4j 2、log4php、log4cxx等其他語言的日誌框架。
7. Ant：一個較為老的Java項目編譯和構建工具，雖然已經較少使用，但依然存在一定的價值。
8. Maven：是一個主流的軟體項目管理工具，提供項目自動編譯、單元測試、打包、發布等生命周期管理。
9. Subversion：一個開源的版本控制軟體，用於代碼版本控制、文件版本控制，幾乎每個開發者都使用過。
10. Struts：一個免費開源的MVC框架，用於創建Java web應用程序，曾風靡一時，但由於漏洞問題，已逐漸被Spring MVC、Spring Boot等替代。
11. FreeMarker：是一個基於Java的模板引擎，允許使用簡單而強大的模板語言引用Java代碼中的對象來生成HTML頁面、電子郵件、配置文件、源代碼等。
12. Velocity：一個基於Java語言的模板引擎，允許使用模板語言引用Java對象生成文本輸出。盡管長期未更新，不再被Spring Boot 1.5.x版本支持，但仍推薦使用其他模板引擎。
13. Tapestry：一個在Java Web開發界知名的面向組件的Web框架，用於創建高度可伸縮的Web應用程序。
14. Shiro：一個功能強大且易於使用的Java安全框架，提供身份驗證、授權、加密和會話管理等功能，有助於快速、輕松地開發和保護企業應用程序。
15. Dubbo：阿里巴巴開源的分布式服務框架（RPC），曾停止維護後又重啟維護並捐獻給Apache軟體基金會，現在在許多企業中仍大量運用。
16. Thrift：一款優秀的、輕量級的RPC框架，最初由Facebook開發，後捐獻給Apache軟體基金會。支持多種語言，具備高度可擴展性。
17. Zookeeper：一個分布式中間件神器，最初由Google Chubby的一個開源實現，主要用途包括配置中心、分布式鎖等，支持高度可靠的分布式服務協調中間件。
18. Curator：Zookeeper的Java客戶端，提供一系列高級API和工具，簡化了Zookeeper操作，易於使用。
19. SkyWalking：一個可觀測性分析平台和應用性能管理系統，提供分布式跟蹤、指標監控、性能診斷、度量匯總和可視化的一體化解決方案。
20. ShardingSphere：由一組分布式資料庫中間件解決方案組成的開源生態系統，包括JDBC、Proxy、Sidecar（計劃中），提供數據分片、分布式事務和資料庫編排功能。
21. Lucene：頂級的開源搜索框架，包括核心搜索庫（Lucene core）和搜索伺服器（Solr），提供強大的索引和搜索功能。
22. ActiveMQ：一款靈活、強大的多協議開源消息中間件，支持JMS 1.1&2.0，目前最流行的Java消息中間件之一。
23. RocketMQ：一款重量級、極具競爭力的消息隊列產品，由阿里巴巴於2012年開源，2016年捐贈給Apache軟體基金會，2017年正式畢業。
24. Kafka：一款重量級開源項目，最初由LinkedIn公司開發，後捐獻給Apache軟體基金會。它是一種分布式、高吞吐量的發布訂閱消息系統，能夠實時處理大量數據。
25. Hadoop：一種高可靠、可伸縮、分布式大數據處理框架，也是大數據行業公認的標准框架。
26. HBase：建立在Hadoop HDFS上的非關系資料庫，用於大數據存儲，適用於隨機、實時的讀寫訪問。
27. Pig：一個基於Hadoop的大數據分析平台，提供類似SQL的面向數據流的高級語言Pig Latin，用於執行Map Rece任務。
28. Hive：一個基於Hadoop的數據倉庫工具，用於提取、轉化和載入數據，可以將Hadoop原始結構化數據映射為Hive表，並提供類似SQL的HiveQL語言查詢功能。
29. Spark：一個用於大規模數據處理的統一分析引擎，支持無邊界和有邊界數據流上的有狀態計算。
30. Flink：一個分布式處理引擎框架，用於無邊界和有邊界數據流上的有狀態計算，設計用於在所有常見的集群環境中運行。
31. Storm：一個分布式實時計算系統，能夠輕松可靠地處理數據流，類似於Hadoop的實時批處理。
32. Cassandra：一款可伸縮、高可用、高性能去中心化的分布式資料庫，最初由Facebook為了解決消息收件箱搜索問題而設計。
33. CouchDB：一個面向文檔的分布式資料庫，以JSON作為存儲格式和查詢語言，提供直觀可靠的RESTful API介面。
34. Groovy：一個功能強大的基於JVM平台的動態編程語言，語法與Java相似，但更簡潔、易於學習和高效。
35. NetBeans：一款開源開發工具（IDE），集成開發環境和應用框架，支持Java、JavaScript、PHP等編程語言，最初由SUN公司開發，後被Oracle收購並捐贈給Apache軟體基金會。
總結：這些頂級項目涵蓋了基礎組件、Web、分布式、搜索、消息中間件、大數據/資料庫、編程語言、工具等多個領域，為Java生態系統的發展做出了巨大貢獻。盡管有些項目面臨淘汰，但它們都曾經輝煌過，正是這些開源項目推動了Java生態的繁榮。希望本文的分享對大家在日常開發中有所幫助。

❼ 大數據核心技術有哪些

大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、NoSQL資料庫、數據倉庫、機器學習、並行計算、可視化等各種技術范疇和不同的技術層面。首先給出一個通用化的大數據處理框架，主要分為下面幾個方面：數據採集與預處理、數據存儲、數據清洗、數據查詢分析和數據可視化。

一、數據採集與預處理

對於各種來源的數據，包括移動互聯網數據、社交網路的數據等，這些結構化和非結構化的海量數據是零散的，也就是所謂的數據孤島，此時的這些數據並沒有什麼意義，數據採集就是將這些數據寫入數據倉庫中，把零散的數據整合在一起，對這些數據綜合起來進行分析。數據採集包括文件日誌的採集、資料庫日誌的採集、關系型資料庫的接入和應用程序的接入等。在數據量比較小的時候，可以寫個定時的腳本將日誌寫入存儲系統，但隨著數據量的增長，這些方法無法提供數據安全保障，並且運維困難，需要更強壯的解決方案。

Flume NG作為實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據，同時，對數據進行簡單處理，並寫到各種數據接收方(比如文本，HDFS，Hbase等)。Flume NG採用的是三層架構：Agent層，Collector層和Store層，每一層均可水平拓展。其中Agent包含Source，Channel和 Sink，source用來消費（收集）數據源到channel組件中，channel作為中間臨時存儲，保存所有source的組件信息，sink從channel中讀取數據，讀取成功之後會刪除channel中的信息。

NDC，Netease Data Canal，直譯為網易數據運河系統，是網易針對結構化資料庫的數據實時遷移、同步和訂閱的平台化解決方案。它整合了網易過去在數據傳輸領域的各種工具和經驗，將單機資料庫、分布式資料庫、OLAP系統以及下游應用通過數據鏈路串在一起。除了保障高效的數據傳輸外，NDC的設計遵循了單元化和平台化的設計哲學。

Logstash是開源的伺服器端數據處理管道，能夠同時從多個來源採集數據、轉換數據，然後將數據發送到您最喜歡的 「存儲庫」 中。一般常用的存儲庫是Elasticsearch。Logstash 支持各種輸入選擇，可以在同一時間從眾多常用的數據來源捕捉事件，能夠以連續的流式傳輸方式，輕松地從您的日誌、指標、Web 應用、數據存儲以及各種 AWS 服務採集數據。

Sqoop，用來將關系型資料庫和Hadoop中的數據進行相互轉移的工具，可以將一個關系型資料庫(例如Mysql、Oracle)中的數據導入到Hadoop(例如HDFS、Hive、Hbase)中，也可以將Hadoop(例如HDFS、Hive、Hbase)中的數據導入到關系型資料庫(例如Mysql、Oracle)中。Sqoop 啟用了一個 MapRece 作業（極其容錯的分布式並行計算）來執行任務。Sqoop 的另一大優勢是其傳輸大量結構化或半結構化數據的過程是完全自動化的。

流式計算是行業研究的一個熱點，流式計算對多個高吞吐量的數據源進行實時的清洗、聚合和分析，可以對存在於社交網站、新聞等的數據信息流進行快速的處理並反饋，目前大數據流分析工具有很多，比如開源的strom，spark streaming等。

Strom集群結構是有一個主節點（nimbus）和多個工作節點（supervisor）組成的主從結構，主節點通過配置靜態指定或者在運行時動態選舉，nimbus與supervisor都是Storm提供的後台守護進程，之間的通信是結合Zookeeper的狀態變更通知和監控通知來處理。nimbus進程的主要職責是管理、協調和監控集群上運行的topology（包括topology的發布、任務指派、事件處理時重新指派任務等）。supervisor進程等待nimbus分配任務後生成並監控worker（jvm進程）執行任務。supervisor與worker運行在不同的jvm上，如果由supervisor啟動的某個worker因為錯誤異常退出（或被kill掉），supervisor會嘗試重新生成新的worker進程。

當使用上游模塊的數據進行計算、統計、分析時，就可以使用消息系統，尤其是分布式消息系統。Kafka使用Scala進行編寫，是一種分布式的、基於發布/訂閱的消息系統。Kafka的設計理念之一就是同時提供離線處理和實時處理,以及將數據實時備份到另一個數據中心，Kafka可以有許多的生產者和消費者分享多個主題，將消息以topic為單位進行歸納；Kafka發布消息的程序稱為procer，也叫生產者，預訂topics並消費消息的程序稱為consumer，也叫消費者；當Kafka以集群的方式運行時，可以由一個服務或者多個服務組成，每個服務叫做一個broker，運行過程中procer通過網路將消息發送到Kafka集群，集群向消費者提供消息。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Procer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息。Kafka可以和Flume一起工作，如果需要將流式數據從Kafka轉移到hadoop，可以使用Flume代理agent，將Kafka當做一個來源source，這樣可以從Kafka讀取數據到Hadoop。

Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。它的作用主要有配置管理、名字服務、分布式鎖和集群管理。配置管理指的是在一個地方修改了配置，那麼對這個地方的配置感興趣的所有的都可以獲得變更，省去了手動拷貝配置的繁瑣，還很好的保證了數據的可靠和一致性，同時它可以通過名字來獲取資源或者服務的地址等信息，可以監控集群中機器的變化，實現了類似於心跳機制的功能。

二、數據存儲

Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。

HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。HBase是一種Key/Value系統，部署在hdfs上，克服了hdfs在隨機讀寫這個方面的缺點，與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用伺服器，來增加計算和存儲能力。

Phoenix，相當於一個Java中間件，幫助開發工程師能夠像使用JDBC訪問關系型資料庫一樣訪問NoSQL資料庫HBase。

Yarn是一種Hadoop資源管理器，可為上層應用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。Yarn由下面的幾大組件構成：一個全局的資源管理器ResourceManager、ResourceManager的每個節點代理NodeManager、表示每個應用的Application以及每一個ApplicationMaster擁有多個Container在NodeManager上運行。

Mesos是一款開源的集群管理軟體，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應用架構。

Redis是一種速度非常快的非關系資料庫，可以存儲鍵與5種不同類型的值之間的映射，可以將存儲在內存的鍵值對數據持久化到硬碟中，使用復制特性來擴展性能，還可以使用客戶端分片來擴展寫性能。

Atlas是一個位於應用程序與MySQL之間的中間件。在後端DB看來，Atlas相當於連接它的客戶端，在前端應用看來，Atlas相當於一個DB。Atlas作為服務端與應用程序通訊，它實現了MySQL的客戶端和服務端協議，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。Atlas啟動後會創建多個線程，其中一個為主線程，其餘為工作線程。主線程負責監聽所有的客戶端連接請求，工作線程只監聽主線程的命令請求。

Ku是圍繞Hadoop生態圈建立的存儲引擎，Ku擁有和Hadoop生態圈共同的設計理念，它運行在普通的伺服器上、可分布式規模化部署、並且滿足工業界的高可用要求。其設計理念為fast analytics on fast data。作為一個開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Ku不但提供了行級的插入、更新、刪除API，同時也提供了接近Parquet性能的批量掃描操作。使用同一份存儲，既可以進行隨機讀寫，也可以滿足數據分析的要求。Ku的應用場景很廣泛，比如可以進行實時的數據分析，用於數據可能會存在變化的時序數據應用等。

在數據存儲過程中，涉及到的數據表都是成千上百列，包含各種復雜的Query，推薦使用列式存儲方法，比如parquent,ORC等對數據進行壓縮。Parquet 可以支持靈活的壓縮選項，顯著減少磁碟上的存儲。

三、數據清洗

MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，」Map（映射）」和」Rece（歸約）」，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。

隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。

Oozie是用於Hadoop平台的一種工作流調度引擎，提供了RESTful API介面來接受用戶的提交請求(提交工作流作業)，當提交了workflow後，由工作流引擎負責workflow的執行以及狀態的轉換。用戶在HDFS上部署好作業(MR作業)，然後向Oozie提交Workflow，Oozie以非同步方式將作業(MR作業)提交給Hadoop。這也是為什麼當調用Oozie 的RESTful介面提交作業之後能立即返回一個JobId的原因，用戶程序不必等待作業執行完成（因為有些大作業可能會執行很久(幾個小時甚至幾天)）。Oozie在後台以非同步方式，再將workflow對應的Action提交給hadoop執行。

Azkaban也是一種工作流的控制引擎，可以用來解決有多個hadoop或者spark等離線計算任務之間的依賴關系問題。azkaban主要是由三部分構成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban將大多數的狀態信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、認證、調度以及對工作流執行過程中的監控等；Azkaban Executor Server用來調度工作流和任務，記錄工作流或者任務的日誌。

流計算任務的處理平台Sloth，是網易首個自研流計算平台，旨在解決公司內各產品日益增長的流計算需求。作為一個計算服務平台，其特點是易用、實時、可靠，為用戶節省技術方面（開發、運維）的投入，幫助用戶專注於解決產品本身的流計算需求。

四、數據查詢分析

Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。Hive本身不存儲和計算數據，它完全依賴於HDFS和MapRece。可以將Hive理解為一個客戶端工具，將SQL操作轉換為相應的MapRece jobs，然後在hadoop上面運行。Hive支持標準的SQL語法，免去了用戶編寫MapRece程序的過程，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece 、編程能力較弱與不擅長Java語言的用戶能夠在HDFS大規模數據集上很方便地利用SQL 語言查詢、匯總、分析數據。

Hive是為大數據批量處理而生的，Hive的出現解決了傳統的關系型資料庫(MySql、Oracle)在大數據處理上的瓶頸 。Hive 將執行計劃分成map->shuffle->rece->map->shuffle->rece…的模型。如果一個Query會被編譯成多輪MapRece，則會有更多的寫中間結果。由於MapRece執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。在Hive的運行過程中，用戶只需要創建表，導入數據，編寫SQL分析語句即可。剩下的過程由Hive框架自動的完成。

Impala是對Hive的一個補充，可以實現高效的SQL查詢。使用Impala來實現SQL on Hadoop，用來進行大數據實時查詢分析。通過熟悉的傳統關系型資料庫的SQL風格來操作大數據，同時數據也是可以存儲到HDFS和HBase中的。Impala沒有再使用緩慢的Hive+MapRece批處理，而是通過使用與商用並行關系資料庫中類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。Impala將整個查詢分成一執行計劃樹，而不是一連串的MapRece任務，相比Hive沒了MapRece啟動時間。

Hive 適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢，Impala給數據人員提供了快速實驗，驗證想法的大數據分析工具，可以先使用Hive進行數據轉換處理，之後使用Impala在Hive處理好後的數據集上進行快速的數據分析。總的來說：Impala把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的map->rece模式，以此保證Impala有更好的並發性和避免不必要的中間sort與shuffle。但是Impala不支持UDF，能處理的問題有一定的限制。

Spark擁有Hadoop MapRece所具有的特點，它將Job中間輸出結果保存在內存中，從而不需要讀取HDFS。Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。Spark 是在 Scala 語言中實現的，它將 Scala 用作其應用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。

Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬蟲。

Solr用Java編寫、運行在Servlet容器（如Apache Tomcat或Jetty）的一個獨立的企業級搜索應用的全文搜索伺服器。它對外提供類似於Web-service的API介面，用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML文件，生成索引；也可以通過Http Get操作提出查找請求，並得到XML格式的返回結果。

Elasticsearch是一個開源的全文搜索引擎，基於Lucene的搜索伺服器，可以快速的儲存、搜索和分析海量的數據。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。

還涉及到一些機器學習語言，比如，Mahout主要目標是創建一些可伸縮的機器學習演算法，供開發人員在Apache的許可下免費使用；深度學習框架Caffe以及使用數據流圖進行數值計算的開源軟體庫TensorFlow等，常用的機器學習演算法比如，貝葉斯、邏輯回歸、決策樹、神經網路、協同過濾等。

五、數據可視化

對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。主流的BI平台比如，國外的敏捷BI Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數（可點擊這里免費試用）等。

在上面的每一個階段，保障數據的安全是不可忽視的問題。

基於網路身份認證的協議Kerberos，用來在非安全網路中，對個人通信以安全的手段進行身份認證，它允許某實體在非安全網路環境下通信，向另一個實體以一種安全的方式證明自己的身份。

控制許可權的ranger是一個Hadoop集群許可權框架，提供操作、監控、管理復雜的數據許可權，它提供一個集中的管理機制，管理基於yarn的Hadoop生態圈的所有數據許可權。可以對Hadoop生態的組件如Hive，Hbase進行細粒度的數據訪問控制。通過操作Ranger控制台，管理員可以輕松的通過配置策略來控制用戶訪問HDFS文件夾、HDFS文件、資料庫、表、欄位許可權。這些策略可以為不同的用戶和組來設置，同時許可權可與hadoop無縫對接。