東軟大數(shù)據(jù)技術-典型應用案例 (1)

1、大數(shù)據(jù)技術典型應用案例東軟集團技術戰(zhàn)略與發(fā)展部2015年7月Copyright 2015 Neusoft Corporation典型應用一：實時監(jiān)測數(shù)據(jù)統(tǒng)一采集管理平臺數(shù)據(jù)應用需求1、隨著傳感器、通信技術的發(fā)展以及智能電子設備的廣泛使用，企業(yè)生產現(xiàn)場產生的實時信息量大幅度增長；2、對現(xiàn)存的自動化孤島進行整合需要統(tǒng)一的實時數(shù)據(jù)采集管理平臺；3、需要接入的智能設備、控制器、自動化系統(tǒng)種類龐雜，過去針對某幾種特定設備、僅限于滿足具體項目需求的前置系統(tǒng)難以復用，迫切需要能夠廣泛適應多種系統(tǒng)接入的實時數(shù)據(jù)采集平臺；4、不管是電網運行管理還是電廠生產運營，要求有全方位的實時數(shù)據(jù)去支撐企業(yè)實時決策、敏捷制造

2、；5、企業(yè)只有將自動化系統(tǒng)和管理信息系統(tǒng)進行融合，才能充分發(fā)揮信息化的作用；數(shù)據(jù)特點分析采集測點900萬低壓用戶，未來會達到2300萬（每用戶一個測點）20萬高壓用戶，未來會達到100萬（每用戶40個測點）30萬終端設備，未來會達到100萬終端設備采集頻率6小時內采集成功率要求達到98%，每兩小時采集一輪（每天每個測點保證成功入庫一次）未來可能針對部分高壓用戶的重要測點需要每15分鐘集一輪數(shù)據(jù)量每天1700萬數(shù)據(jù)入庫，未來會達到63008000萬每年16.2T，未來會達到每年60T80T數(shù)據(jù)關鍵架構決策點復雜事件引擎StormS4分布式消息隊列kafkaMetaQ海量數(shù)據(jù)存儲HBaseMong

3、oDB分布式緩存RedisMemcached技術架構數(shù)據(jù)采集用電信息采集物聯(lián)網類銀行聯(lián)網類第三方系統(tǒng)采集Agent采集Agent采集Agent采集Agent電能表通訊規(guī)約電力負荷管理數(shù)據(jù)通訊規(guī)約網省集抄規(guī)約、東軟集抄規(guī)約ModBus PlusModNetDNP 3.0IEC101/104規(guī)約非標協(xié)議自編程Socket 集成應用安全生產監(jiān)控系統(tǒng)輸變電狀態(tài)監(jiān)測系統(tǒng)用電信息采集系統(tǒng)實時信息監(jiān)控系統(tǒng)管網監(jiān)控運維系統(tǒng)召測召測召測結果采集持續(xù)計算消息隊列（流數(shù)據(jù)）BoltBoltBoltBoltBoltBoltBolt格式轉換數(shù)據(jù)處理數(shù)據(jù)庫NoSQL關系型數(shù)據(jù)庫量測模型業(yè)務模型采集數(shù)據(jù)海量日志業(yè)務處理加密

4、數(shù)據(jù)解密服務監(jiān)控數(shù)據(jù)入庫數(shù)據(jù)分析數(shù)據(jù)過濾Bolt數(shù)據(jù)預警Bolt數(shù)據(jù)加密案例總結Storm-0.9.0.1ZeroMQ or netty?：Storm新版節(jié)點間通信采用netty實現(xiàn)，不穩(wěn)定，經常出現(xiàn)連接中斷，更換成ZeroMQ后正常消息去重：從業(yè)務上去重【如：消息上增加業(yè)務標識】Kafka-2.8.0消息確認機制選擇（不確認、Leader確認、Leader和Follower確認），不確認性能最高同步寫文件策略選擇（批量寫：消息數(shù)量和時間間隔）Redis-2.8.6通過批量key獲取數(shù)據(jù)性能最好ZooKeeper-3.4.5單獨獨立部署：Zookeeper和Storm均涉及大量IO，存在資源爭

