小米數(shù)據(jù)工場的技術(shù)架構(gòu)
小米數(shù)據(jù)工場主要承擔著為全公司各團隊及小米的生態(tài)鏈企業(yè)，提供數(shù)據(jù)采集、計算、存儲等基礎能力，以及機器學習、挖掘的工具和方法的任務。
整個底層基礎平臺建立在 Hadoop 體系之上?？紤]到擴展性，數(shù)據(jù)工場天生基于 Scala 設計成分布式架構(gòu)。由于小米及其生態(tài)鏈企業(yè)業(yè)務場景豐富 ，因此在技術(shù)選型方面全生態(tài)都會涉及，如消息流、批處理、實時計算等技術(shù)都需要用到，HBase、Hive、Spark、Storm 、Impala 都在不同的場景下使用。
最底層使用 HDFS，上面使用 Hive、Spark 和 Mapreduce 這些混合到一個亞運集群上。而且 Impala 小米很早就在用，是一個很重的計算角色。
小米數(shù)據(jù)工場總體結(jié)構(gòu)
如上圖，上半部分是小米自研的數(shù)據(jù)工廠，是為最頂部業(yè)務層提供服務的。數(shù)據(jù)工廠主要是提供數(shù)據(jù)可視化、計算任務管理、數(shù)據(jù)管理、權(quán)限管理、任務調(diào)度、數(shù)據(jù)共享等服務。
公司越大就更希望數(shù)據(jù)能夠開放給公司的各個部門，數(shù)據(jù)可相互利用。但不能沒有任何限制的去使用，所以需要對數(shù)據(jù)權(quán)限做管理。
任務調(diào)度是整個工廠里面最重的部分。數(shù)據(jù)共享就是類似非?；鸬挠脩舢嬒耦悢?shù)據(jù)，還有其他公共數(shù)據(jù)如 IP 庫，這些數(shù)據(jù)具有公共特點，不用重復計算，就可以通過數(shù)據(jù)共享的方式在各個團隊之間使用。
數(shù)據(jù)管理
分為數(shù)據(jù)預覽、元數(shù)據(jù)、數(shù)據(jù)源三部分。
數(shù)據(jù)預覽，是每個團隊用來互相了解數(shù)據(jù)。
元數(shù)據(jù)，就是數(shù)據(jù)使用過程中要把非結(jié)構(gòu)化的數(shù)據(jù)轉(zhuǎn)換成結(jié)構(gòu)化的數(shù)據(jù)。元數(shù)據(jù)管理就是去了解每個字段的含義和機器解析。機器解析包括 Mapreduce 程序可直接讀文件可解析，如用 Impala、Spark 和 Hive 同樣也能解析，而不需要每個使用者再去格式化，再去解析這個數(shù)據(jù)。但面臨的問題是數(shù)據(jù)一旦出現(xiàn)格式的轉(zhuǎn)變或者某些字段的調(diào)整，以前任務可能都會出現(xiàn)問題，所以一定要統(tǒng)一管理的地方。
數(shù)據(jù)源，數(shù)據(jù)管理非常核心的是數(shù)據(jù)集成，能夠把各個地方的數(shù)據(jù)集成到平臺上來。
HDFS 目錄管理
有公共數(shù)據(jù)空間、業(yè)務數(shù)據(jù)空間、團隊數(shù)據(jù)空間、個人數(shù)據(jù)空間、Yarn計算空間五部分。
公共數(shù)據(jù)空間，是用來把公共數(shù)據(jù)放到上面，把維護權(quán)限和讀的權(quán)限分開。這樣大部分都是讀這個空間，空間數(shù)據(jù)安全性等級相對來講比較低，可以付給更多人。
業(yè)務數(shù)據(jù)空間，因為每個業(yè)務數(shù)據(jù)的增長量是不一樣的，甚至有些業(yè)務會出現(xiàn)如剛上來一個新功能，數(shù)據(jù)量迅速的增大，有的甚至會出現(xiàn)某個團隊的數(shù)據(jù)增加，導致把整個集群空間全吃掉，又沒有事先打招呼。這種情況下做好業(yè)務間的限額配額非常重要，防止某一個團隊的增長導致整個集群出現(xiàn)一些問題。
團隊數(shù)據(jù)空間，就是把權(quán)限控制到個人，用來幫助做團隊之間的數(shù)據(jù)協(xié)作。如把線上任務放到團隊賬號中去，團隊賬號的權(quán)限要做好控制，權(quán)限不隨便開放。當團隊人員發(fā)生變動后，整個團隊任務不用再去切換賬戶而導致交接的復雜性。
個人數(shù)據(jù)空間，數(shù)據(jù)工程師、開發(fā)工程師等是需要做一些調(diào)試或做自己的計算，這就要給這些人一定空間的同時對其數(shù)據(jù)做配額。這是為了防止這些人過多的使用資源和為了空間不夠需要清理數(shù)據(jù)時，哪些數(shù)據(jù)要清理，哪些數(shù)據(jù)不能清理一目了然。這樣限制空間的情況下，廢棄文件或者垃圾文件的積累會相對較少。
Yarn計算空間，做配額限制是為了杜絕空間濫用的問題。比如：之前發(fā)生過一件事，某人在 Reduce 里面寫了一個死循環(huán)，不停的輸出數(shù)據(jù)，導致整個集群很快出現(xiàn)報警。后來才發(fā)現(xiàn)是這個計算造成的一些問題，最后差點導致那些日志上傳、數(shù)據(jù)的寫入都出問題，幸虧處理的比較及時。
所以，Yarn 計算空間是需要做一個配額限制，防止對整個集群造成過大的影響。
小米數(shù)據(jù)處理方式
除了底層的能力，小米數(shù)據(jù)工場也為公司及生態(tài)鏈企業(yè)提供一些具體的基礎數(shù)據(jù)服務，用于小米信用卡的風控和額度評估、廣告精準投放、限時搶購時用數(shù)據(jù)打擊黃牛等等。通過數(shù)據(jù)工場提供的數(shù)據(jù)能力，企業(yè)不僅能夠?qū)I(yè)務進行數(shù)據(jù)分析，也實實在在將數(shù)據(jù)應用到核心業(yè)務場景中。
小米數(shù)據(jù)存儲格式
統(tǒng)一采用的 Parquet，優(yōu)點在于其使用的是列式存儲，支持Mapreduce、Hive、Impala、Spark 和讀取快、占用空間少。
客戶端數(shù)據(jù)接入
客戶端指的是 Wap、App 等數(shù)據(jù)，存在方式有 SDK 和服務端 Log 兩種模式。下圖為兩種模式的優(yōu)劣勢。
客戶端數(shù)據(jù)接入兩種模式優(yōu)劣勢
服務器端數(shù)據(jù)源
除前端數(shù)據(jù)源外，整個處理數(shù)據(jù)時還會有大量服務器端數(shù)據(jù)源需要處理。業(yè)務數(shù)據(jù)庫類，用 ETL 工具做導入。服務器端日志，用 Scribe 將數(shù)據(jù)寫入 HDFS.
元數(shù)據(jù)管理
當公司業(yè)務變多后，每一個數(shù)據(jù)的處理方式都有可能不一樣，這時候就凸顯出元數(shù)據(jù)管理的重要性。如視頻播放日志，分析師希望用 Hive，用 Impala 直接寫 SQL 去計算，但數(shù)據(jù)挖掘工程師就要去寫 Mapreduce，寫 Spark 的方式去讀，去解析。
元數(shù)據(jù)管理就是要做數(shù)據(jù)統(tǒng)一，既能夠滿足 Hive、Spark、Impala，還能滿足 Mapreduce.這樣一來節(jié)省大家對數(shù)據(jù)理解、執(zhí)行的時間。
元數(shù)據(jù)管理
如上圖，小米數(shù)據(jù)工廠是每一份數(shù)據(jù)的描述都需要在數(shù)據(jù)工廠上提交，之后數(shù)據(jù)工廠會在 MetaStore 中做建表的同時帶上元數(shù)據(jù)的行為，供 Hive、Spark、Impala 使用。數(shù)據(jù)管理還會生成 Jave Class，給 Mapreduce 使用。當去解析用某個數(shù)據(jù)的時候，可以直接用這樣的方式把它解析成 Jave 類。
計算管理
數(shù)據(jù)管理相對來講是一次性的活，計算就是很復雜的事情。計算任務數(shù)一天達到幾千或過萬時，就會變得非常復雜。對于計算管理這塊的優(yōu)化，小米做了如下一些工作：
Docker
為了管理好這些紛繁的計算框架和模型，在計算的執(zhí)行方面，小米使用 Docker 來解決對環(huán)境的不同需求和異構(gòu)問題，并且與 Hive、Impala、Spark 這些不同的計算模型都進行了對接，去適配不同應用場景計算不同數(shù)據(jù)的模型。
另外，在不同業(yè)務場景下，同一個計算邏輯也可以選用不同的計算模型，Docker 的使用也避免了資源的浪費。比如：一個計算任務每天凌晨運行，為了追求吞吐量，可以放到 Hive 里跑；還是同樣一個計算模型，現(xiàn)在就要跑，可以不用更改，就放到 Impala 里運行。
Docker 不僅解決了環(huán)境的異構(gòu)，也解決了資源問題。
另外，Docker 的環(huán)境適應性很強，做橫向擴展會比較容易。對于數(shù)據(jù)隱私方面，小米考慮得非常重。采用 Docker 與自身安全策略的綜合，小米用戶數(shù)據(jù)的隱私和安全性也得到了極其嚴格的控制。
總結(jié)
無論你用什么樣的技術(shù)，一定要做好數(shù)據(jù)的積累，這是一家數(shù)據(jù)公司非常重要的部分。不僅要提前規(guī)劃好數(shù)據(jù)，還要避免邏輯孤島，還需要注意 ID 問題，也就是關聯(lián)的問題。不要當采集了數(shù)據(jù)，卻發(fā)現(xiàn)沒有采用戶 ID，當算到用戶級別的時候，那就尷尬了。
以前講的是流量時代，講的是 PV 如何，而現(xiàn)在越來越多的業(yè)務都回到了用戶時代。核心問題就是我們要做好用戶的數(shù)據(jù)積累，尤其是用戶模型建立。模型包括畫像、用戶點點滴滴行為等。這些行為在業(yè)務發(fā)展之后，尤其是要做數(shù)據(jù)挖掘，做推薦系統(tǒng)時，會非常有幫助。
閱讀排行榜
