📖 ZKIZ Archives


深度解析LinkedIn大數據平台

http://newshtml.iheima.com/2014/0812/144872.html
日誌幾乎與計算機同時產生的,它是許多分佈式數據系統和實時應用結構的核心。但是大多數軟件工程師對他們不是很熟悉。在這裡,我們將聚焦LinkedIn大數據平台的深度解析,探討日誌是什麼,如何在數據集成、實時處理和系統構建中使用日誌等內容。
 
我在六年前的一個令人興奮的時刻加入到LinkedIn公司。從那個時候開始我們就破解單一的、集中式數據庫的限制,並且啟動到特殊的分佈式系統套件的轉換。這是一件令人興奮的事情:我們構建、部署,而且直到今天仍然在運行的分佈式圖形數據庫、分佈式搜索後端、Hadoop安裝以及第一代和第二代鍵值數據存儲。
 
從這一切裡我們體會到的最有益的事情是我們構建的許多東西的核心裡都包含一個簡單的理念:日誌。有時候也稱作預先寫入日誌或者提交日誌或者事務日誌,日誌幾乎在計算機產生的時候就存在,同時它還是許多分佈式數據系統和實時應用結構的核心。
 
不懂得日誌,你就不可能完全懂得數據庫,NoSQL存儲,鍵值存儲,複製,paxos,Hadoop,版本控制以及幾乎所有的軟件系統;然而大多數軟件工程師對它們不是很熟悉。我願意改變這種現狀。在這篇博客文章裡,我將帶你瀏覽你必須瞭解的有關日誌的所有的東西,包括日誌是什麼,如何在數據集成、實時處理和系統構建中使用日誌等。
 
第一部分:日誌是什麼?
 
\
 
 
日誌是一種簡單的不能再簡單的存儲抽象。它是一個只能增加的,完全按照時間排序的一系列記錄。日誌看起來如下:
 
我們可以給日誌的末尾添加記錄,並且可以從左到右讀取日誌記錄。每一條記錄都指定了一個唯一的有一定順序的日誌記錄編號。
 
日誌記錄的排序是由「時間」來確定的,這是因為位於左邊的日誌記錄比位於右邊的要早些。日誌記錄編號可以看作是這條日誌記錄的「時間戳」。在一開始就把這種排序說成是按時間排序顯得有點多餘 ,不過 ,與任何一個具體的物理時鐘相比,時間屬性是非常便於使用的屬性。在我們運行多個分佈式系統的時候,這個屬性就顯得非常重要。
 
對於這篇討論的目標而言,日誌記錄的內容和格式不怎麼重要。另外提醒一下,在完全耗盡存儲空間的情況下,我們不可能再給日誌添加記錄。稍後我們將會提到這個問題。
 
日誌並不是完全不同於文件或者數據表的。文件是由一系列字節組成,表是由一系列記錄組成,而日誌實際上只是按照時間順序存儲記錄的 一種數據表或者文件。
 
此時,你可能奇怪為什麼要討論這麼簡單的事情呢?不同環境下的一個只可增加的有一定順序的日誌記錄是怎樣與數據系統關聯起來的呢?答案是日誌有其特定的應用目標:它記錄了什麼時間發生了什麼事情。 而對分佈式數據系統許多方面而言, 這才是問題的真正核心。
 
不過,在我們進行更加深入的討論之前,讓我先澄清有些讓人混淆的概念。每個編程人員都熟悉另一種日誌記錄——應用使用syslog或者log4j可能寫入到本地文件裡的沒有結構的錯誤信息或者追蹤信息。為了區分開來,我們把這種情形的日誌記錄稱為「應用日誌記錄」。應用日誌記錄是我在這兒所說的日誌的一種低級的變種。最大的區別是:文本日誌意味著主要用來方便人們閱讀,而我所說明的「日誌」或者「數據日誌」的建立是方便程序訪問。
 
(實際上,如果你對它進行深入的思考,那麼人們讀取某個機器上的日誌這種理念有些不順應時代潮流。當涉及到許多服務和服務器的時候,這種方法很快就變成一個難於管理的方式,而且為了認識多個機器的行為,日誌的目標很快就變成查詢和圖形化這些行為的輸入了——對多個機器的某些行為而言,文件裡的英文形式的文本同這兒所描述的這種結構化的日誌相比幾乎就不適合了。)
 
數據庫日誌
 
我不知道日誌概念起源於何處-可能它就像二進制搜索一樣:發明者認為它太簡單而不能當作一項發明。它早在IBM的系統R出現時候就出現了。數據庫裡的用法是在崩潰的時候用它來同步各種數據結構和索引。為了保證操作的原子性和持久性,在對數據庫維護的所有各種數據結構做更改之前,數據庫把即將修改的信息謄寫到日誌裡。日誌記錄了發生了什麼,而且其中的每個表或者索引都是一些數據結構或者索引的歷史映射。由於日誌是即刻永久化的,可以把它當作崩潰發生時用來恢復其他所有永久性結構的可信賴數據源。
 
隨著時間的推移,日誌的用途從實現ACID細節成長為數據庫間複製數據的一種方法。利用日誌的結果就是發生在數據庫上的更改順序與遠端複製數據庫上的更改順序需要保持完全同步。
 
Oracle,MySQL 和PostgreSQL都包括用於給備用的複製數據庫傳輸日誌的日誌傳輸協議。Oracle還把日誌產品化為一個通用的數據訂閱機制,這樣非Oracle數據訂閱用戶就可以使用XStreams和GoldenGate訂閱數據了,MySQL和PostgreSQL上的類似的實現則成為許多數據結構的關鍵組件。
 
正是由於這樣的起源,機器可識別的日誌的概念大部分都被侷限在數據庫內部。日誌用做數據訂閱的機制似乎是偶然出現的,不過要把這種 抽象用於支持所有類型的消息傳輸、數據流和實時數據處理是不切實際的。
 
分佈式系統日誌
 
日誌解決了兩個問題:更改動作的排序和數據的分發,這兩個問題在分佈式數據系統裡顯得尤為重要。協商出一致的更改動作的順序(或者說保持各個子系統本身的做法,但可以進行存在副作用的數據拷貝)是分佈式系統設計的核心問題之一。
 
以日誌為中心實現分佈式系統是受到了一個簡單的經驗常識的啟發,我把這個經驗常識稱為狀態機複製原理:如果兩個相同的、確定性的進程從同一狀態開始,並且以相同的順序獲得相同的輸入,那麼這兩個進程將會生成相同的輸出,並且結束在相同的狀態。
 
這也許有點難以理解,讓我們更加深入的探討,弄懂它的真正含義。
 
確定性意味著處理過程是與時間無關的,而且任何其他「外部的「輸入不會影響到處理結果。例如,如果一個程序的輸出會受到線程執行的具體順序影響,或者受到gettimeofday調用、或者其他一些非重複性事件的影響,那麼這樣的程序一般最有可能被認為是非確定性的。
 
進程狀態是進程保存在機器上的任何數據,在進程處理結束的時候,這些數據要麼保存在內存裡,要麼保存在磁盤上。
 
以相同的順序獲得相同輸入的地方應當引起注意-這就是引入日誌的地方。這兒有一個重要的常識:如果給兩段確定性代碼相同的日誌輸入,那麼它們就會生成相同的輸出。
 
分佈式計算這方面的應用就格外明顯。你可以把用多台機器一起執行同一件事情的問題縮減為實現分佈式一致性日誌為這些進程輸入的問題。這兒日誌的目的是把所有非確定性的東西排除在輸入流之外,來確保每個複製進程能夠同步地處理輸入。
 
當你理解了這個以後,狀態機複製原理就不再複雜或者說不再深奧了:這或多或少的意味著「確定性的處理過程就是確定性的」。不管怎樣,我都認為它是分佈式系統設計裡較常用的工具之一。
 
這種方式的一個美妙之處就在於索引日誌的時間戳就像時鐘狀態的一個副本——你可以用一個單獨的數字描述每一個副本,這就是經過處理的日誌的時間戳。時間戳與日誌一一對應著整個副本的狀態。
 
由於寫進日誌的內容的不同,也就有許多在系統中應用這個原則的不同方式。舉個例子,我們記錄一個服務的請求,或者服務從請求到響應的狀態變化,或者它執行命令的轉換。理論上來說,我們甚至可以為每一個副本記錄一系列要執行的機器指令或者調用的方法名和參數。只要兩個進程用相同的方式處理這些輸入,這些進程就會保持副本的一致性。
 
一千個人眼中有一千種日誌的用法。數據庫工作者通常區分物理日誌和邏輯日誌。物理日誌就是記錄每一行被改變的內容。邏輯日誌記錄的不是改變的行而是那些引起行的內容被改變的SQL語句(insert,update和delete語句)。
 
分佈式系統通常可以寬泛分為兩種方法來處理數據和完成響應「狀態機器模型」通常引用一個主動—主動的模型——也就是我們為之記錄請求和響應的對象。對此進行一個細微的更改,稱之為「預備份模型」,就是選出一個副本做為leader,並允許它按照請求到達的時間來進行處理並從處理過程中輸出記錄其狀態改變的日誌。其他的副本按照leader狀態改變的順序而應用那些改變,這樣他們之間達到同步,並能夠在leader失敗的時候接替leader的工作。
 
\
 
                    primary-Backup                       State Machine Replication
 
為了理解兩種方式的不同,我們來看一個不太嚴謹的例子。假定有一個算法服務的副本,保持一個獨立的數字作為它的狀態(初始值為0),並對這個值進行加法和乘法運算。主動—主動方式應該會輸出所進行的變換,比如「+1」,「*2」等。每一個副本都會應用這些變換,從而得到同樣的解集。主動—被動方式將會有一個獨立的主體執行這些變換並輸出結果日誌,比如「1」,「3」,「6」等。這個例子也清楚的展示了為什麼說順序是保證各副本間一致性的關鍵:一次加法和乘法的順序的改變將會導致不同的結果。
 
分佈式日誌可以理解為一致性問題模型的數據結構。因為日誌代表了後續追加值的一系列決策。你需要重新審視Paxos算法簇,儘管日誌模塊是他們最常見的應用。 在Paxos算法中,它通常通過使用稱之為多paxos的協議,這種協議將日誌建模為一系列的問題,在日誌中每個問題都有對應的部分。在ZAB, RAFT等其它的協議中,日誌的作用尤為突出,它直接對維護分佈式的、一致性的日誌的問題建模。
 
我懷疑的是,我們就歷史發展的觀點是有偏差的,可能是由於過去的幾十年中,分佈式計算的理論遠超過了其實際應用。在現實中,共識的問題是有點太簡單了。計算機系統很少需要決定單個值,他們幾乎總是處理成序列的請求。這樣的記錄,而不是一個簡單的單值寄存器,自然是更加抽象。
 
此外,專注於算法掩蓋了 抽象系統需要的底層的日誌。我懷疑,我們最終會把日誌中更注重作為一個商品化的基石,不論其是否以同樣的方式 實施的,我們經常談論一個哈希表而不是糾結我們得到是不是具體某個細節的哈希表,例如線性或者帶有什麼什麼其它變體哈希表。日誌將成為一種大眾化的接口,為大多數算法和其實現提升提供最好的保證和最佳的性能。
 
變更日誌101:表與事件的二相性
 
讓我們繼續聊數據庫。數據庫中存在著大量變更日誌和表之間的二相性。這些日誌有點類似借貸清單和銀行的流程,數據庫表就是當前的盈餘表。如果你有大量的變更日誌,你就可以使用這些變更用以創建捕獲當前狀態的表。這張表將記錄每個關鍵點(日誌中一個特別的時間點)的狀態信息。這就是為什麼日誌是非常基本的數據結構的意義所在:日誌可用來創建基本表,也可以用來創建各類衍生表。同時意味著可以存儲非關係型的對象。
 
這個流程也是可逆的:如果你正在對一張表進行更新,你可以記錄這些變更,並把所有更新的日誌發佈到表的狀態信息中。這些變更日誌就是你所需要的支持准實時的克隆。基於此,你就可以清楚的理解表與事件的二相性: 表支持了靜態數據而日誌捕獲變更。日誌的魅力就在於它是變更的完整記錄,它不僅僅捕獲了表的最終版本的內容,它還記錄了曾經存在過的其它版本的信息。日誌實質上是表歷史狀態的一系列備份。
 
這可能會引起你對源代碼的版本管理。源代碼管理和數據庫之間有密切關係。版本管理解決了一個大家非常熟悉的問題,那就是什麼是分佈式數據系統需要解決的——時時刻刻在變化著的分佈式管理。版本管理系統通常以補丁的發布為基礎,這實際上可能是一個日誌。您可以直接對當前類似於表中的代碼做出「快照」互動。你會注意到,與其他分佈式狀態化系統類似,版本控制系統 當你更新時會複製日誌,你希望的只是更新補丁並將它們應用到你的當前快照中。
 
最近,有些人從Datomic——一家銷售日誌數據庫的公司得到了一些想法。這些想法使他們對如何在他們的系統應用這些想法有了開闊的認識。 當然這些想法不是只針對這個系統,他們會成為十多年分佈式系統和數據庫文獻的一部分。
 
這可能似乎有點過於理想化。但是不要悲觀!我們會很快把它實現。
 
接下來的內容
 
在這篇文章的其餘部分,我將試圖說明日誌除了可用在分佈式計算或者抽象分佈式計算模型內部之外,還可用在哪些方面。其中包括:
 
數據集成-讓機構的全部存儲和處理系統裡的所有數據很容易地得到訪問。
 
實時數據處理-計算生成的數據流。
 
分佈式系統設計-實際應用的系統是如何通過使用集中式日誌來簡化設計的。
 
所有這些用法都是通過把日誌用做單獨服務來實現的。
 
在上面任何一種用法裡,日誌的用途開始都是使用了日誌所能提供的某個簡單功能:生成永久的、可重現的歷史記錄。令人意外的是,問題的核心是可以讓多少台機器以特定的方式,按照自身的速度重現歷史記錄的能力。
 
第二部分:數據集成
 
請讓我首先解釋 一下「數據集成」是什麼意思,還有為什麼我覺得它很重要,之後我們再來看看它和日誌有什麼關係。
 
數據集成就是將數據組織起來,使得在與其有關的服務和系統中可以訪問它們。「數據集成」(data integration)這個短語應該不止這麼簡單,但是我找不到一個更好的解釋。而更常見的術語 ETL 通常只是覆蓋了數據集成的一個有限子集(譯註:ETL,Extraction-Transformation-Loading的縮寫,即數據提取、轉換和加載)——相對於關係型數據倉庫。但我描述的東西很大程度上可以理解為,將ETL推廣至實時系統和處理流程。
 
