數據架構參考及數據結構(樹)_第1頁
數據架構參考及數據結構(樹)_第2頁
數據架構參考及數據結構(樹)_第3頁
數據架構參考及數據結構(樹)_第4頁
數據架構參考及數據結構(樹)_第5頁
已閱讀5頁,還剩101頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

數據架構設計(數據架構組)概述總體描述相對于業(yè)務架構和應用架構,數據架構在總體架構中處于基礎和核心地位。因為信息系統支撐下的海關業(yè)務運作狀況,是通過信息系統中的數據反映出來的,數據信息系統管理的重要資源。因此構建海關的IT總體架構時,首先要考慮數據架構對當前業(yè)務的支持。理想的IT總體架構規(guī)劃邏輯上是數據驅動的,即:首先根據業(yè)務架構分析定義數據架構;然后根據數據架構結合業(yè)務功能定義應用架構;最后根據應用架構與數據架構的定義,來設計技術架構。數據架構藍圖邏輯藍圖圖:數據架構總體邏輯藍圖數據架構的六個統一,即統一數據規(guī)劃、統一存儲、統一計算、統一服務、統一接入、統一數據治理。物理藍圖圖4-1-1通過萬兆連接核心交換區(qū),實現網絡高速交換,確保可靠性各服務器均雙線連接數據區(qū)核心交換機,消除單點故障結構清晰,層次分明設計原則1、整體性原則共享服務平臺必須根據統一的總體方案的統籌規(guī)劃,按總署、直屬海關、隸屬海關的功能劃分實行多級部署,同時按照職責分工進行建設和管理,保證三個層級的部署構成一個整體,各部分通信暢順,信息共享,形成一個全國性的共享服務平臺。2、標準化原則總署統一制定信息資源共享服務的技術標準、通信協議標準、數據交換報文標準,提供數據訪問功能、基本業(yè)務邏輯處理功能的標準組件。系統的開發(fā)、集成按照規(guī)定的標準進行,保證海關共享服務平臺的結構一致性和技術規(guī)范性。3、安全與效率并重原則總結和汲取超大業(yè)務量海關的成功經驗,采取充分足夠的技術手段和管理制度,在保證共享服務平臺與海關業(yè)務應用系統之間高速的數據交換,在保證共享服務平臺良好運行效率的同時,保證海關業(yè)務運行網和業(yè)務管理網的信息安全和運行安全。系統設計方面要充分考慮共享服務平臺數據量大、負荷高等因素,嚴格控制程序流程設計、嚴把程序編制質量、同步制定配套的系統運行管理辦法,確保共享服務平臺運行的高效性和穩(wěn)定性。4、系統功能與職責分工相適應原則平臺多方共建,發(fā)揮各方面的積極性,信息系統、業(yè)務系統與業(yè)務管理或操作運行的主體之間的關系和分工必須明確。5、一致性原則共享服務平臺在體系架構上必須與金關業(yè)務解決方案的框架保持一致,在系統開發(fā)建設的設備選型、開發(fā)技術、認證授權、門戶框架、數據定義、參數管理、通信協議、網絡結構、安全運維等方面必須與金關總體技術方案保持一致,保證共享服務平臺成為現代海關綜合管理系統的有機組成部分。注:整體統籌原則數據層和應用層解耦數據的高可靠服務的高可用設計目標“信息資源體系建設”是一項長期工程,是支撐海關各個業(yè)務條線之間實現充分協作信息共享基礎架構。將確保金關工程二期在海關信息資源開發(fā)利用方面抓住數據一致性、規(guī)范性等數據質量源頭建設,形成統一頂層設計,做到海關信息資源一盤棋,數據統一管控,統一開發(fā)利用,促進海關信息共享、業(yè)務協作效率和科學決策水平的更高提升。總體目標主要包括以下五個方面內容:1、實現信息資源整合信息資源規(guī)劃的一項很重要的目標就是要解決目前信息系統建設中的重復建設問題,達到信息系統的整合和集約,信息資源規(guī)劃是信息系統頂層設計的一部分,能夠從整體上對信息資源進行設計,并能夠提供信息系統建設的標準和規(guī)范,這樣信息系統就能夠以此為標準,進行適時、適度、逐步整合,最終達到消除冗余,集約良性發(fā)展的效果。2、提高技術響應速度業(yè)務需求的變化和技術的響應速度之間一直是一對矛盾,信息資源規(guī)劃通過對信息系統,尤其是信息資源架構進行科學設計,可以增強信息資源架構的穩(wěn)定性,當業(yè)務需求變化時,可以通過很少的數據結構和程序變動就能夠滿足業(yè)務需求,這樣不但提高了技術響應速度,而且能夠增強系統的穩(wěn)定性,降低故障率。3、實現信息共享信息資源規(guī)劃通過建設信息共享服務平臺,實現了數據的集中存儲和計算,并實現了對外統一的服務接口,不論是對于海關內部的信息共享需求,還是外部的數據共享需求;不論是直接面向用戶的共享查詢,還是面向應用系統的數據服務,都可以通過數據服務共享平臺解決。4、實現大數據分析海關要實現智能海關,必須實現海關信息系統的物聯化、互聯化、智能化,而最重要的就是智能化,即通過大數據分析,為海關準確決策提供信息支持。信息資源規(guī)劃通過設計和實現數據共享服務平臺,引入并行數據庫、分布式數據庫等大數據存儲和計算技術,能夠解決海關的大數據分析問題,達到數據用得好、決策準的業(yè)務目標。5、提升數據質量信息資源規(guī)劃通過設定標準規(guī)范、業(yè)務管理流程,能夠規(guī)范數據的定義、存儲、使用、傳輸、交換,使得數據采集更加規(guī)范、數據傳輸更加準確高效,數據使用更加安全方便,通過各種管理流程和規(guī)范,能夠大幅提升數據質量。數據定義總體描述數據的基本結構分三個層次,反映了觀察數據的三種不同角度。(1)概念數據層。它是數據的整體邏輯表示。指出了每個數據的邏輯定義及數據間的邏輯聯系,是存貯記錄的集合。它所涉及的是數據所有對象的邏輯關系,而不是它們的物理情況。(2)物理數據層。它是物理存貯設備上實際存儲的數據的集合。這些數據是原始數據,是用戶加工的對象,由內部模式描述的指令操作處理的位串、字符和字組成。(3)邏輯數據層。它是用戶所看到和使用的數據,表示了一個或一些特定用戶使用的數據集合,即邏輯記錄的集合。 數據建模業(yè)務域根據目前海關不同的網絡,運行網、管理網和接入網以及總署和直屬的這種物理關系,梳理出每個域中業(yè)務情況和相互的關聯關系劃分出不同的業(yè)務域。海關目前的現狀梳理出來的業(yè)務域有:公共域、首長決策域、公共辦公域、業(yè)務管理域、綜合保障域和內部監(jiān)控公共域:公共時間域公共金融域公共位置域公共人員域公共機構域公共參數域首長決策:署長辦公公共辦公:辦公國際事務業(yè)務管理:政法關稅監(jiān)管物流加貿稽查緝私統計綜合保障:科技財務關務保障人事內部監(jiān)控督查審計監(jiān)察根據業(yè)務劃分核心數據和非核心數據。概念模型設計概念數據模型是最終用戶對數據存儲的看法,反映了最終用戶綜合性的信息需求,它以數據類的方式描述企業(yè)級的數據需求,數據類代表了在業(yè)務環(huán)境中自然聚集成的幾個主要類別數據。概念數據模型的內容包括重要的實體及實體之間的關系。在概念數據模型中不包括實體的屬性,也不用定義實體的主鍵。這是概念數據模型和邏輯數據模型的主要區(qū)別。概念數據模型的目標是統一業(yè)務概念,作為業(yè)務人員和技術人員之間溝通的橋梁,確定不同實體之間的最高層次的關系。根據業(yè)務域的劃分,梳理跨業(yè)務域的端到端的業(yè)務流程,從而梳理出大的對象之間的關系和小的業(yè)務流程。例如,用戶(user)E-R圖邏輯模型設計邏輯數據模型反映的是系統分析設計人員對數據存儲的觀點,是對概念數據模型進一步的分解和細化。邏輯數據模型是根據業(yè)務規(guī)則確定的,關于業(yè)務對象、業(yè)務對象的數據項及業(yè)務對象之間關系的基本藍圖。邏輯數據模型的內容包括所有的實體和關系,確定每個實體的屬性,定義每個實體的主鍵,指定實體的外鍵,需要進行范式化處理。邏輯數據模型的目標是盡可能詳細的描述數據,但并不考慮數據在物理上如何來實現。邏輯數據建模不僅會影響數據庫設計的方向,還間接影響最終數據庫的性能和管理。如果在實現邏輯數據模型時投入得足夠多,那么在物理數據模型設計時就可以有許多可供選擇的方法。解決端到端的業(yè)務流程梳理出大量的小流程和對象關系,進一步梳理出各個業(yè)務域的業(yè)務對象及其行為和屬性。物理模型設計物理數據模型是在邏輯數據模型的基礎上,考慮各種具體的技術實現因素,進行數據庫體系結構設計,真正實現數據在數據庫中的存放。物理數據模型的內容包括確定所有的表和列,定義外鍵用于確定表之間的關系,基于用戶的需求可能進行發(fā)范式化等內容。在物理實現上的考慮,可能會導致物理數據模型和邏輯數據模型有較大的不同。物理數據模型的目標是指定如何用數據庫模式來實現邏輯數據模型,以及真正的保存數據。常用的設計范式,以及對于數據量大的業(yè)務,在數據模型層面不處理表之間的主外鍵之間的關系。主要將邏輯模型的各個業(yè)務對象及之間的關系,以表、主外鍵及關聯表的方式表示。針對各個邏輯模型勾勒出各個域的ER模型。數據分布總體描述將數據物理分布式處理方式逐步轉為集中式處理方式,本節(jié)主要描述數據在各個業(yè)務子系統之間的邏輯分布,以及數據物理分布。邏輯分布系統名稱分系統名稱子系統名稱系統應用類型業(yè)務應用類數據業(yè)務分析類數據緝私監(jiān)控指揮企業(yè)信息應用歸類風險監(jiān)控審單執(zhí)法企業(yè)綜合資信數據交換應急指揮情報預警監(jiān)測決策分析風險監(jiān)測物流鏈監(jiān)控分析專家會診審單數據信息管理全國HG監(jiān)控指揮系統風險管理分系統風險監(jiān)控子系統實時性要求不高的OLTP風險處置子系統實時性要求不高的OLTP應急指揮分系統應急監(jiān)控預警子系統實時性要求不高的OLTP應急指揮調度子系統實時性要求不高的OLTP決策分析分系統決策分析分系統OLAP值班管理分系統值班管理分系統實時性要求不高的OLTP預案管理分系統預案管理子系統實時性要求不高的OLTP演練管理子系統實時性要求不高的OLTP緝私作戰(zhàn)指揮分系統實戰(zhàn)管理子系統實時性要求不高的OLTP信息支持子系統實時性要求不高的OLTP地理信息子系統實時性要求不高的OLTP移動應用分系統移動客戶端框架子系統實時性要求不高的OLTP移動端統一入口子系統實時性要求不高的OLTP移動應用服務中間件子系統實時性要求不高的OLTP移動應用管理子系統實時性要求不高的OLTP移動設備管理子系統實時性要求不高的OLTP業(yè)務應用插件子系統實時性要求不高的OLTP地理信息系統應用分系統地理信息系統應用分系統實時性要求不高的OLTP進出口企業(yè)誠信管理系統企業(yè)誠信守法申報子系統實時性要求不高的OLTP企業(yè)資格管理子系統實時性要求不高的OLTP報關員管理子系統實時性要求不高的OLTP企業(yè)稽(核)查子系統實時性要求不高的OLTP企業(yè)誠信守法信息采集子系統實時性要求不高的OLTP企業(yè)誠信守法規(guī)則管理子系統實時性要求不高的OLTP企業(yè)誠信守法差別化應用子系統實時性要求高的OLTP企業(yè)誠信守法信息指標統計子系統OLAP企業(yè)誠信守法評估子系統OLAP企業(yè)誠信守法績效評估子系統OLAP加工和保稅貨物管理系統加工貿易手冊管理分系統加工貿易手冊申報子系統實時性要求高的OLTP加工貿易手冊審批管理子系統實時性要求高的OLTP加工貿易賬冊管理分系統加工貿易賬冊申報子系統實時性要求高的OLTP加工貿易賬冊審批管理子系統實時性要求高的OLTPHG特殊監(jiān)管區(qū)域管理分系統HG特殊監(jiān)管區(qū)域管理申報子系統實時性要求高的OLTPHG特殊監(jiān)管區(qū)域審批管理子系統實時性要求高的OLTP保稅監(jiān)管場所管理分系統保稅監(jiān)管場所申報子系統實時性要求高的OLTP保稅監(jiān)管場所審批管理子系統實時性要求高的OLTP保稅綜合管理分系統保稅業(yè)務監(jiān)控分析子系統OLAP單耗管理子系統實時性要求不高的OLTPHG物流監(jiān)控系統HG物流鏈可視化管理分系統物流鏈數據收集子系統實時性要求高的OLTP物流鏈信息展示子系統實時性要求高的OLTP物流鏈分析預警作業(yè)子系統實時性要求高的OLTP物流連信息預警處置子系統實時性要求高的OLTP物流可視化預警參數管理子系統實時性要求高的OLTP智能卡口分系統前端集成子系統實時性要求高的OLTP現場服務子系統實時性要求高的OLTP后臺核放子系統實時性要求高的OLTP查驗業(yè)務管理分系統機檢查驗管理子系統實時性要求高的OLTP人工查驗管理子系統實時性要求高的OLTP知識產權自動識別子系統實時性要求高的OLTP輔助管理子系統實時性要求高的OLTP統計查詢子系統實時性要求高的OLTP機動巡查管理分系統機動巡查作業(yè)管理子系統實時性要求高的OLTP機動巡查查詢統計子系統實時性要求高的OLTP通關管理系統報關單通關無紙化分系統通關電子數據申報子系統實時性要求高的OLTP通關事務/行政許可審批子系統實時性要求高的OLTP報關單無紙化審單子系統實時性要求高的OLTP報關單無紙化放行子系統實時性要求高的OLTP非報關單管理分系統快件管理子系統實時性要求高的OLTP旅客行李物品監(jiān)管子系統實時性要求高的OLTP郵政總包監(jiān)管子系統實時性要求高的OLTP郵件通關監(jiān)管子系統實時性要求高的OLTP特殊人員及機構進出境公自用物品通關子系統實時性要求高的OLTP免稅店及商品監(jiān)管子系統實時性要求高的OLTP電子隨附單據管理分系統通關電子隨附單據管理子系統實時性要求高的OLTP執(zhí)法電子隨附單據管理子系統實時性要求高的OLTP通關電子隨附單據歸檔管理子系統實時性要求高的OLTP執(zhí)法電子隨附單據歸檔管理子系統實時性要求高的OLTP接單環(huán)節(jié)派單叫號分系統公共服務子系統實時性要求高的OLTP現場作業(yè)子系統實時性要求高的OLTP掛號管理子系統實時性要求高的OLTP查詢統計子系統實時性要求高的OLTP關稅管理系統關稅電子數據申報子系統實時性要求高的OLTP減免稅管理子系統實時性要求高的OLTP原產地管理子系統實時性要求高的OLTP歸類風險監(jiān)控子系統OLAP價格管理子系統實時性要求不高的OLTP報關單批量復審子系統實時性要求不高的OLTP審單輔助支持子系統實時性要求不高的OLTP遠程專家在線會診/審單子系統實時性要求高的OLTP商品條碼信息管理子系統實時性要求不高的OLTP征稅管理子系統OLAP征稅分析子系統實時性要求高的OLTPHG基礎數據管理系統數據分析管理分系統數據抽取分發(fā)子系統實時性要求不高的OLTP動態(tài)數據倉庫子系統OLAPHG業(yè)務數據管理分系統數據質量監(jiān)控子系統實時性要求不高的OLTP業(yè)務數據管理子系統實時性要求不高的OLTP數據信息管理子系統OLAP統一數據加工子系統OLAP緝私管理系統執(zhí)法規(guī)范分系統刑事執(zhí)法子系統實時性要求不高的OLTP行政執(zhí)法子系統實時性要求不高的OLTP輔助辦案子系統實時性要求不高的OLTP證據管理子系統實時性要求不高的OLTP協查管理子系統實時性要求不高的OLTP職能管理分系統督察管理子系統實時性要求不高的OLTP績效管理子系統實時性要求不高的OLTP要案管理子系統實時性要求不高的OLTP綜合應用子系統OLAP情報作業(yè)分系統情報信息采集子系統實時性要求高的OLTP情報線索辦理子系統實時性要求不高的OLTP境外執(zhí)法合作子系統實時性要求不高的OLTP情報產品生產子系統實時性要求不高的OLTP情報預警監(jiān)測子系統實時性要求高的OLTP情報研判分系統情報信息智能檢索子系統OLAP情報專題研判子系統OLAP常用研判工具集子系統OLAP圖形視頻研判子系統OLAP情報研判模型管理子系統OLAP情報管理分系統情報監(jiān)督子系統實時性要求不高的OLTP績效評估子系統實時性要求不高的OLTP情報培訓子系統實時性要求不高的OLTP情報應用積分子系統實時性要求不高的OLTP業(yè)務數據監(jiān)測與處理子系統OLAP情報服務分系統緝私辦案離線支持子系統實時性要求不高的OLTP緝私信息決策支持子系統實時性要求不高的OLTP情報布控及協查子系統實時性要求高的OLTPHG監(jiān)管支持子系統實時性要求高的OLTP情報共享交換子系統實時性要求高的OLTP對外聯網應用系統聯網數據采集分系統企業(yè)綜合資信庫數據采集子系統實時性要求不高的OLTP聯網核查證件數據采集子系統實時性要求不高的OLTP情報公安數據采集子系統實時性要求不高的OLTP外單位數據采集子系統實時性要求不高的OLTP互聯網公開數據采集子系統實時性要求不高的OLTP數據轉換處理分系統企業(yè)綜合資信數據處理子系統OLAP聯網核查證件數據處理子系統實時性要求不高的OLTP聯網核查通關處理分系統自動進口許可證聯網核查子系統實時性要求高的OLTP密碼產品和含有密碼技術設備進出口許可證聯網核查子系統實時性要求高的OLTP瀕危物種允許進出口證明書聯網核銷子系統實時性要求高的OLTP進口藥品通關單聯網核銷子系統實時性要求高的OLTP進口獸藥通關單聯網核查子系統實時性要求高的OLTP原產地證書聯網共享子系統實時性要求高的OLTP關庫聯網核銷子系統實時性要求高的OLTP加工貿易多方聯網管理子系統實時性要求高的OLTP數據對外服務分系統聯網數據企業(yè)服務子系統實時性要求不高的OLTP聯網核查國家(地區(qū))、部委數據服務子系統實時性要求不高的OLTP企業(yè)綜合資信數據政務服務子系統實時性要求不高的OLTP緝私案件數據服務子系統實時性要求不高的OLTP物理分布數據存放:集中存放+災備?分布式主從模式?分布式無中心化?數據:核心交易:商用關系DB+小機集群?分析:newSQL+小機集群?低價值密度的大規(guī)模數據:NoSQL+大規(guī)模普通機器集群據地理分布:交易數據集中存放+災備;其他管理支持類應用數據可三中心分別存放?數據分類總體描述數據分類是企業(yè)數據的組成部分,其目的是為了滿足各種數據需求對數據組織的要求,根據數據內容的屬性或特征,將信息按一定的原則和方法進行區(qū)分和歸類,并建立起一定的分類體系,為數據的合理分布提供決策依據,以便管理和使用數據信息。分類原則在數據分類時遵循以下原則:數據分類需要滿足各種數據需求對數據組織的要求,即數據分類應該獨立于具體的數據模型;數據分類應有利于數據的維護和擴充。分類內容金關工程二期綜合考慮海關應用系統所產生的數據屬性、應用性質、處理方式、使用范圍等因素對數據進行分類,同時考慮對數據進行生命周期管理和數據質量管理;海關數據可以從業(yè)務、生命周期及數據特點進行分類。1、按照業(yè)務,海關的數據分為數據管理類(N)、業(yè)務基礎類(Y)、業(yè)務處理類(Y)、業(yè)務管理類(N)、業(yè)務應用類(N)、業(yè)務分析類(N)六類數據。業(yè)務數據分類核心和非核心數據與上面業(yè)務域數據之間的對應關系數據管理類數據,此類數據包含動態(tài)數據倉庫、數據抽取分發(fā)、數據質量監(jiān)控、統一數據加工、數據生命周期管理中的數據。業(yè)務基礎類數據,此類數據包含商品條碼、企業(yè)信息基礎、多維、公安信息資源、案件信息服務資源、自動許可證聯網核查、聯網核銷、原產地證書聯網共享、加工貿易多方聯網、GIS應用、核心系統參數、海關情報信息采集、海關情報移動支持的數據。業(yè)務處理類數據,此類數據包含報關單、免稅品、行郵、關稅電子、外單位信息資源、加貿手冊、加貿賬冊、互聯網信息資源、智能卡口、核心系統基本通關、核心系統輔助通關、核心系統備案的數據。業(yè)務管理類數據,此類數據包含減免稅管理、原產地管理、價格管理、業(yè)務數據管理、機動巡查、值班、預案、移動應用、海關特殊監(jiān)控區(qū)域、保稅監(jiān)管場所、保稅綜合管理、批量復審、海關情報業(yè)務管理、海關情報境外執(zhí)法合作、執(zhí)法規(guī)范化業(yè)務執(zhí)法、執(zhí)法規(guī)范化輔助辦案、執(zhí)法規(guī)范化職能管理的數據。業(yè)務應用類數據,此類數據包括緝私監(jiān)控指揮、企業(yè)信息應用、歸類風險監(jiān)控、審單執(zhí)法、企業(yè)綜合資信、數據交換、應急指揮、海關情報預警監(jiān)測的數據。業(yè)務分析類數據,此類數據包含決策分析、風險數據、物流鏈監(jiān)控分析、專家會診審單、數據信息管理的數據。2、按照數據來源以及服務對象,海關數據可分為對外交換數據、生產數據、共享數據、決策支持數據、元數據五類。對外交換數據,此類數據包括物流艙單、國外海關、電商訂單、互聯網輿情、政務公開等數據。生產數據,此類數據包括報關單、證件核銷、稅收、減免稅、證件監(jiān)管、加貿手冊、加貿合同、加貿單耗、風險布控、風險查驗、行政辦公等數據。共享數據,此類數據包括企業(yè)主數據、商品主數據、公共業(yè)務通關、公共業(yè)務企管數據。決策支持數據,此類數據包括數據倉庫、數據集市、業(yè)務報表、分析報告等數據。元數據,此類數據包括技術元數據、數據模型、指標體系、標準化等數據。3、按照生命周期,海關數據可以分為“生產數據(核心,非核心)”、“分析數據”、“歸檔數據”三類。4、按照數據本身的特點,海關數據可以分為結構化數據和非結構化數據,結構化數據主要是應用系統生成的存儲在關系數據庫中的數據,數據具有明顯的共性結構特點。非結構化數據主要指一些文本、圖片、圖像、視頻、音頻等數據。對于某一種數據(維度中的1個格子)對應一種存儲技術。數據接入總體描述數據統一接入層主要目的是解耦應用系統和數據存儲之間的關系,本部分主要描述應用系統和關系型數據庫之間的解耦,應用與其他類型的存儲之間的關系在本章的其他小節(jié)來描述。其整體架構如下圖所示:應用系統應用系統數據存儲MySqlOracleSQLServer。。。統一接入管理平臺應用系統管理邏輯節(jié)點管理配置數據管理物理節(jié)點管理路由規(guī)則管理擴容遷移管理代理訪問統一訪問服務數據驅動故障切換Mysql協議適配Oracle協議適配SQLServer協議適配數據節(jié)點池故障備份處理引擎數據擴容Sql的解析數據路由數據分片備份管理結果集處理備份管理上層為應用系統;下層為關系數據存儲。中間層為統一接入平臺。一般的應用開發(fā),應用層直接通過數據的驅動直接訪問關系數據庫進行數據的存取。在我們的數據架構中增加了一層統一接入層,其目的主要解決:提供統一的訪問服務。對應用來說,屏蔽了數據庫本身的差異,數據庫對應用來說只是服務。提供了服務的高可用,上層應用無需關心下層存儲的可用性問題,JDS層會做自動的主備切換,防止單點故障。提供了數據的高可靠,上層應用無需關心下層存儲數據的可靠性問題,存儲層會自動做好數據的自動全量及增量備份工作。并在需要的時候可以快速從備份恢復數據。支持數據的自動拆分,可應對海量數據的存儲及高性能訪問場景,對上層應用拆分邏輯完全透明,應用使用標準客戶端即可使用。數據存儲自動擴容,應用無需關心底層存儲的容量問題,一鍵進行數據的遷移及擴容工作。整體系統運維的自動化智能化管理,運維成本低。統一訪問服務統一訪問服務主要是為上層應用提供一個透明訪問代理層,應用無需關心底層存儲細節(jié)及產品類型,統一訪問服務層幫助應用抽象出了一個統一入口,屏蔽掉了底層的不同存儲產品帶來的復雜性。并同時實現了高性能具備過載保護及容災功能的接入服務,應用通過軟負載均衡設備來接入服務,軟負載均衡設備會實現多個接入節(jié)點的狀態(tài)監(jiān)測,故障剔除等工作。同時接入服務層提供了過載熔斷等保護功能,保護后端代理的存儲節(jié)點的穩(wěn)定和安全。處理引擎SQL解析模塊處理引擎會進行SQL請求的攔截和處理,并根據路由信息對SQL語句進行修改或拆分,如果涉及多個節(jié)點,則會將拆分后的SQL請求并行發(fā)送到不同的物理實例上,并等待結果返回,在查詢結果返回后,接入層會進行結果集的合并和計算,最終返回給客戶端,整個過程對客戶端完全透明。數據分片數據分片模塊可以將數據按照應用指定的規(guī)則進行水平切分,解決容量和訪問量的問題,即可以不使用任何高端存儲設備,只用普通x86機器完成很多高端存儲才能達到的存儲能力和訪問能力。降低海關業(yè)務整體的硬件成本。數據可以根據海關各子業(yè)務的訪問規(guī)則進行靈活配置,靈活擴展。數據路由海關各業(yè)務針對各自訪問規(guī)則進行了數據水平切分和分片后,引擎層邏輯會通過具體的訪問規(guī)則將實際的訪問請求路由到指定分片。路由規(guī)則的存儲是在元數據管理模塊中,并推送給邏輯處理引擎。邏輯處理引擎會本地存儲路由規(guī)則,正常的訪問流程在邏輯引擎本地查詢相關規(guī)則即可,無需訪問遠端的元數據管理模塊。結果集處理數據進行了分片并路由到指定后端存儲節(jié)點后,會在遠端的存儲節(jié)點執(zhí)行,并將數據返回給邏輯引擎,由于數據可能已經被水平拆分過,所以有可能會涉及到多個遠端的存儲節(jié)點,即多個遠端節(jié)點的數據需要進行結果集的匯總和再計算工作,比如orderby或者groupby等語句的執(zhí)行,需要在邏輯引擎中進行結果的緩存和計算工作,這部分邏輯集成在了邏輯引擎內部,對業(yè)務端是完全無感知的。數據擴容雖然我們可以按照業(yè)務類型預先對數據的容量和訪問量做好規(guī)劃并進行數據的水平切分和路由,但是通常我們預先規(guī)劃的容量是未必完全合適的,這個時候我們可能需要對數據進行再次水平切分進行擴容遷移等操作,這個過程需要統一接入管理平臺與邏輯引擎共同完成,邏輯引擎負責線上路由切換的一部分,并通過一些手段完成多個邏輯處理引擎節(jié)點之間的同步問題,保障數據的可靠性和一致性。備份管理備份管理主要保障數據的高可靠。數據的高可靠是通過系統后臺自動定時全量及增量備份數據到云存儲端來完成的。全量備份及增量備份的間隔時間通過管理系統可以靈活配置,全量備份采用快照機制不會對線上訪問造成任何影響,增量備份通過數據庫binlog完成。數據驅動層數據驅動層會對涉及的所有物理節(jié)點進行管理,能夠方便靈活的配置物理節(jié)點信息,動態(tài)增減機器規(guī)模。并對節(jié)點進行實時監(jiān)控和檢測,剔除故障節(jié)點,保障業(yè)務使用的穩(wěn)定性.故障切換故障切換模塊保障服務的高可用性,這是通過底層存儲數據庫的主備切換來完成,系統會監(jiān)控所有管理的數據庫實例,發(fā)現某個實例異?;蚬收虾?,會自動將訪問切換到從庫上,并通過數據庫的半同步機制來保障數據在切換過程中是完全沒有任何數據丟失的。協議適配由于海關業(yè)務可能會涉及不同種類的數據庫存儲節(jié)點,針對這種情況可以通過單獨的協議適配模塊進行協議的轉換。對上層業(yè)務使用標準SQL語句或者其它具體某種數據庫方言均可正常訪問。統一接入管理平臺統一接入管理平臺主要進行整體接入系統的一些管理工作,比如元數據的存儲,監(jiān)控檢測機制,自動化運維模塊等。配置數據管理配置數據管理主要存儲整體接入系統的一些配置信息,比如集群數據庫的一些參數組配置,安全組配置等信息,可以方便的完成集群中部分機器的一些特殊定制配置等需求,給整體系統帶來比較大的靈活型。應用系統管理應用系統管理模塊對接入的應用和業(yè)務進行統一管理。主要包括應用具體的一些接入信息配置,包括應用獨立的一些配置數據,注冊信息,訪問用戶權限和角色等。邏輯與物理節(jié)點管理統一管理模塊會對整個集群的所有物理節(jié)點和邏輯節(jié)點進行管理,物理節(jié)點涉及所有機器的配置信息,運行中的動態(tài)負載信息,狀態(tài)信息等。邏輯節(jié)點是暴露給業(yè)務使用的一些抽象的邏輯庫和邏輯表,并對此進行具體的邏輯到物理節(jié)點的映射工作。該模塊也是配合路由規(guī)則管理模塊協同工作的。路由規(guī)則管理路由規(guī)則即具體分片規(guī)則信息,該信息通過統一接入管理平臺來進行存儲和管理,并通過統一管理平臺與邏輯引擎進行交互。業(yè)務的路由規(guī)則錄入與變更首先會通過統一管理平臺的管理端界面進行錄入和修改,統一管理平臺會將變更信息推送給所有的邏輯引擎。并通過內部加鎖等機制完成各邏輯節(jié)點更新的一致性問題。擴容遷移管理擴容遷移功能是通過統一接入平臺來完成的和發(fā)起的,監(jiān)控系統會檢測所有物理節(jié)點的使用情況,包含數據量和訪問量的信息,根據系統當前負載情況判斷是否需要進行遷移和擴容工作。當需要進行此項工作時,統一平臺會發(fā)起遷移任務,遷移任務交由一個工作節(jié)點進行線下的物理數據遷移,待到達指定閾值時會通知邏輯引擎進行相關路由的鎖定與切換工作,完成遷移和擴容的過程。備份管理備份管理模塊會統一調度和進行所管理物理節(jié)點的數據全量備份與增量備份工作,具體備份的時間與間隔通過統一平臺的管理界面進行配置。全量備份通過操作系統的塊設備的快照機制完成,對業(yè)務訪問無任何感知和影響。增量備份通過數據庫的binlog來完成。所有備份文件統一上傳至統一存儲模塊。需要時可以完成快速恢復和容災。接入層節(jié)點的水平擴展與容災接入層本身單個節(jié)點可以提供每秒10W級的高性能訪問,可以根據業(yè)務訪問量的需求或者容災的考慮來動態(tài)增減節(jié)點,由于接入層節(jié)點是完全無狀態(tài)的所以動態(tài)增減并不會影響上面的應用,上面的應用可以通過類似LVS或者HA的方式來統一訪問接入層節(jié)點,HA軟件會自動對接入層節(jié)點進行狀態(tài)檢測,并剔除故障的接入層節(jié)點對上層應用無感知。加入新的接入節(jié)點對上層應用同樣是無感知的。存儲層存儲層主要解決下列問題:服務的高可用數據的高可靠自動化運維管理自動化運維平臺提供靈活方便的用戶管理操作入口,系統基本無需專人運維,大部分的工作是自動化的,一小部分工作通過人員確認一鍵完成。配置數據管理集群路由和分配以及擴容遷移等信息全部存儲在中心節(jié)點Manager中,所有路由變更等配置信息統一通過Manager來完成,Manager節(jié)點會自動同步路由變更信息給所有的接入節(jié)點,并保障接入節(jié)點對變更信息的一致性問題,即所有接入節(jié)點在任意時刻看到的路由信息都是完全一致的,Manager與接入節(jié)點之間通過路由版本號信息來保障這一點。元數據管理通過主備方式來進行容災,主節(jié)點故障,從節(jié)點自動接管工作,對應用完全無影響。數據無縫遷移擴容數據達到一定容量后,通過Transfer模塊可以進行自動無縫擴容和遷移工作,遷移模塊會分成線上和線下兩部分完成,首先進行線下的全量數據及部分增量數據的遷移,待線下數據遷移達到指定閾值后,會進行線上的最后一部分數據追趕及路由切換等工作,應用的訪問最終會自動被切換到新的實例上。遷移過程中會多次對數據進行校驗,保障數據遷移的準確性。分布式緩存分布式緩存出于如下考慮,首先是緩存本身的水平線性擴展問題,其次是緩存大并發(fā)下的本身的性能問題,再次避免緩存的單點故障問題(多副本和副本一致性)。分布式緩存的核心技術包括首先是內存本身的管理問題,包括了內存的分配,管理和回收機制。其次是分布式管理和分布式算法,其次是緩存鍵值管理和路由。技術架構支持數據類型提供如下形式的數據:Key/Value、Set、List、Map、Object數據之間支持排序和集合運算緩存服務主要包括可分為以下幾類:

