本文根據【2016 第七屆中國數據庫技術大會】現場演講嘉賓歐陽辰老師分享內容整理而成。錄音整理及文字編輯。
嘉賓介紹：
▲歐陽辰
歐陽辰，畢業于北京大學計算機系，獲得碩士學位，喜歡互聯網技術，架構設計，數據挖掘，質量改進，旅游閱讀，是一個簡單樂觀，熱愛生活的人。
正文：
大家好，很高興參加這次大會。先簡單介紹一下我自己。我在北大計算機系念完書以后不久加入到了Oracle公司，是中國Oracle研發的第一批員工，做了三年數據庫企業軟件。之后，2005年，我加入微軟從事互聯網方面的研發工作，主要做了兩個項目:一個是搜索，一個是廣告平臺。去年一月份加入小米公司，從事大數據平臺和廣告平臺的研發工作。
首先和大家分享一下我對大數據的感悟吧。提到大數據，大家可能馬上就會想到4個v，快速、大量、變化、多樣，那么我自己理解的大數據是什么呢?
因為現在各種數據的應用場景很多，但是在有些場景下，采樣的數據不能夠滿足業務需求，我們需要一個完整的數據集來做處理業務。舉個例子，在廣告里面有一個精準投放的概念，就是了解用戶興趣愛好以后，然后精準的投放廣告，這種投放的廣告效果和用戶體驗都會比較好，那么這是怎么做到的?必須采用全量數據，假設我們只采樣10%的用戶去做這個數據處理，肯定是不科學的。
我自己覺得大數據需要全量數據，才能把業務做好。如果只用采樣數據，做到的效果，我認為不叫大數據業務。實時數據的價值最大。大家很多時候都覺得大數據光鮮亮麗，其實在做大數據的過程很苦逼，需要經過數據清洗、數據挖掘等等過程。大數據很像紅樓夢，金玉其外，其實內在有很多很多無奈。
大家都知道小米是一個手機公司，雷總經常說小米是一個互聯網和軟件公司，其實我個人理解除了這些，小米還是一個很好的大數據公司。我們有超過兩億的用戶在使用小米的手機、電視和路由器等等。小米的數據量非常大，除了我們自己的數據，還有合作伙伴的數據，生態鏈的數據，那么怎么處理這些數據?
我們的數據基礎架構還是很豐富和強大，采用的基本上都是開源技術。我們用Scribe收集一些Log，然后用ETL去處理數據。存儲層我們針對不同場景采用了很多方案，包括HDFS、HBase和KUDU等等。HBase是小米投入比較大的技術。數據管理層，我們用Hue來做業務管理配置，Kerberos是傳統的認證體系。數據分析層，我們也嘗試了很多工具，例如傳統的MapReduce，Spark, Strom，Hive，Impala以及新工具Druid和Elastic search。算法層，主要包括研究機器學習、自然語言、數據挖掘和統計分析的方向。
大數據的應用場景是困擾很多大數據人員的一個問題。大家都知道數據很有用，數據可以指導我們精細化運營，那么數據怎么變現呢?其實是一個非常難的問題，我自己總結了一下，大數據的直接變現場景有兩個比較明確，一個是廣告營銷方面，包括精準投放，廣告效果的跟蹤。第二個就是互聯網金融，互聯網金融有很多泛征信的問題，所以很多金融服務愿意掏錢去買有價值的數據。其他方面只要是扶持業務精細化運營和正常發展，比如說防黃牛和圖片分析處理的算法。
小米的技術應用場景有很多，我們有一個開放平臺，提供類似友盟的統計服務。另外我們內部有一個實時分析系統，幫助我們查看手機銷量、日活以及哪個地方的手機bug比較多。
實時數據分析包括數據收集、數據處理、數據建模、數據分析、數據可視化多個部分。其中數據分析也分好幾個層次，最底下的一層叫做響應型分析，主要是收集數據，安排一定規格做報表，是比較基礎的處理方法。第二個層次叫診斷型分析，主要是做競品分析和趨勢分析。第三個層次是數據分析很重要的一點，戰略分析，包括制作戰略方向、預測模型。有很多公司在做戰略分析方面的工作，著名的有麥肯錫7S模型、波士頓矩陣分析圖。最后一個層次叫做預測型分析，預測型分析可能是下一代數據分析的頂尖層次，很多時候是需要人工智能給我們一些真正的建議。我認為數據分析下一個比較熱門的地方，就是預測型數據分析，現在的數據分析基本都是反映現狀，很難給企業一些建設性意見，幫助企業繼續發展。
我把大數據分析工具分為開源方案和商業方案兩類。大規模實時數據分析的商業項目有HP vertica，Oracle Exadata、Teradata。Vertica是一個挺不錯的工具，Facebook也在使用 Vertica解決方案來做商業分析，大家都知道Facebook本身就是一個很強的互聯網公司，他也在釆用 vertica解決方案，就說明Vertica的數據處理量非常大，部署相對也比較簡單，關鍵是速度快，兼容各種SQL查詢工具。Exadata是Oralce和SUN合并以后，推出了軟硬件一體機的服務器，效果非常好，它的響應速度非常快、可用性非常高，Oracle Exadata可以應用自如的在線處理TB級別的數據。
開源方案其實有2類工具，一類是MOLAP多維數據分析工具，包括Pinot、DRUID、ES、Kylin。另外一類是基于關系型數據庫的ROLAP，這類工具大多是基于傳統型數據庫的解決方案，支持的數據規模比較小，數據處理的靈活性較低。
數據分析工具很多也很雜亂，我們應該怎么挑選這些工具呢?其實這些工具在CAP理論里都有自己的定位，這里有幾個指標可供大家在挑選數據分析工具的時候參考一下。第一個是數據量處理分析的能力，第二是能夠提供多少并發度，第三是實時性的能力以及總體的成本和分析系統的效率。
小米統計的數據平臺包括了很多技術，我們有個入口層可以從終端直接把數據打到服務器。接入層使用LVS/NGIX，對于HTTPS，我們采用專用的硬件加大服務器吞吐量，Analytics Server上的Scribe Log把數據傳到HDFS上，同時把同樣的數據打印一份到Kafka里，kafka做分布式處理，然后MapReduce和Spark做一些批處理和實時處理。最后落盤的時候，我們會選擇不同的落盤方式，落到ES上的直接接Kafka，數據比較穩定的，量小一些的，有結構的，(例如一些元數據和系統統計數據，會落到MySQL，在線的大量應用數據落地HBase里，數據量比較大且經常需要實時查詢的會落到DRUID里。前端的服務大概分為兩類，一類是運營，對每個產品進行精細化運營，另一類是洞察，老板或者管理者通過這個系統去查看一些核心指標。
我們在內部使用比較多的NoSQL是HBase，它是比較好數據庫，比MySQL的存儲容量大很多，基本上可以到P量級，且訪問速度非常快。
我們在HBase的使用過程中也不斷做了很多改進，比如我們提供名字服務，很多HBase可以通過名字去訪問Cluster;HBase天生是不支持索引的，它只用key去找value，知道key才可能知道value，我們在內部實現了一個二級索引;salted table，在插入數據的時候，如果key比較接近，可能會落在一起，導致整個系統不平衡。Salted Table就是給它們加個隨機數，讓它們在落盤的時候更加平均;HBase以前不是強類型的，我們會在API加強類型的檢查，讓操作更規范一些。
除此之外，我們還對HBase在小米上的使用做了一些改進：單機多實例，減少Heap大小;BucketCache(Heap+Offheap);Compaction限速;Read/Write Quota限制;table/CF粒度的Replication限速;在線更新集群配置;新的HLog寫模型;根據業務類型選擇存儲介質。
我們以前有很多數據是在MySQL中，那么如何實現從MySQL平滑遷移到HBase?
第一步是雙寫MySQL和HBase ，把所有最新的數據都放在兩個數據庫里，第二步就是把MySQL數據全部嵌入到HBase里面，這樣理論上它們是有一樣的數據。第三步就是雙讀，驗證數據是否一致，如果不一致則需繼續讀取，直到數據完全一致，最后灰度返回HBase結果，完成整個遷移。
下面我們對比一下幾種MOLAP的分析工具。
DRUID是采用JAVA開發語言的實時數據分析工具，是在2011年發布的，當時創始這個工具的公司叫MetaMarkets。MetaMarkets是一個互聯網廣告的分析公司，因為互聯網廣告里有大量的數據，所以它就開發了這樣一個工具來做實時分析，它的特點是實時聚合，目前很多互聯網公司都在使用，包括雅虎、小米、阿里，網易，新浪等等。
Pinot是去年11月份LinkedIn開源的實時分析軟件，它跟DRUID都是JAVA語言開發的，輸入輸出都是json。LinkedIn在開源軟件領域非常有名氣，因為當時它把Kafka開源出來了。
Kylin以前是eBay的一個項目，去年eBay將它開源出來，它支持標準的OLAP/JDBC協議，并且和一些標準數據庫連接。它的處理跟實時聚合可能有點不一樣，Pinot的進程是把進來的數據變成列存儲，簡化存儲，所以聚合會比較快。而Kylin更多的是做一些預處理、cache。
DRUID 支持很多功能，查詢性能也比較好。DRUID是為OLAP工作流的探索性分析而構建。它支持各種filter、aggregator和查詢類型，并為添加新功能提供了一個框架。現有的DRUID部署每天處理數十億事件和TB級數據。
DRUID的架構比較經典，當查詢語句來了之后，它會把請求發給兩個節點，其中一個節點是Real-time，該節點主要存儲最新的數據，另外一個是Historical節點，主要存儲歷史數據。
我們的廣告系統里是這樣應用DRUID的：在廣告的前端有展現和點擊過來時，我們有兩條線可以走。一條線是通過Kafka直接到DRUID做聚合，然后再做展現。這是一條實時線，延時大概是1分鐘左右。還有一條是可追溯的線，把log放到HDFS里，我們每天會有腳本去HDFS中拷貝存儲，然后到DRUID里面去做矯正，最后會把這里面的結果和DRUID里面的數據重新掛一下。我們認為這些持久化數據是可以重跑的，所以我們是十分信任這條線上的數據。
Pinot是LinkedIn的工具，是分布式的實時OLAP數據分析平臺，現在主要應用于LinkedIn內部，大概有50多個場景，比如“誰看了我的Profile”、“廣告創建，跟蹤”、“內部數據分析BI等”。據最新數據表明，Pinot的規模不到一千個節點，數據量不算太大，但是場景很多。它的SQL-Like查詢不是標準的SQL而是提供一個類似SQL的工具，支持多種數據源，目前也在開發UDF。
Pinot的架構也是比較經典Lambda架構，查詢來了以后，它主要查看兩個節點,一個是歷史節點，還有一個是realtime節點，中間協調采用的是Apache Helix，Apache Helix在調度能力和cluster管理能力方面要比DRUID好一些。Pinot在對SQL查詢的支持方面花了很多力氣，它的輸入對象是類SQL，容易和傳統的數據工具集成。
Kylin大家都知道是eBay開源的一個分析引擎，它提供了標準的SQL查詢、提供了BI工具的集成，提供了完美的管理界面、任務監控、增量更新。
Kylin除了支持標準SQL查詢，還支持Restful API查詢，它會把查詢Query記錄下來，來自Hadoop的元數據會調度以前任務，把數據發到Query里。這樣架構在一些預定義好的場景和數據下的執行速度是非常快的，比較適合每天的報表。如果業務有了很好的格式化工具或者報表以后，你只需要把數據源替換一下。以前，這部分查詢功能可能需要從MySQL、SQL Server遷移到HBase接口。
我們也利用Kylin嘗試過以下場景，例如API請求分析、廣告返回類型的分析。我們發現它在響應時間和誤差率方面的表現也不錯。
KUDO是去年十月份開源的項目，小米也參與其中。KUDO最早是Cloudera做的項目，大家都知道Cloudera是一家非常棒的分布式Hadoop存儲的技術公司。我們知道存儲在開源方面有兩個方案，一個是Hadoop HDFS，另一個是HBase。Hadoop HDFS的特點是批處理能力特別強，但是響應時間慢。HBase特點是小吞吐，低延時，簡單的查詢是可以，大批量的數據可能會有些挑戰。KUDO其實是介于兩者之間，無論響應時間方面還是數據處理量方面都是介乎兩者之間。目前小米主要應用在服務質量監控和問題排查。
我們以前的數據處理方法是這樣的：從數據源獲取到數據以后，我們通過Hive和MapReduce Spark寫到HDFS里面，將它變成列存儲，用Impala工具查詢。
但是現在我們應用了一個全新的模式，數據傳到Kafka里去查，然后Storm傳到KUDO里，最后采用兩條路徑陸續查，一條路徑是Impala查詢，另一條是直接查詢。我們發現大部分的分析查詢場景，都能滿足我們的預期。
Elasic Search的核心引擎是Lucene，是一款實時分布式搜索引擎和分析引擎，支持全文檢索，結構化搜索和分析。小米部分應用也是將log進行索引來做分析，主要應用在廣告分析和查詢方面。
數據可視化方面我們主要用一些的標準的開源工具，包括 Meteorite Saiku、Microsoft Power BI、Excel、Baidu eChart。
數據分析和數據處理中有一個概念叫數據隱私，它最早是1890年提出來的，2012年，歐盟頒布了一項的法律叫做《用戶保護條約》，這個條約里規定了很多名詞條例，2016年4月份，歐盟頒布了一個效力更強的條約，《歐盟通用數據保護條約》。該條約規定每個公司必須有一個CDO，禁止搜集個人特別信息，包括政治觀點、性取向，保護兒童數據等等。在數據隱私方面，歐盟走的比較靠前。而在國內的話，我們還是在參考民法通則等一些老舊的方法。
在互聯網里最重要的隱私數據叫PII，PII代表個人標識數據，這些信息能夠關聯到個體本身，比如說你的手機號、你的身份證號都能關聯到你。
我認為大數據分析一定要以業務為基礎，沒有業務支持的大數據分析都是耍流氓，一定很難有好的收獲，大數據分析一定要找到業務做落地點。
技術選型的指標不如想象中的重要，只要選用的技術用的精妙即可。舉個例子，小米要在服務器中存儲一些用戶之間的消息信息，有些用戶可能會查詢消息，但查詢的概率非常非常小，我們當時有兩個選項，一個選項是使用Elasic Search，第二個就直接用HBase，如果用ElasicSearch會引入新的很多麻煩，包括基礎的部署、安全等方面，所以我們就跟其他內容一樣都放到HBase里面去做一些簡單的查詢，這樣可以更好地保護安全。
在實時分析的時候，維度是一個永遠的痛。
我們希望大家在做數據分析處理的時候，要像保護你的眼睛一樣保護用戶的隱私。
數據分析是挺難的一件事情，大家既然走上這個道路，我希望大家不忘初心，方得始終!特別是你想從業務中洞察出一些信息，它不僅需要你的技術牛逼，而且還需要數據的敏感性，能夠發現自己的數據問題。數據分析的未來看似光明，實則道阻且長。