你一定不會聽到數據集成就興趣盎然屏住呼吸,並且天花亂墜的想到關於大數據的概念,不過,我相信世俗的問題「讓數據可被訪問」 是一個組織應該關注的有價值的事情。
 
對數據的高效使用遵循一種馬斯洛的需要層次理論 。金字塔的基礎部分包括捕獲所有相關數據,能夠將它們全部放到適當的處理環境(那個環境應該是一個奇妙的實時查詢系統,或者僅僅是文本文件和python腳本)。這些數據需要以統一的方式建模,這樣就可以方便讀取和數據處理。如果這種以統一的方式捕獲數據的基本需求得到滿足,那麼就可以在基礎設施上以若干種方法處理這些數據——映射化簡(MapReduce),實時查詢系統,等等。
 
很明顯,有一點值得注意:如果沒有可靠的、完整的數據流,Hadoop集群除了象昂貴的且難於安裝的空間取暖器哪樣外不會做更多事情了。一旦數據和處理可用,人們就會關心良好數據模型和一致地易於理解的語法哪些更細緻的問題。最後,人們才會關注更加高級的處理——更好的可視化、報表以及處理和預測算法。
 
以我的經驗,大多數機構在數據金字塔的底部存在巨大的漏洞——它們缺乏可靠的、完整的數據流——而是打算直接跳到高級數據模型技術上。這樣做完全是反著來做的。
 
因此,問題是我們如何構建通過機構內所有數據系統的可靠的數據流。
 
數據集成:兩個併發症
 
兩種趨勢使數據集成變得更困難。
 
事件數據管道
 
第一個趨勢是增長的事件數據(event data)。事件數據記錄的是發生的事情,而不是存在的東西。在web系統中,這就意味著用戶活動日誌,還有為了可靠的操作以及監控數據中心的機器的目的,所需要記錄的機器級別的事件和統計數字。人們傾向稱它們為「日誌數據」,因為它們經常被寫到應用的日誌中,但是這混淆了形式與功能。這種數據位於現代web的中心:歸根結底,Google的資產是由這樣一些建立在點擊和映像基礎之上的相關管道所生成的——那也就是事件。
 
這些東西並不是僅限於網絡公司,只是網絡公司已經完全數字化,所以它們更容易用設備記錄。財務數據一直是面向事件的。RFID(無線射頻識別)將這種跟蹤能力賦予物理對象。我認為這種趨勢仍將繼續,伴隨著這個過程的是傳統商務活動的數字化。
 
這種類型的事件數據記錄下發生的事情,而且往往比傳統數據庫應用要大好幾個數量級。這對於處理提出了重大挑戰。
 
專門的數據系統的爆發
 
第二個趨勢來自於專門的數據系統的爆發,通常這些數據系統在最近的五年中開始變得流行,並且可以免費獲得。專門的數據系統是為OLAP,搜索, 簡單在線存儲, 批處理, 圖像分析,等等而存在的。
 
更多的不同類型數據的組合,以及將這些數據存放到更多的系統中的願望,導致了一個巨大的數據集成問題。
 
日誌結構數據流
 
為了處理系統之間的數據流,日誌是最自然的數據結構。其中的秘訣很簡單:
 
將所有組織的數據提取出來,並將它們放到一個中心日誌,以便實時查閱。
 
每個邏輯數據源都可以建模為它自己的日誌。一個數據源可以是一個應用程序的事件日誌(如點擊量或者頁面瀏覽量),或者是一個接受修改的數據庫表。每個訂閱消息的系統都儘可能快的從日誌讀取信息,將每條新的記錄保存到自己的存儲,並且提升其在日誌中的地位。訂閱方可以是任意一種數據系統 —— 一個緩存,Hadoop,另一個網站中的另一個數據庫,一個搜索系統,等等。
 
\
 
例如,日誌針對每個更改給出了邏輯時鐘的概念,這樣所有的訂閱方都可以被測量。推導不同的訂閱系統的狀態也因此變得相對簡單的多,因為每個系統都有一個讀取動作的「時間點」。
 
為了讓這個顯得更具體,我們考慮一個簡單的案例,有一個數據庫和一組緩存服務器集群。日誌提供了一種同步更新所有這些系統,並推導出每一個系統的接觸時間點的方法。我們假設寫了一條日誌X,然後需要從緩存做一次讀取。如果我們想保證看到的不是陳舊的數據,我們只需保證沒有從任何尚未複製X的緩存中讀取即可。
 
日誌也起到緩存的作用,使數據生產與數據消費相同步。由於許多原因這個功能很重要,特別是在多個訂閱方消費數據的速度各不相同的時候。這意味著一個訂閱數據系統可以宕機,或者下線維護,之後重新上線以後再趕上來:訂閱方按照自己控制的節拍來消費數據。批處理系統,如Hadoop或者是一個數據倉庫,或許只是每小時或者每天消費一次數據,而實時查詢系統可能需要及時到秒。由於無論是原始數據源還是日誌,都沒有各種目標數據系統的相關知識,因此消費方系統可以被添加和刪除,而無需傳輸管道的變化。
 
「每個工作數據管道設計得就像是一個日誌;每個損壞的數據管道以其自己的方式損壞。」—Count Leo Tolstoy (由作者翻譯)
 
特別重要的是:目標系統只知道日誌,不知道數據源系統的任何細節。消費方系統自身無需考慮數據到底是來自於一個RDBMS(關係型數據庫管理系統Relational Database Management System),一種新型的鍵值存儲,或者它不是由任何形式的實時查詢系統所生成的。這似乎是一個小問題,但實際上是至關重要的。
 
這裡我使用術語「日誌」取代了「消息系統」或者「發佈—訂閱」,因為它在語義上更明確,並且對支持數據複製的實際實現這樣的需求,有著更接近的描述。我發現「發佈訂閱」並不比間接尋址的消息具有更多的含義——如果你比較任何兩個發佈—訂閱的消息傳遞系統的話,你會發現他們承諾的是完全不同的東西,而且大多數模型在這一領域都不是有用的。你可以認為日誌是一種消息系統,它具有持久性保證和強大的訂閱語義。在分佈式系統中,這個通信模型有時有個(有些可怕的)名字叫做原子廣播。
 
值得強調的是,日誌仍然只是基礎設施。這並不是管理數據流這個故事的結束:故事的其餘部分圍繞著元數據,模式,兼容性,以及處理數據結構的所有細節及其演化。除非有一種可靠的,一般的方法來處理數據流運作,語義在其中總是次要的細節。
 
在LinkefIn(SNS社交網站)
 
在LinkedIn從集中式關係數據庫向分佈式系統集合轉化的過程中,我看到這個數據集成問題迅速演變。
 
現在主要的數據系統包括:
 
搜索
 
社交圖譜
 
Voldemort (鍵值存儲)(譯註:一種分佈式數據庫)
 
Espresso (文檔存儲)
 
推舉引擎
 
OLAP查詢引擎(譯註:OLAP聯機分析技術)
 
Hadoop
 
Terradata
 
Ingraphs (監控圖表和指標服務)
 
這些都是專門的分佈式系統,在其專業領域提供先進的功能。
 
這種使用日誌作為數據流的思想,甚至在我到這裡之前就已經與LinkedIn相伴了。我們開發的一個最早的基礎設施之一,是一種稱為databus 的服務,它在我們早期的Oracle表上提供了一種日誌緩存抽象,可伸縮訂閱數據庫修改,這樣我們就可以很好支持我們的社交網絡和搜索索引。
 
我會給出一些歷史並交代一下上下文。我首次參與到這些大約是在2008年左右,在我們轉移鍵值存儲之後。我的下一個項目是讓一個工作中的Hadoop配置演進,並給其增加一些我們的推薦流程。由於缺乏這方面的經驗,我們自然而然的安排了數週計劃在數據的導入導出方面,剩下的時間則用來實現奇妙的預測算法。這樣我們就開始了長途跋涉。
 
我們本來計劃是僅僅將數據從現存的Oracle數據倉庫中剖離。但是我們首先發現將數據從Oracle中迅速取出是一種黑暗藝術。更糟的是,數據倉庫的處理過程與我們為Hadoop而計劃的批處理生產過程不適合——其大部分處理都是不可逆轉的,並且與即將生成的報告具體相關。最終我們採取的辦法是,避免使用數據倉庫,直接訪問源數據庫和日誌文件。最後,我們為了加載數據到鍵值存儲並生成結果,實現了另外一種管道。
 
這種普通的數據複製最終成為原始開發項目的主要內容之一。糟糕的是,在任何時間任意管道都有一個問題,Hadoop系統很大程度上是無用的——在錯誤的數據基礎上運行奇特的算法,只會產生更多的錯誤數據。
 
雖然我們已經以一種通用的方式創建事物,但是每個數據源都需要自定義配置安裝。這也被證明是巨量錯誤與失敗的根源。我們在Hadoop上實現的網站功能已經開始流行起來,同時我們發現我們有一長串感興趣的工程師。每個用戶都有他們想要集成的一系列系統,他們想要的一系列新數據源。
 
古希臘時代的 ETL(提取轉換加載Extract Transform and Load)。並沒有太多變化
 
有些東西在我面前開始漸漸清晰起來。
 
首先,我們已建成的通道雖然有一些雜亂,但實質上它們是很有價值的。在採用諸如Hadoop的新的處理系統生成可用數據的過程,它開啟了大量的可能性。 基於這些數據過去很難實現的計算,如今變為可能。 許多新的產品和分析技術都來源於把分片的數據放在一起,這些數據過被鎖定在特定的系統中。
 
第二, 眾所周知,可靠的數據加載需要數據通道的深度支持。如果我們可以捕獲所有我們需要的結構,我就就可以使得Hadoop數據全自動的加載,這樣就不需要額外的操作來增加新的數據源或者處理模式變更–數據就會自動的出現在HDFS,Hive表就會自動的生成對應於新數據源的恰當的列。
 
第三,我們的數據覆蓋率仍然非常低。如果你查看存儲於Hadoop中的可用的Linked 數據的全部百分比,它仍然是不完整的。花費大量的努力去使得各個新的數據源運轉起來,使得數據覆蓋度完整不是一件容易的事情。
 
我們正在推行的,為每個數據源和目標增建客戶化數據加載,這種方式很顯然是不可行的。我們有大量的數據系統和數據倉庫。把這些系統和倉庫聯繫起來,就會導致任意一對系統會產生如下所示的客戶化通道。
 
\
 
需要注意的是:數據是雙向流動的:例如許多系統諸如數據庫和Hadoop既是數據轉化的來源又是數據轉化的目的地。這就意味著我們我們不必為每個系統建立兩個通道:一個用於數據輸入,一個用於數據輸出。
 
這顯然需要一大群人,而且也不具有可操作性。隨著我們接近完全連接,最終我們將有差不多O(N2)條管道。
 
替代的,我們需要像這樣通用的東西:
 
\
 
我們需要儘可能的將每個消費者與數據源隔離。理想情形下,它們應該只與一個單獨的數據倉庫集成,並由此讓他們能訪問到所有東西。
 
這個思想是增加一個新的數據系統——或者它是一個數據源或者它是一個數據目的地——讓集成工作只需連接到一個單獨的管道,而無需連接到每個數據消費方。
 
這種經歷使得我關注創建Kafka來關聯我們在消息系統所見的與數據庫和分佈式系統內核所發佈的日誌。我們希望一些實體作為中心的通道,首先用於所有的活動數據,逐步的擴展到其他用途,例如Hadoop外的數據實施,數據監控等。
 
在相當長的時間內,Kafka是獨一無二的底層產品,它既不是數據庫,也不是日誌文件收集系統,更不是傳統的消息系統。但是最近Amazon提供了非常類似Kafka的服務,稱之為Kinesis。相似度包括了分片處理的方式,數據的保持,甚至包括在Kafka API中,有點特別的高端和低端消費者分類。我很開心看到這些,這表明了你已經創建了很好的底層協議,AWS已經把它作為服務提供。他們對此的期待與我所描述的吻合:通道聯通了所有的分佈式系統,諸如DynamoDB,RedShift,S3等,它同時作為使用EC2進行分佈式流處理的基礎。
 
與ETL和數據倉庫的關係
 
我們再來聊聊數據倉庫。數據倉庫是清洗和歸一數據結構用於支撐數據分析的倉庫。這是一個偉大的理念。對不熟悉數據倉庫概念的人來說,數據倉庫方法論包括了:週期性的從數據源抽取數據,把它們轉化為可理解的形式,然後把它導入中心數據倉庫。對於數據集中分析和處理,擁有高度集中的位置存放全部數據的原始副本是非常寶貴的資產。在高層級上,也許你抽取和加載數據的順序略微調整,這個方法論不會有太多變化,無論你使用傳統的數據倉庫Oracle還是Teradata或者Hadoop。
 
數據倉庫是極其重要的資產,它包含了原始的和規整的數據,但是實現此目標的機制有點過時了。
 
對以數據為中心的組織關鍵問題是把原始的歸一數據聯結到數據倉庫。數據倉庫是批處理的基礎查詢:它們適用於各類報表和臨時性分析,特別是當查詢包含了簡單的計數、聚合和過濾。但是如果一個批處理系統僅僅包含了原始的完整的數據的數據倉庫,這就意味著這些數據對於實時數據處理、搜索索引和系統監控等實時的查詢是不可用的。
 
依我之見,ETL包括兩件事:首先,它是抽取和數據清洗過程–特別是釋放被鎖在組織的各類系統中的數據,移除系統專有的無用物。第二,依照數據倉庫的查詢重構數據。例如使其符合關係數據庫類型系統,強制使用星號、雪花型模式,或者分解為高性能的柱狀格式等。合併這兩者是有困難的。這些規整的數據集應當可以在實時或低時延處理中可用,也可以在其它實施存儲系統索引。
 
在我看來,正是因為這個原因有了額外好處:使得數據倉庫ETL更具了組織級的規模。數據倉庫的精典問題是數據倉庫負責收集和清洗組織中各個組所生成的全部數據。各組織的動機是不同的,數據的生產者並不知曉在數據倉庫中數據的使用情況,最終產生的數據很難抽取,或者需要花費規模化的轉化才可以轉化為可用的形式。當然, 中心團隊不可能恰到好處的掌握規模,使得這規模剛好與組織中其它團隊相匹配,因此數據的覆蓋率常常差別很大,數據流是脆弱的同時變更是緩慢的。
 
