1、提綱背景需求分析背景 各高校建成的信息管理系統越來越多，海量數據背后隱藏著許多重要信息，是學校正常運轉的核心資源，以靈活便捷的方式對數據進行統計、分析，進而為高校管理與決策提供支持的需求日益強烈背景 商業智能(BI, business intelligence) Gartner Group, Howard Dresner, 1996：一類由數據倉庫(或數據集市)、查詢報表、數據分析、數據挖掘、數據備份和恢復等局部組成，以幫助企業決策為目的的技術及其應用。背景 微軟的BI體系框架背景 IBM的BI體系框架背景 建立BI系統的根本步驟包括： 確認和解讀數據源； 進行數據采集和存儲管理； 構建模型并

2、在此根底上分析數據背景 商業智能的根底是數據倉庫(DW , Data Warehouse) 數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合。 數據倉庫為有效地為BI系統提供了全局一致的數據環境，也為歷史數據綜合數據的處理提出了一種行之有效的解決方法。背景 國外:BI應用已經進入了數據分析階段，有些已經積累了高端的數據挖掘經驗； 國內:BI的應用那么還停留在數據整合的初級階段，應用的主要領域集中在電信、保險、銷售等行業， 國內高校的情況不容樂觀： 數據分散在不同的源系統中，數據的標準性和共享性還存在很大問題； 數據統計和分析根本上是基于單個系統中的操作型數據進行的，既不能反

3、映出不同系統之間的數據關聯，又缺乏對數據的全局把握；還會因為操作型數據的動態性和分散性影響統計結果的準確性，也無法對歷史數據進行統計和分析。背景 要建立高校的BI應用，滿足為高校管理與決策提供支持的需求，首先必須打破不同應用系統之間的“藩籬，建立全局一致的數據倉庫，將操作型數據轉換為靜態的、穩定的、標準化的、能夠反映歷史的分析型數據，然后在此根底上搭建統一的數據統計效勞平臺。需求分析 數據統計需求按用途不同分為2類： 一是以年報表或者季度報表的形式上報上級部門的統計數據，有著固定的報表格式、復雜的報表內容、專門的統計口徑，有的報表甚至還有嚴格的填報流程； 二是部門日常所需要統計數據，往往和某種

4、類型具體業務相關，和第一類需求相比，統計數據的格式和內容比較簡單，沒有復雜的填報流程，但時間粒度要求更細，要以月報表、周報表乃至日報表的形式提供統計結果，并且要求提供數據鉆取的功能。需求分析 這些需要統計的數據涉及高校人事、學生、科研、教學等各個領域，每個領域下面又細分為了很多不同的細類，具體如圖1所示。平臺設計 總體架構 數據倉庫建模 統計數據模型總體架構 高校數據統計效勞平臺由源系統、數據倉庫和統計平臺三部分組成。總體架構 源系統：高校業務涉及的數據源比較廣泛，主要有人事系統、教務系統、研究生系統、科研系統等，再加上校園網之外的一些其他外部數據源，構成了數據統計效勞平臺的數據根底，由于系統

5、業務職能和具體需求不同，在實現時會選用不同的數據庫，數據結構也可能存在較大差異，從而導致數據間有較大的異構性和不一致性。總體架構 數據倉庫：數據倉庫全面接收源系統數據，ETL進程對數據進行標準化、驗證、清洗，并最終裝載進入數據集市，通過數據集市支持系統進行數據查詢、分析；整個數據倉庫包含四大層次： 復制層(SSA, system-of-records-staging-area) 原子層(SOR, system-of-record) 匯總層(SMA, summary-area) 集市層(DM, data mart)總體架構 復制層(SSA, system-of-records-staging-a

6、rea)：直接復制源系統的數據，盡量保持業務數據的原貌；與源系統數據唯一不同的是，復制層中的數據在源系統數據的根底上參加了時間戳的信息，形成了多個版本的歷史數據信息； 原子層(SOR, system-of-record)：基于模型開發的一套符合3NF范式規那么的表結構，它存儲了數據倉庫內最細層次的數據，并按照不同的主題域對數據分類存儲；根據目前局部需求，將全校數據在原子層中按人事、學生、教學、科研四大主題存儲；原子層是整個數據倉庫的核心和根底，在設計過程中應具有足夠的靈活性，以能應對添加更多的數據源、支持更多的分析需求，同時能夠支持進一步的升級和更新；總體架構 匯總層(SMA, summary

7、-area)：匯總層是原子層和集市層的中間過渡，由于原子層的數據是高度標準化數據，因此要完成一個查詢需要大量的關聯工作，同時集市層中的數據粒度往往要比原子層高很多，對要生成集市層中的匯總數據需要進行大量的匯總工作，因此，匯總層根據需求把原子層數據進行適度的反范例如，設計寬表結構將人員信息、干部信息等多個表的數據合并起來和匯總例如，一些常用的人頭匯總、機構匯總等；從而提高數據倉庫查詢的性能。總體架構 集市層(DM, data mart)：集市層保存的數據是供用戶直接訪問的；可以將集市層理解成最終用戶直接最終想要看的數據；集市層主要是各類粒度的事實數據，通過提供不同粒度的數據，適應不同的數據訪問需