1)頁面緩存

2)應用對象緩存3)狀態(tài)緩存4)分析計算緩存5)事務處理數據存儲總體描述本章描述對核心數據,非核心數據等各類不同種類數據的數據處理系統,以及數據存儲系統的架構實現。根據下列數據分類以及各類數據特點制定數據存儲的架構方式。圖4-6-1:各種分類維度下的數據分類技術實現按照不同數據分類下的數據特征(包括數據量,數據價值,以及結構化特征),使用不同的數據存儲架構實現數據這些數據的存儲和管理。圖4-6-2:各種數據存儲架構總覽核心數據存儲架構1)數據庫管理系統在采用Oracle11gRAC的基礎上,對需要加速的數據處理,通過內存數據庫技術融合,以提高系統對核心數據的處理性能。2)數據存儲系統磁盤陣列:采用SAS盤,支持RAID0.1.5.SAN交換機:采用FC協議,SAN采用8Gbps/4Gbps的帶寬。圖4-6-3:核心數據存儲架構表4-6-1SAN與NAS存儲服務的比較存儲層在修改一下,再細分層,各種技術之間的優(yōu)勢(比如SAN,NAS的選擇的分析比較)。非核心數據存儲架構1)數據庫管理系統采用MySqlCluster的開源集群數據庫處理技術。2)數據存儲系統磁盤陣列:采用SAS盤,支持RAID0.1.5.SAN交換機:采用FC協議,SAN采用8Gbps/4Gbps的帶寬。存儲技術:通過分層關系描述圖4-6-4:非核心數據存儲架構分析型數據存儲架構1)數據庫管理系統采用商用的MPP分布數據庫(如Gbase),和Hadoop開源并行數據處理平臺的混搭技術。2)數據存儲系統x86PC服務器上本地磁盤:采用SAS盤,支持24個磁盤(600G),RAID0.1.5.MPP網絡:采用基于萬兆以太網或Infiniband的高速網絡。圖4-6-5:分析數據存儲架構非結構化數據存儲架構1)數據庫管理系統采用基于Hadoop的開源并行數據處理平臺的非結構化數據存儲技術。2)數據存儲系統x86PC服務器上本地磁盤:采用SAS盤,支持24個磁盤(600G),RAID0.1.5.Hadoop網絡:采用基于萬兆以太網或Infiniband的高速網絡。圖4-6-6:非結構化數據存儲架構數據計算總體描述本章描述數據層面上的數據計算架構。從數據層,可以將數據計算分成實時性的流處理模型,和以MapReduce和OLAP多維分析計算為代表的批處理。批處理滿足非實時數據處理業(yè)務場景,將批量數據以任務的方式進行處理,并以異步方式提交計算結果,典型場景包括:數據挖掘模型計算、指標引擎計算、OLAP多維分析計算、MapReduce批處理等。數據挖掘模型計算,可以依靠傳統的自我編程實現,但受限于開發(fā)水平和開發(fā)時間要求,且性能也常常不如商業(yè)工具強勁和穩(wěn)定。目前在中國市場上最為流行的三大數據挖掘軟件(SAS公司的EnterpriseMiner、IBM公司的IntelligentMiner和SPSS公司的Clementine。在選擇合適的數據發(fā)掘工具產品時,需要考慮以下幾點:數據挖掘是短期使用還是長期行為,數據挖掘經驗和水平,數據狀態(tài),預算和性能要求。指標引擎計算與OLAP多維分析計算,可以通過關系型數據庫計算引擎,在庫內實現??紤]數據量級和計算性能,建議使用完全并行的MPP+SharedNothing架構數據庫產品,由許多松耦合的處理單元組成,以保證每一個節(jié)點(node)都是獨立的、自給的、節(jié)點之間對等,而且整個系統中不存在單點瓶頸,具有非常強的擴展性。技術要求:1、支持X86PCserver以及虛擬化環(huán)境運行,具有低成本優(yōu)勢;2、采用列存儲和高效透明壓縮技術,降低I/O,提高存儲能力;3、具有基于全部字段,自動建立粗粒度智能索引,快速過濾數據包,提高查詢性能;4、具有多種數據分布算法策略,確保數據均勻分布在集群節(jié)點上,提高整體批量計算性能;5、利用多核CPU,多個I/O通道等硬件資源,具有并行加載,并行計算與并行導出等場景的良好性能;6、具有多種OLAP函數,支持動態(tài)hashjoin,靜態(tài)hashjoin等智能算法適配功能,滿足強一致性關聯要求;圖SEQ圖\*ARABIC2靜態(tài)hashjoin技術圖SEQ圖\*ARABIC3動態(tài)hashjoin技術具有高并發(fā)特點,有效支撐自助查詢等大規(guī)模查詢服務和批量調度任務;8、具有線性擴展能力,硬件擴容與計算能力近似線性增長關系。MapReduce是一種編程模型,用于大規(guī)模數據集(大于1TB)的并行運算。概念"Map(映射)"和"Reduce(規(guī)約)",主要思想,都是從函數式編程語言里借來的,還有從矢量編程語言里借來的特性。當前的實現是指定一個Map(映射)函數,用來把一組鍵值對映射成一組新的鍵值對,指定并發(fā)的Reduce(規(guī)約)函數,用來保證所有映射的鍵值對中的每一個共享相同的鍵組。實現過程:一個代表客戶機在單個主系統上啟動的MapReduce應用程序稱為JobTracker。類似于NameNode,它是Hadoop集群中惟一負責控制MapReduce應用程序的系統。在應用程序提交之后,將提供包含在HDFS中的輸入和輸出目錄。JobTracker使用文件塊信息(物理量和位置)確定如何創(chuàng)建其他TaskTracker從屬任務。MapReduce應用程序被復制到每個出現輸入文件塊的節(jié)點。將為特定節(jié)點上的每個文件塊創(chuàng)建一個惟一的從屬任務。每個TaskTracker將狀態(tài)和完成信息報告給JobTracker。流式處理滿足實時處理業(yè)務場景,實現數據的實時,高效處理計算。典型產品包括:storm,S4,StreamBase等。非實時計算幾乎都基于MapReduce計算框架,但MapReduce并不是萬能的。對于搜索等應用環(huán)境中的某些現實問題,MapReduce并不能很好地解決問題。商用搜索引擎,像Google、Bing和Yahoo!等,通常在用戶查詢響應中提供結構化的Web結果,同時也插入基于流量的點擊付費模式的文本廣告。為了在頁面上最佳位置展現最相關的廣告,通過一些算法來動態(tài)估算給定上下文中一個廣告被點擊的可能性。上下文可能包括用戶偏好、地理位置、歷史查詢、歷史點擊等信息。一個主搜索引擎可能每秒鐘處理成千上萬次查詢,每個頁面都可能會包含多個廣告。為了及時處理用戶反饋,需要一個低延遲、可擴展、高可靠的處理引擎。然而,對于這些實時性要求很高的應用,盡管MapReduce作了實時性改進,但仍很難穩(wěn)定地滿足應用需求。因為Hadoop為批處理作了高度優(yōu)化,MapReduce系統典型地通過調度批量任務來操作靜態(tài)數據;而流式計算的典型范式之一是不確定數據速率的事件流流入系統,系統處理能力必須與事件流量匹配,或者通過近似算法等方法優(yōu)雅降級,通常稱為負載分流(load-shedding)。當然,除了負載分流,流式計算的容錯處理等機制也和批處理計算不盡相同。最近Facebook在Sigmod11上發(fā)表了利用HBase/Hadoop進行實時數據處理的論文,通過一些實時性改造,讓批處理計算平臺也具備實時計算的能力。這類基于MapReduce進行流式處理的方案有三個主要缺點。將輸入數據分隔成固定大小的片段,再由MapReduce平臺處理,缺點在于處理延遲與數據片段的長度、初始化處理任務的開銷成正比。小的分段會降低延遲,增加附加開銷,并且分段之間的依賴管理更加復雜(例如一個分段可能會需要前一個分段的信息);反之,大的分段會增加延遲。最優(yōu)的分段大小取決于具體應用。為了支持流式處理,MapReduce需要被改造成Pipeline的模式,而不是Reduce直接輸出;考慮到效率,中間結果最好只保存在內存中等。這些改動使得原有的MapReduce框架的復雜度大大增加,不利于系統的維護和擴展。用戶被迫使用MapReduce的接口來定義流式作業(yè),這使得用戶程序的可伸縮性降低。綜上所述,流式處理的模式決定了要和批處理使用非常不同的架構,試圖搭建一個既適合流式計算又適合批處理計算的通用平臺,結果可能會是一個高度復雜的系統,并且最終系統可能對兩種計算都不理想。數據分析系統整體組成示意圖上圖從整個分析系統的架構角度,給出了實時計算子系統所處的位置。實時計算系統和批處理計算系統同屬于計算這個大的范疇,批處理計算可以是MapReduce、MPI、SCOPE等,實時計算可以是S4、Storm等,批處理和實時都可以或不依賴統一的資源調度系統。另外,計算系統的輸入、輸出,包括中間過程的輸入、輸出,都與存儲系統交互,可以是塊存儲系統HDFS,也可以是K-V存儲系統Hypertable等。計算層的上層是數據倉庫,或者直接和用戶交互,交互方式可以是SQL-like或者MR-like等。StormStorm是一個分布式的、容錯的實時計算系統,遵循EclipsePublicLicense1.0,Storm可以方便地在一個計算機集群中編寫與擴展復雜的實時計算,Storm之于實時處理,就好比Hadoop之于批處理。Storm保證每個消息都會得到處理,而且它很快——在一個小集群中,每秒可以處理數以百萬計的消息。可以使用任意編程語言來做開發(fā)。