較好的方法是有一個中心通道,日誌和用於增加數據的定義良好的API。與通道集成的且提供良好的結構化的數據文件的職責依賴於數據的生產者所生成的數據文件。這意味著在設計和實施其它系統時應當考慮數據的輸出以及輸出的數據如何轉化為結構良好的形式並傳遞給中心通道。增加新的存儲系統倒是不必因為數據倉庫團隊有一個中心結點需要集成而關注數據倉庫團隊。數據倉庫團隊僅需處理簡單的問題,例如從中心日誌中加載結構化的數據,向其它周邊系統實施個性化的數據轉化等。
 
\
 
如圖所示:當考慮在傳統的數據倉庫之外增加額外的數據系統時,組織結構的可擴展性顯得尤為重要。例如,可以考慮為組織的完整的數據集提供搜索功能。或者提供二級的數據流監控實時數據趨勢和告警。無論是這兩者中的哪一個,傳統的數據倉庫架構甚至於Hadoop聚簇都不再適用。更糟的是,ETL的流程通道的目的就是支持數據加載,然而ETL似乎無法輸出到其它的各個系統,也無法通過引導程序,使得這些外圍的系統的各個架構成為適用於數據倉庫的重要資產。這就不難解釋為什麼組織很難輕鬆的使用它的全部數據。反之,如果組織已建立起了一套標準的、結構良好的數據,那麼任何新的系統要使用這些數據僅僅需要與通道進行簡單的集成就可以實現。
 
這種架構引出了數據清理和轉化在哪個階段進行的不同觀點:
 
由數據的生產者在把數據增加到公司全局日誌之前。
 
在日誌的實時轉化階段進行,這將會產生一個新的轉化日誌。
 
在向目標系統加載數據時,做為加載過程的一部分進行。
 
理想的模形是:由數據的生產者在把數據發佈到日誌之前對數據進行清理。這樣可以確保數據的權威性,不需要維護其它的遺留物例如為數據產生的特殊處理代碼或者維護這些數據的其它的存儲系統。這些細節應當由產生數據的團隊來處理,因為他們最瞭解他們自己的數據。這個階段所使用的任何邏輯都應該是無損的和可逆的。
 
任何可以實時完成的增值轉化類型都應當基於原始日誌進行後期處理。這一過程包括了事件數據的會話流程,或者增加大眾感興趣的衍生字段。原始的日誌仍然是可用的,但是這種實時處理產生的衍生日誌包含了參數數據。
 
最終,只有針對目標系統的聚合需要做了加載流程的一部分。它包括了把數據轉化成特定的星型或者雪花狀模式,從而用於數據倉庫的分析和報表。因為在這個階段,大部分自然的映射到傳統的ETL流程中,而現在它是在一個更加乾淨和規整的數據流集在進行的,它將會更加的簡單。
 
日誌文件和事件
 
我們再來聊聊這種架構的優勢:它支持解耦和事件驅動的系統。
 
在網絡行業取得活動數據的典型方法是把它記為文本形式的日誌,這些文本文件是可分解進入數據倉庫或者Hadoop,用於聚合和查詢處理的。由此產生的問題與所有批處理的ETL的問題是相同的:它耦合了數據流進入數據倉庫系統的能力和流程的調度。
 
在LinkedIn中,我們已經以中心日誌的方式構建了事件數據處理。我們正在使用Kafka做為中心的、多訂閱者事件日誌。我們已經定義了數百種事件類型,每種類型都會捕獲用於特定類型動作的獨特的屬性。這將會覆蓋包括頁面視圖、表達式、搜索以及服務調用、應用異常等方方面面。
 
為了進一步理解這一優勢:設想一個簡單的事務–在日誌頁面顯示已發佈的日誌。這個日誌頁面應當只包括顯示日誌所需要的邏輯。然而,在相當多的動態站點中,日誌頁面常常變的添加了很多與顯示日誌無關的邏輯。例如,我們將對如下的系統進行集成:
 
需要把數據傳送到Hadoop和數據倉庫中用於離線數據處理。
 
需要對視圖進行統計,確保視圖訂閱者不會攻擊一些內容片段。
 
需要聚合這些視圖,視圖將用於作業發佈者的分析頁面顯示。
 
需要記錄視圖以確保我們為作業推薦的使用者提供了恰當的印象覆蓋,我們不想一次次的重複同樣的事情。
 
推薦系統需要記錄日誌用於正確的跟蹤作業的普及度。
 
等等。
 
不久,簡單的作業顯示變得相當的複雜。我們增加了作業顯示的其它終端——移動終端應用等——這些邏輯必須繼續存在,複雜度不斷的增加。更糟的是我們需要與之做接口交互的系統現在是錯綜複雜的–在為顯示日作業而工作的工程師們需要知曉多個其它系統和它們的特徵,才可以確保它們被正確的集成了。這僅僅是問題的簡單版本,真實的的應用系統只會更加的複雜。
 
「事件驅動」的模式提供了一種簡化這類問題的機制。作業顯示頁面現在只顯示作業並記錄與正在顯示的作業,作業訂閱者相關的其它屬性,和其它與作業顯示相關的其它有價值的屬性。每個與此相關的其它系統諸如推薦系統、安全系統、作業推送分析系統和數據倉庫,所有這些只是訂閱種子文件,並進行它們的操作。顯示代碼並不需要關注其它的系統,也不需要因為增加了數據的消費者而相應的進行變更。
 
構建可伸縮的日誌
 
當然,把發佈者與訂閱者分離不再是什麼新鮮事了。但是如果你想要確保提交日誌的行為就像多個訂閱者實時的分類日誌那樣記錄網站發生的每件事時,可擴展性就會成為你所面臨的首要挑戰。如果我們不能創建快速、高性價比和可擴展性靈活的日誌以滿足實際的可擴展需求,把日誌做為統一的集成機制不再是美好的想像,
 
人們普遍認為分佈式日誌是緩慢的、重量經的概念(並且通常會把它僅僅與「原數據」類型的使用聯繫起來,對於這類使用Zookeeper可以適用)。但是深入實現並重點關注分類記錄大規模的數據流,這種需求是不切實際的。在LinkedIn,我們現在每天通過Kafka運行著超過600億個不同的消息寫入點(如果統計鏡相與數據中心之間的寫入,那麼這個數字會是數千億)。
 
我們在Kafk中使用了一些小技巧來支持這種可擴展性:
 
日誌分片
 
通過批處理讀出和寫入優化吞吐力
 
規避無用的數據複製。
 
\
 
為了確保水平可擴展性,我們把日誌進行切片:
 
每個切片都是一篇有序的日誌,但是各片之間沒有全局的次序(這個有別於你可能包含在消息中的掛鐘時間)。把消息分配到特定的日誌片段這是由寫入者控制的,大部分使用者會通過用戶ID等鍵值來進行分片。分片可以把日誌追加到不存在協作的片段之間,也可以使系統的吞吐量與Kafka聚簇大小成線性比例關係。
 
每個分片都是通過可配置數量的複製品複製的,每個複製品都有分片的一份完全一致的拷貝。無論何時,它們中的任一個都可以做為主分片,如果主分片出錯了,任何一個複製品都可以接管並做為主分片。
 
缺少跨分片的全局順序是這個機制的侷限性,但是我們不認為它是最主要的。事實上,與日誌的交互主要來源於成百上千個不同的流程,以致於對於它們的行為排一個總體的順序是沒什麼意義的。相反,我們可以確保的是我們提供的每個分片都是按順序保留的。Kafka保證了追加到由單一發送者送出的特定分片會按照發送的順序依次處理。
 
日誌,就像文件系統一樣,是容易優化成線性可讀可寫的樣式的。日誌可以把小的讀入和寫出組合成大的、高吞吐量的操作。Kafka一直至立於實現這一優化目標。批處理可以發生在由客戶端向服務器端發送數據、寫入磁盤;在服務器各端之間複製;數據傳遞給消費者和確認提交數據等諸多環節。
 
最終,Kafka使用簡單的二進制形式維護內存日誌,磁盤日誌和網絡數據傳送。這使得我們可以使用包括「0數據複製傳送」在內的大量的優化機制。
 
這些優化的積累效應是你常常進行的寫出和讀入數據的操作可以在磁盤和網絡上得到支持,甚至於維護內存以外的大量數據集。
 
這些詳細記述並不意味著這是關於Kafka的主要內容,那麼我就不需要瞭解細節了。你可閱讀到更多的關於LinkedIn的方法在這個鏈接,和Kafka的設計總述在這個鏈接。
 
第三部分:日誌和實時流處理
 
到此為止,我只是描述從端到端數據複製的理想機制。但是在存儲系統中搬運字節不是所要講述內容的全部。最終我們發現日誌是流的另一種說法,日誌是流處理的核心。
 
但是,等等,什麼是流處理呢?
 
如果你是90年代晚期或者21世紀初數據庫文化或者數據基礎架構產品的愛好者,那麼你就可能會把流處理與建創SQL引擎或者創建「箱子和箭頭」接口用於事件驅動的處理等聯繫起來。
 
如果你關注開源數據庫系統的大量出現,你就可能把流處理和一些開源數據庫系統關聯起來,這些系統包括了:Storm,Akka,S4和Samza。但是大部分人會把這些系統作為異步消息處理系統,這些系統與支持群集的遠程過程調用層的應用沒什麼差別(而事實上在開源數據庫系統領域某些方面確實如此)。
 
這些視圖都有一些侷限性。流處理與SQL是無關的。它也侷限於實時流處理。不存在內在的原因限制你不能處理昨天的或者一個月之前的流數據,且使用多種不同的語言表達計算。
 
\
 
我把流處理視為更廣泛的概念:持續數據流處理的基礎架構。我認為計算模型可以像MapReduce或者分佈式處理架構一樣普遍,但是有能力處理低時延的結果。
 
處理模型的實時驅動是數據收集方法。成批收集的數據是分批處理的。數據是不斷收集的,它也是按順序不斷處理的。
 
美國的統計調查就是成批收集數據的良好典範。統計調查週期性的開展,通過挨門挨戶的走訪,使用蠻力發現和統計美國的公民信息。1790年統計調查剛剛開始時這種方式是奏效的。那時的數據收集是批處理的,它包括了騎著馬悠閒的行進,把信息寫在紙上,然後把成批的記錄傳送到人們統計數據的中心站點。現在,在描述這個統計過程時,人們立即會想到為什麼我們不保留出生和死亡的記錄,這樣就可以產生人口統計信息這些信息或是持續的或者是其它維度的。
 
這是一個極端的例子,但是大量的數據傳送處理仍然依賴於週期性的轉儲,批量轉化和集成。處理大容量轉儲的唯一方法就是批量的處理。但是隨著這些批處理被持續的供給所取代,人們自然而然的開始不間斷的處理以平滑的處理所需資源並且消除延遲。
 
例如LinkedIn幾乎沒有批量數據收集。大部分的數據或者是活動數據或者是數據庫變更,這兩者都是不間斷髮生的。事實上,你可以想到的任何商業,正如:Jack Bauer告訴我們的,低層的機制都是實時發生的不間斷的流程事件。數據是成批收集的,它總是會依賴於一些人為的步驟,或者缺少數字化或者是一些自動化的非數字化流程處理的遺留信息。當傳送和處理這些數據的機制是郵件或者人工的處理時,這一過程是非常緩慢的。首輪自動化總是保持著最初的處理形式,它常常會持續相當長的時間。
 
每天運行的批量處理作業常常是模擬了一種一天的窗口大小的不間斷計算。當然,低層的數據也經常變化。在LinkedIn,這些是司空見貫的,並且使得它們在Hadoop運轉的機制是有技巧的,所以我們實施了一整套管理增量的Hadoop工作流的架構。
 
由此看來,對於流處理可以有不同的觀點。流處理包括了在底層數據處理的時間概念,它不需要數據的靜態快照,它可以產生用戶可控頻率的輸出,而不用等待數據集的全部到達。從這個角度上講,流處理就是廣義上的批處理,隨著實時數據的流行,會兒更加普遍。
 
這就是為什麼從傳統的視角看來流處理是利基應用。我個人認為最大的原因是缺少實時數據收集使得不間斷的處理成為了學術性的概念。
 
我想缺少實時數據收集就像是商用流處理系統注定的命運。他們的客戶仍然需要處理面向文件的、每日批量處理ETL和數據集成。公司建設流處理系統關注的是提供附著在實時數據流的處理引擎,但是最終當時極少數人真正使用了實時數據流。事實上,在我在LinkedIn工作的初期,有一家公司試圖把一個非常棒的流處理系統銷售給我們,但是因為當時我們的全部數據都按小時收集在的文件裡,當時我們提出的最好的應用就是在每小時的最後把這些文件輸入到流處理系統中。他們注意到這是一個普遍性的問題。這些異常證明了如下規則:流處理系統要滿足的重要商業目標之一是:財務, 它是實時數據流已具備的基準,並且流處理已經成為了瓶頸。
 
甚至於在一個健康的批處理系統中,流處理作為一種基礎架構的實際應用能力是相當廣泛的。它跨越了實時數據請求——應答服務和離線批量處理之間的鴻溝。現在的互聯網公司,大約25%的代碼可以劃分到這個類型中。
 
最終這些日誌解決了流處理中絕大部分關鍵的技術問題。在我看來,它所解決的最大的問題是它使得多訂閱者可以獲得實時數據。對這些技術細節感興趣的朋友,我們可以用開源的Samza,它是基於這些理念建設的一個流處理系統。這些應用的更多技術細節我們在此文檔中有詳細的描述。
 
數據流圖
 
\
 
流處理最有趣的角度是它與流處理系統內部無關,但是與之密切相關的是如何擴展了我們談到的早期數據集成的數據獲取的理念。我們主要討論了基礎數據的獲取或日誌——事件和各類系統執行中產生的數據等。但是流處理允許我們包括了計算其它數據的數據。這些衍生的數據在消費者看來與他們計算的原始數據沒什麼差別。這些衍生的數據可以按任意的複雜度進行壓縮。
 
讓我們再深入一步。我們的目標是:流處理作業可以讀取任意的日誌並把日誌寫入到日誌或者其它的系統中。他們用於輸入輸出的日誌把這些處理關聯到一組處理過程中。事實上,使用這種樣式的集中日誌,你可以把組織全部的數據抓取、轉化和工作流看成是一系列的日誌和寫入它們的處理過程。
 
流處理器根本不需要理想的框架:它可能是讀寫日誌的任何處理器或者處理器集合,但是額外的基礎設施和輔助可以提供幫助管理處理代碼。
 
日誌集成的目標是雙重的:
 