8、求；集市層中的數據以2種不同類型存儲：一類以星型模型建設，便于部門日常的靈活查詢和統計，另一類按寬表以及重新組織的適應固定報表的表結構存儲，便于高校的年統和季度統計工作。總體架構 統計平臺：高校數據統計效勞平臺采用B/S架構的3層體系結構，即：數據操作層、邏輯層、表示層。 數據操作層 邏輯層 表示層總體架構 數據操作層：充分考慮系統的高可用性，數據統計效勞平臺與數據倉庫所使用的數據庫互相獨立，由此保證數據統計效勞平臺對數據進行加工處理時不會影響數據倉庫中的數據；數據存取模塊實現對數據統計效勞平臺數據的訪問。總體架構 邏輯層：分為報表預定義、報表查詢、報表生成、報表填報、報表審核及報表匯總等模塊

9、；每個模塊分別實現不同的功能；在統計平臺中，不同身份的用戶其功能權限和數據權限是不一樣的：報表預定義是給系統管理員用的；報表生成、報表填報是給院系管理人員使用的，只能查看和操作本院系的數據；報表審核、報表匯總是給學校相關部門的管理人員用的，可以操作全校數據；功能權限和數據權限通過公用層與身份認證效勞平臺對接，統一進行管理總體架構 表示層：提供交互界面給用戶使用，此外還提供一些效勞接口供其他系統調用數據倉庫建模 目前較為流行的數據倉庫的建模方法較多，常用的有Inmon所提倡的范式建模法和Kimball所提倡的維度建模法。數據倉庫建模 維度建模法針對各個維做了大量的預處理，通過這些預處理能夠極大地

10、提升數據倉庫的處理能力，相對于范式建模法來說，在性能上占據了明顯的優勢；同時維度建模非常直觀，緊緊圍繞著業務模型，可以直觀地反映出業務模型中的業務問題。不需要經過特別的抽象處理即可以完成維度建模。因此高校數據統計效勞平臺的數據倉庫采取維度建模的方式構建。 維度建模法采用事實表維表的方式來構建數據倉庫，數據集市、事實表存儲實際的數據，維表存儲事實表中對象的屬性，事實表和維表的關聯關系常用的是“星型模型。數據倉庫建模 維度建模的步驟 結合具體需求確定分析主題，結合高校主要業務定義了一個公共維度主題和人事、學生、教學、科研4個業務主題：公共維度包含時間維、地理維、國標及校標，時間維和地理維在不同的應

11、用場景可以使用視圖形式轉換為具體的分析維度，國標和校標主要用來解決在數據集成過程中的一致性問題；人事主題核心內容是教師的根本情況，具體分析主體有收入、崗位、職稱以及杰出人才等；學生主題核心內容是在校生根本情況，具體分析主題有招生、成績、獎懲、異動、就業等；科研主題主要分析全校師生科研成果完成情況，根據實際業務可以納入所有科研成果，如工程、論文、著作、專利、學術活動等；教學主題以教學活動相關內容為主，如課程方案、教學任務、選課、教學工作量等。數據倉庫建模 確定分析粒度，通俗地說就是分析對象的詳細程度。為了滿足分析的可擴展性及需求的多樣性，以最小粒度來設計數據模型總是能到達最好的分析效果，如：記錄

12、每個學生的明細情況、記錄每項科研成果的詳細情況。數據倉庫建模 設計維表，維度是統計和分析數據的角度，與統計查詢的參數相對應。在選取維度時應該將實體作為一個對象，把與該對象相關的所有重要屬性都提取出來作為獨立維度。數據倉庫建模 設計事實表，為了跟蹤具有生命周期的活動數據的變化過程以保存歷史信息，設計事實表時使用緩慢變化維的方法以捕獲變化數據。事實表中的版本、開始時間和結束時間3個字段是實現緩慢變化的核心。版本表示同一事物歷史狀態的順序，開始時間和結束時間表示在該段時間內該事物處于某一狀態，每一條數據的結束時間等于新數據的開始時間，這樣該事物不同時間段的狀態就分布在一條時間軸上，從而可以得到任一時