5、搶問題Hadoop-2.3.0-CDH5.0搭建專門的dns服務器時鐘同步密鑰文件在共享存儲中集中管理IO（磁盤、網絡）：千兆網絡以上Hbase-0.96.1禁止自動文件拆分典型應用二：中國移動X省大數(shù)據(jù)平臺建設方案數(shù)據(jù)應用需求業(yè)務人員可根據(jù)日常工作需求快速創(chuàng)建分析報表，提供靈活的過濾、篩選、分組及鉆取能力，適用于個性化主題分析的快速創(chuàng)建。用戶通過指標篩選后進行分析，針對指標按不同維度下鉆，包括：時間維度、空間維度、區(qū)域維度等普通用戶可以通過（類）SQL接口自行數(shù)據(jù)報表開發(fā)高級用戶也可以直接使用MR、scala等語言，進行復雜的專題分析設計與應用以網絡業(yè)務體系為基礎的指標導航數(shù)據(jù)特點分析目前每

6、日數(shù)據(jù)量接近4T，2015年將達到7T。當前已建立完成覆蓋近30萬頻道和27億網頁（含WAP）的URL地址庫，形成2463個互聯(lián)網分類標簽和27萬關鍵詞庫。通過與主流市場和APP廠商合作，能夠解析覆蓋用戶產生流量95%以上的手機應用。分類數(shù)據(jù)源數(shù)據(jù)描述網絡話務網管 GSM、TD網絡性能和動態(tài)資源數(shù)據(jù)。數(shù)據(jù)網管 WLAN網絡性能和動態(tài)資源數(shù)據(jù)。網優(yōu)平臺 鄰區(qū)數(shù)據(jù)綜合資源 靜態(tài)資源數(shù)據(jù)業(yè)務CRMBOSSVGOPESOP經分 語音、GPRS、WLAN話單數(shù)據(jù)；小區(qū)級月收入匯總；用戶基礎信息月匯總用戶Gn監(jiān)測 用戶上網Gn話單數(shù)據(jù)A+Abis信令 用戶A接口話單數(shù)據(jù)上網日志 用戶上網日志位置位置系統(tǒng)

7、軌跡管理管理信息系統(tǒng) 財務、ERP等互聯(lián)網 互聯(lián)網網頁 網頁內容爬取關鍵架構決策點數(shù)據(jù)處理將構建基于Hadoop+Spark+MPP混搭架構，并嘗試探索利用Spark的高速交互迭代計算技術取代MPP商用數(shù)據(jù)庫實現(xiàn)數(shù)據(jù)分析與挖掘去IOE的可行性。研究驗證在事務處理和高并發(fā)機制場景下嗎，利用MySQL取代Oracle的可行性，驗證HDFS+Spark+Mysql全開源，完全去IOE架構的應用情況。技術架構大規(guī)模明細數(shù)據(jù)話單信令HDFS分布式文件存儲詳單和基于詳單的細粒度匯聚結果以及數(shù)據(jù)挖掘的結果自助分析（Impala ) &批量處理（Spark、Hive）&數(shù)據(jù)挖掘（Spark、Mahout）大數(shù)

8、據(jù)的清洗、輕度匯聚、計算與挖掘實時流處理與計算引擎綜合采集平臺匯總數(shù)據(jù)應用數(shù)據(jù)庫（MySQL）專題分析的結果數(shù)據(jù)，按照專題分庫存儲數(shù)據(jù)同步上層專題應用、即席查詢與分析MySQL數(shù)據(jù)查詢代理大數(shù)據(jù)采集大數(shù)據(jù)即席查詢 與分析（Impala）數(shù)據(jù)共享告警數(shù)據(jù)倉庫（MPP）結構化、維度化、詳單與網管數(shù)據(jù)關聯(lián)后的，面向分析主題的明細分析數(shù)據(jù)。多維度即席查詢 與分析（SQL）性能資源終端網優(yōu)MR營帳經分案例總結Hadoop與MPP如何分工協(xié)作，充分發(fā)揮各自的優(yōu)勢Hadoop擅長處理那些海量的，處理邏輯相對固定的數(shù)據(jù)，如對信令CDR進行預處理和簡單的關聯(lián)匯聚處理，可以有針對性的對處理程序進行優(yōu)化MPP適合對