主要商業(yè)應用及案例:Twitter

Storm的優(yōu)點

1.簡單的編程模型。類似于MapReduce降低了并行批處理復雜性,Storm降低了進行實時處理的復雜性。

2.服務化,一個服務框架,支持熱部署,即時上線或下線App.

3.可以使用各種編程語言。你可以在Storm之上使用各種編程語言。默認支持Clojure、Java、Ruby和Python。要增加對其他語言的支持,只需實現一個簡單的Storm通信協議即可。

4.容錯性。Storm會管理工作進程和節(jié)點的故障。

5.水平擴展。計算是在多個線程、進程和服務器之間并行進行的。

6.可靠的消息處理。Storm保證每個消息至少能得到一次完整處理。任務失敗時,它會負責從消息源重試消息。

7.快速。系統的設計保證了消息能得到快速的處理,使用ZeroMQ作為其底層消息隊列。

8.本地模式。Storm有一個“本地模式”,可以在處理過程中完全模擬Storm集群。這讓你可以快速進行開發(fā)和單元測試。Storm架構Storm集群由一個主節(jié)點和多個工作節(jié)點組成。主節(jié)點運行了一個名為“Nimbus”的守護進程,用于分配代碼、布置任務及故障檢測。每個工作節(jié)點都運行了一個名為“Supervisor”的守護進程,用于監(jiān)聽工作,開始并終止工作進程。Nimbus和Supervisor都能快速失敗,而且是無狀態(tài)的,這樣一來它們就變得十分健壯,兩者的協調工作是由Zookeeper來完成的。ZooKeeper用于管理集群中的不同組件,ZeroMQ是內部消息系統,JZMQ是ZeroMQMQ的JavaBinding。有個名為storm-deploy的子項目,可以在AWS上一鍵部署Storm集群.Storm的一些常用應用場景1.流聚合

