歐陽辰,超過15年的軟件開發和設計經驗,目前就職于小米公司,負責小米廣告平臺的架構研發。
曾為微軟公司工作10年,擔任高級軟件開發主管,領導團隊參與微軟搜索索引和搜索廣告平臺的研發工作。曾在甲骨文公司從事數據庫和應用服務器的研發工作。熱愛架構設計和高可用性系統,特別對于大規模互聯網軟件的開發,具有豐富的理論知識和實踐經驗。
大家好,很高興能跟大家分享一些關于實時數據分析的話題。
剛畢業時我有幸去了Oracle公司做企業軟件數據庫,成為Oracle中國第一批研發員工。后來做了幾年,覺得還是想做互聯網軟件,就去了微軟,工作了十年左右。在那做兩個項目,一個是搜索,一個是廣告平臺。去年一月份加入小米公司,現在主要負責搭建廣告平臺和大數據平臺。
所以今天我會結合我在小米、微軟的一些大數據實踐,給大家談談我對大數據的理解,并介紹一些好用的工具。
本次演講的內容大致分為以下部分:
大數據和價值
大數據分析工具分類
HBase的應用和改進
Druid的實時分析實踐
其它工具的探索
一、大數據和價值
什么是大數據?眾說紛紜。大家似乎覺得具備快、多、變化大、種類多四個特征的數據就是大數據,我個人更愿意從另一個角度來定義:只有當你擁有全量的數據,并通過非常多的數據把問題解決得比較完美時,這時候的問題才是叫做大數據問題。
給大家舉個例子:比如說計算中國的人口,我們可以通過每省、每市、每區的抽樣、采樣等方法來獲取非常接近真實的數據,很快就能完成這個任務。但是這個通過采樣解決人口統計問題的場景是否就是大數據問題呢?再給大家舉一個我自己在做的大數據問題——廣告系統的推薦。由于每個人看的廣告內容、類型都是不一樣的,你需要對每個人去做算法,通過數據分析挖掘每個人的數據潛力。假設現在你想通過一些算法找到一些用戶喜歡的廣告或者內容,而這時你要找到的內容少了一半,你就沒法推算出一半用戶的數據,這時候你的效果也差了一半。也就是說你的數據量越多,覆蓋越多用戶,效果越好時,這時候我們可以認為它是一個真正的大數據問題。
圖1 大數據的故事:價值為美
大數據外表光鮮亮麗,就像紅樓夢里的大觀園,但里面其實是很無奈的。做大數據技術的同學都知道,這里面涉及到數據的清洗、整理、存儲等很多很多枯燥的事情。此外,大數據還有一個特點,就是當你有了大數據,還得想如何去變現。在我看來,大數據實際上很難找到一個直接的途徑來變現,它的確可以去推動業務的智能化,做內容推薦讓用戶的體驗更好,但這些都是一些間接的變現場景,真正大數據能夠變現的場景,我自己總結了一下,大概有兩個方向:一個是廣告,二是銀行的征信系統,除了這兩個領域之外,很少有公司愿意為數據買單。
下面簡單介紹小米的大數據技術框架。
圖2 小米的大數據技術框架
和很多公司類似,小米的大數據框架也包括數據采集、存儲、管理、分析、算法和可視化。大部分組件都是開源的,另外我們會對一些核心的組件做一些深加工或者優化、自定義。其中,在數據采集部分就是Scribe,存儲用得較多的還是HBase,后面我會介紹小米在這一塊的優化。管理上我們用了Kerberos去做認證,在上面還有一些Spark、Storm、Hive、Impala和Druid。
說到大數據應用,種類非常多,我簡單講一下小米在大數據上的一些應用。
圖3 小米大數據應用
首先是精準營銷,我們可以對每個用戶做一些畫像。用在搜索和推薦上,讓它變得更加精準;還有互聯網金融,有一些征信體系可以用到;精細化運營;還有防黃牛,因為小米手機的性價比較高,很多時候新品出來時黃牛們會去搶,另一方面,現在的黃牛手段越來越高明了,他們會模擬很多IP、新的賬號或者老的賬號等一些復雜的購買行為,所以就很需要采取一些手段去防黃牛。還有圖片、圖像的分析和處理,像小米手機新推出的寶寶相冊等。
圖4 小米大數據實時分析場景案例
剛剛說的是一些業務的場景,還有一些給開發者用的場景。
比如說小米推出的一個數據統計分析平臺,它提供一些API讓你嵌進去,可以用數據分析你的應用使用情況。然后結合小米的用戶畫像,為開發者提供更好的數據分析服務。
目前小米日活超過千萬的APP大概有二十幾家,包括瀏覽器、應用商店、視頻等,這些應用實時分析的需求非常旺盛,他們都是用這一套系統去做數據打點、AB測試、畫像、分組等,所以在后面我們需要一個吞吐量大的實時數據分析處理系統來承擔這部分計算的任務。
圖5 數據分析的幾個步驟
說到數據分析的步驟,最開始是數據收集,然后處理,清洗,建模,分析,最后可視化。這是大概的基本步驟。
從數據分析的類型來看,也可以分為四個層次:最下面是一個比較基礎的層次,叫響應型分析,基本上是按照商業需求出商業報表。第二個層次叫診斷型分析,就是說當你有了很多數據以后,從數據里面挖掘出一些問題,或者通過數據去解釋這些問題,像一些競品分析、趨勢分析。第三個層次叫戰略分析,這個層次相對前面兩個層次來說比較難了,即在做很多公司的分析時,你需要建個模型,然后用數據去得出一些結論,很多咨詢公司就提供這種戰略分析,像麥肯錫、貝恩等公司很多時候就是在這一層次做事情。最后一個層次也難,叫預測型分析。你不光要建好模,還要想到底怎么做,采用什么樣的行動,給出真正的建議。
二、大數據分析工具
小米統計平臺承接的數據量非常大,而且對實時的要求非常高,所以在工具的選取上也花了很多時間。下面給大家介紹一下小米在大數據實時處理時一些工具選型的思路。
圖6 大數據分析工具
實時分析不是一個新問題,但如果上到億萬級的數據量時,這個問題也顯得非常重要。在數據分析尤其是多維分析這塊,有幾個流派,一個流派是開源的工具,還有一個流派是商業的工具。商業的工具中有幾家比較有名,一個是惠普的Vertica,一個是Oracle,Oracle的不足之處就是太貴了,成本較高,還有就是Teradata,美國加州一個老牌的多維數據分析公司。在另一邊的開源軟件,也可大概分為兩個流派,一個叫做MOLAP ,它在設計之初就是想把數據結構變成一個多維數據庫,這樣查詢起來既快又方便;另一個叫ROLAP,企圖用傳統關系型數據庫去構建多維數據庫,因為像MySQL、Hive這種傳統數據庫是非常方便的。總的來說,開源的大概有兩條路,一條就是原生的支持多維的,另一條就是通過關系型數據庫去模擬這種多維查詢。原生多維這邊工具的話,小米用的比較多的就是Druid,Pinot,Kylin和ElasticSearch。
圖7 如何選擇數據分析工具
在選數據分析工具的時候需要考慮很多事情,像一些很重要的數據量,還有就是你需要分析這些數據的維度有多少,你的用戶并發度,這些都是實際過程中需要考慮的重要因素。特別是維度,維度越多,系統會越復雜。
剛剛前面講到小米的統計工具,這里再放一張小米統計后臺的架構圖,我把它稍微簡化了一下:
圖8 小米數據統計分析平臺-架構
首先是手機、電視、電腦把事件通過網絡打開小米分析服務器,這時服務器有兩條路,一條路是把Log存在 Scirbe里面,然后通過MapReduce和HDFS去做計算和存儲,結果會放到MySQL數據庫和HBase中,另外一條路則是所有事件來了以后,經過Kafka以及Storm的計算集群把預計算算好,最后存到HBase中。所以在小米統計平臺上像分鐘級的數據都是從上面這條路來的,按天的數據則是從下面這條路來的,我們每天會用完整跑的Log去取代實時的數據,大概是這樣一個過程。
三、HBase的應用和改進
圖9 為什么青睞HBase?
小米用HBase還是蠻多的,HBase是一個比較有名的列式存儲,我們公司也有三個HBase Committer,對HBase做了很多改進。比如對源代碼的改進,改完以后我們又會把這些改進返回到開源社區。再如名字服務,以前的話,HBase訪問要填很多Server名、端口名,現在用一個名字就可以訪問,包括HBase是不支持二級索引的,我們往里面增加了索引功能。
圖10 HBase在小米的改進
圖11 HBase在小米
在服務器端改進的過程中,我們發現有些改進可以反饋到社區,但有些反饋回去時整個審核流程特別慢,以至于后來小米內部慢慢、逐步地就演變成了一個官方的版本,長期來看,這兩個版本的融合值得深思熟慮。
圖12 如何從MySQL平滑遷移到HBASE?
小米在初期時很多業務是使用MySQL的,因為相對來說簡單粗暴,但它的容量有限。業務容量擴張以后,小米大概有兩億個用戶,1.5億個月活用戶,日活也超過一億多,MySQL一般來說是撐不住的,這個時候很多業務就需要遷移到HBase上。
因此,最后小米提出一個很Common的HBase遷移方法,在最開始寫數據的時候雙寫,既寫HBase又寫MySQL的,保證新的數據會同時存在于HBase和MySQL里,第二個就是把MySQL中的歷史數據遷移到HBase,這樣從理論上兩個數據庫就能擁有同樣的內容了。第三個是雙讀HBase和MySQL,校驗數據是不是都一致,一般達到99.9%的結果時,我們就認為遷移是比較成功的。最后灰度返回到HBase結果。
圖13 實時數據分析之旅
四、Druid的實時分析實踐
一開始做小米統計平臺時,數據其實也沒有做到實時的,都是走上面的一條路,第二個階段通過MapReduce處理以后,把數據放到關系型數據里面,比如像MySQL這樣的數據庫。再后來,業務慢慢擴展,RDBMS的容量有限,出現很多問題,所以到第三個階段我們把RDBMS變成HBase,這個階段也持續了很久,再后來我們想得到實時的數據,來到第四步,通過Kafka、Storm再到RDBMS或者NoSQL,最后一步我們直接是把數據從Kafka轉到Druid。
圖14 幾種開源MOLAP分析工具的比較
Druid由一家叫MetaMarkets的公司開發,目前像Yahoo、小米、阿里、百度等公司都在用它大量地做一些數據的實時分析,包括一些廣告、搜索、用戶的行為統計。它的特點包括:
為分析而設計
為OLAP而生,它支持各種filter、aggregator和查詢類型。
交互式查詢
低延遲數據,內部查詢為毫秒級。
高可用性
集群設計,去中性化規模的擴大和縮小不會造成數據丟失。
可伸縮
現有的Druid部署每天處理數十億事件和TB級數據。Druid被設計成PB級別。
與Druid相類似的實時數據分析工具,還有Linkedln的Pinot和eBay的Kylin,它們都是基于Java開發的。Druid相對比較輕量級,用的人也多,畢竟開發時間久一些,問題也少一些。
圖15 DRUID使用場景:廣告實時統計分析架構圖(非計費部分)
Druid在小米內部除了應用于小米統計之外,還應用于廣告系統。小米的廣告系統主要是對每個廣告的請求、點擊、展現做一些分析,一條線是通過Kafka→Druid→數據可視化顯示,另外一條路就是完整數據落盤到HDFS,每天晚上通過數據重放去糾正Druid里的一些數據,覆蓋Druid的準確數據,最后做可視化。
五、其它工具的探索
圖16 什么是Pinot
Pinot,Linkedln開發的類似于Druid的多維數據分析平臺,它的功能實際上要比Druid強大一些,但因為去年才剛剛開始開源,用的人比較少。大家有興趣的可以去試試。它的整個代碼量也比較大,架構與Druid也非常相似,但它引入了更好的一種協調管理器,更多的是一種企業級別的設計,更加完整、規范。
圖17 Apache KYLIN
Kylin是eBay的開源分析工具,它的優點就是很快,特別適合每天定時報表,缺點也很明顯,就是隨機查詢很慢。它還有一個好處就是支持標準的SQL,與Tableau等BI工具集成,可以直接連到eBay的這個Kylin工具。而且,Kylin在Fast Cubing上做了一些預處理,反應較快。
圖18 Apache KUDU
KUDU是去年十月份Apache開源的一個工具,與小米聯合發布。它的定位是什么呢?大家都知道Druid是一個批處理、高容量的查詢系統,響應時間很慢,而HBase可以支持快速的響應時間,但它主要是一個寫少讀多的情況。
圖19 小米KUDU的實踐
KUDU,走在這兩個極端的中間,它既能夠保證大吞吐,又可以保證低延時。小米從去年十月份開始使用KUDU,主要用于一些服務質量監控、問題排查,總體感覺還不錯。小米也是KUDU現在最大的一個用戶,因為我們很多時候需要考慮HBase和Druid綜合的一些優點,所以KUDU也是小米目前實驗的一個工具。
圖20 ElasticSearch
ElasticSearch可能很多公司都有實踐,同樣可以對LOG和信息做一些倒排表,核心是用Lucene去做索引。
最后,小米雖然每天都在處理大數據、各種用戶的數據,但我自己的信念就是“我們需要像保護自己的眼睛一樣保護用戶的隱私”,小米在用戶隱私這方面投資了很多,并做出了明確的規定。
圖21 用戶隱私保護
在歐洲,很多公司內部會把數據分成很嚴格的等級,像個人信息,所有可以關聯到個人的信息都是存在一個獨立的庫,任何人都沒有權限去訪問。還有一些普通信息,大家是可以用的,還有比如說超過一萬人的一些聚合信息,可以拿去做一些算法。但個人信息是堅決不可以訪問的。而在2006年4月14日,歐洲當時還推出了一個非常酷的隱私權保護條例,它定義了每個公司要設立首席數據官,來保護數據隱私,并且要求每個公司數據都是可遷移的,也就是說,你的公司雖然擁有數據,但數據有權利把屬于他的個人信息從一個服務商轉移到另外一個服務商。
分享的最后,總結一下我做數據分析多年來的心得:
1、沒有業務應用的大數據都是耍流氓,不要純粹去找工具,一定要結合業務去選擇。
2、技術選型沒有想象中那么重要,實用和精通為妙。
3、維度不夠是一個永遠的痛,無盡的傷。在數據分析的過程中,維度是不斷增加的。所以在未來選擇工具的同時,一定要考慮維度的增加。
4、像保護你的眼睛一樣去保護用戶的權利和隱私。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://m.guhuozai8.cn/
本文標題:你所不知的小米大數據技術
本文網址:http://m.guhuozai8.cn/html/consultation/10839719834.html