9、大量的數(shù)據(jù)進行復雜的統(tǒng)計與分析，提供很好的人機SQL界面，適合快速變化的分析需求和對大量數(shù)據(jù)進行即席查詢的場景通過統(tǒng)一的作業(yè)調度將Hadoop和MPP的作業(yè)穿插結合起來，將兩個平臺的數(shù)據(jù)處理作業(yè)結合在一起形成一個整體的數(shù)據(jù)處理流程Hadoop與MPP數(shù)據(jù)同步的效率問題Sqoop適用于中小數(shù)據(jù)量，對于大數(shù)據(jù)量就會存在性能問題M/R程序在各個數(shù)據(jù)節(jié)點本地生成文件，在各個數(shù)據(jù)節(jié)點本地將文件裝載到MPP數(shù)據(jù)庫中案例總結多條件詳單查詢的效率問題詳單數(shù)據(jù)存放在Hadoop中，簡單按照號碼和日期查詢一個用戶的詳單很快，但是如果通過多個查詢條件查詢符合這些條件的用戶的詳單就會很慢對海量詳單數(shù)據(jù)建立有效的二級索

10、引，來實現(xiàn)多條件多用戶的快速詳單查詢Hadoop集群數(shù)據(jù)分布不均的問題集群在運行一段時間后，各個數(shù)據(jù)節(jié)點的數(shù)據(jù)會出現(xiàn)不均衡的現(xiàn)象，影響整體集群的運行效率定期在閑時進行數(shù)據(jù)的重分布操作海量信令數(shù)據(jù)如何進行快速處理引入Spark，用Spark對信令話單數(shù)據(jù)進行預處理和簡單的關聯(lián)匯聚處理后續(xù)根據(jù)Spark的成熟情況逐漸將Spark的應用場景擴大到復雜的數(shù)據(jù)統(tǒng)計和分析中，逐漸替換MPP的一些工作典型應用三：企業(yè)信用公示大數(shù)據(jù)應用實踐數(shù)據(jù)應用需求2013年國務院在推進公司注冊資本登記制度改革時強調：推行注冊資本登記制度改革，就是要按照便捷高效、規(guī)范統(tǒng)一、寬進嚴管的原則，創(chuàng)新公司登記制度，降低準入門檻，強

11、化市場主體責任，促進形成誠信、公平、有序的市場秩序。會議明確，將企業(yè)年檢制度改為年度報告制度，任何單位和個人均可查詢，使企業(yè)相關信息透明化。企業(yè)信用數(shù)據(jù)公示需求省數(shù)據(jù)中心信用公示庫數(shù)據(jù)同步索引文檔庫檢索引擎公示服務數(shù)據(jù)獲取建索引企業(yè)明細檢索企業(yè)公眾查詢數(shù)據(jù)特點分析數(shù)據(jù)量大強關系查詢?yōu)橹鳟悩嫼投鄻有詷I(yè)務交易數(shù)據(jù)全省工商數(shù)據(jù)登記、年檢、股東、分支機構等對外提供檢索服務圖片、PDF、Word等外部采集數(shù)據(jù)網上申報數(shù)據(jù)外部交換數(shù)據(jù)內外接口多共享、交換、同步關鍵架構決策點1243大數(shù)據(jù)平臺Hadoop發(fā)行版Hbase vs MongoDBHbase 數(shù)據(jù)模型安全數(shù)據(jù)集成Oracle到HBaseHbase

12、到SolrDataExchange vs SqoopUniEAP 集成UniEAP v4版本Hbase 訪問接口封裝Solr RESTful服務接口封裝檢索引擎開源與商業(yè)產品Solr vs ElasticSearch索引實時性并發(fā)訪問性能技術架構數(shù)據(jù)源省工商數(shù)據(jù)中心省綜合業(yè)務交易數(shù)據(jù)其它部門共享數(shù)據(jù)公示平臺HDFS公示庫（HBase）檢索庫（Solr）DataExchange年報庫（Oracle）initCDC實時（lily）批量(DataExchange)批量文件系統(tǒng)/共享存儲管理監(jiān)控業(yè)務應用資源監(jiān)控（Aclome）集群管理（ClouderaManager）安全(Kerberos)公示系統(tǒng)年

13、報系統(tǒng)關系數(shù)據(jù)非關系數(shù)據(jù)案例總結1、DataExchange往HBase大批量加載數(shù)據(jù)時，RegionServer出現(xiàn)不響應問題。解決辦法：預先創(chuàng)建Region，并停止 WAL日志，改善批量加載性能。2、Solr在初始化批量索引時，使用lily構建索引，容易引起HBase GC時間過長，導致zookeeper強制其下線。解決辦法：構建索引使用兩種方式，一種是批量索引使用import方式導入，一種是增量索引場景，從 HBase使用lily增量近實時構建索引。3、索引及業(yè)務數(shù)據(jù)一致性驗證缺乏有效手段，解決辦法：定期做一遍索引的全量更新。4、分詞詞庫選擇，IK有效性、準確性還有待提高。5、在該平臺基

