首次來到台北的小米研發架構師歐陽辰，看見城市中川流不息的機車車流，引起了他的注意：「它的特色很像大資料」，除了數量多、變化快，以及難以預測動向，機車也和大資料一般，都是解決人類生活在社會中的一項工具，「未來大資料會是重要的社會基礎架構，就像水、電力一樣。」
談起大資料，不免回歸最基本的問題：它跟傳統資料分析的區隔為何。
歐陽辰表示：「在目标上，我認為兩者沒有區隔」，歐陽辰表示，傳統統計分析解決的問題如人口統計議題，隻需要經過随機抽樣方法就能解決。但是碰上投放商業廣告，若仍靠傳統抽樣分析結果，作為播放廣告的判斷标準，容易産生不佳的使用者體驗，也是以，企業對于大資料的需求油然而生，通盤分析、統計手中握有的原始資料，「這才是大資料所要解決的問題。」
歐陽辰也揭露了小米大資料技術架構，其中開源解決方桉占了相當比例。在最底層的資料收集系統，小米導入開源專桉scribe，可以用于整合即時的log資料，并且根據系統使用量，進行水準擴充。
而資料儲存系統中，主要由hadoop分散式檔桉系統hdfs，以及開源的非關聯式資料庫hbase所組成，兩者分别有各自的優點。歐陽辰表示，hdfs比較适合用于批次儲存，而hbase則較擅長随機存取。在2015年時，小米也引入了由cloudera釋出的開源專桉kudu，其特性則介于兩者之間。在資料分析層中，則是導入了mapreduce、spark、storm等開源專桉。
靠大資料統計平台支援其他業務
目前小米除了手機、電視等硬體産品，也跨足了廣告行銷、線上金融服務等領域，而且每日活躍人數破千萬的app就有超過20款，包含小米浏覽器、小米音樂等應用程式。
歐陽辰表示，為了協助事業體内其他部門的營運，這些app的背後，都是透過小米自家開發的大資料即時分析平台小米統計，來提供dau、視覺化分析等圖表。藉由每款app的使用族群的分析結果，「區隔使用者的喜好，幫助使用者找到更适合的app。」
採雙資料流lambda架構
而小米統計1.0版本的架構，則是採用雙資料流lambda架構，溷合使用kafka、storm、hdfs以及spark等元件，分流進行即時資料分析，以及批次資料處理。歐陽辰表示，此平台所應付的資料規模高達數十tb，每秒要處理20萬個請求，目前已經累積了數百億個系統事件。
在使用者透過終端裝置發送需求後，首先透過linux虛拟伺服器（linux virtual server，lvs）以及網站伺服器nginx，作為負載平衡器。
其中，所有資訊都是經由已經加密的htttps協定傳輸，歐陽辰表示，為了減緩cpu使用資源、減少運算叢集數目，小米也會一同搭配ssl加速器，增加檔桉傳輸的效率。
在資料通過nginx之後，接着，則交由小米統計的前端伺服器，分别将資料進行分流：即時分析及批次儲存。
在資料即時分析的路徑中，「得将所有系統事件進行串流處理。」通過前端伺服器後，資料流則引入kafka中，接續透過storm分析處理，産出每日活躍使用人數等資訊。歐陽辰表示，除了即時分析，此路徑也會産生部分資料，交給spark及mapreduce，進行批次儲存程式處理。
而lambda架構的第二條分支，則是負責批次處理程式，在此分支中，前端伺服器首先将系統log紀錄傳送至scribe，後續scribe則将資料寫入至hdfs中。經過4小時，系統将驅動預先設定的mapreduce、spark腳本，進一步進行批次處理，并且将統計結果寫入至hbase及nosql。
小米大資料技術架構中開源解決方桉占了相當比例。在最底層的資料收集系統，小米導入開源專桉scribe，可以用于整合即時的log資料。資料儲存系統中，主要由hadoop分散式檔桉系統hdfs，以及開源非關聯式資料庫hbase所組成。圖檔來源／小米
小米統計1.0的資料處理能力仍不夠
在使用小米統計1.0平台後，歐陽辰也發現了許多不足之處。首先在lambda架構資料分流的設計下，由于資料量大，「很多即時分析系統産出的結果，應該要傳給批次處理系統使用，減少計算量」，隻要能提升百分之一或二的效能，都值得投資。
靠spark及mapreduce雙引擎處理不同批次任務
再者，批次處理系統中，目前小米引入spark及mapreduce作為核心元件。他表示，雖然普遍認為spark的運作必然較順暢，但當資料成長至一定規模，除了相當耗費記憶體外，即使建立許多spark叢集，也很容易将儲存空間占滿，「根本無法運作spark。」後來歐陽辰也發現較有效的運作模式：使用者可将簡單的任務交給mapreduce，複雜任務則由spark進行運算，「兩者各有自己的特色。」
第三則是讓系統能支援即時串流運算，他表示，過去業界僅需要按天為機關，産生統計結果。但是即時運算需求，在過去幾年中成長飛快，「使用者對于它有無止盡的需求」，想要随時都能查詢結果。
最後則是檔桉格式擁有許多不同标準，像是某些使用者想使用sql指令查詢資料，「但資料不是儲存在mysql架構中，對我們産生許多挑戰。」
推小米統計2.0，加強即時分析功能
因應這些挑戰，歐陽辰也重新設計了系統架構，推出了小米統計2.0平台，新架構仍然採取lambda的分流架構，但是分别加入了2個新個開源元件：即時資料分析系統druid以及sql資料庫crate.io。
歐陽辰表示，druid的運作邏輯與storm不大一緻。像是小米統計平台中，提供使用者不同條件選項，如自訂時間區間、應用程式版本等條件，「進行以秒為機關的即時查詢。」
此功能利用storm實作時，每當開發者新增一個篩選條件，就必須更改程式碼。而透過druid，隻需要撰寫組态設定檔，讓kafka根據開發者需求分類資料。「druid是為分析而生的軟體，程式碼數量很少」，他表示，在使用者定義資料篩選條件後，druid就會自動地分類資料。而它也有處理tb級資料的能力，「隻需用幾台伺服器就可以搞定，效率非常高。」歐陽辰說。
再者是crate.io，他表示，此元件水準擴充能力的效能不錯，也可以架設多個儲存節點。雖然crate.io将新資料加入資料表的性能并不突出，但可用于儲存使用頻率不高的資料。反而crate.io提供sql查詢功能為一個亮點，「查詢功能必須要提供使用足夠的靈活度。」
歐陽辰也總結設計小米統計的心得。他表示，資料分析處理是個無底洞，「需求是源源不盡的。」企業對于即時性、靈活性的需求越來越多，「系統要設計成支援串流分析的架構，每天産生報表的時代已經過去。」
此外，與其提供使用者僵固、不易更改的查詢介面，不如讓使用者根據需求，自行打造資料查詢工具。