流聚合把兩個或者多個數據流聚合成一個數據流—基于一些共同的tuple字段。2.批處理

有時候為了性能或者一些別的原因,你可能想把一組tuple一起處理,而不是一個個單獨處理。3.BasicBolt

1).讀一個輸入tuple

2).根據這個輸入tuple發(fā)射一個或者多個tuple

3).在execute的方法的最后ack那個輸入tuple

遵循這類模式的bolt一般是函數或者是過濾器,這種模式太常見,storm為這類模式單獨封裝了一個接口:IbasicBolt4.內存內緩存+Fieldsgrouping組合

在bolt的內存里面緩存一些東西非常常見。緩存在和fieldsgrouping結合起來之后就更有用了。比如,你有一個bolt把短鏈接變成長鏈接(bit.ly,t.co之類的)。你可以把短鏈接到長鏈接的對應關系利用LRU算法緩存在內存里面以避免重復計算。比如組件一發(fā)射短鏈接,組件二把短鏈接轉化成長鏈接并緩存在內存里面。5.計算topN

比如你有一個bolt發(fā)射這樣的tuple:"value","count"并且你想一個bolt基于這些信息算出topN的tuple。最簡單的辦法是有一個bolt可以做一個全局的grouping的動作并且在內存里面保持這topN的值。