14、礎上可以進一步引入Streaming 處理，機器學習等技術，實現(xiàn)更高效的企業(yè)黑名單識別、企業(yè)族譜的建立等應用決策場景。6、安全方面目前實現(xiàn)基于Kerberos的安全認證，下一步可以結合Sentry實現(xiàn)細粒度授權。典型應用四：基于社會化媒體分析的精準營銷數(shù)據(jù)應用需求精準營銷人口統(tǒng)計興趣喜好客戶價值客戶需求社會化隱性顯性消費基因關聯(lián)分析規(guī)則匹配SEO向上營銷交叉營銷流失預警流失挽留趨勢預測意見領袖情感分析情感統(tǒng)計熱門主題主題跟蹤社交圖譜知識圖譜興趣圖譜數(shù)據(jù)特點分析數(shù)據(jù)價值查詢頻率數(shù)據(jù)規(guī)模關系復雜數(shù)據(jù)格式社會化媒體數(shù)據(jù)7X24小時不間斷采集或爬取海量數(shù)據(jù)，數(shù)億用戶用戶行為數(shù)據(jù)。領域數(shù)據(jù)非結構化、數(shù)據(jù)

15、多樣多維度、噪音大、重復數(shù)據(jù)多價值密度低，浪里淘沙卻又彌足珍貴具有準確性數(shù)據(jù)按日更新最大限度保證數(shù)據(jù)的時效性知識圖譜、興趣圖譜、社交圖譜響應時間處理速度快，秒級響應關鍵架構決策點興趣圖譜分布式存儲 業(yè)務需求：海量數(shù)據(jù)，查詢條件復雜，包含groupby、sort等條件多條件查詢無響應內存資源占用大分布式版與單機版查詢性能相差不大兩個條件到五個條件查詢3050s個興趣詞響應時間大約在510s之間橫向擴展能力可以應對興趣-人關系數(shù)據(jù)的增長Neo4jembedd不穩(wěn)定導入數(shù)據(jù)時間長，有timeout異常Neo4jrestserver技術架構數(shù)據(jù)資源層內容數(shù)據(jù)社交媒體數(shù)據(jù)客服中心數(shù)據(jù)行為數(shù)據(jù)網站、App

16、、設備業(yè)務交易業(yè)務主數(shù)據(jù)CRM數(shù)據(jù)資源數(shù)據(jù)領域數(shù)據(jù)維基百科、百度百科、Freebase企業(yè)知識庫數(shù)據(jù)數(shù)據(jù)存儲層數(shù)據(jù)抓取Weblech（網頁爬取）WeiboSDK（開放API）數(shù)據(jù)預處理數(shù)據(jù)存儲層HBase（列存儲數(shù)據(jù)庫）HDFS（分布式文件系統(tǒng)）數(shù)據(jù)整合數(shù)據(jù)去重數(shù)據(jù)轉換數(shù)據(jù)過濾大數(shù)據(jù)管理Ozzie（工作流調度）Zookeeper（系統(tǒng)協(xié)調）Cloudera Manager日志管理分布式并行計算框架YARN數(shù)據(jù)分析挖掘自然語言處理中文分詞特征提取潛在語義文本挖掘文本濾重情感分析標簽傳播訓練模型模型構建模型訓練模型優(yōu)化分類算法聚類算法關聯(lián)分析特征選擇主題提取標簽傳播社交圖譜興趣圖譜知識圖譜安全管理數(shù)據(jù)訪問層Solr（分布式搜索）Redis（分布式緩存）離線算法評估案例總結 選取數(shù)據(jù)構建模型時，需要考慮業(yè)務產品是否具有季節(jié)性，比如銀行的考核有季度性帶來業(yè)務上的一些優(yōu)惠等措施，對流失率影響比較大，所以在選取數(shù)據(jù)構建模型時都應該有所考慮。選取的訓練樣本應考慮各影響因子。不同業(yè)務場景數(shù)據(jù)分析周期不同，合理考慮框架模型，根據(jù)業(yè)務選取線上和線下分析，選取流計算框架或分布式計算框架。對于社交化媒體數(shù)據(jù)這種