以下為分享實景全文：
我将我的時間分為三個session:
1、 神州泰嶽積極參與大資料時代的業務拓展
2、 海量使用者通信業務平台的設計實踐
3、 對于資料營運的思考
一、神州泰嶽近幾年在大資料領域做了不少投資和業務布局。歸納起來主要集中在四個層面：
1、入口：“智慧線”
2、基礎設施：“iaas”“dbaas”“hadoop”“mpp“ “智能推薦引擎”
3、資料源建設：“使用者行為資料”“使用者屬性資料”“使用者社交資料”“系統運作日志”“自然與地理資訊資料”
4、行業應用：電信、金融、零售、網際網路、旅遊、氣象
并成立了專業子公司來拓展大資料方面的業務。
應用案例之一，商場人流熱度分析：
二、海量使用者通信業務平台的設計實踐
接下來我分享一下關于海量使用者業務平台的設計實踐，我的案例不少來自飛信業務。雖然它目前不能算一個特别成功的業務，但由于産品定位的特殊性以及移動使用者的巨大數量，是以飛信在系統設計上也比較有特色，有很多有意思的地方，值得玩味。總結起來跟同類系統對比的差異是：
1、需要支援同帳号的多點登陸：這點很要命，由于不同終端的能力不一緻性，系統需要增加很多能力協商機制以及多份資料快照，也使得消息的傳輸邏輯變得異常複雜；
2、需要将短信能力作為消息不可達時的補償體系：難點在系統如何判定“不可達”，一旦失真，結果就是要不丢消息，要不多次騷擾；
3、是通信系統，不是社交娛樂工具：最本質的差別是消息要即時發送到達使用者，使用者體驗難處理，使用者期望值不一樣；
4、客服要求高，監管婆婆多：電信系統特色，導緻需要投入巨資建設資料實時查詢系統，一旦有使用者投訴需要立即處理，還有安全系統，對平台的日志要求高；
系統邏輯架構圖舉例：
我将系統設計中幾個重點需要考慮的方面拎出來介紹一下：容量、可靠性與穩定性、資料處理、安全。個人的體會是業務營運到一定程度，雕琢的都是細節的問題了，也是最不好對付的。
1、容量
海量使用者平台的設計首先碰到的是系統計算容量是否滿足的問題，由于任何單一的系統和裝置都不可能滿足需求，就算有，成本也會高昂得難以承受。
網絡層：由于飛信系統屬于電信營運商的業務，是以系統設計上必須符合電信級規範，帶來的第一個挑戰就是防火牆裝置性能不足的問題，需要通過組合來支援千萬級同時線上。
主機：為了有效降低成本，采用都是通用架構的pc server，我們通過優化後實作了單機承載同時線上使用者數25萬的目标，每秒處理請求：8000/秒
資料與存儲：百億條使用者關系鍊；10億使用者賬号；日處理消息百億級；支援最高50000/秒的登入請求處理；過去在存儲環節碰到的問題是磁盤容量夠，但心軸數不夠，導緻存儲的i/o能力不足，直到有了ssd硬碟，才緩解了該問題。現在經常碰到的問題是千兆網卡不夠用的問題。
在實際營運過程中，還需要處理鍊路波動導緻的潮湧沖擊，譬如聯通鍊路中斷後，大量使用者的自動重連将會帶來遠遠超出系統設計容量的請求，此時就需要啟動”優雅降級技術”，通過降低服務等級來集中資源處理登入業務（最大的瓶頸還是在資料庫）。
2、可靠性與穩定性
海量使用者通信業務平台的可靠性需要适應四個設計前提：
a、任何單一的計算節點都可能發生故障
磁盤：每天運維人員要推着磁盤車更換磁盤；
主機：某台主機當機能夠不影響使用者體驗（不讓使用者察覺）
網絡：某個網絡裝置當機，能夠快速切換路由
b、任何研發環境裡的測試都不可能是充分的
系統需要具備灰階釋出能力:在單元測試、功能測試、性能測試、容量測試後，需要通過灰階釋出機制，先将功能釋出給部分典型使用者試用，以控制故障和大規模投訴風險。
c、必須适應複雜的終端接入網絡
由于全國的終端接入方式多種多樣，部分組織和企業的it管控政策差異很大，任何在終端裝置上需要安裝用戶端軟體的系統都必須要建立一套通用通訊引擎（更多是營運經驗的積累），以穿透複雜網絡的種種限制。
d、必須支援頻繁變更情況下的系統穩定，使用者體驗穩定
網際網路業務不同于電信業務，“快速疊代”的需求帶來的就是頻繁系統更新，如何能夠不停服務的情況下而能夠快速更新，特别是需要把更新分發到成千上萬台機器上，需要在架構設計時就要預先考慮。
運維系統舉例一：業務運作品質監控
運維系統舉例二：60s級故障自動響應系統
3、資料處理：
在我經曆的工程實踐中，在資料處理這塊主要解決的問題有：
a、資料庫多的問題
對于一個大型營運業務，需要面臨不同的業務單元或者部門需要建立和維護很多資料庫，這會帶來兩個方面的問題：一是部署與管理困難；二是需要耗費很多dba工程師并散落在各部門。這也是很多大型企業的it建設中會碰到的問題。
我們的對策是開發了一套“dbop”資料庫托管平台，集中建設資料庫平台，任何使用方隻需送出申請，描述資料庫的規格需求，就可以在1各小時内開通配置設定。這樣就可以把優秀的dba集中起來維護調優該平台，節省了大量的人力開支。現在已經跑着近300個資料庫了。
b、資料庫大的問題
對于海量使用者平台，單表行數超億條是非常正常的事，以往的處理都是采用顯式分表的方式來縮小庫表的尺寸，但這樣導緻程式員寫代碼非常不友善。
我們的對策是基于mysql開發了一套“dbproxy”海量資料庫平台，這樣業務使用方的程式員徹底不用考慮分表的問題，對于他們來說都是透明的，就正常的寫sql語句就可以。
c、資料庫雜的問題
一個大型營運業務中，産生各類資料是非常正常的。有些是結構化的，有些是非結構化的，有些是實時要求高的，有些是可以慢慢處理的。是以在我們的實踐中同時維護着db2,oracle,sqlserver，mysql，hadoop體系等各類資料存儲和處了解決方案。為了節省開支，目前處于清理和統一的過程中。
資料平台邏輯結構示意圖：
4、安全
在海量使用者通信系統的設計中，安全方面的考慮消耗了大量的投資。主要包含的方面有：
1、網絡安全
這個所有it系統都會碰到，但量變會導緻質變。正常的網絡安全設計方法在量大到一定程度時就無法适用了，譬如沒有那麼大處理能力的ips/ids,ddos黑洞,防火牆。目前很多的安全裝置廠商和監管部門的觀念還是比較落後，都是面向過程是否合規，而不是面向結果是否符合預期，是以導緻事倍功半的局面。有時候為了應付審查，不得不投入巨資來滿足規範。
2、業務安全
在系統設計中，個人非常認同一句話“一小撮人壞了大多數人的體驗”。為了對付一小撮别有用心的人，需要給系統設定層層保護和障礙，使得正常使用者的體驗下降。舉幾個例子：
a、業務濫用
飛信具備免費發短信能力，這就可能被某些人濫用。“卡商養卡”是營運商業務特有的煩惱，你打擊了他，他還會去工信部投訴你。
b、防止洩密
其實洩密最重要的就是使用者密碼問題。為了能夠自動登入，必須在用戶端儲存密鑰資訊，那麼本地存儲是否會被盜，傳輸過程是否會被截獲，背景會不會有内鬼這都是需要特别設計防護的。在現在的app大發展時代，相信一定會有企業從app安全業務中獲得成功。
現在對于海量使用者系統的盜号犯罪，已經是集團化的體系在運作，盜号，銷售，發詐騙資訊各有分工，打擊起來非常困難。有些人在境外，有些人在邊遠地區，譬如儋州，楚雄，貴港等一般治安比較差的地方，警察一般都不願意去。曆史上我們在公安部和北京市警察局的幫助下打擊過一批。
c、特殊情況
一個案例：曾經有人利用gae平台進行程式設計，利用飛信可以免費發短信的特點，将短信和twitter平台對接，就是發一條短信到某個飛信賬号上，這個賬号在gae平台上接收資訊然後釋出到twitter上，繞過了gfw，釀成了“重大安全事件”j,最後隻好封殺所有來自gae平台的通路。
3、内容安全
這個最具中國特色，一般的資訊安全教科書上不太細談。當然，有部分内容安全屬于業務濫用範疇，比如目前很火的利用imessage群發營銷消息的生意，就是因為蘋果公司沒有這方面的營運經驗造成的，他們對付不了“聰明”的中國人。
還有一部分就是“敏感詞”範疇了，這個領域不多談了，反正一般的nlp技術是對付不了的，我們是建立了一套“行為識别平台”來提升管控效果。
安全管控系統舉例之一：實時行為資料監控分析系統
以上是一些工程實踐中的系統設計總結，比較粗略，如果有群友有興趣，可以找機會細聊。近期在思考一些關于大規模分布式軟硬體系統如何更好的協同操作（所謂的電信級标準真的需要嗎？）、什麼才算好的可擴充計算架構，如何才能提升pue效率的問題，因為未來的融合通信系統（全ip網絡，長線上）将會面臨這些問題。
在一個網際網路業務營運中，其中很重要的一塊是“資料營運”。但一般來講，目前絕大部分企業或者業務所謂的資料營運還都是bi層面，還沒到“大資料”層面，是以經常搞着搞着就覺得也沒啥意思，“熱鬧”大于“實用”，花了很多錢，最後發現對于發展業務也不是那麼有效，因為事實上目前很多所謂的資料分析都是基于算法和邏輯推理出來的結論，這些結論的獲得從某種意義上來講不值當花那麼多錢，這是目前的一種比較普遍的現象，導緻很多投資決策者失去興趣，非常不利于“大資料”産業的發展。
“養“資料需要耐心和大投入。我們在實際營運中采集沉澱了很多資料，但往往因為缺少某些資料而導緻這些資料不能被有效的串在一起，使得價值大打折扣。這時候就需要通過産品設計和營運活動來”養“出這些資料，這個過程比較漫長，也很費錢。
如何”用“好資料，非常考驗使用者的智慧和經驗，甚至生活閱曆。在很多地方，往往存在這樣一些思維：我這裡有很多資料，看看你們bi工程師能不能挖掘出來點啥。事實證明，這樣的效果往往很不好，沒有商業需求驅動下的使用資料，在目前還沒看到特别的好效果，我們也投入過幾個類似項目，分析的結果就是出來一大堆報告，看上去很吸引人，但也沒發現啥商業價值。但有些優秀産品人員就能夠根據”大資料“的思維提出資料需求和簡單的分析模型，譬如“找出某款遊戲的潛在使用者群”“找出中繼節點的最佳部署位置”“勾勒使用者社交關系的強弱圖譜”等，然後資料部門就幫他準備資料并提供分析結果，來指導産品設計和營運，往往取得較好的成果。是以别指望着資料工程師或分析工程師”用”好資料。j
消除”資料孤島“靠行政力量不行，唯有靠商業利益。譬如營運商擁有大量的資料，但使用者的profile資料、消費記錄、位置資訊、增值業務行為資料等散落在不同部門，要想讓各部門主動的貢獻出來這些資料非常困難，是以很多創新業務就開展不起來，之前我們在推動時也頗感吃力。未來如果能夠成立專業公司來營運這些資料并擷取商業利益，再作價結算給各部門，才有些可能。這個問題同樣也會發生在很多組織和企業裡。
“服務使用者”與“侵犯使用者”的邊界問題。現在很多産品和業務在采集使用者資料方面是非常具備“侵略性”的，以前有些企業還會将采集的資料打亂塞在心跳包裡偷偷上傳，至少還掩飾一下，現在很多app以更好的“服務使用者“名義竊取使用者手機裡的資訊時肆無忌憚，如果這些資訊被濫用，導緻使用者出現反彈情緒，再引來cctv的關注，那麼就會嚴重損害産業的發展。如果有一些可信任的權威機構來統一建設一些基礎資料庫，并公平、規範的開放出來，将會使創新更加容易一些。
原文釋出時間為：2014-05-12
本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号