講師介紹
歐陽辰，超過15年的軟體開發和設計經驗，目前就職于小米公司，負責小米廣告平台的架構研發。
曾為微軟公司工作10年，擔任進階軟體開發主管，上司團隊參與微軟搜尋索引和搜尋廣告平台的研發工作。曾在甲骨文公司從事資料庫和應用伺服器的研發工作。熱愛架構設計和高可用性系統，特别對于大規模網際網路軟體的開發，具有豐富的理論知識和實踐經驗。
大家好，很高興能跟大家分享一些關于實時資料分析的話題。
剛畢業時我有幸去了oracle公司做企業軟體資料庫，成為oracle中國第一批研發員工。後來做了幾年，覺得還是想做網際網路軟體，就去了微軟，工作了十年左右。在那做兩個項目，一個是搜尋，一個是廣告平台。去年一月份加入小米公司，現在主要負責搭建廣告平台和大資料平台。
是以今天我會結合我在小米、微軟的一些大資料實踐，給大家談談我對大資料的了解，并介紹一些好用的工具。
本次演講的内容大緻分為以下部分：
大資料和價值
大資料分析工具分類
hbase的應用和改進
druid的實時分析實踐
其它工具的探索
一、大資料和價值
什麼是大資料？衆說紛纭。大家似乎覺得具備快、多、變化大、種類多四個特征的資料就是大資料，我個人更願意從另一個角度來定義：隻有當你擁有全量的資料，并通過非常多的資料把問題解決得比較完美時，這時候的問題才是叫做大資料問題。
給大家舉個例子：比如說計算中國的人口，我們可以通過每省、每市、每區的抽樣、采樣等方法來擷取非常接近真實的資料，很快就能完成這個任務。但是這個通過采樣解決人口統計問題的場景是否就是大資料問題呢？再給大家舉一個我自己在做的大資料問題——廣告系統的推薦。由于每個人看的廣告内容、類型都是不一樣的，你需要對每個人去做算法，通過資料分析挖掘每個人的資料潛力。假設現在你想通過一些算法找到一些使用者喜歡的廣告或者内容，而這時你要找到的内容少了一半，你就沒法推算出一半使用者的資料，這時候你的效果也差了一半。也就是說你的資料量越多，覆寫越多使用者，效果越好時，這時候我們可以認為它是一個真正的大資料問題。
大資料外表光鮮亮麗，就像紅樓夢裡的大觀園，但裡面其實是很無奈的。做大資料技術的同學都知道，這裡面涉及到資料的清洗、整理、存儲等很多很多枯燥的事情。此外，大資料還有一個特點，就是當你有了大資料，還得想如何去變現。在我看來，大資料實際上很難找到一個直接的途徑來變現，它的确可以去推動業務的智能化，做内容推薦讓使用者的體驗更好，但這些都是一些間接的變現場景，真正大資料能夠變現的場景，我自己總結了一下，大概有兩個方向：一個是廣告，二是銀行的征信系統，除了這兩個領域之外，很少有公司願意為資料買單。
下面簡單介紹小米的大資料技術架構。
和很多公司類似，小米的大資料架構也包括資料采集、存儲、管理、分析、算法和可視化。大部分元件都是開源的，另外我們會對一些核心的元件做一些深加工或者優化、自定義。其中，在資料采集部分就是scribe，存儲用得較多的還是hbase，後面我會介紹小米在這一塊的優化。管理上我們用了kerberos去做認證，在上面還有一些spark、storm、hive、impala和druid。
說到大資料應用，種類非常多，我簡單講一下小米在大資料上的一些應用。
首先是精準營銷，我們可以對每個使用者做一些畫像。用在搜尋和推薦上，讓它變得更加精準；還有網際網路金融，有一些征信體系可以用到；精細化營運；還有防黃牛，因為小米手機的成本效益較高，很多時候新品出來時黃牛們會去搶，另一方面，現在的黃牛手段越來越高明了，他們會模拟很多ip、新的賬号或者老的賬号等一些複雜的購買行為，是以就很需要采取一些手段去防黃牛。還有圖檔、圖像的分析和處理，像小米手機新推出的寶寶相冊等。
剛剛說的是一些業務的場景，還有一些給開發者用的場景。
比如說小米推出的一個資料統計分析平台，它提供一些api讓你嵌進去，可以用資料分析你的應用使用情況。然後結合小米的使用者畫像，為開發者提供更好的資料分析服務。
目前小米日活超過千萬的app大概有二十幾家，包括浏覽器、應用商店、視訊等，這些應用實時分析的需求非常旺盛，他們都是用這一套系統去做資料打點、ab測試、畫像、分組等，是以在後面我們需要一個吞吐量大的實時資料分析處理系統來承擔這部分計算的任務。
說到資料分析的步驟，最開始是資料收集，然後處理，清洗，模組化，分析，最後可視化。這是大概的基本步驟。
從資料分析的類型來看，也可以分為四個層次：最下面是一個比較基礎的層次，叫響應型分析，基本上是按照商業需求出商業報表。第二個層次叫診斷型分析，就是說當你有了很多資料以後，從資料裡面挖掘出一些問題，或者通過資料去解釋這些問題，像一些競品分析、趨勢分析。第三個層次叫戰略分析，這個層次相對前面兩個層次來說比較難了，即在做很多公司的分析時，你需要建個模型，然後用資料去得出一些結論，很多咨詢公司就提供這種戰略分析，像麥肯錫、貝恩等公司很多時候就是在這一層次做事情。最後一個層次也難，叫預測型分析。你不光要建好模，還要想到底怎麼做，采用什麼樣的行動，給出真正的建議。
二、大資料分析工具
小米統計平台承接的資料量非常大，而且對實時的要求非常高，是以在工具的選取上也花了很多時間。下面給大家介紹一下小米在大資料實時處理時一些工具選型的思路。
實時分析不是一個新問題，但如果上到億萬級的資料量時，這個問題也顯得非常重要。在資料分析尤其是多元分析這塊，有幾個流派，一個流派是開源的工具，還有一個流派是商業的工具。商業的工具中有幾家比較有名，一個是惠普的vertica，一個是oracle，oracle的不足之處就是太貴了，成本較高，還有就是teradata，美國加州一個老牌的多元資料分析公司。在另一邊的開源軟體，也可大概分為兩個流派，一個叫做molap ，它在設計之初就是想把資料結構變成一個多元資料庫，這樣查詢起來既快又友善；另一個叫rolap，企圖用傳統關系型資料庫去建構多元資料庫，因為像mysql、hive這種傳統資料庫是非常友善的。總的來說，開源的大概有兩條路，一條就是原生的支援多元的，另一條就是通過關系型資料庫去模拟這種多元查詢。原生多元這邊工具的話，小米用的比較多的就是druid，pinot，kylin和elasticsearch。
在選資料分析工具的時候需要考慮很多事情，像一些很重要的資料量，還有就是你需要分析這些資料的次元有多少，你的使用者并發度，這些都是實際過程中需要考慮的重要因素。特别是次元，次元越多，系統會越複雜。
剛剛前面講到小米的統計工具，這裡再放一張小米統計背景的架構圖，我把它稍微簡化了一下：
首先是手機、電視、電腦把事件通過網絡打開小米分析伺服器，這時伺服器有兩條路，一條路是把log存在 scirbe裡面，然後通過mapreduce和hdfs去做計算和存儲，結果會放到mysql資料庫和hbase中，另外一條路則是所有事件來了以後，經過kafka以及storm的計算叢集把預計算算好，最後存到hbase中。是以在小米統計平台上像分鐘級的資料都是從上面這條路來的，按天的資料則是從下面這條路來的，我們每天會用完整跑的log去取代實時的資料，大概是這樣一個過程。
三、hbase的應用和改進
小米用hbase還是蠻多的，hbase是一個比較有名的列式存儲，我們公司也有三個hbase committer，對hbase做了很多改進。比如對源代碼的改進，改完以後我們又會把這些改進傳回到開源社群。再如名字服務，以前的話，hbase通路要填很多server名、端口名，現在用一個名字就可以通路，包括hbase是不支援二級索引的，我們往裡面增加了索引功能。
在伺服器端改進的過程中，我們發現有些改進可以回報到社群，但有些回報回去時整個稽核流程特别慢，以至于後來小米内部慢慢、逐漸地就演變成了一個官方的版本，長期來看，這兩個版本的融合值得深思熟慮。
小米在初期時很多業務是使用mysql的，因為相對來說簡單粗暴，但它的容量有限。業務容量擴張以後，小米大概有兩億個使用者，1.5億個月活使用者，日活也超過一億多，mysql一般來說是撐不住的，這個時候很多業務就需要遷移到hbase上。
是以，最後小米提出一個很common的hbase遷移方法，在最開始寫資料的時候雙寫，既寫hbase又寫mysql的，保證新的資料會同時存在于hbase和mysql裡，第二個就是把mysql中的曆史資料遷移到hbase，這樣從理論上兩個資料庫就能擁有同樣的内容了。第三個是雙讀hbase和mysql，校驗資料是不是都一緻，一般達到99.9%的結果時，我們就認為遷移是比較成功的。最後灰階傳回到hbase結果。
四、druid的實時分析實踐
一開始做小米統計平台時，資料其實也沒有做到實時的，都是走上面的一條路，第二個階段通過mapreduce處理以後，把資料放到關系型資料裡面，比如像mysql這樣的資料庫。再後來，業務慢慢擴充，rdbms的容量有限，出現很多問題，是以到第三個階段我們把rdbms變成hbase，這個階段也持續了很久，再後來我們想得到實時的資料，來到第四步，通過kafka、storm再到rdbms或者nosql，最後一步我們直接是把資料從kafka轉到druid。
druid由一家叫metamarkets的公司開發，目前像yahoo、小米、阿裡、百度等公司都在用它大量地做一些資料的實時分析，包括一些廣告、搜尋、使用者的行為統計。它的特點包括：
為分析而設計
為olap而生，它支援各種filter、aggregator和查詢類型。
互動式查詢
低延遲資料，内部查詢為毫秒級。
高可用性
叢集設計，去中性化規模的擴大和縮小不會造成資料丢失。
可伸縮
現有的druid部署每天處理數十億事件和tb級資料。druid被設計成pb級别。
與druid相類似的實時資料分析工具，還有linkedln的pinot和ebay的kylin，它們都是基于java開發的。druid相對比較輕量級，用的人也多，畢竟開發時間久一些，問題也少一些。
druid在小米内部除了應用于小米統計之外，還應用于廣告系統。小米的廣告系統主要是對每個廣告的請求、點選、展現做一些分析，一條線是通過kafka→druid→資料可視化顯示，另外一條路就是完整資料落盤到hdfs，每天晚上通過資料重放去糾正druid裡的一些資料，覆寫druid的準确資料，最後做可視化。
五、其它工具的探索
pinot
pinot，linkedln開發的類似于druid的多元資料分析平台，它的功能實際上要比druid強大一些，但因為去年才剛剛開始開源，用的人比較少。大家有興趣的可以去試試。它的整個代碼量也比較大，架構與druid也非常相似，但它引入了更好的一種協調管理器，更多的是一種企業級别的設計，更加完整、規範。
kylin
kylin是ebay的開源分析工具，它的優點就是很快，特别适合每天定時報表，缺點也很明顯，就是随機查詢很慢。它還有一個好處就是支援标準的sql，與tableau等bi工具內建，可以直接連到ebay的這個kylin工具。而且，kylin在fast cubing上做了一些預處理，反應較快。
kudu
kudu是去年十月份apache開源的一個工具，與小米聯合釋出。它的定位是什麼呢？大家都知道druid是一個批處理、高容量的查詢系統，響應時間很慢，而hbase可以支援快速的響應時間，但它主要是一個寫少讀多的情況。
kudu，走在這兩個極端的中間，它既能夠保證大吞吐，又可以保證低延時。小米從去年十月份開始使用kudu，主要用于一些服務品質監控、問題排查，總體感覺還不錯。小米也是kudu現在最大的一個使用者，因為我們很多時候需要考慮hbase和druid綜合的一些優點，是以kudu也是小米目前實驗的一個工具。
elasticsearch
elasticsearch可能很多公司都有實踐，同樣可以對log和資訊做一些倒排表，核心是用lucene去做索引。
最後，小米雖然每天都在處理大資料、各種使用者的資料，但我自己的信念就是“我們需要像保護自己的眼睛一樣保護使用者的隐私”，小米在使用者隐私這方面投資了很多，并做出了明确的規定。
在歐洲，很多公司内部會把資料分成很嚴格的等級，像個人資訊，所有可以關聯到個人的資訊都是存在一個獨立的庫，任何人都沒有權限去通路。還有一些普通資訊，大家是可以用的，還有比如說超過一萬人的一些聚合資訊，可以拿去做一些算法。但個人資訊是堅決不可以通路的。而在2006年4月14日，歐洲當時還推出了一個非常酷的隐私權保護條例，它定義了每個公司要設立首席資料官，來保護資料隐私，并且要求每個公司資料都是可遷移的，也就是說，你的公司雖然擁有資料，但資料有權利把屬于他的個人資訊從一個服務商轉移到另外一個服務商。
分享的最後，總結一下我做資料分析多年來的心得：
1、沒有業務應用的大資料都是耍流氓，不要純粹去找工具，一定要結合業務去選擇。
2、技術選型沒有想象中那麼重要，實用和精通為妙。
3、次元不夠是一個永遠的痛，無盡的傷。在資料分析的過程中，次元是不斷增加的。是以在未來選擇工具的同時，一定要考慮次元的增加。
4、像保護你的眼睛一樣去保護使用者的權利和隐私。
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-07-28</b>