首先,它確保每個數據集都有多個訂閱者和有序的。讓我們回顧一下狀態複製原則來記住順序的重要性。為了使這個更加具體,設想一下從數據庫中更新數據流–如果在處理過程中我們把對同一記錄的兩次更新重新排序,可能會產生錯誤的輸出。 TCP之類的鏈接僅僅侷限於單一的點對點鏈接,這一順序的持久性要優於TCP之類的鏈接,它可以在流程處理失敗和重連時仍然存在。
 
第二,日誌提供了流程的緩衝。這是非常基礎的。如果處理流程是非同步的,那麼上行生成流數據的作業比下行消費流數據的作業運行的更快。這將會導致處理流程阻塞,或者緩衝數據,或者丟棄數據。丟棄數據並不是可行的方法,阻塞將會導致整個流程圖立即停止。 日誌實際上是一個非常大的緩衝,它允許流程重啟或者停止但不會影響流程圖其它部分的處理速度。如果要把數據流擴展到更大規模的組織,如果處理作業是由多個不同的團隊提供的,這種隔離性是極其重的。我們不能容忍一個錯誤的作業引發後台的壓力,這種壓力會使得整個處理流程停止。
 
Storm和Sama這兩者都是按非同步方式設計的,可以使用Kafka或者其它類似的系統作為它們的日誌。
 
有狀態的實時流處理
 
一些實時流處理在轉化時是無狀態的記錄。在流處理中大部分的應用會是相當複雜的統計、聚合、不同窗口之間的關聯。例如有時人們想擴大包含用戶操作信息的事件流(一系列的單擊動作)–實際上關聯了用戶的單擊動作流與用戶的賬戶信息數據庫。不變的是這類流程最終會需要由處理器維護的一些狀態信息。例如數據統計時,你需要統計到目前為止需要維護的計數器。如果處理器本身失敗了,如何正確的維護這些狀態信息呢?
 
最簡單的替換方案是把這些狀態信息保存在內存中。但是如果流程崩潰,它就會丟失中間狀態。如果狀態是按窗口維護的,流程就會回退到日誌中窗口開始的時間點上。但是,如果統計是按小時進行的,那麼這種方式就會變得不可行。
 
另一個替換方案是簡單的存儲所有的狀態信息到遠程的存儲系統,通過網絡與這些存儲關聯起來。這種機制的問題是沒有本地數據和大量的網絡間通信。
 
我們如何支持處理過程可以像表一樣分區的數據呢?
 
回顧一下關於表和日誌二相性的討論。這一機制提供了工具把數據流轉化為與處理過程協同定位的表,同時也提供了這些表的容錯處理的機制。
 
流處理器可以把它的狀態保存在本地的表或索引——bdb,或者leveldb,甚至於類似於Lucene 或fastbit一樣不常見的索引。這些內容存儲在它的輸入流中(或許是使用任意的轉化)。生成的變更日誌記錄了本地的索引,它允許存儲事件崩潰、重啟等的狀態信息。流處理提供了通用的機制用於在本地輸入流數據的隨機索引中保存共同分片的狀態。
 
當流程運行失敗時,它會從變更日誌中恢復它的索引。每次備份時,日誌把本地狀態轉化成一系列的增量記錄。
 
這種狀態管理的方法有一個優勢是把處理器的狀態也做為日誌進行維護。我們可以把這些日誌看成與數據庫表相對應的變更日誌。事實上,這些處理器同時維護著像共同分片表一樣的表。因為這些狀態它本身就是日誌,其它的處理器可以訂閱它。如果流程處理的目標是更新結點的最後狀態,這種狀態又是流程的輸出,那麼這種方法就顯得尤為重要。
 
為了數據集成,與來自數據庫的日誌關聯,日誌和數據庫表的二象性就更加清晰了。變更日誌可以從數據庫中抽取出來,日誌可以由不同的流處理器(流處理器用於關聯不同的事件流)按不同的方式進行索引。
 
我們可以列舉在Samza中有狀態流處理管理的更多細節和大量實用的例子。
 
日誌壓縮
 
當然,我們不能奢望保存全部變更的完整日誌。除非想要使用無限空間,日誌不可能完全清除。為了澄清它,我們再來聊聊Kafka的實現。在Kafka中,清理有兩種選擇,這取決於數據是否包括關鍵更新和事件數據。對於事件數據,Kafka支持僅維護一個窗口的數據。通常,配置需要一些時間,窗口可以按時間或空間定義。雖然對於關鍵數據而言,完整日誌的重要特徵是你可以重現源系統的狀態信息,或者在其它的系統重現。
 
隨著時間的推移,保持完整的日誌會使用越來越多的空間,重現所耗費的時間越來越長。因些在Kafka中,我們支持不同類型的保留。我們移除了廢棄的記錄(這些記錄的主鍵最近更新過)而不是簡單的丟棄舊日誌。我們仍然保證日誌包含了源系統的完整備份,但是現在我們不再重現原系統的全部狀態,而是僅僅重現最近的狀態。我們把這一特徵稱為日誌壓縮。
 
第四部分:系統建設
 
我們最後要討論的是在線數據系統設計中日誌的角色。
 
在分佈式數據庫數據流中日誌的角色和在大型組織機構數據完整中日誌的角色是相似的。在這兩個應用場景中,日誌是對於數據源是可靠的,一致的和可恢復的。組織如果不是一個複雜的分佈式數據系統呢,它究竟是什麼?
 
分類計價嗎?
 
如果換個角度,你可以看到把整個組織系統和數據流看做是單一的分佈式數據系統。你可以把所有的子查詢系統(諸如Redis,SOLR,Hive表等)看成是數據的特定索引。你可以把Storm或Samza一樣的流處理系統看成是發展良好的觸發器和視圖具體化機制。我已經注意到,傳統的數據庫管理人員非常喜歡這樣的視圖,因為它最終解釋了這些不同的數據系統到底是做什麼用的–它們只是不同的索引類型而已。
 
不可否認這類數據庫系統現在大量的出現,但是事實上,這種複雜性一直都存在。即使是在關係數據庫系統的鼎盛時期,組織中有大量的關係數據庫系統。或許自大型機時代開始,所有的數據都存儲在相同的位置,真正的集成是根本不存在的。存在多種外在需求,需要把數據分解成多個系統,這些外在需求包括:規模、地理因素、安全性,性能隔離是最常見的因素。這些需求都可以由一個優質的系統實現:例如,組織可以使用單一的Hadoop聚簇,它包括了全部的數據,可以服務於大型的和多樣性的客戶。
 
因此在向分佈式系統變遷的過程中,已經存在一種處理數據的簡便的方法:把大量的不同系統的小的實例聚合成為大的聚簇。許多的系統還不足以支持這一方法:因為它們不夠安全,或者性能隔離性得不到保證,或者規模不符合要求。不過這些問題都是可以解決的。
 
依我之見,不同系統大量出現的原因是建設分佈式數據庫系統很困難。通過削減到單一的查詢或者用例,每個系統都可以把規模控制到易於實現的程度。但是運行這些系統產生的複雜度依然很高。
 
未來這類問題可能的發展趨勢有三種:
 
第一種可能是保持現狀:孤立的系統還會或長或短的持續一段時間。這是因為建設分佈式系統的困難很難克服,或者因為孤立系統的獨特性和便捷性很難達到。基於這些原因,數據集成的核心問題仍然是如何恰當的使用數據。因此,集成數據的外部日誌非常的重要。
 
第二種可能是重構:具備通用性的單一的系統逐步融合多個功能形成超極系統。這個超級系統表面看起來類似關係數據庫系統,但是在組織中你使用時最大的不同是你只需要一個大的系統而不是無數個小系統。在這個世界裡,除了在系統內已解決的這個問題不存在什麼真正的數據集成問題。我想這是因為建設這樣的系統的實際困難。
 
雖然另一種可能的結果對於工程師來說是很有吸引力的。新一代數據庫系統的特徵之一是它們是完全開源的。開源提供了一種可能性:數據基礎架構不必打包成服務集或者面嚮應用的系統接口。在Java棧中,你可以看到在一定程度上,這種狀況已經發生了。
 
Zookeeper用於處理多個系統之間的協調,或許會從諸如Helix 或者Curator等高級別的抽象中得到一些幫助。
 
Mesos和YARN用於處理流程可視化和資源管理。
 
Lucene和LevelDB等嵌入式類庫做為索引。
 
Netty,Jetty和Finagle,rest.li等封裝成高級別的用於處理遠程通信。
 
Avro,Protocol Buffers,Thrift和umpteen zillion等其它類庫用於處理序列化。
 
Kafka和Bookeeper提供支持日誌。
 
如果你把這些堆放在一起,換個角度看,它有點像是簡化版的分佈式數據庫系統工程。你可以把這些拼裝在一起,創建大量的可能的系統。顯而易見,現在探討的不是最終用戶所關心的API或者如何實現,而是在不斷多樣化和模塊化的過程中如何設計實現單一系統的途徑。因為隨著可靠的、靈活的模塊的出現,實施分佈式系統的時間週期由年縮減為周,聚合形成大型整體系統的壓力逐步消失。
 
日誌文件在系統結構中的地位
 
那些提供外部日誌的系統如今已允許個人電腦拋棄他們自身複雜的日誌系統轉而使用共享日誌。在我看來,日誌可以做到以下事情:
 
通過對節點的並發更新的排序處理數據的一致性(無論在及時還是最終情況下)
 
提供節點之間的數據複製
 
提供」commit「語法(只有當寫入器確保數據不會丟失時才會寫入)
 
位系統提供外部的數據訂閱資源
 
提供存儲失敗的複製操作和引導新的複製操作的能力
 
處理節點間的數據平衡
 
這實際上是一個數據分發系統最重要的部分,剩下的大部分內容與終端調用的API和索引策略相關。這正是不同系統間的差異所在,例如:一個全文本查詢語句需要查詢所有的分區,而一個主鍵查詢只需要查詢負責鍵數據的單個節點就可以了。
 
下面我們來看下該系統是如何工作的。系統被分為兩個邏輯區域:日誌和服務層。日誌按順序捕獲狀態變化,服務節點存儲索引提供查詢服務需要的所有信息(鍵—值的存儲可能以B-tree或SSTable的方式進行,而搜索系統可能存在與之相反的索引)。寫入器可以直接訪問日誌,儘管需要通過服務層代理。在寫入日誌的時候會產生邏輯時間戳(即log中的索引),如果系統是分段式的,那麼就會產生與段數目相同數量的日誌文件和服務節點,這裡的數量和機器數量可能會有較大差距。
 
\
 
服務節點訂閱日誌信息並將寫入器按照日誌存儲的順序盡快應用到它的本地索引上。
 
客戶端只要在查詢語句中提供對應的寫入器的時間戳,它就可以從任何節點中獲取」讀寫「語義。服務節點收到該查詢語句後會將其中的時間戳與自身的索引比較,如果必要,服務節點會延遲請求直到對應時間的索引建立完畢,以免提供舊數據。
 
服務節點或許根本無需知道」控制「或」投標選擇(leader election)「的概念,對很多簡單的操作,服務節點可以愛完全脫離領導的情況下提供服務,日誌即是信息的來源。
 
分發系統所需要做的其中一個比較複雜的工作,就是修復失敗節點並移除幾點之間的隔離。保留修復的數據並結合上各區域內的數據快照是一種較為典型的做法,它與保留完整的數據備份並從垃圾箱內回收日誌的做法幾乎等價。這就使得服務層簡單了很多,日誌系統也更有針對性。
 
有了這個日誌系統,你可以訂閱到API,這個API提供了把ETL提供給其它系統的數據內容。事實上,許多系統都可以共享相同的日誌同時提供不同的索引,如下所示:
 
\
 
這樣一個以日誌為中心的系統是如何做到既數據流的提供者又同時加載其它系統的數據的呢?因為流處理器既可以消費多個輸入的數據流,隨後又可以通過其它系統對數據做索引為它們提供服務。
 
這個系統的視圖可以清晰的分解到日誌和查詢API,因為它允許你從系統的可用性和一致性角度分解查詢的特徵。這可以幫助我們對系統進行分解,並理解那些並沒按這種方式設計實施的系統。
 
雖然Kafka和Bookeeper都是一致性日誌,但這不是必須的,也沒什麼意義。你可以輕鬆的把Dynamo之類的數據構分解為一致性的AP日誌和鍵值對服務層。這樣的日誌使用起來靈活,因為它重傳了舊消息,像Dynamo一樣,這樣的處理取決於消息的訂閱者。
 
在很多人看來,在日誌中另外保存一份數據的完整複本是一種浪費。事實上,雖然有很多因素使得這件事並不困難。首先,日誌可以是一種有效的存儲機制。我們在Kafka生產環境的服務器上存儲了5 TB的數據。同時有許多的服務系統需要更多的內存來提供有效的數據服務,例如文本搜索,它通常是在內存中的。服務系統同樣也需樣硬盤的優化。例如,我們的實時數據系統或者在內存外提供服務或者使用固態硬盤。相反,日誌系統只需要線性的讀寫,因此,它很樂於使用TB量級的硬盤。最終,如上圖所示,由多個系統提供的數據,日誌的成本分攤到多個索引上,這種聚合使得外部日誌的成本降到了最低點。
 
LinkedIn就是使用了這種方式實現它的多個實時查詢系統的。這些系統提供了一個數據庫(使用數據總線做為日誌摘要,或者從Kafka去掉專用的日誌),這些系統在頂層數據流上還提供了特殊的分片、索引和查詢功能。這也是我們實施搜索、社交網絡和OLAP查詢系統的方式。事實上這種方式是相當普遍的:為多個用於實時服務的服務系統提供單一的數據(這些來自Hadoop的數據或是實時的或是衍生的)。這種方式已被證實是相當簡潔的。這些系統根本不需要外部可寫入的API,Kafka和數據庫被用做系統的記錄和變更流,通過日誌你可以查詢系統。持有特定分片的結點在本地完成寫操作。這些結點盲目的把日誌提供的數據轉錄到它們自己的存儲空間中。通過回放上行流日誌可以恢復轉錄失敗的結點。
 
這些系統的程度則取決於日誌的多樣性。一個完全可靠的系統可以用日誌來對數據分片、存儲結點、均衡負載,以及用於數據一致性和數據複製等多方面。在這一過程中,服務層實際上只不過是一種緩存機制,這種緩存機制允許直接寫入日誌的流處理。
 
結束語
 
如果你對於本文中所談到的關於日誌的大部內容,如下內容是您可以參考的其它資料。對於同一事務人們會用不同的術語,這會讓人有一些困惑,從數據庫系統到分佈式系統,從各類企業級應用軟件到廣闊的開源世界。無論如何,在大方向上還是有一些共同之處。
 