13、間點該事物的狀態信息數據倉庫建模統計數據模型 確定統計相關的星型模型，即數據統計針對的是事實表中間的那些事實，涉及到哪些統計指標，統計的粒度如何。 確定報表中具體的每一行和每一列分別代表的統計指標，統計指標簡單地說即維度取值，每個統計指標對應到維表中是某個維度取某個值，也有可能是多個維度取值的累加。 確定單元格的統計方法，每個單元格的統計指標應該是其對應的行、列所代表的維度取值的并集。 將維度轉化為可執行查詢的語句，去事實表中查詢出相應的統計數據和事實數據，為了方便，在數據統計效勞平臺的報表數據庫中還可以將查詢到的統計結果固化，以數據庫表的形式存儲下來。統計數據模型 將1張業務報表拆分為5張配

14、置表，它們分別是指標表、維表、維值表、行列表、指標維度組合表；最后計算得到的結果存儲在指標數據表中。平臺實現 ETL處理 前臺展示ETL處理 ETL(extraction-transformation-loading)負責將分散的、異構數據源中的數據抽取到臨時中間層后進行清洗、轉換、集成，最后加載到數據倉庫或數據集市中。ETL是實施數據倉庫的核心和靈魂，ETL規那么的設計和實施約占整個數據倉庫搭建工作量的60%80%。ETL處理 數據抽取 包括初始化數據裝載和數據刷新：初始化數據裝載主要關注的是如何建立維表、事實表，并把相應的數據放到這些數據表中，在數據倉庫建模小節中已經做了詳細介紹；而數據刷

15、新關注的是當源數據發生變化時如何對數據倉庫中的相應數據進行追加和更新等維護ETL處理 觸發器方式又稱為快照式來實現數據刷新，具體來說就是：在SSA層需要抽取數據的數據表上建立了插入、修改、刪除3個觸發器trigger，每當源數據庫中數據表中的數據發生變化時，復制到SSA的數據也會相應發生改變，相應的觸發器將變化的數據寫入一個臨時區buffer；在數據庫層定義了一系列的作業job和存儲過程procedure：作業規定了包括數據刷新頻率和數據刷新先后次序在內的一系列任務調度策略，調用相應的存儲過程從臨時表中抽取需要刷新的數據，臨時表中抽取過的數據被標記或刪除； 觸發器方式的好處是：數據抽取的性能高

16、、規那么簡單，對于編程人員來說易于上手，特別適合北京大學數據倉庫現有規模還較小的特點，是一種簡單易行的好方法；但隨著以后數據倉庫規模的越來越大，數據表越來越多，需要編寫的觸發器、存儲過程和作業就越來越多，可能會不利于管理ETL處理 數據清洗 主要是針對源數據庫中出現的二義性、重復、不完整、違反業務或邏輯規那么等問題的數據進行統一的處理，下表列出了北京大學在對業務系統進行數據清洗時發現的幾類最常見的問題及針對這些問題所采取的策略。ETL處理 數據轉換 主要是為了將數據清洗后的數據轉換成數據倉庫所需要的數據：來源于不同源系統的同一數據字段的數據字典或者數據格式可能不一樣，在數據倉庫中需要給它們提供

17、統一的數據字典和格式，對數據內容進行歸一化；另一方面，數據倉庫所需要的某些字段的內容可能是源系統所不具備的，而是需要根據源系統中多個字段的內容共同確定； 例如，數據倉庫中的人員類型“事業單位專業技術人員實際上是根據人事表中“編制類型=事業單位、“崗位級別=985并且“人員類別=在職職工等多個字段的內容共同得出的，像這樣字段的形成也依賴于數據轉換ETL處理 考察的工具 ColverETL:開源ETL工具，免費版本支持的連接組件太少Pass Kettle: 功能完善，組件齊全的處理平臺 Talend: 功能完善，組件齊全的處理平臺 Jitterbit: ETL工具，但是功能比較簡單，維護、日志、監

18、控等功能缺乏 Apatar: ETL工具，非效勞器結構，適合單機版本開發小的ETL程序 OpenDigger：ETL工具，非圖形化接口 Spring batch：主要用于實現調度平臺，配置方法和spring工具ETL處理ETL處理 Kettle優勢LGPL License限制較為寬松免費的Repository使得版本管理和代碼遷移非常容易任務調度支持定時,時間和命令支持Job DuplicationETL處理 Talend優勢 接口支持非常豐富，包括：各種數據庫，文件(Excel CSVJason XML Mail等)，外圍系統(SAP,CRM,FTP,SCP,JMS等)，網絡(WS,Socket,RPC,RSS,SOAP等)，流(Buffer, Row) 有假設干高性能組件如：外排序，批量插入(如SQLLoader) 結構簡單，只發布jar包前臺展示 常見的數據倉庫的前端展示工具有BO、Cognos等，能基