這個方式對于大數據量的流顯然是沒有擴展性的,因為所有的數據會被發(fā)到同一臺機器。一個更好的方法是在多臺機器上面并行的計算這個流每一部分的topN,然后再有一個bolt合并這些機器上面所算出來的topN以算出最后的topN。這個模式之所以可以成功是因為第一個bolt的fieldsgrouping使得這種并行算法在語義上是正確的。

用TimeCacheMap來高效地保存一個最近被更新的對象的緩存6.用TimeCacheMap來高效地保存一個最近被更新的對象的緩存

有時候你想在內存里面保存一些最近活躍的對象,以及那些不再活躍的對象。TimeCacheMap是一個非常高效的數據結構,它提供了一些callback函數使得我們在對象不再活躍的時候我們可以做一些事情.7.分布式RPC:CoordinatedBolt和KeyedFairBolt

用storm做分布式RPC應用的時候有兩種比較常見的模式:它們被封裝在CoordinatedBolt和KeyedFairBolt里面.CoordinatedBolt包裝你的bolt,并且確定什么時候你的bolt已經接收到所有的tuple,它主要使用DirectStream來做這個.

KeyedFairBolt同樣包裝你的bolt并且保證你的topology同時處理多個DRPC調用,而不是串行地一次只執(zhí)行一個。S4S4是一個通用的、分布式的、可擴展的、分區(qū)容錯的、可插拔的流式系統?;赟4框架,開發(fā)者可以輕松開發(fā)面向持續(xù)流數據處理的應用。S4的設計特點有以下幾個方面。ActorModel為了能在普通機型構成的集群上進行分布式處理,并且集群內部不使用共享內存,S4架構采用了Actor模式,這種模式提供了封裝和地址透明語義,因此在允許應用大規(guī)模并發(fā)的同時,也提供了簡單的編程接口。S4系統通過處理單元(ProcessingElements,PEs)進行計算,消息在處理單元間以數據事件的形式傳送,PE消費事件,發(fā)出一個或多個可能被其他PE處理的事件,或者直接發(fā)布結果。每個PE的狀態(tài)對于其他PE不可見,PE之間唯一的交互模式就是發(fā)出事件和消費事件。框架提供了路由事件到合適的PE和創(chuàng)建新PE實例的功能。S4的設計模式符合封裝和地址透明的特性。DecentralizedandSymmetricArchitecture除了遵循Actor模式,S4也參照了MapReduce模式。為了簡化部署和運維,從而達到更好地穩(wěn)定性和擴展性,S4采用了對等架構,集群中的所有處理節(jié)點都是等同的,沒有中心控制。這種架構將使得集群的擴展性很好,處理節(jié)點的總數理論上無上限;同時,S4將沒有單點容錯的問題。