學術論文、系統、評論和博客
 
關於狀態機和主備份復現的概述。
 
PacificA是實施微軟基於日誌的分佈式存儲系統的通用架構。
 
Spanner-並不是每個人都支持把邏輯時間用於他們的日誌,Google最新的數據庫就嘗試使用物理時間,並通過把時間戳直接做為區間來直接建時鐘遷移的不確定性。
 
Datanomic:解構數據庫,它是Rich Hickey在它的首個數據庫產品中的的重要陳述之一,Rich Hickey是Clojure的創建者。
 
在消息傳遞系統中回捲恢復協議的調查。我發現這個有助於引入容錯處理和數據庫以外的應用系統日誌恢復。
 
Reactive Manifesto-事實上我並不清楚反應編程的確切涵義,但是我想它和「事件驅動」指的是同一件事。這個鏈接並沒有太多的訊息,但由久富盛史的Martin Odersky講授的課程是很有吸引力的。
 
Paxos!
 
1)Leslie Lamport有一個有趣的歷史:在80年代算法是如何發現的,但是直到1998年才發表了,因為評審組不喜歡論文中的希臘寓言,而作者又不願修改。
 
2)甚至於論文發佈以後,它還是不被人們理解。Lamport再次嘗試,這次它包含了一些並不有趣的小細節,這些細節是關於如何使用這些新式的自動化的計算機的。它仍然沒有得到廣泛的認可。
 
3)Fred Schneider和Butler Lampson分別給出了更多細節關於在實時系統中如何應用Paxos.
 
4)一些Google的工程師總結了他們在Chubby中實施Paxos的經驗。
 
5)我發現所有關於Paxos的論文理解起來很痛苦,但是值得我們費大力氣弄懂。你不必忍受這樣的痛苦了,因為日誌結構的文件系統的大師John Ousterhout的這個視頻讓這一切變得相當的容易。這些一致性算法用展開的通信圖表述的更好,而不是在論文中通過靜態的描述來說明。頗為諷刺的是,這個視頻錄製的初衷是告訴人們Paxos很難理解。
 
6)使用Paxos來構造規模一致的數據存儲。
 
Paxos有很多的競爭者。如下諸項可以更進一步的映射到日誌的實施,更適合於實用性的實施。
 
1)由Barbara Liskov提出的視圖戳復現是直接進行日誌復現建模的較早的算法。
 
2)Zab是Zookeeper所使用的算法。
 
3)RAFT是易於理解的一致性算法之一。由John Ousterhout講授的這個視頻非常的棒。
 
你可以的看到在不同的實時分佈式數據庫中動作日誌角色:
 
1)PNUTS是探索在大規模的傳統的分佈式數據庫系統中實施以日誌為中心設計理念的系統。
 
2)Hbase和Bigtable都是在目前的數據庫系統中使用日誌的樣例。
 
3)LinkedIn自己的分佈式數據庫Espresso和PNUTs一樣,使用日誌來復現,但有一個小的差異是它使用自己底層的表做為日誌的來源。
 
流處理:這個話題要總結的內容過於寬泛,但還是有幾件我所關注的要提一下:
 
1)TelegraphCQ
 
2)Aurora
 
3)NiagaraCQ
 
4)離散流:這篇論文討論了Spark的流式系統。
 
5)MillWheel 它是Google的流處理系統之一。
 
6)Naiad:一個實時數據流系統
 
7)在數據流系統中建模和相關事件:它可能是研究這一領域的最佳概述之一。
 
8)分佈處式流處理的高可用性算法。
 
企業級軟件存在著同樣的問題,只是名稱不同,或者規模較小,或者是XML格式的。哈哈,開個玩笑。
 
事件驅動——據我所知:它就是企業級應用的工程師們常說的「狀態機的復現」。有趣的是同樣的理念會用在如此迥異的場景中。事件驅動關注的是小的、內存中的使用場景。這種機制在應用開發中看起來是把發生在日誌事件中的「流處理」和應用關聯起來。因此變得不那麼瑣碎:當處理的規模大到需要數據分片時,我關注的是流處理作為獨立的首要的基礎設施。
 
變更數據捕獲–在數據庫之外會有些對於數據的舍入處理,這些處理絕大多數都是日誌友好的數據擴展。
 
企業級應用集成,當你有一些現成的類似客戶類系管理CRM和供應鏈管理SCM的軟件時,它似乎可以解決數據集成的問題。
 
複雜事件處理(CEP),沒有人知道它的確切涵義或者它與流處理有什麼不同。這些差異看起來集中在無序流和事件過濾、發現或者聚合上,但是依我之見,差別並不明顯。我認為每個系統都有自己的優勢。
 
企業服務總線(ESB)——我認為企業服務總線的概念類似於我所描述的數據集成。在企業級軟件社區中這個理念取得了一定程度的成功,對於從事網絡和分佈式基礎架構的工程師們這個概念還是很陌生的。
 
一些相關的開源軟件:
 
Kafka是把日誌作為服務的一個項目,它是後邊所列各項的基礎。
 
Bookeeper 和Hedwig 另外的兩個開源的「把日誌作為服務」的項目。它們更關注的是數據庫系統內部構件而不是事件數據。
 
Databus是提供類似日誌的數據庫表的覆蓋層的系統。
 
Akka 是用於Scala的動作者架構。它有一個事件驅動的插件,它提供持久化和記錄。
 
Samza是我們在LinkedIn中用到的流處理框架,它用到了本文論述的諸多理念,同時與Kafka集成來作為底層的日誌。
 
Storm是廣泛使用的可以很好的與Kafka集成的流處理框架之一。
 
Spark Streaming一個流處理框架,它是Spark的一部分。
 
Summingbird是在Storm或Hadoop之上的一層,它提供了便潔的計算摘要。

本文由「華爾街俱樂部」推薦。
PermaLink: https://articles.zkiz.com/?id=108543

脈脈如何搭建一個和LinkedIn不一樣的職場社交網絡?

來源: http://newshtml.iheima.com/2014/0815/144949.html

8月12日晚上消息,職業社交應用脈脈宣布完成由IDG資本和晨興創投聯投的B輪2000萬美元融資。脈脈怎樣才能不淪為下一個求職招聘工作,又如何建一個和LinkedIn不一樣的職場社交網絡?

\ 

Q:

常皓靖:

脈脈如何搭建一個和LinkedIn不一樣的職場社交網絡?

A:

齊特佳—脈脈產品總監

Linkedin作為在世界範圍內最受歡迎的職場社交網站,毫無疑問具有極強的研究價值,也給了脈脈很多啟發. 關於Linkedin的各種精彩的產品分析和觀點已有很多,在這里我主要想對”脈脈與Linkedin不同之處”這一問題談談自己的理解:

1. Linkedin誕生於web,脈脈誕生於移動端, 並因此產生一些區別

眾所周知,Linkedin在職場社交領域已經耕耘多年,遠在移動互聯網興起之前就已成為了最大的職場社交網站,可以說Linkedin是生於web, 並在web上生長壯大的. 在移動互聯網大潮來臨之後,Linkedin也同樣推出了移動版,但由於過去在web領域巨大的成功經驗,Linkedin的移動版更多的是繼承了web版的產品思路.

而脈脈則誕生於移動端,這一點使脈脈天然就有動力去使用”更移動端”的一些思路來構建產品模型, 其中最典型的一個例子就是在用戶互相聯系溝通的問題上,Linkedin采用的是界面有典型郵件風格的”站內信”解決方案, 而脈脈用的則是更具im特色的”聊天”解決方案.

無關優劣,對所處平臺不同應用思路的確會催生不同氣質的產品.

2. “工作版微信”與”中國的Linkedin”的區別

可能同樣做工作場景的原因,脈脈上線伊始就被冠以“中國的LinkedIn”的名號,但是我們覺得相比較LinkedIn,我們更像是微信場景的一個補充。

微信完美的解決了用戶互動交流的需求,但是放在工作場景上,因為用戶詳細資料的缺失,造成工作交友方面的困難,另一方面單純的昵稱場景又造成了用戶在交友方面的顧忌(要不不熟悉不知道交流什麽,要不太熟悉暴露隱私)我們覺得這恰恰是“工作版微信”——脈脈的空間。

脈脈從”工作”的場景切入,其產品目標是”滿足工作中可能產生的需求”,從”工作”的場景需求來看,招人,換工作,職場社交,資訊獲取,溝通交流,商務合作乃至工作上的團隊協作等都在範圍內.

中國已經有LinkedIn,也就是領英,相比較他們比較重pc,我們更偏移動端,因為介質不同,用戶體驗也就很不相同。也就是說雖然我們都在做工作的場景,但在實現上有比較大的差別。

3. 面向中國用戶的一些不同的產品策略

在我看來,將Linkedin式的職場社交模式引入中國,不僅僅是將界面語言翻譯成中文那麽簡單,Linkedin的產品形態在西方大放異彩是和西方人的工作方式乃至性格特點有密切關系的.

如:西方人相當習慣用郵件來溝通,而中國人在多數情況下對郵件的使用是缺乏效率和依賴性的,相對的,中國人用起im來確是格外得心應手.這一點衍生出了前文提到的Linkedin的”站內信”和脈脈的”聊天”的區別.

再如:西方人性格偏外向,喜歡直接溝通,而中國人性格中有更多內斂含蓄的成分,尤其是在求職這樣的場景,東方式的內斂往往會造成大量在的信息不對稱,從而使招聘流程變成了一個不同於西方招聘流程的樣子.在這一點上,脈脈引入了”匿名”的模式來幫助用戶減少不必要的疑慮和信息不對稱的概率.

產品的靈魂不是其靜止的形態,而是它被用戶用時的樣子,因此不同風格的用戶也會催生不同靈魂的產品.

4. 對”匿名”的利用

最近匿名社交著實火了一把,不到半年時間內就有無數匿名社交產品湧現,其實脈脈在去年10月份上線的第一版就已經具備了匿名社交的功能,應該比這半年火起來的國內匿名社交應用都要早.

在包含職場社交場景的應用里引入匿名元素,正是緣於上一條所述的:中國人在表達自己的需求和看法方面更為內斂委婉,匿名表達則是促使內斂的中國人”更愛表達”的方式之一.

匿名表達求職意願,匿名表達職場觀點看法,甚至是在群里以匿名的身份聊天,脈脈將匿名表達視為和實名表達並列的一種表達方式,成為用戶溝通主流程的一部分,這也是脈脈較為獨特的與Linkedin不同的地方.

5. 在構建人脈網絡的角度, Linkedin傾向於”冷啟動”, 脈脈傾向於”熱啟動”

簡單來說,這個不同點就表現為:新加入Linkedin的用戶需要從頭構建自己的人脈網絡(也即”冷啟動”),新加入脈脈的用戶會在一個脈脈同計算分析”還原”出的人脈網絡的基礎上繼續構建自己的人脈網絡(也即”熱啟動”).

Linkedin具有強大的人脈計算能力和人脈圖譜,更具備強大的號召力,有信心憑借著用戶的導入推薦來協助每一個新用戶建立起自己的人脈.同時,西方人相對開放式的溝通方式也使人脈的構建對已有人脈的還原程度依賴度相對不高.

脈脈作為創業產品,對用戶快速上手的需求更為迫切,同時脈脈也堅信中國式的人脈很大程度上依賴於對線下已有人脈的線上還原,基於線下熟人關系衍生出來的新人脈才是靠譜的人脈.

6. 其它例子

前幾條大多在說比較”大”的維度,還有些具體的細節例子,也是脈脈和Linkedin不同的:

如: 驗證用戶身份時的”加v”功能

再如: 為解決多人即時溝通所設立的”脈脈群”功能

再如: 求職者匿名發布求職信息,吸引用人單位反過來聯系的”求帶走”功能

再如: 使人脈動態信息在人脈網絡中快速流動的”擴散

結語: 一不留神寫了這麽多,總之,Linkedin是脈脈很好的老師,同時脈脈也基於平臺的特點,產品的定位和中國用戶的特點而產生了一些和Linkedin不同的思路, 這些不同的思路會產生哪些不同的體驗,就請大家和我們一起來經歷和見證吧.

互聯網天帝--京華眾天恒網絡科技有限責任公司CEO

關於職場社交,沒有任何意義了在中國,微信本身的群功能已經可以讓大部分職場社交網絡洗洗睡了。沒有好的項目,投資一個還有故事的應用也是可以的,未來會不會死我覺得對於IDG和晨興來說只要不是最後接盤子的就好。陌陌不是也被收購了嗎?資本層面的事情不用太評論了,只是職場社交網絡在中國依然是吃飯喝茶唱歌,如果硬要說,微信已經做的很好了,外企會用Linkedin,但是土鱉公司,包括3BAT,任何職場社交應用都沒有意義,一個微信夠了。
 

更多關於“脈脈如何搭建一個和LinkedIn不一樣的職場社交網絡?”的討論,請戳鏈接。

PermaLink: https://articles.zkiz.com/?id=108959

LinkedIn CEO: 怎樣做一個好的創始人

來源: http://newshtml.iheima.com/2014/1115/147746.html

i黑馬:斯坦福公開課How to Start a Startup第13講今天推出,由大名鼎鼎,號稱擁有大半個矽谷的LinkedIn創始人和CEO,Greylock Ventures合夥人 Reid Hoffman主講,以他閱人無數的眼光和豐富的實戰經驗,分享怎樣才是一個好的創始人。

\本講Reid的分享亮點如下:

1.好的創始人得是超人嗎?

- 在媒體報道成功的創業故事時,往往將好的創始人描述成超人一般,擁有超凡魔力,要會做產品,對市場很敏感,精通戰略,善於運營,還會融資等等,全能而完美;也曾有報道說比爾蓋茨比愛因斯坦還要聰明,我想比爾自己都會覺得好笑。

其實創始人的超凡能力,最多體現在面對層出不窮的頭疼問題時如何解決,沒有人具有超凡魔力;

- 好的創始人更多的時候在一兩個方面超出常人,在他要解決問題的領域,具有較強的競爭優勢,但絕不是由於他是全能天才;這個競爭優勢很多時候在面臨不確定性的時候表現出來。

2. 那麽好的創始人到底要具備哪些能力呢?

- 組建優勢互補的創始團隊 Form a Great Founding Team:創始團隊最好2-3個人,能力優勢互補,而不是一個人;因為初創公司成長過程中面臨的問題會非常多,需要一個具有多方面能力的團隊一起來解決,這樣的競爭優勢更強大,初創公司才有可能活下來;

