Yonghong Z-Suite
除了提供優秀的前端BI工具之外，Yonghong Z-Suite讓用戶可以選購分布式數據集市來支持實時大數據分析。
對於這種百億級的大數據案例，Yonghong Z-Suite有哪些技術可以保證大數據的實時響應呢？下面大致從技術上介紹下：
庫內計算(In-Database Computing)
Z-Suite支持各種常見的匯總，還支持幾乎全部的專業統計函數。得益於庫內計算技術，Z-Suite數據分析引擎將找尋出最優化的計算方案，繼而把所有開銷較大的、昂貴的計算都移動到數據存儲的地方直接計算，稱之為庫內計算(In-Database)。這一技術大大減少了數據移動，降低了通訊負擔，保證了高性能數據分析。
2. 並行計算(MPP Computing)
Z-Suite是基於MPP架構的商業智能平台，她能夠把計算分布到多個計算節點，再在指定節點將計算結果匯總輸出。Z-Suite能夠充分利用各種計算和存儲資源，不管是服務器還是普通的PC，她對網絡條件也沒有嚴苛的要求。作為橫向擴展的大數據平台，Z-Suite能夠充分發揮各個節點的計算能力，輕松實現針對TB/PB級數據分析的秒級響應。
3. 列存儲 (Column-Based)
Z-Suite是列存儲的。基於列存儲的數據集市，不讀取無關數據，能降低讀寫開銷，同時提高I/O 的效率，從而大大提高查詢性能。另外，列存儲能夠更好地壓縮數據，一般壓縮比在5 -10倍之間，這樣一來，數據占有空間降低到傳統存儲的1/5到1/10 。良好的數據壓縮技術，節省了存儲設備和內存的開銷，卻大大了提升計算性能。
4. 內存計算
得益於列存儲技術和並行計算技術，Z-Suite能夠大大壓縮數據，並同時利用多個節點的計算能力和內存容量。一般地，內存訪問速度比磁盤訪問速度要快幾百倍甚至上千倍。通過內存計算，CPU直接從內存而非磁盤上讀取數據並對數據進行計算。內存計算是對傳統數據處理方式的一種加速，是實現大數據分析的關鍵應用技術。
通過結合多種Yonghong自有的專利技術，在幾個節點下，Yonghong Z-Suite就能擔負起幾十億，乃至上百億數據量的實時分析和展現。
Yonghong Z-Suite相對Hadoop有哪些不足呢？Hadoop能支撐PB級大數據，數千節點的大規模集群。對於Yonghong Z-Suite這種實時大數據分析系統，一般支撐TB~PB級的大數據，節點數一般不超過100。
以下分享一個Yonghong Z-Suite的真實案例：中國移動省分公司數據流量與監控系統
2013年5月，Yonghong收到一個電話線索，客戶需要支持幾十億數據量的實時查詢與分析，包括數據抓取和存儲，讓我們先出報價。在實時大數據分析領域，Yonghong的產品和服務是很有競爭力的。不過，當客戶拿到我們的報價后，還是覺得比他們的預算貴一些，決定自己招聘Hadoop團隊，實施該系統……
半個月后，客戶打來第二個電話，明確表示Hadoop未能滿足需求，決定接受我們的報價，並願意預付一半的費用。客戶要求我們不僅出產品，還要負責實施……於是乎，開工！
項目價值
CMNET網間流量分析與監控系統（簡稱流控系統），是中國移動省分公司的一個項目。項目要求能基於時間、地區、運營商、業務、App、IP分組、域名等維度對全省的上網流量進行實時分析和報告。這些分析報告能給客戶帶來如下好處：
1. 實現對接入鏈路和基站的全程監控。例如，一旦來自某鏈路或基站的流量很低，可及時對鏈路和基站進行檢修，這將大大降低故障率。
2. 由於具備了對鏈路和基站進行全程監控的能力，客戶可以對鏈路和基站的帶寬進行動態調整，基於需求進行合理的資源配置。
3. 覆蓋全省的全量數據，能提供基於業務/地域/App/行業/域名等維度的數據分析報告，具備100%的可信度和極高的商業價值。
數據流向
上網數據從硬件設備中抓取出來，形成壓縮的日志文件存儲在服務器上，服務器每五分鍾生成新的日志文件。該服務器提供FTP訪問。
Yonghong承擔的流控系統，將通過FTP每五分鍾訪問一次日志文件服務器，將新生成的壓縮日志文件抽取出來。這是一個典型的、增量更新的ETL過程，如下：
1. Extract: 定期抽取的日志文件並解壓縮。
2. Transform: 解析出上網信息，同MySQL的維度表進行關聯，生成包括業務/地域/App/行業/域名等維度的寬表。
3. Load: 將數據裝載入Yonghong 分布式集市。
初期驗證（POC）
中國移動的日志數據分G類和A類，各取幾塊樣本日志文件，驗證數據流向的可行性以及性能。
我們很快完成了ETL的整個過程，寬表數據被成功地裝載入Yonghong 分布式集市。
性能上，我們按照用戶提出的每天數據量5000萬條增量，計算出支持100天50億數據量的分布式集群所需的磁盤空間、內存總量、和CPU總量。由於客戶一再強調預算有限，於是配置了6台低配PC server：1cpu x 4core，32G內存，1T硬盤。
我們模擬了常用的用戶場景，整個系統的響應能力基本滿足需求。系統架構如下：
正式實施
中國移動省分公司的上網數據在內網，一般不提供外網連接，需要嚴格申請之后才能在一定時間內提供外網連接。因而，我們先把整個系統的ETL工作開發完成之后，才正式申請了外網連接進行數據裝載。
從開始進行上網數據的ETL工作，我們就發現數據量與預期嚴重不符。預期的上網數據是每天不超過5000萬條，但實際上每天的上網數據在6億條以上，100天保存的數據量將會達到驚人的六百億條。6台低配PC server有點小馬拉大車的感覺，完全達不到“海量數據、實時分析”的設計目標。我們趕緊聯系客戶，確定上網數據每天6億條以上，而不是之前預估的每天5000萬條左右。怎么辦？
系統重構
經過與客戶的詳細溝通和理性分析，大家一致決定進行系統重構。
上網數據的日志文件是5分鍾粒度的。我們將上網數據按照分析需求分為兩類：
1. 細節數據：保留三天的細節數據（5分鍾粒度），共約20億條。這樣，由於保留了細節數據，客戶可以對近三天的上網數據進行任意的探索式BI分析。
2. 匯總數據：在認真研究了流控系統的分析報告需求之后，我們將五分鍾的細節數據匯總為兩小時的匯總數據。這樣數據量可以降到約為原來的1/10，100天的數據總量大約60億條。
重構之后的數據流如下：
后期，我們陸續進行了一些系統調優，包括JVM調優、存儲調優、計算調優等等。客戶打開一個Dashboard的響應時間基本控制在秒級，最極端的分析報告也能在一分鍾之內生成。基本實現了“海量數據、實時分析”：
1. 系統定期推送日報、周報和月報。
2. 系統支持探索式BI分析。多數分析請求達到了秒級響應。
案例總結
1. 項目的數據量非常大，100天超過600億條日志；
2. 項目的預算非常有限，采購了6台低端PC Server。硬件投入不大，軟件性價比也很高；
3. ETL過程難度較高，隨着降維的需求加入，BI層難度也相應提高；
4. 為達到秒級響應，以支持探索式BI的交互式分析，對系統進行了多個層面的優化。
這個系統的成功實施和上線，完美詮釋了Yonghong的大數據之道：大數據，小投入。