PluggableArchitecture

S4系統使用Java開發(fā),采用了極富層次的模塊化編程,每個通用功能點都盡量抽象出來作為通用模塊,而且盡可能讓各模塊實現可定制化。PartialFault-Tolerance基于Zookeeper服務的集群管理層將會自動路由事件從失效節(jié)點到其他節(jié)點。除非顯式保存到持久性存儲,否則節(jié)點故障時,節(jié)點上處理事件的狀態(tài)會丟失。ObjectOriented節(jié)點間通信采用“PlainOldJavaObjects”(POJOs)模式,應用開發(fā)者不需要寫Schemas或用哈希表來在節(jié)點間發(fā)送Tuples。S4的功能組件分3大類,Clients、Adapters和PNodeCluster,圖2顯示了S4系統框架。

Yahoo!S4流式系統框架結構圖

S4提供ClientAdapter,允許第三方客戶端向S4集群發(fā)送事件和接收事件。Adapter實現了基于JSON的API,支持多語言實現的客戶端驅動。Client通過Driver組件與Adapter進行交互,Adapter也是一個Cluster,其中有多個Adapter結點,Client可以通過多個Driver與多個Adapter進行通信,這樣可以保證單個Client在分發(fā)大數據量時Adapter不會成為瓶頸,也可以確保系統支持多個Client應用并發(fā)執(zhí)行的快速、高效和可靠性。在Adapter中,真正與Client交互的是其Stub組件,該組件實現了管理Client與Adapter之間通過TCP/IP協議進行通信的功能。GenericJsonClientStub這個類支持將事件在Client與Adapter之間以JSON的形式轉換,從而支持更多種類型的Client應用。不同的Client可以配置不同的Stub來與Adapter進行通信,用戶可以定義自己的Stub來實現自己想要的業(yè)務邏輯,這樣也使得Client的行為更加多樣性、個性化。StreamBaseStreamBase是IBM開發(fā)的一款商業(yè)流式計算系統,在金融行業(yè)和政府部門使用,其本身是商業(yè)應用軟件,但提供了DevelopEdition。相對于付費使用的EnterpriseEdition,前者的功能更少,但這并不妨礙我們從外部使用和API接口來對StreamBase本身進行分析。StreamBase使用Java開發(fā),IDE是基于Eclipse進行二次開發(fā),功能非常強大。StreamBase也提供了相當多的Operator、Functor以及其他組件來幫助構建應用程序。用戶只需要通過IDE拖拉控件,然后關聯一下,設置好傳輸的Schema并且設置一下控件計算過程,就可以編譯出一個高效處理的流式應用程序了。同時,StreamBase還提供了類SQL語言來描述計算過程。