-選擇最佳創業地點Location, Location, Location:這一點其實很重要,你一定要選者一個最適合你的創業方向和領域的環境,包括人才資源圈,融資環境,市場環境,產業生態鏈等等。矽谷的環境很適合軟件公司,移動互聯網應用,輕科技公司等,但可能就不適合其他的一些創業方向。

例如Groupon團購網,幸好在芝加哥起步;團購網在矽谷就會不受待見,因為他們起步時要依靠大量的銷售人員,超過80%都是銷售推廣,而這不是矽谷喜歡的模式。還有,假如你跑到矽谷來做時裝設計公司,肯定是跑錯地方了。要想清楚最適合你的創業方向的人才資源圈和生態圈在哪兒。

-善於逆向思考 Be a Contrarian:逆向思考並不難,難的是逆向正確思考;很多時候當你周圍的聰明人都不認同你的創業想法和模式時,要靜下心來仔細分析他們為什麽不認同,有沒有你所了解的東西/價值點被他們所忽視;當你確認那些被忽視的價值點時,你就很可能是對的。

LinkedIn的起步就是很好的例子,當時我的朋友圈超過2/3的人都反對,不認同它的發展前景,而我確認我看到了這里被忽視的專業人士社交網絡的需求和價值點;LinkedIn 的增長模式也與Facebook等社交網絡的爆炸式增長不同,我們一直是穩步持續增長,並沒有爆發點。

-掌控和解決問題與放手 Do the Work or Delegate?:這個問題常常讓創始人困惑,到底是掌控全局還是盡量放手,將任務傳遞給團隊?我的建議是兩手都要抓,兩手都要硬,既要掌控全局,盡量解決問題,同時要充分信任團隊,放手讓他們發揮,承擔責任(聽起來好熟悉啊,呵呵)。

-靈活善變與堅持不變 Being Flexible or Persistent ?:什麽時候應該靈活求變?什麽時候應該持續堅持?這個把握非常重要。要仔細分析當碰到公司發展碰到難處時,你和團隊的信心是持續下降還是保持不變?如果你和團隊的信心一直持續下降,就要好好想想如何求變,怎樣做才能增長信心。

- 向內為主還是向外為主 Internal or External?:創始人也常常困惑到底我是應該把主要精力放在公司內部事務上,例如產品開發,團隊成長,日常營運等等,還是把更多精力放在外部事務。

例如公司的市場開拓,品牌宣傳,聯盟企業,公共關系等等,答案同樣是兩者都需要100%,都非常重要,必須同時兼顧,根據具體情況和需求來及時調整精力分配和策略。

- 堅持使命還是聆聽數據 Vision or Data?:在初創公司成長過程中,面臨的不確定性經常會讓我們懷疑自己的使命是否是空想。聆聽數據很重要,更重要的時如何正確聆聽數據,什麽樣的數據值得聆聽,還要知道什麽時候聽數據,什麽時候聽從直覺和自己的內心。

- 冒險還是規避風險 Take Risk or Minimize Risk?:大家都覺得創業者是敢於冒險的人,但聰明的創始人知道什麽樣的風險,多大的風險者值得去嘗試?在什麽時候要冒險?絕不能無畏的冒險。通常要在對公司面對的狀況有清除的了解,對風險的大小有冷靜的評估之後,再去冒險。

3. 結束語:

最後總結一下:好的創始人不是天才,而是在某一兩個方面超出常人,極具競爭優勢的人,他們要善於組建優勢互補的團隊,要善於選擇最適合他創業的地點,要善於逆向思考,要能掌控全局也要敢於放手,要堅持使命也知道如何求變。優秀的創始人各不相同,他們最突出的優勢就是快速學習和不斷成長的能力,只有具備這個能力,才有可能創造奇跡。


Linkedin打造人力資源終極平台

http://www.xcf.cn/newfortune/cy/201503/t20150326_734360.htm如果說企業成功有方程式,那就是優異的產品、優異的商業模式和優異的企業文化。立足職場白領的領英,正是憑藉這三板斧在社交網絡佔據了重要的一席之地,並立志高遠,打造人力資源終極平台。

  2014年年底,全球最大的職場白領社交網站領英(Linkedin,LNKD.NYSE)斥資近2億美元收購B2B市場營銷的領袖企業Bizo。後者通過高水準的數據分析,幫助客戶對商業用戶進行精準定位和營銷。這一舉措標誌著領英向市場營銷服務領域繼續邁進。與此同時,其還推出了一系列高端產品,如銷售導航(sale navigator)等,進一步為現有客戶提供增值服務。近幾年來,積極創新的領英表現甚佳,2014年的收入高達20億美元,股價從上市時的45美元/股上升到目前的224美元/股。

  和其他大名鼎鼎的硅谷傳奇企業的出身類似,領英同樣由斯坦福大學畢業生瑞德·霍夫曼(Reid Hoffman)和幾位同事在他的公寓房裡創立。霍夫曼曾是網上支付鉅子PayPal的高管,在PayPal被eBay收購後離職。2003年他和同事們一起創立領英時,只是為了幫助像他們一樣的創業者拓展商業人脈,沒曾想推出的第一個月即有4000多會員加入,其後的發展則更為迅猛,短短3年後即擁有1000萬用戶,並於同年實現盈利。2008年,領英當仁不讓地成為全球最大的職場白領網上社交平台,成員來自170個產業。2010年,它榮登全球最有價值新創企業百強榜的第十位,並於2011年上市。2012年,領英再獲業界一致認可,勇奪享有盛譽的最佳創業公司獎(ENCORE award)。

  今天,以20種語言出現的領英共有3億用戶,遍佈全球200多個國家和地區。其中不但有財富全球500強企業的幾乎所有高管,還有全球知名企業家如維京集團(Virgin)的創始人和總裁理查德·布蘭森(Richard Branson)等商界大腕。和其他許多社交網站不同,領英的大多數用戶積極活躍,僅在美國的每月訪問人數就有6500萬,而在全球範圍內則高達1.7億人。目前,領英在全球擁有5000多名員工, 市值約220億美元,在福布斯全球2000強企業榜上排名1700位。它的成功甚至引申出一個專門的商業用語:領英效應 (the LinkedinEffect)。在網絡社交這個競爭極其激烈的行業中,領英能夠披荊斬棘成就霸業並不容易,它成功的秘訣何在?

  優異的產品性能

  任何企業獲得輝煌成功的基礎都是卓越的產品,領英也不例外。和其他社交網絡不同,領英從誕生之初就為它成千上萬的用戶提供切實而顯著的價值。它的經營使命就是將全球職場白領通過網絡連接起來,通過人脈互建和資源共享幫助他們取得事業上的成功。多年來領英一直遵循這個承諾,不斷推出真正具有價值的新產品和服務,竭盡全力為他們提供各類職業發展的資源和機會,如 Linkedin for Groups,幫助不同群體或組織的成員互動; Linkedin Services,會員可在四層隔離度之內找尋服務提供者,如律師、會計師等;還有Personal Plus,允許會員使用InMail,一個帶有個人信用度級別的內部電郵系統和其他任何會員聯繫。此外,它還推出眾多針對於不同行業的交流牆報(discussion board),鼓勵會員頻繁互動,以促進各自的職業發展。

  除個人用戶外,領英的另一個核心用戶群是企業。它們不但利用領英建立自身員工交流互動的平台,還將其視為招收新員工的最佳場所。為向這些用戶提供卓越的價值,領英推出 Linkedin Jobs,允許招聘人張貼聘用廣告,還讓供求雙方看到各自更多的相關信息,如同事的評價和推薦等,大大提高交流的透明度及成功的概率。領英的招聘服務給企業用戶提供的價值就更加出色。它不但允許招聘人對候選者進行精準搜索,而且可以通過找到佔據僱員市場高達60%的「隱形候選人」,即目前並未尋工,但機會合適就會考慮的人士。與此相類似,人才管道(Talent Pipeline)服務則允許招聘人跟蹤符合要求但還沒有準備換工的候選人等。

  通過提供這些多元化的優質服務,領英早已不僅是職場白領發展商業人脈的場所,而是他們及企業招聘的最佳平台。由於對個人和企業兩類用戶都十分具有價值,領英的出現和成長對價值270億美元的傳統獵頭行業產生了巨大衝擊。過去5年,著名獵頭企業如海德思哲(Heidrick & Struggles)和Monster Worldwide的股價分別下跌了67%和81%,幾乎潰不成軍。顯而易見,不斷提供幫助用戶成功的優異產品是領英成就霸業的最核心原因。

  高效的商業模式

  企業,尤其是高科技企業要想獲取持久的成功,單靠優異的產品並不夠,還需要一個合理高效的商業模式。優質產品和優良商業模式的整合才是制勝之道,而領英即是如此。它的免付費混合(freemium)商業模式和大多數互聯網企業截然不同。基本服務免費、高端服務收費的模式不但可以通過網絡效應確保用戶群的快速增長,還能實現盈利。更重要的是,領英的商業模式是由數據驅動的,其主要盈利渠道是用戶數據的變現,而非依賴他們的眼球。

  臉譜(Facebook)和谷歌無一例外都是廣告驅動型的,靠用戶點擊廣告盈利。如Facebook的廣告收入佔總額的85%,而且只有當用戶在線時才能賺錢。領英則不同,它利用用戶數據盈利,而非用戶時間。Facebook總裁馬克·扎克伯格曾誇耀,其用戶每月平均上線6.4小時,而領英用戶只有18分鐘。但Facebook用戶的廣告點擊率只是1/2000。如果比較單一用戶上線一小時產生的價值,領英是1.3美元,臉譜是6.2美分,差距巨大。很明顯,領英的商業模式和盈利方法更具有可持續性和擴展空間。

  具體來講,領英有三大收入來源,其一是人才解決方案,面向企業招聘人,佔到總收入的60%。這項服務低價高速,不但精準而且能夠定位隱形候選人,具有傳統獵頭無法比擬的優勢。所以,對於幾乎所有財富500強企業而言,一個領英招聘人賬戶如同金融交易員必須擁有的彭博數據終端那樣不可或缺。其二是營銷解決方案,允許廣告商進行精準廣告,佔到總收入的20%。其廣告的受眾質量甚至高於《華爾街日報》、《福布斯》和《商業週刊》。其三是面向個人用戶的高端會員服務。付費用戶可使用高效搜尋工具和各項增值服務,更加有效地尋找工作,建立商業人脈,並獲取各類職場資源等,此項收入佔到總量的20%。領英如此合理穩定的收入結構是其他互聯網公司難以企及的。

  而且,領英的商業模式使它具有非常清晰而優質的用戶群,除了C字頭的高管和藍領工人外,它覆蓋所有職場白領。與Facebook和推特(Twitter)相比,領英的成員具有更高的收入、教育水平和工作能力。它的典型用戶平均年齡41歲,年收入11萬美元,個人資產至少25萬美元。這個含金量很高的用戶群讓其他網絡企業羨慕不已。更讓它們無法匹敵的是,領英還擁有極其優質的商業用戶,幾乎涵蓋所有企業類型,尤其是財富500強企業。而且,其用戶的維護費用極低,續約率高達95%。

  領英商業模式中另一個得天獨厚的優勢是它具有天生的移動平台契合性。互聯網移動平台化是大勢所趨,但向小而輕便的移動平台發送廣告具有更多的困難,這一直是Facebook和谷歌這些依賴廣告收入的企業最大的擔憂。但對於領英而言,用戶採用移動端上網,只能讓它的數據更為豐富。另外,領英遵循開放的生態系統模式,早在2007年就推出智能應用平台(intelligent application platform),允許第三方軟件商開發應用軟件,幫助領英及其商業夥伴將鏈接互嵌入各自網頁。目前,已有超過7萬多軟件開發人員為領英打造各類應用軟件和服務。領英的定位清晰,收入均衡穩定,和移動平台天然契合併具有開放性,商業模式幾乎無懈可擊。

  卓越的企業文化

  企業文化雖然無形無相,卻是企業獲得持續成功的關鍵因素。所謂性格決定命運,企業文化決定的則是一個企業的成敗。和優質產品和高效商業模式相比,企業文化處於更為戰略的層面,能夠高屋建瓴地解決企業未來發展的宏觀問題。一個企業能否持續健康發展,全在於它是否具備健康積極的企業文化。

  領英現任CEO傑夫·威納爾(Jeff Weiner)在被問及領英成功的核心秘密時,毫不猶豫地指出是企業文化,並將其核心精神概括為:向世界做出積極貢獻為目標、將領英打造成為全球最佳企業為奮鬥方向、崇尚正直誠實的作風、營造協作和開明的工作氛圍、把快樂和卓越的工作成績作為企業管理的重點,並在讓每個員工感到自身工作深遠意義的同時,充分享受工作的快樂。同時,領英的文化鼓勵員工承擔風險,永遠保持新創企業的心態,銳意創新,敢為人先。

  為將企業文化落於實處,領英通過定期組織活動來不斷強化企業精神。在領英,一個最受員工歡迎的活動是每月兩次的全員聚會。總裁威納爾、高管團隊和員工濟濟一堂,聊聊公司的最新進展和願景,然後歡迎新員工,並要求他們表演節目。整個活動氣氛歡樂而積極,對企業文化的建立至關重要。另外,為鼓勵員工的協作共榮,領英設立了每月一次的旗艦項目「駭客日」(Hackdays),允許員工自組5人團隊在三天內解決他們感興趣的創新問題,並在全公司內部進行評選。獲獎團隊不但獲得精神上的認可,還會獲得資金將這些創意變為現實。領英的一些成功產品如簡歷自建器(Resume Builder)等都是這項活動的產物。

  領英還投入大量資源用於員工培訓,如為期四周的工程師集訓營,管理者培訓項目和每月一次的自我培養日(Investment Day),並允許員工自由選擇個人發展的內容,如參加課程、專業會議、輔導或被輔導、慈善義工、學習新技術等。這項活動的宗旨在於讓員工有時間從繁忙的日常工作中暫時脫離,放鬆身心並思考,以成為各方面均衡發展的個人,而非工作狂。通過建立企業文化的各種措施,領英將一個清晰而強大的企業使命和正能量注入到每個員工的心中,不但幫助他們成長,同時不斷改良企業,從而改變整個世界。

  領英的輝煌前途

  雖然領英已取得驕人成績,但它立志高遠,放眼更為宏大的目標。領英的最終計劃是將全球33億職場人士都納入其網絡中。不但如此,隨著人力資源數據的日益豐富,其旨在將每個職場人士的技能、背景和資歷與各個公司的人力需求對接,即打造全球人力市場供求圖表。這項工作一旦完成,將會對全球人力資源市場及經濟產生直接而深遠的影響。因為這份宏大的供求圖表能將員工和工作崗位的錯位問題降到最小,從而使全球人力市場運作更加有效,並在很大程度上解決就業和失業問題。

  當然,在開拓此極具潛力的嶄新領域中,領英將面臨嚴峻挑戰。網絡社交巨頭Facebook、微軟、谷歌、推特和salesforce.com都是其強有力的競爭對手。在同一領域的法國企業Viadeo和德國Xing也不可小視。尤其是Viadeo,近年來積極拓展中國市場,並收購了天際網,坐擁6000萬用戶,對領英的霸主地位虎視眈眈。但領英的前途一定輝煌。如果說,企業成功有方程式,那就是優異的產品、優異的商業模式和優異的企業文化。領英三者兼備,世間少有。尤其是它的企業文化立意高遠,給人以積極進取的力量和靈感,堪稱企業中的典範。


LinkedIn是怎麽應對用戶流失的?

來源: http://www.iheima.com/news/2015/1015/152368.shtml

很多人都玩過《憤怒的小鳥》,有一只鳥,飛到半空中,以拋物線的姿態,這條拋物線可以分成四個點,起飛點、平衡點、快要降落點、降落點,是不是客戶的生命周期有類似之處,從消費開始、成長、穩定、下降,最後離網。

我們想讓這只小鳥飛得遠一點,不要立刻落地,落地就相當於客戶流失了,應該在哪一個生命周期做工作?

一、什麽時候給它一個推力,它可以飛得更遠?

還有一個有意思的故事,Linkedin是個企業級的服務商,它是世界上第二大的SAAS公司,就是提供企業軟件服務的。

以前我們在LinkedIn最早做客戶流失模型時,每次檢測到用戶快流失的時候,就給他發E-Mail(美國一般都用E-mail營銷),比如給客戶50%的折扣、或者這個月可免費等促銷手段,但我們很快發現,客戶立馬關了,他關了。

啟動營銷方案了,用戶流失的可能性反而加大了。

為什麽?因為很多付費用戶都忘了自己在付費,等到我們檢測他會流失的時候,一旦郵件發了50%這種折扣促銷,反而等於提醒了他還在付費,立刻讓他把賬戶關了。

我們開始反省用戶流失模型怎麽會產生負面影響?用戶不使用我們的產品,產品沒有價值,怎麽做?

把助推點提前,把用戶生命周期往前推,不是在他流失的時候,才對他進行照顧,而是把郵件或者營銷方法提前,提前到小鳥飛行中間節點,好很多。後來甚至推到極致,在他剛剛開始註冊賬戶,LinkedIn負責客戶關系的部門就介入培訓客戶,又好很多。

在我們負責推廣這套客戶關系系統管理後,LinkedIn用戶的流失率從最早的時候51%、變成30%到了今天低於20%,估計明年的流失率是10%以內。

流失率從50%降到10%,每年有90%的付費用戶留存,這意味著什麽?中間Revenue是在以幾何倍數的增長。

大家可以再玩一下《憤怒的小鳥》,數學分析和物理相互關系,把低活躍變成高活躍,為未來流失減低做了很多偉大貢獻。 

所有數據和業務是完全強關聯,管理客戶流失在早期就要進行行動。但和產品接洽時間不一樣,每個客戶流失時間也不一樣。以前把所有用戶加起來報一個數,這是錯誤的。

鳥飛得遠,不是同時發出去,是按照時間點發的,每個用戶精確管理它的生命周期。也就是今天我們講的行動和數據緊密結合。

二、怎麽可能精確到管理每個客戶?

LinkedIn有3.5億左右的用戶,5000名銷售,我們怎麽可能能精確管理到每個客戶的生命周期呢?

彼德·德魯克說,如果一個事物無法度量的話,那麽我們就沒法管理它。說的是,定下目標以後,必須要可衡量、可度量,我們才能對它進行管理和成長。

我們怎麽能做到可衡量、可度量每一個客戶的生命周期?

我們當時針對所有用戶,他們怎麽用Linkedin網站的,我們分析了每一位用戶的行為,每個公司的獵頭人員,或者每個賣家、買家很細微的點擊、看、發信。

把這些細微的行為,算出來了一個積分,我們定期地對用戶進行打分,每天、每星期、每月,打完分以後對整個數據庫進行排序,每天只把這種最有可能流失的客戶,及時地通知負責客戶管理的客戶關系經理。

而在以往,還是每個季度才能做一次這樣的分析,為什麽?

因為慢。

現在Linkedin變成實時地在計算著這種東西,每天都能看到最重要客戶的排名,最可能流失的客戶排名。這樣,客戶關系經理的效率極速提高。以前,他拍腦子都不會知道,這300個客戶里面張三、李四都在幹什麽,但今天,僅僅通過一張積分表,他就能夠很精準地預測一個用戶的流失。

這實際上就是自動化。這是一個高緯度自動化的模型在後面猛烈計算,它算出來一個非常簡單的數字值。

以前在Linkedin產品里面,我們當時大約有200-300個不同KPI。後來通過這個抽象出來以後,只有兩個值,銷售或者客戶關系經理只看兩個數值,溫度和健康度。

溫度,就是說用戶繼續購買Linkedin服務的可能性有多少。

健康度,就是說用戶使用這個產品的頻次有多少.

使用並不表示他要付費,付費並不等於他要使用,但是這兩個東西放在一起以後,所有的人員就都被這些數據帶動起來了。

比如說一個客戶非常健康卻不購買,那麽客戶關系經理就要追賣東西;有的客戶只付費不使用,這些客戶一定會流失,客戶關系經理就要開始培訓客戶如何使用付費功能………

這樣,每天都在帶動客戶越來越和這個平臺有更多的互動,這套東西後來就形成了整個客戶成功的服務體系。

到今天,Linkedin的員工90%的銷售每天都在用這套系統,99%的人每周都在用這套系統,每天會用多少次?平均每天每個人用10次左右。

而在以前,他一年才能做兩個數據驅動決策,現在他每天基本平均接觸10個數據決策。這樣他的效率是呈幾何倍數在升高。

結果就是,流失率從50%降到10%,每年90%的付費用戶留存。

所以,為什麽要做數據驅動下的精細運營,其實數據驅動的核心就是要提高效率,真正做數據驅動就是為拉十列車裝上輪子。

本文作者,GrowingIO CEO張溪夢:前LinkedIn美國商業分析部高級總監,美國Data Science Central評選其為“世界前十位前沿數據科學家”,親手建立了LinkedIn將近90人商業數據分析和數據科學團隊,支撐了LinkedIn公司所有與營收相關業務的高速增長。

本文作者張溪夢,文章僅代表作者。如需轉載請聯系郵箱[email protected]授權,未經授權,轉載必究。


它估值逾300億,LinkedIn創辦人也投資 主宰區塊鏈生態的隱形霸主

2016-03-07  TCW

如果說區塊鏈技術即將發動改變世界的革命,Blockstream(區塊流)這家公司就是加速這場革命的引擎!

成立不到兩年,融資總額已經達七千六百萬美元(約合新台幣二十五億元),估值上看十億美元,是全世界近千家與區塊鏈相關的新創公司中,融資速度最快、估值最高的公司。

其背後的投資者更是驚人,包含全球最大人脈網站LinkedIn創辦人霍夫曼(Reid Hoffman)個人,Google前董事長施密特(Eric Schmidt)旗下創投,以及亞洲富豪李嘉誠旗下維港投資。

能同時獲得東西方科技界與富豪們的青睞,在千家類似概念的新創公司中勝出,關鍵,就在它的核心創始團隊。

團隊兩成員有核心訪問權

執行長希爾(Austin Hill)從一九九0年代就開始研究電子貨幣,曾成功創辦兩家公司。其他成員則來自Google、微軟、火狐(Pirefox),有駭客級電腦高手,也有密碼學家與安全防護專家。最重要的是,這公司成員中有兩人握有進入比特幣區塊鏈核心資料庫的訪問權。

區塊鏈設計的原則,就是要去中心化,沒有任何單一個人或權威能決定其發展,所有的變動都是要採用共識決,就像是聯邦制度中的內閣一樣。比特幣核心開發者賀恩(MikeHearn)指出,全世界只有五個人可以修改核心源代碼,而Blockstream就占了兩個,另外三人中有兩人的立場向來都偏向該公司。

換句話說,它是區塊鏈世界的最大黨,只要他們四人意見一致,就能左右區塊鏈未來的發展。這讓該公司擁有了舉足輕重的業界地位。

創辦Linkedln之前曾擔任過電子支付系統Paypal的資深副總裁霍夫曼,在被問到為何投資Blockstream時說:「他們的技術不僅可以改善整個區塊鏈的生態系統,更會改變世界。」

獲利多來自加速流程技術

因區塊鏈現在還在萌芽階段,規模不夠大,傳輸速度也不夠快,平均一秒鐘只能完成七筆資料傳輸,若是應用在貨幣交易上,更可能延遲到一小時。

乍聽之下似乎沒什麼,但因為速度過慢造成使用者對整個交易過程產生懷疑,將近七0%的人不願再嘗試,更不用說交易速度要精確到毫秒的股票、期貨交易。

它的技術,正是能將整個交易流程從分鐘縮短到秒,大幅提高交易的便利性。這也是它主要的獲利來源,只要有人想要使用這個加速技術,它就能從中收取服務費。

另外,由於區塊鏈就像Linux Android一樣,屬於開放式的平台,任何人都可以在上面開發不同的服務,從而產生了不少旁枝,而每個旁枝都想爭奪主導權,各自訂定了獨立性的規則,造成了彼此之間難以串聯,就像現在台灣的第三方支付系統一樣。

Blockstream同樣能解決這個問題,它能把不同的區塊鏈服務整合在一起,讓資產可以在不同的系統問自由轉移。這就大幅提升了交易便利性,讓整個生態系統更加成熟完善。「我們就像是思科(Cisco)一樣,不是開發酷炫的服務或產品,而是把基礎建設與設備做好,讓更多使用者進來,」希爾說。

看上它的技術能力,全球四大會計師事務所之一的資誠(PWC)搶著與它戰略合作,創實體服務之先河。這意味著區塊鏈不只是一群宅男玩弄的高科技概念,而是可以與現實生活中的主流企業串聯。

採訪過程中,希爾興奮的談論著如何運用區塊鏈把貨幣決定權從政府收回人民手上,我彷彿看到一棟棟樓高牆大樓土崩瓦解,取而代之的是一個廣闊平坦的新世界。

撰文者林俊劭


262億美元!微軟宣布收購全球最大職業社交網站LinkedIn

來源: http://www.iheima.com/zixun/2016/0613/156492.shtml

262億美元!微軟宣布收購全球最大職業社交網站LinkedIn
i黑馬 i黑馬

262億美元!微軟宣布收購全球最大職業社交網站LinkedIn

根據協議,微軟將為每股LinkedIn股票支付196美元,微軟方面表示,在收購之後將會繼續保留LinkedIn品牌、文化和獨立性

i黑馬訊 6月13日消息 今日晚間,美國微軟公司宣布,已同意以262億美元現金收購全球最大職業社交網站LinkedIn。受此消息推動,LinkedIn股價盤前飆升47%。

根據協議,微軟將為每股LinkedIn股票支付196美元,較該股上周五收盤價溢價50%。微軟表示,計劃發行新債券為此項交易融資,並預計此項交易將使其2017財年剩余時間的每股盈利減少約1%。

此項交易預計將於今年年底前完成,LinkedIn現任CEO傑夫-韋納(Jeff Weiner)將繼續領導該公司,並向微軟CEO薩蒂亞-納德拉(Satya Nadella)匯報。微軟方面表示,在收購之後將會繼續保留LinkedIn品牌、文化和獨立性。

據悉,LinkedIn (領英) 創建於 2002 年,致力於向全球職場人士提供溝通平臺,並協助他們事半功倍,發揮所長。作為全球最大的職業社交網站,LinkedIn 會員人數在世界範圍內已超過 3 億,每個《財富》世界500強公司均有高管加入。

2002 年,Reid Hoffman在自家客廳里與合作夥伴共同創建了領英,2003 年5月5日,網站正式上線。

LinkedIn 微軟 收購
贊(...)
文章評論
匿名用戶
發布

微軟收購LinkedIn,下一個輪到Salesforce?

來源: http://www.iheima.com/zixun/2016/0614/156498.shtml

微軟收購LinkedIn,下一個輪到Salesforce?
科技茱比莉Jubilee 科技茱比莉Jubilee

微軟收購LinkedIn,下一個輪到Salesforce?

LinkedIn歸並微軟之後將獨立存在,但是它必將實現微軟企業軟件社會化的目的。

文|陳翔

微軟262億美元收購LinkedIn的消息一夜之間已經鋪天開地,隨即LinkedIn股票大漲愈50%。很多人都質疑為什麽?這個被微軟和LinkedIn稱作“全球最領先的企業雲”和“全球最領先的職業網”的結合,到底說明什麽?

茱比莉朋友圈中的一位SaaS企業創始人判斷一語中的,他在微信寫到:“下一個會是Salesforce?”不僅闡釋了為何微軟會這樣做,而且預測了微軟的戰略路徑。LinkedIn被外界看做披著2B外衣的社交網絡公司,歸並微軟之後將獨立存在,但是它必將實現微軟企業軟件社會化的目的,這和微軟企業軟件雲化相得益彰。

企業軟件社交化:社交網絡也許被認為是消費端的事兒,但是在企業級軟件中,類似Yammer(2012年已被微軟12億美元收購)、釘釘等協同軟件的大熱,甚至微信群在企業中的廣泛應用,都讓企業軟件開始社交化。好處顯而易見,這可以帶來偏平化、跨組織的高效協作。

企業軟件雲化:在雲計算大潮下,微軟的Office365已經成功從傳統生產力工具軟件變成了SaaS雲服務。微軟CEO納德拉在公開聲明中指出,

“與LinkedIn的交易將使Office365和Dynamics與全球最大最有價值的職業網絡聯機在一起,微軟可以開發出更多新方法來提供職業人士的辦公生產力,同時重塑銷售、營銷和人才管理業務流程。”

這就已經招式了微軟的野心,HR、CRM赫然紙上,這正是全球最大的SaaS企業Salesforce的地盤。

這是納德拉上任微軟CEO兩年以來操刀的首次重大並購,這也更為深刻理解納德拉將“雲”作為戰略發展方向。在傳統軟件上,微軟沒有成效的HR、CRM領域,無疑成就了SAP和甲骨文的成功,而在雲計算顛覆一切的趨勢下,通過SaaS雲應用就可以實現變道超車。