StreamBase組件交互圖

StreamBaseServer是節(jié)點上啟動的管理進程,它負責管理節(jié)點上Container的實例,每個Container通過Adapter獲得輸入,交給應用邏輯進行計算,然后通過Adapter進行輸出。各個Container相互連接,形成一個計算流圖。Adapter負責與異構輸入或輸出交互,源或目的地可能包括CSV文件、JDBC、JMS、Simulation(StreamBase提供的流產生模擬器)或用戶定制。

每個StreamBaseServer上面都會存在一個SytsemContainer,主要是產生系統監(jiān)控信息的流式數據。HAContainer用于容錯恢復,可以看出它實際包含兩個部分:Heartbeat和HAEvents,其中HeartBeat也是Tuple在Container之間傳輸。在HA方案下,HAContainer監(jiān)控PrimaryServer的活動情況,然后將這些信息轉換成為HAEvents交給StreamBaseMonitor來處理。Monitor就是從SystemContainer和HAContainer中獲取數據并且進行處理。StreamBase認為HA問題應該通過CEP方式處理,也就是說如果哪個部件出現問題,就肯定會反映在SystemContainer和HAContainer的輸出流上面,然后Monitor通過復雜事件處理這些Tuples的話就能夠檢測到機器故障等問題,并作出相應處理。StreamBase提出了以下4種模板策略來解決容錯問題。Hot-HotServerPairTemplatePrimaryServer和SecondaryServer都在同時計算,并且將計算結果交給下游。優(yōu)點是PrimaryServer如果故障的話那么SecondaryServer依然工作,幾乎沒有任何切換時間;并且下游只需要選取先到來的Tuple就可以處理了,保證處理速度最快;缺點是浪費計算和網絡資源。Hot-WarmServerPairTemplatePrimaryServer和SecondaryServer都在同時計算,但只有PrimaryServer將計算結果交給下游。優(yōu)點是如果PrimaryServer故障,SecondaryServer可以很快切換,而不需要任何恢復狀態(tài)的工作。相對于Hot-Hot方式時間稍微長一些,但沒有Hot-Hot那么耗費網絡資源,同時也浪費了計算資源。SharedDiskTemplatePrimaryServer在計算之后,將計算的一些中間關鍵狀態(tài)存儲到磁盤、SAN(StorageAreaNetwork)或是可靠的存儲介質。如果SrimaryServer故障,SecondaryServer會從介質中讀取出關鍵狀態(tài),然后接著繼續(xù)計算。優(yōu)點是沒有浪費任何計算和網路資源,但恢復時間依賴狀態(tài)的量級而定,相對于前兩種,恢復時間可能會稍長。FastRestartTemplate這種方案限定了應用場景,只針對無狀態(tài)的應用。對于無狀態(tài)的情況,方案可以非常簡單,只要發(fā)現PrimaryServer故障,SecondaryServer立即啟動,并接著上游的數據流繼續(xù)計算即可。BorealisBorealis是BrandeisUniversity、BrownUniversity和MIT合作開發(fā)的一個分布式流式系統,由之前的流式系統Aurora、Medusa演化而來。目前Borealis系統已經停止維護,最新的Release版本停止在2008年。Borealis具有豐富的論文、完整的用戶/開發(fā)者文檔,系統是C++實現的,運行于x86-basedLinux平臺。系統是開源的,同時使用了較多的第三方開源組件,包括用于查詢語言翻譯的ANTLR、C++的網絡編程框架庫NMSTL等。Borealis系統的流式模型和其他流式系統基本一致:接受多元的數據流和輸出,為了容錯,采用確定性計算,對于容錯性要求高的系統,會對輸入流使用算子進行定序。Borealis的系統架構圖QueryProcessor(QP)是計算執(zhí)行的地方,是系統的核心部件,其大部分功能繼承自Aurora。I/OQueues將數據流導入QP,路由Tuples到其他節(jié)點或客戶端程序。Admin模塊用來控制本地的QP,例如建立查詢、遷移數據流圖片段,該模塊也會同LocalOptimizer協作優(yōu)化現有數據流圖。LocalOptimizer職責包括本地調度策略、調整Operator行為、超載后丟棄低價值元組等。StorageManager模塊用于存儲本地計算的狀態(tài)數據。LocalCatalog存儲本地數據流圖和元數據,可以被本地所有組件訪問。BorealisNode還有彼此通信的模塊用于執(zhí)行協作任務。NeighborhoodOptimizer使用本地和鄰居節(jié)點來優(yōu)化節(jié)點間的負載均衡或shedload。HighAvailability(HA)模塊相互監(jiān)測,發(fā)現對方故障時及時代替對方。LocalMonitor收集本地性能相關統計數字報告給本地和NeighborhoodOptimizer。GlobalCatalog為整個數據流計算提供了一個邏輯上的完整視圖。除作為基本功能節(jié)點外,BorealisServer也可以被設計成一個協作節(jié)點來執(zhí)行全局的系統監(jiān)控和其他優(yōu)化任務,比如全局的負載分布和GlobalLoadShedding,因此Borealis實際上提供了完整的3級監(jiān)控和優(yōu)化(Local、Neighborhood、Global)。負載均衡方面,Borealis提供了動態(tài)和靜態(tài)兩種部署機制。Correlation-basedOperatorDistribution通過分析不同Operators和Nodes間的負載變化的關系,決定和動態(tài)調整Operatpr的部署,使之達到負載均衡。ResilientOperatorDistributionAlgorithm該算法的目標是提供一種靜態(tài)的Operator部署方案,該方案能夠在不需要重新調整的情況下處理最大可能的輸入速度變化范圍。由于動態(tài)調整需要時間和消耗,前者適用于負載變化持續(xù)時間較長的系統;而后者則能處理較快較短的負載峰值。在實現上前者使用相關系數作為節(jié)點關聯度指標,并通過貪婪算法將NP問題轉化為多項式求解;而后者在部署前計算完畢,保證系統能夠容忍負載峰值。該算法在線性代數上建模,包括OperatorOrdering、OperatorAssignment兩個階段。Borealis通過四種容錯機制來滿足用戶需求。AmnesiaBackup備機發(fā)現主機故障,立即從一個空的狀態(tài)開始重做。PassiveStandby主機處理,備機待命,主機按周期做Checkpoint,主機故障后切換到備機,重放Checkpoint和數據流,對于不確定性計算可以很好地支持,缺點是恢復時間較長。ActiveStandby主備機同時計算,主機故障時直接切換到備機,不支持不確定性計算,浪費計算資源,不過恢復時間幾乎沒有。UpstreamBackup通過上游備份來容錯,故障時從上游重放數據即可,恢復時間最長,不過最節(jié)省資源。除此之外,Borealis還提供了更高級的容錯機制RollbackRecovery,它是一種基于副本在節(jié)點失效、網絡失效或網絡分區(qū)時的故障恢復機制,在盡量減少系統不一致的情況下,盡可能地保證系統的可用性。該機制允許用戶定義一個閾值來在一致性和可用性之間做一個平衡。當系統數據恢復后,系統支持重新計算輸出正確的結果,保證最終一致性。該機制使用了Data-serializingOperator(SUnion)來確保所有的副本處理同樣順序的數據。當失效恢復后,通過Checkpoint/Redo、Undo/Redo來實現恢復重放。小結 stormYahoo!S4的最新版本是Alphaversionv0.3.0,動態(tài)負載均衡和在線服務遷移等重要功能都尚未實現,不過其代表性的3個特點值得學習,Actor模式、非中心化的對稱結構及可插入式的架構。StreamBase是有著功能強大的IDE并且支持控件式的方法來搭建應用程序,同時還提供了高級語言來搭建應用程序的方法。由于是商業(yè)產品,其用戶接口的精彩設計值得借鑒,同時其可組合的HA方案也是亮點之一。