因此,Salesforce恐怕是微軟實現大計的必備之選。微軟對Salesforce的態度並非揣測,早些時候,Salesforce一直傳出被軟件巨頭看上的消息,甲骨文和微軟都是熱門人選,當然收購金額更是一度傳聞高達400億美元以上。

當然微軟也可以通過此次262億美元的收購,鞏固自身的CRM Dynamics,但是立竿見影還是直接收購。按照微軟的套路,不僅做了Windows、office、IE,安全,居然又做了平板surface和電腦;

那麽在“雲+移動”的戰略下,雲作為戰略投資,不僅做了IaaS、PaaS的Azure雲,還有SaaS的Office365,再接著整合企業級社交Linkdein進而進軍HR、CRM領域,來個“全套雲”也未嘗不可。

所以如果微軟有足夠的現金,下一個大筆收購就是Salesforce?

q22.webp_副本

微軟 LinkedIn Salesforce
贊(...)
文章評論
匿名用戶
發布

微軟CEO就收購Linkedin交易致員工電郵

來源: http://www.iheima.com/zixun/2016/0614/156494.shtml

微軟CEO就收購Linkedin交易致員工電郵
楊博丞 楊博丞

微軟CEO就收購Linkedin交易致員工電郵

微軟在宣布收購完成後,微軟CEO薩提亞·納德拉就收購Linkedin一事向公司員工發出電子郵件。

i黑馬訊 6月14日消息,微軟周一傍晚時宣布,該公司將以262億美元的現金價格收購職業社交網站LinkedIn,這是微軟歷史上規模最大的一項收購交易。

微軟CEO薩提亞·納德拉就收購Linkedin一事於北京時間6月14日淩晨向公司員工發出電子郵件,全文如下:

致微軟團隊:

今天,我很激動地在此分享微軟宣布收購Linkedin的消息。在公開的展示文件中,你們可以看到Linkedin CEO傑夫·韋納爾(Jeff Weiner)和我是如何構想未來將有的機會的。

這項交易將把全球領先的專業雲服務與全球領先的職業社交網絡結合到一起。我對Linkedin已經有了一段時間的了解,同時也還可回想起社交網絡是如何讓雲服務真正變得各不相同的。在我看來,Linkedin團隊明顯已經發展出了一項不可思議的業務,構建起了一個擁有4.33億名用戶的令人印象深刻的社交網絡。

鑒於這是自我出任微軟CEO以來規模最大的一項並購交易,我想要與你們分享自己有關並購的整體想法。首先,我考慮的問題是一項資產是否將可擴大我們的機會——尤其是,這種資產是否能夠擴大我們的整體可尋址市場?這種資產是否能夠駕馭長期的使用和技術發展趨勢?這種資產是否契合我們的核心業務和整體使命感?

就Linkedin而言,所有這些問題的答案都是肯定的。我們都在尋求履行同一種使命,其核心是給個人和組織帶阿里更大的能力。

我們的Office 365商用業務和Dynamics業務都正在取得新的增長,而這項交易對於我們對生產力和業務流程進行再創造的大膽抱負來說是至關重要的。想想看吧:人們如何找到工作、如何發展自身技能、如何出售產品、如何開拓市場以及如何做好自己的工作,都是需要在一個緊密聯系的職業世界中進行的,需要一個生機勃勃的社交網絡,從而把LinkedIn網絡上一名專業人士的信息與Office 365和Dynamics上的信息結合起來。

這種結合將令一些新的體驗成為可能,比如說LinkedIn信息流能基於你正在做的項目提供相關文章,而Office則可建議一名專家通過LinkedIn與你取得聯系,幫你完成手頭的任務。這些體驗將會變得更加智能,也更能令人愉悅,因此LinkedIn和Office

365的用戶參與度也就將提高。反過來說,新的機會將可通過個人和組織訂閱及定向廣告而被創造出來並被商業化。

傑夫和我都認為,我們有很大機會將可加快Linkedin的增長速度,並給其用戶帶來微軟的資產和規模所能創造出來的價值。事實上,當Linkedin創始人雷德·霍夫曼(Reid Hoffman)和我在談及兩家公司合並將可帶來的機會時,他將此稱為Linkedin的“二次創立”時刻,並帶來一個能讓這家公司完成13年前成立時所抱使命的機會。

對Office 365和Dynamics來說,這項交易也同樣能帶來深遠的機會。在過去十年時間里,我們已經將Office從一種生產力工具變成了一種跨越任何平臺和設備的雲服務。這項交易對Office 365和Dynamics而言代表著下一步的發展方向,原因是它們將可與全球最大的、最有價值的職業社交網絡結合到一起。

實際而言,我們將可重新創造出新的方式,提高專業人才的生產力,同時對銷售、營銷以及人力管理業務流程都進行再創造。我已經迫不及待地想要看到,一旦交易完成以後,我們的團隊將可聯手創造出什麽樣的產品。我們預計,交易將在今年完成。

這項交易在很大程度上旨在加快Linkedin的增長速度。為了達到這個目的,LinkedIn將保留其獨特的品牌和獨立性,公司文化也將保持不變,而LinkedIn的公司文化與我們的公司文化是相當契合的。傑夫將繼續擔任LinkedIn CEO,他將向我匯報工作,並加入我們的高級管理團隊。

實際上,我已要求傑夫去做的事情就是根據帶來了我們的整體成功的各項主要績效指標來管理LinkedIn。

隨後,他將決定整合哪些東西是有意義的,而哪些是沒有意義的。我們知道,近期內誰向誰匯報工作是不會有所變化的,就此而言微軟內部的工作匯報關系也不會改變。這種作法旨在讓Linkedin的團隊能將重點放在努力作出成果上去,同時又能與Office 365和Dynamics團隊配合實施產品整合計劃。

在整合期間,我們將會選擇雙方能深度合作的關鍵項目,這些項目最終將可為用戶帶來新的體驗。科特·德爾貝恩(Kurt DelBene)將負責領導微軟內部的整體整合事務,與陸奇和斯科特·格思里(Scott Guthrie)展開密切合作。

我今天身處LinkedIn的加州園區,將在太平洋時間8:45與傑夫、布拉德和艾米召開一次投資者電話會議——如果你們可以的話,也請來參加。隨後,我將花一天時間會見LinkedIn團隊。明天,我將召開一次特別的微軟職員問答大會,希望你們能來參加。

到目前為止,我對Linkedin團隊的了解還只是我們兩家公司的文化有著很多的共同特性。我們都非常關心個人和集體的成長,而且都認為我們所做的工作能讓整個世界變得不同。我們將可聯手做到這一點。

在我置身於北加州分享我們有關讓專業人才變得更有能力的觀點的同時,Xbox團隊正在南加州的E3大會上分享我們有關給遊戲玩家也帶來更大能動性的觀點。我鼓勵你們留意E3大會的新聞發布會,此次大會將在太平洋時間9:30召開。

最後,如果你們還不是Linkedin用戶,那麽現在就加入並開始使用和了解更多吧。

薩提亞

微軟 內部信
贊(...)
文章評論
匿名用戶
發布

刷屏後的冷思考:262 億美元買下LinkedIn,微軟為什麽?

來源: http://www.iheima.com/zixun/2016/0615/156549.shtml

刷屏後的冷思考:262 億美元買下LinkedIn,微軟為什麽?
石慧 石慧

刷屏後的冷思考:262 億美元買下LinkedIn,微軟為什麽?

一篇文章看懂這次收購。

i黑馬 黑馬說  相信這幾天,你的朋友圈已經被微軟收購LinkedIn刷屏了,也許你還轉發了。但黑馬哥知道,看了各種角度的分析之後,你其實還是沒弄懂這次收購到底是怎麽回事(來打我呀)。別急,讓哥來跟你講講。畢竟這麽重要的事,你一定要明白發生了什麽。

微軟以262 億美元收購LinkedIn,溢價接近50%,這引發了最大的爭論點——微軟虧不虧?他到底想幹什麽?

微軟自己當然覺得值了。

據BI中文站報道,微軟首席執行官納德拉(Satya Nadella)已向員工們發出公開信,表示了他對這項交易的期望,“將全世界領先的專業雲、全世界領先的職業網絡融合在一起”,“是我們重塑生產力和業務流程的目標的關鍵”。

他認為,LinkedIn的職業信息、Office 365和Dynamics中的信息兩方面的結合將創造新體驗,比如讓LinkedIn新聞聚合根據你正在做的工作來推送相關文章;Office則可以提供專家人選,你通過LinkedIn與專家聯系,幫助你完成工作。隨著用戶體驗和參與度上升,微軟就能通過個人和組織付費服務和定向廣告創造新的盈利機會。

騰訊科技展示了微軟的官方解釋。其中提到LinkedIn是全球最大且最具價值的職場網絡。其用戶不斷增長,在200多個國家的地區,有超過4.33億用戶,超過1.05億月活躍用戶;活躍度也不斷增長,每季度450億次頁面瀏覽量,超過700萬個活躍職位發布;收入不斷增長:周營收達30億美元。以及雙方合作將創造出3150億美元的新潛在市場。

LinkedIn得了“便宜”也必須賣個乖。據愛範兒介紹,領英董事長里德·霍夫曼(Reid Hoffman)在聲明中說,今天對 LinkedIn 來說是個重生的時刻。消息一出,領英股價暴漲,盤前股價上漲幅度直逼50%,達到 194.5 美元,幾乎達到微軟的每股收購價。

領英全球副總裁兼中國區總裁沈博陽也表示:這是科技史上最大的收購之一。領英加微軟,想象空間無限。

客觀來講,在過去 6 年間,LinkedIn從一個 7000 萬左右年營收的企業,增長至 30 億美元營業額的企業,增長超過40倍。這種增長速度是驚人的。前 LinkedIn 美國商業分析部高級總監張溪夢認為,華爾街給予 LinkedIn 的估值,基於很多非常基礎的指標。

她撰文介紹說,其中一個重要的公式就是獲客成本(CAC)和用戶生命周期價值(LTV)之間的關系,LinkedIn 獲取企業客戶的成本遠遠低於普通的 SaaS 競爭對手。LinkedIn 對比普通運營良好的 SaaS 企業, CAC/LTV 比值一般只有競爭對手的一半左右。銷售和市場的總cost,比競爭對手或同類型公司低一倍以上。

LinkedIn 的企業級客戶銷售效率是業內最佳之一。其中的數據驅動整個的變現團隊(銷售,市場,運營,產品)用超快的速度獲取了客戶,最有效率的減少了用戶的流失,同時在單位時間內,在既有客戶上有效率的變現和增長。這是華爾街一直給予 LinkedIn 較高估值的核心原因。

而且,雙方攜手帶來巨大的想象空間。來自紐約的一家外國數字產品服務機構,分析了二者聯合能做的9件事。包括微軟可以將LinkedIn作為Windows的一項嵌入服務,當你想聯系LinkedIn中的人脈,你可以直接用Hotmail 和Outlook寫信,一鍵發送。

微軟可以將LinkedIn嵌入Microsoft Office。Office將承擔更多社交功能。當你不知道論文中的某一部分怎麽寫,你可以請求行業專家為你填充這部分內容。微軟還有一個巨大的機會,將LinkedIn變成全球商界的交流平臺。

微軟可以利用LinkedIn的數據制定產品策略。微軟能在紮克伯克之前知道Facebook的走向,知道全球的HR在尋找什麽。因此,它可以用這些信息向公司推廣自己的服務。微軟還可以利用LinkedIn的數據創造新的廣告產品。它一邊知道了你每周打開幾次Microsoft Excel, 另一邊又知道了你在現在的職位上待了多久,你的上司是否剛獲提升。這樣的連接,一定會讓世界上最大的廣告商和媒體廣告買主蓄勢待發。

最終,微軟將會提升LinkedIn,讓其更像一個現代的、聚焦商業的社交網絡。

有人覺得值,自然也有人唱衰。畢竟,數據不都是鼓舞人心的。據悉,今年2月,LinkedIn的股價已經出現了一次“大波動”,在公司報表放出後,盈利一項的數字沒有達到預期,股價下跌近 41%,市值蒸發 100 億美元。那次下跌的初始價格正好是192美元,與微軟目前 196 美元的單股收購報價相差無幾。簡單來說,這4個多月來領英在股價上面的虧空直接被微軟一舉填補。

更有意思的是,領英在上市前,曾想以20億美元作價賣給微軟,但微軟當時沒有收購。BI透露,微軟最早的報價是 5 億美元。對此,職場社交軟件脈脈上有人評論稱,微軟真逗,5億不要,兩百多億要了,另有人對此回複稱,如果領英當時賣了,現在也就不值這個價。

如果從這個角度來看,領英還真是高明。

脈脈CEO林凡也談了他對此次交易的看法。他認為,LinkedIn團隊已經耗費了15年,團隊的變現訴求更大,而微軟又急於鞏固地位,才促成了這次的收購。對2B創業肯定是利好。“這次收購是全現金交易,對於核心團隊來說,當手上的股權全部換成現金以後,不管明面上說得有多好聽,實際上當口袋里有這麽多錢的時候,有多少人會繼續努力奮鬥,有多少人會去享受生活,大概都能想清楚……”

林凡還爆出一條小道消息,Facebook即將設立中國公司,有些員工就是從領英中國挖來的,這些人甚至都還未正式提出離職。

無論如何,這次交易再次證實了職場社交的前景,也對國內社交市場產生了不小的震動。

“我們更關註用戶,不太在意競爭對手的變化,因為滿足用戶需求才是最終成功的關鍵。不過客觀來說,收購必然會帶來領英中國的目標、人員結構等一系列不確定因素,對脈脈在中國市場的競爭態勢是有利的。”林凡認為這次新聞對脈脈的競爭態勢是“有利的”,難怪也有用戶也脈脈上面開玩笑,脈脈這下身價高了,以後會不會也和巨頭結婚呢?

黑馬哥總結:微軟為什麽要領英?主要看中其數據能和微軟的企業業務相結合,並使其市場得到進一步增長。微軟有的是錢,但缺少代表未來的產品形態,做過MSN,但已死掉,此後一直缺少一款直接觸達用戶的工具。領英做了14年,用戶遍布全球兩百多個國家,數據庫龐大,盈利能力尚佳,代表著未來,同時也是微軟應對Facebook、Google等不斷深入企業服務領域、加劇市場競爭的一個手段。

而對於領英團隊來說,或許正如林凡所言,創業了14年,獲得兩百多億美金現金,也是相當不錯的選擇。

只是從此以後,“美國最佳老板”傑夫·韋納要給微軟匯報工作了。

領英 微軟 收購
贊(...)
文章評論
匿名用戶
發布

Next Page

ZKIZ Archives @ 2019