Borealis是學術界研究的重要產出,它對新一代的流式系統涉及的諸多方面,如系數據模型、負載管理、高可用性、可擴展性都作了全面和翔實的研究,一方面系統變得強大、先進,另一方面使得系統也變得臃腫、復雜。這套系統的許多策略都值得我們學習,可以應用于不同的流式計算場景。數據服務總體描述數據服務主要解決將企業(yè)的資源信息共享出來,能夠為企業(yè)服務,但是企業(yè)信息多樣化,某一個團隊很難理解企業(yè)所有的業(yè)務信息,因此數據服務平臺提供一個開放的開發(fā)服務平臺,用戶可以在數據服務平臺創(chuàng)建相關的主題域,做與其業(yè)務相關的主題分析而無需平臺的運維和開發(fā)人員參與。本平臺主要有數據服務層、平臺服務層和數據接入層。數據服務層主要是對外提供數據服務;平臺服務層提供對元數據的管理、數據的開發(fā)和數據服務的接口的實現;底層接口層因數據平臺本身不產生原始數據,原始數據來源于數據計算模塊,將數據計算的結果導入到數據平臺,數據平臺在此數據做相關的分析之后提供給用戶,或者用戶直接在此平臺做數據的開發(fā)分析。數據訪問接口目前對外提供的數據服務的方式主要有兩類:圖形表格的方式接口API的方式兩類方式服務接口針對不同的用戶使用需求,對同一份數據使用者可以通過API的方式獲取數據或者通過圖表的方式直接將相關的圖表信息嵌入到應用之中。數據服務管理數據管理數據字典可以根據表名、字段名、表描述、字段描述快速定位到表,便于查看數據表信息,支持模糊查詢。數據申請可以通過這個頁面對數據主題進行申請,需要填寫相關的申請目的、理由,并可以上傳PRD、MRD。目前對上傳文件格式限制是:doc,docx,ppt,pptx。同一時間,只允許提交一個申請,需要等待審核完成后(不論是否通過)才能進行下一次的申請。申請?zhí)峤煌戤吅?,運營人員在管理平臺,進行審核,確定是否開放權限,給予審核意見。數據開發(fā)數據集市中的內容多樣化,內容從業(yè)務的角度來說是多樣的,不同的主題域有不同的分析方法和分析手段。因此在基于各個業(yè)務會有相應的分析模型。數據開發(fā)為不同的業(yè)務分析員提供了通用的分析平臺。因此需要對開發(fā)的平臺程序進行管理。本章節(jié)主要介紹:目錄管理、程序管理、數據庫表管理。目錄管理當用戶登錄平臺之后,進入數據開發(fā)模塊,用戶需要在該平臺開發(fā)程序,首先要在平臺能夠管理自己的程序,因此在本模塊提供了類似操作系統管理其文件的方式來管理用戶程序。在目錄管理功能部分,提供用戶能夠創(chuàng)建目錄、修改目錄名稱、刪除目錄和移動目錄的功能。創(chuàng)建目錄是在目錄結構中增加一個新目錄。當用戶登錄系統之后,用戶希望在哪里創(chuàng)建目錄,選擇進入某個目錄,在該目錄下用戶可以創(chuàng)建新的目錄,當前目錄與創(chuàng)建的新目錄是父子關系,創(chuàng)建目錄包括目錄的名稱。修改目錄是修改某一目錄的名稱。當用戶登錄系統之后,用戶希望休改哪個目錄名稱,選擇要修改的目錄之后,可以直接修改。修改目錄僅僅修改目錄的名稱,其父目錄和包含的子目錄、文件與其關系不變。刪除目錄是刪除一個空的用戶目錄。當用戶登錄系統之后,用戶選擇希望刪除的目錄,可以進行刪除目錄操作。待刪除的目錄不能包含有文件或者子目錄,否則不允許刪除,把待刪除目錄包含的子目錄和文件移動到別的目錄下之后才能進行刪除操作。目錄移動是將一個源目錄移動到一個目標目錄。當用戶登錄系統之后,用戶選擇希望移動的源目錄和目標目錄之后,用進行移動目錄操作,用戶將源目錄下的所有的子目錄和文件都移動到目標目錄上。程序管理因為數據服務本身能夠提供的數據功能是有限的,或者說只是能夠提供一些很通用的功能,更多的業(yè)務相關的功能需要業(yè)務開發(fā)人員來開發(fā)。因此,數據服務更多的是提供一個開放的平臺,允許用戶在該平臺做相應的主題域的數據開發(fā)來滿足業(yè)務的需要。程序管理主要包含程序創(chuàng)建、程序刪除、程序內容修改、程序名稱修改、程序文件移動和程序試運行等方面在創(chuàng)建管理和試運行改程序。程序創(chuàng)建程序創(chuàng)建是用戶根據業(yè)務的要求,創(chuàng)建某個業(yè)務主題的程序,提取與其業(yè)務相關的數據。用戶登錄系統之后,用戶可以選擇某個目錄,當用戶確定要在該目錄下創(chuàng)建程序之后,用戶可以操作創(chuàng)建程序,用戶可以輸入程序的名稱和一個可以編輯程序的數據輸入框,創(chuàng)建的程序一般為比較簡單的腳本,比如:SQL腳本、groovy腳本和R語言腳本。當用戶編輯完腳本之后,保存即完成用戶程序的開發(fā)。程序刪除程序刪除是刪除用戶已經開發(fā)好的程序,一般程序發(fā)布之后就不能刪除了,發(fā)布作為一種契約,一旦發(fā)布成功,就同意對外提供服務了。用戶登錄系統之后,找到希望刪除的程序,進行刪除操作即可以。程序內容修改程序內容修改是因為程序在運行的過程中有bug或者是業(yè)務的變更,要求程序做相應的修改來滿足業(yè)務的要求。用戶登錄系統之后,選擇某個程序之后,用戶即可以對程序進行修改,修改完成之后保存即可。用戶對同一程序內容的修改次數是多次的。程序名稱修改程序名稱修改是修改程序的名稱,在程序開發(fā)的時候給程序起名,但是在后來的業(yè)務討論的過程中發(fā)現該程序名并不能準確的表達該程序實際的功能,因此需要修改該程序名稱。當用戶登錄到該平臺之后,找到要修改的程序之后,可以直接修改其名稱。在同一個目錄下不能有相同的文件名稱。程序文件移動程序文件移動是為了程序管理的方便,程序文件能夠移動到不通的目錄下。當用戶登錄到平臺之后,用戶選著要移動的文件然后將其移動到目標目錄上即可。程序執(zhí)行是程序開發(fā)完成之后,可以隨時執(zhí)行,但是這個執(zhí)行需要人工觸發(fā)才能執(zhí)行。當用戶登錄到平臺之后,用戶選擇其要執(zhí)行的文件,觸發(fā)該文件的執(zhí)行操作即可。數據表管理數據表在整個數據服務平臺中為用戶提供一個自己建模的工具,為用戶

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論