1. 數據倉庫技術的特點
數據倉庫最根本的特點是物理地存放數據，而且這些數據並不是最新的、專有的，而是來源於其它資料庫的。數據倉庫的建立並不是要取代資料庫，它要建立在一個較全面和完善的信息應用的基礎上，用於支持高層決策分析，而事務處理資料庫族明臘在企業的信息環境中承擔的是日常操作性的任務。數據倉庫是資料庫技術的一種新的應用，而且到槐慎目前為止，數據倉庫還是用關系資料庫管理系統來管理其中的兆滑數據。
2. 結合pki技術原理，闡述網上銀行系統如何保障信息傳輸的機密性和不可否認性
一、引言 隨著網路的發展，網路信息的安全越來越引起世界各國的重視，防病毒產品、防火牆、入侵檢測、漏洞掃描等安全產品都得到了廣泛的應用，但是這些信息安全產品都是為了防禦外部的入侵和竊取。隨著對網路安全的認識和技術的發展，發現由於內部人員造成的泄密或入侵事件佔了很大的比例，所以防止內部的非法違規行為應該與抵培猜御外部吵純的入侵同樣地受到重視，要做到這點就需要在網路中實現對網路資源的使用進行審計。 在當今的網路中各種審計系統已經有了初步的應用，例如：資料庫審計、應用程序審計以及網路信息審計等，但是，隨著網路規模的不斷擴大，功能相對單一的審計產品有一定的局限性，並且對審計信息的綜合分析和綜合管理能力遠遠不夠。功能完整、管理統一，跨地區、跨網段、集中管理才是綜合審計系統最終的發展目標。 本文對涉密信息系統中安全審計系統的概念、內容、實現原理、存在的問題、以及今後的發展方向做出了討論。 二、什麼是安全審計 國內通常對計算機信息安全的認識是要保證計算機信息系統中信息的機密性、完整性、可控性、可用性和不可否認性(抗抵賴)，簡稱「五性」。安全審計是這「五性」的重要保障之一，它對計算機信息系統中的所有網路資源(包括資料庫、主機、操作系統、安全設備等)進行安全審計，記錄所有發生的事件，提供給系統管理員作為系統維護以及安全防範的依據。安全審計如同銀行的監控系統，不論是什麼人進出銀行，都進行如實登記，並且每個人在銀行中的行動，乃至一個茶杯的挪動都被如實的記錄，一旦有突發事件可以快速的查閱進出記錄和行為記錄，確定問題所在，以便採取相應的處理措施。 近幾年，涉密系統規模不斷擴大，系統中使用的設備也逐漸增多，每種設備都帶有自己的審計模塊，另外還有專門針對某一種網路應用設計的審計系統，如：操作系統的審計、資料庫審計系統、網路安全審計系統、應用程序審計系統等，但是都無法做到對計算機信息系統全面的安全審計，另外審計數據格式不統一、審計分析規則無法統一定製也給系統的全面綜合審計造成了一定的困難。如果在當前的系統條件下希望全面掌握信息系統的運行情況，就需要對每種設備的審計模塊熟練操作，並且結合多種專用審計產品才能夠做到。 為了能夠方便地對整個計算機信息系統進行審計，就需要設計綜合的安全審計系統。它的目標是通過數據挖掘和數據倉庫等技術，實現在不同網路環境中對網路設備、終端、數據資源等進行監控和管理，在必要時通過多種途徑向管理員發出警告或自動採取排錯措施，並且能夠對歷史審計數據進行分析、處理和追蹤。主要作用有以下幾個方面： 1. 對潛在的攻擊者起到震懾和警告的作用; 2. 對於已經發生的系統破壞行為提供有效的追究證據; 3. 為系統管理員提供有價值的系統使用日誌，從而幫助系統管理員及時發現系統入侵行為或潛在的系統漏洞; 4. 為系統管理員提供系統的統計日誌，使系統管理員能夠發現系統性能上的不足或需要改進和加強的地方。 三、涉密信息系統安全審計包括的內容 《中華人民共和國計算機信息系統安全保護條例》中定義的計算機信息系統，是指由計算機及其相關的和配套的設備、設施(含網路)構成的，按照一定的應用目標和規則對信息進行採集、加配碰型工、存儲、傳輸、檢索等處理的人機系統。涉密計算機信息系統(以下簡稱「涉密信息系統」)在《計算機信息系統保密管理暫行規定》中定義為：採集、存儲、處理、傳遞、輸出國家秘密信息的計算機信息系統。所以針對涉密信息系統的安全審計的內容就應該針對涉密信息系統的每一個方面，應該對計算機及其相關的和配套的設備、設施(含網路)，以及對信息的採集、加工、存儲、傳輸和檢索等方面進行審計。 具體來說，應該對一個涉密信息系統中的以下內容進行安全審計： 被審計資源安全審計內容 網路通信系統網路流量中典型協議分析、識別、判斷和記錄，Telnet、HTTP、Email、FTP、網上聊天、文件共享等的檢測，流量監測以及對異常流量的識別和報警、網路設備運行的監測等。 重要伺服器主機操作系統系統啟動、運行情況，管理員登錄、操作情況，系統配置更改(如注冊表、配置文件、用戶系統等)以及病毒或蠕蟲感染、資源消耗情況的審計，硬碟、CPU、內存、網路負載、進程、操作系統安全日誌、系統內部事件、對重要文件的訪問等。 重要伺服器主機應用平台軟體重要應用平台進程的運行、Web Server、Mail Server、Lotus、Exchange Server、中間件系統、健康狀況(響應時間等)等。 重要資料庫操作資料庫進程運轉情況、繞過應用軟體直接操作資料庫的違規訪問行為、對資料庫配置的更改、數據備份操作和其他維護管理操作、對重要數據的訪問和更改、數據完整性等的審計。 重要應用系統辦公自動化系統、公文流轉和操作、網頁完整性、相關業務系統(包括業務系統正常運轉情況、用戶開設/中止等重要操作、授權更改操作、數據提交/處理/訪問/發布操作、業務流程等內容)等。 重要網路區域的客戶機病毒感染情況、通過網路進行的文件共享操作、文件拷貝/列印操作、通過Modem擅自連接外網的情況、非業務異常軟體的安裝和運行等的審計 四、安全審計系統使用的關鍵技術 根據在涉密信息系統中要進行安全審計的內容，我們可以從技術上分為以下幾個模塊： 1.網路審計模塊：主要負責網路通信系統的審計; 2.操作系統審計模塊：主要負責對重要伺服器主機操作系統的審計; 3.資料庫審計模塊：主要負責對重要資料庫操作的審計; 4.主機審計模塊：主要負責對網路重要區域的客戶機進行審計; 5.應用審計模塊：主要負責重要伺服器主機的應用平台軟體，以及重要應用系統進行審計。 還需要配備一個資料庫系統，負責以上審計模塊生成的審計數據的存儲、檢索、數據分析等操作，另外，還需要設計一個統一管理平台模塊，負責接收各審計模塊發送的審計數據，存入資料庫，以及向審計模塊發布審計規則。如下圖所示： 安全審計系統中應解決如下的關鍵技術： 1.網路監聽： 是安全審計的基礎技術之一。它應用於網路審計模塊，安裝在網路通信系統的數據匯聚點，通過抓取網路數據包進行典型協議分析、識別、判斷和記錄，Telnet、HTTP、Email、FTP、網上聊天、文件共享等的檢測，流量監測以及對異常流量的識別和報警、網路設備運行的監測等，另外也可以進行資料庫網路操作的審計。 2.內核驅動技術： 是主機審計模塊、操作系統審計模塊的核心技術，它可以做到和操作系統的無縫連接，可以方便的對硬碟、CPU、內存、網路負載、進程、文件拷貝/列印操作、通過Modem擅自連接外網的情況、非業務異常軟體的安裝和運行等進行審計。 3.應用系統審計數據讀取技術： 大多數的多用戶操作系統(Windows、UNIX等)、正規的大型軟體(資料庫系統等)、多數安全設備(防火牆、防病毒軟體等)都有自己的審計功能，日誌通常用於檢查用戶的登錄、分析故障、進行收費管理、統計流量、檢查軟體運行情況和調試軟體，系統或設備的審計日誌通常可以用作二次開發的基礎，所以如何讀取多種系統和設備的審計日誌將是解決操作系統審計模塊、資料庫審計模塊、應用審計模塊的關鍵所在。 4.完善的審計數據分析技術： 審計數據的分析是一個安全審計系統成敗的關鍵，分析技術應該能夠根據安全策略對審計數據具備評判異常和違規的能力，分為實時分析和事後分析： 實時分析：提供或獲取審計數據的設備和軟體應該具備預分析能力，並能夠進行第一道篩選; 事後分析：統一管理平台模塊對記錄在資料庫中的審計記錄進行事後分析，包括統計分析和數據挖掘。 五、安全審計系統應該注意的問題 安全審計系統的設計應該注意以下幾個問題： 1.審計數據的安全： 在審計數據的獲取、傳輸、存儲過程中都應該注意安全問題，同樣要保證審計信息的「五性」。在審計數據獲取過程中應該防止審計數據的丟失，應該在獲取後盡快傳輸到統一管理平台模塊，經過濾後存入資料庫，如果沒有連接到管理平台模塊，則應該在本地進行存儲，待連接後再發送至管理平台模塊，並且應該採取措施防止審計功能被繞過;在傳輸過程中應該防止審計數據被截獲、篡改、丟失等，可以採用加密演算法以及數字簽名方式進行控制;在審計數據存儲時應注意資料庫的加密，防止資料庫溢出，當資料庫發生異常時，有相應的應急措施，而且應該在進行審計數據讀取時加入身份鑒別機制，防止非授權的訪問。 2.審計數據的獲取 首先要把握和控制好數據的來源，比如來自網路的數據截取;來自系統、網路、防火牆、中間件等系統的日誌;通過嵌入模塊主動收集的系統內部信息;通過網路主動訪問獲取的信息;來自應用系統或安全系統的審計數據等。有數據源的要積極獲取;沒有數據源的要設法生成數據。對收集的審計數據性質也要分清哪些是已經經過分析和判斷的數據，哪些是沒有分析的原始數據，要做出不同的處理。 另外，應該設計公開統一的日誌讀取API，使應用系統或安全設備開發時，就可以將審計日誌按照日誌讀取API的模式進行設計，方便日後的審計數據獲取。 3.管理平台分級控制 由於涉密信息系統的迅速發展，系統規模也在不斷擴大，所以在安全審計設計的初期就應該考慮分布式、跨網段，能夠進行分級控制的問題。也就是說一個涉密信息系統中可能存在多個統一管理平台，各自管理一部分審計模塊，管理平台之間是平行關系或上下級關系，平級之間不能互相管理，上級可以向下級發布審計規則，下級根據審計規則向上級匯報審計數據。這樣能夠根據網路規模及安全域的劃分靈活的進行擴充和改變，也有利於整個安全審計系統的管理，減輕網路的通信負擔。 4.易於升級維護 安全審計系統應該採用模塊設計，這樣有利於審計系統的升級和維護。 專家預測，安全審計系統在2003年是最熱門的信息安全技術之一。國內很多信息安全廠家都在進行相關技術的研究，有的已經推出了成型的產品，另一方面，相關的安全審計標准也在緊鑼密鼓的制定當中，看來一個安全審計的春天已經離我們越來越近了。 但是信息系統的安全從來都是一個相對的概念，只有相對的安全，而沒有絕對的安全。安全也是一個動態發展的過程，隨著網路技術的發展，安全審計還有很多值得關注的問題，如： 1. 網路帶寬由現在的100兆會增加到1G，安全審計如何對千兆網路進行審計就是值得關注的問題; 2. 當前還沒有一套為各信息安全廠商承認的安全審計介面標准，標準的制定與應用將會使安全審計跨上一個新的台階; 3. 現在的安全審計都建立在TCP/IP協議之上，如果有系統不採用此協議，那麼如何進行安全審計。 六、小結 安全審計作為一門新的信息安全技術，能夠對整個計算機信息系統進行監控，如實記錄系統內發生的任何事件，一個完善的安全審計系統可以根據一定的安全策略記錄和分析歷史操作事件及數據，有效的記錄攻擊事件的發生，提供有效改進系統性能和的安全性能的依據。本文從安全審計的概念、在涉密信息系統中需要審計的內容、安全審計的關鍵技術及安全審計系統應該注意的問題等幾個方面討論了安全審計在涉密信息系統中的應用。安全審計系統應該全面地對整個涉密信息系統中的網路、主機、應用程序、資料庫及安全設備等進行審計，同時支持分布式跨網段審計，集中統一管理，可對審計數據進行綜合的統計與分析，從而可以更有效的防禦外部的入侵和內部的非法違規操作，最終起到保護機密信息和資源的作用。
3. 資料庫與數據倉庫的本質差別是什麼
資料庫與數據倉庫的本質差別如下：
1、邏輯層面/概念層面：資料庫和數據倉庫其實是一樣的或者及其相似的，都是通過某個資料庫軟體，基於某種數據模型來組織、管理數據。但是，資料庫通常更關注業務交易處理（OLTP），而數據倉庫更關注數據分析層面（OLAP），由此產生的資料庫模型上也會有很大的差異。
2、資料庫通常追求交易的速度，交易完整性，數據的一致性等，在資料庫模型上主要遵從範式模型（1NF，2NF，3NF等），從而盡可能減少數據冗餘，保證引用完整性；而數據倉庫強調數據分析的效率，復雜查詢的速度，數據之間的相關性分析，所以在資料庫模型上，數據倉庫喜歡使用多維模型，從而提高數據分析的效率。
3、產品實現層面：資料庫和數據倉庫軟體是有些不同的，資料庫通常使用行式存儲，如SAP ASE，Oracle, Microsoft sql Server，而數據倉庫傾向使用列式存儲，如SAP IQ，SAP HANA。
4. 數據倉庫的用途
信息技術與如衡數據智能大環境下，數據倉庫在軟硬體領域、Internet 和企業內部網解決方案以及資料庫方高族面提供了許多經濟高效的計算資源，可以保存極大量的數據供分析使用，且允許使用多種數據訪問技術。
開放系統技術使得分析大量數據的成本趨於合理，並且硬體解決方案也更為成熟。在數據倉庫應用中主要使用的技術如下：
並行
計算的硬體環境、操作系統環境、 資料庫管理系統和所有相關的資料庫操作、查詢工具和技術、應用程序等各個領域都可以從並行的最新成就中獲益。
分區
分區功能使得支渣念做持大型表和索引更容易，同時也提高了數據管理和查詢性能。
數據壓縮
數據壓縮功能降低了數據倉庫環境中通常需要的用於存儲大量數據的磁碟系統的成本，新的數據壓縮技術也已經消除了壓縮數據對查詢性能造成的負面影響。
5. 數據倉庫之數據粒度
確定數據倉庫中數據的恰當粒度是數據倉庫開發者需要面對的一個最重要的設計問題。數據粒度主要針對指標數據的計算范圍，如人口這個數據項在統計部門是以街區范圍還是一個社區為范圍統計的。人口數據細化程度越高，粒度級就越小；相反，細化程度越低，粒度級就越大。粒度是數據倉庫主要設計問題，因為它極大地影響存放在數據倉庫中的數據量的大小，同時影響數據倉庫所能回答的查詢類型。在設計數據倉庫的時候權衡數據量大小和查詢類型得出合理的粒度大小。下面我們通過規劃設計和建設兩個階段來講解數據倉庫粒度的確定。
1.規劃階段
「規劃」——對未來整體性、長期性、基本型問題的思考和考量，設計未來整套行動的方案。在規劃階段過程中首先粗略估算數據量，估算的目的是掌握數據倉庫中數據量的一個范圍。第二步預測未來數據集市中應用需要的粒度，數據倉庫存儲數據集市使用的最小粒度。
1.1. 建立良好的循環反饋機制是很重要的。
首先就要建立完善的循環反饋機制。數據倉庫是面對模糊需求開始建立的，粒度不可能一次就能規劃好，先導入少量數據，建立一部分應用提交給用戶使用，並聆聽用戶使用意見，根據用戶的使用意見調整粒度的大慧好小。
1.2. 對存儲數據進行粗略估算對設計體系結構的人員來說非常有用。
粗略估算數據倉庫的亂碧橘數據量，可跟好的規劃數據倉庫架構。如果數據只有10 000行，那麼數據倉庫採用粒度級越小的數據存儲，數據倉庫中存儲所有明細數據。如果明細數據有10 000 000行，進入數據倉庫的數據就需要進行初步匯總。如果有100億行，數據倉庫不但需要有一個高粒度級，還可能將大部分數據移到溢出存儲器上去。
估算方法如下：
1.3. 預測數據集市中可能使用的數據粒度是很必要的。
為了合適地填充所有的數據集市，數據倉庫中的數據必須在一個所有數據集市所需要的最低粒度水平上。
規劃階段的成果是數據倉庫建設的重要依據內容。規劃階段對組織架構，數據量大小和後期應用的摸底，可以制定方案，並對可能的結果有預先的認知，對可能存在的問題設計上進行避免。
2. 建設階段
2.1.根據估算的空間結果，在體系架構設計上可以根據數據量大小進行存儲設備選擇。需要多少直接存取存儲設備，是否需採用雙重粒度設計。
2.2.設計溢出數據的管理。溢出數據是指數據倉庫將不經常被訪問的過時的數據轉移到存儲量更大的訪問速度慢的存儲器上的數據。管理溢出數據可以方便索引定位歷史數據並可以快速取出該數據。
跨介質存儲管理器和數據活動監控器可以對溢出數據進行有效的管理。磁碟存儲器和大容量低速存儲器之間的數據移動是通過一種稱為「跨介質存儲管理器（CMSM）」的軟體來控制的。數據活動監控器，用來確定哪些數據正在被訪問，哪些沒被訪問。數據活動監控器能提供數據存儲的位置信息。
2.3.實施數據倉庫過程中粒度的確定是一個往復循環的過程。利用規劃階段建立的反饋循環方法，不斷的從分析員獲得反饋，不斷的優化數據倉庫。
從圖可以看出成功建立數據倉庫離不開分析人員的通力協作。建設者要不斷的聆聽分析員的意見。分析人員在建立數據倉庫的時候並不知道自己需要什麼，只有在他們看到最終分析結果，才能告訴數據倉庫工作人員什麼才是他們真正有用的。為了有效的獲得反饋，以下幾點技巧可供參考：
快速建立數據倉庫很小的子集並認真聽取用戶的反饋意見；
使用原型方法；
參考別人的經驗；
與有經驗的用戶協同工作；
以企業中已有的功能需要作參考；
定期舉行數據倉庫建設例會。
3.例舉銀行粒度小例子
3.1.銀行環境中粒度嘩團級別，下圖是銀行中的數據粒度例子。
銀行的操作層存放的是以日為單位粒度的數據。銀行的各個業務系統只存放最近60天交易活動明細內容，方便用戶查詢最近兩個月的交易信息詳情，這段時間用戶對交易數據明細最為關心。
數據倉庫層將數據匯聚成以月為單位粒度的匯總數據。銀行將過去長達十年的數據按每個賬戶每月交易信息進行匯聚，存儲在直接存儲設備，供高速查詢訪問，用戶對過去很久的交易明細並不在意，但是用戶需要快速查詢得出結果，此時提供以月為單位的匯總數據可以滿足用戶的需求。
所有的歷史數據以日為單位存放在溢出存儲區，該區域數據量極大，訪問頻率極低。一般銀行不受理長達十年的歷史明細數據查詢的請求，如果一些特殊情況需要查詢超過十年的歷史數據，查詢時間會相當緩慢。
4.小結
數據倉庫粒度的確定是一個困難的過程，要求一個合適的級別，既不能太高也不能太低。
選擇粒度級別很大程度上基於常識。建設之前作好適當的規劃，估算數據量並建立相應的反饋制度。在實施的過程中，首先建立數據倉庫的一小部分，並讓分析人員使用。然後聆聽他們的意見，根據他們的反饋對粒度級別進行適當的調整。
6. 什麼是數據倉庫，數據倉庫如何分層
數據倉庫分層的原因
1通過數據預處理提高效率，因為預處理，所以會存在冗餘數據
2如果不分層而業務系統的業務規則發生變化，就會影響整個數據清洗過程，工作量巨大
3通過分層管理來實現分步完成工作，這樣每一層的處理邏輯就簡單了
標準的數據倉庫分層：ods（臨時存儲層），pdw（數據倉庫層），mid（數據集市層），app（應用層）
ods：歷史存儲層，它和源系統數據是同構的，而且這一層數據粒度是最細的，這層的表分為兩種，一種是存儲當前需要載入的數據，一種是用於存儲處理完後的數據。
pdw：數據倉庫層，它的數據是干凈的數據，是一致的准確的，也就是清洗後的數據，它的數據一般都遵循資料庫第三範式，數據粒度和ods的粒度相同，它會保存bi系統中所有歷史數據
mid：數據集市層，它是面向主題組織數據的，通常是星狀和雪花狀數據，從數據粒度將，它是輕度匯總級別的數據，已經不存在明細的數據了，從廣度來說，它包含了所有業務數量。從分析角度講，大概就是近幾年
app：應用層，數據粒度高度匯總，倒不一定涵蓋所有業務數據，只是mid層數據的一個子集。
數據倉庫的目的是構建面向分析的集成化數據環境，為企業提供決策支持。數據倉庫的context也可以理解為：數據源，數據倉庫，數據應用
數據倉庫可以理解為中間集成化數據管理的一個平台
etl（抽取extra，轉化transfer，裝載load）是數據倉庫的流水線，也可以認為是數據倉庫的血液。
數據倉庫的存儲並不需要存儲所有原始數據，因為比如你存儲冗長的文本數據完全沒必要，但需要存儲細節數據，因為需求是多變的，而且數據倉庫是導入數據必須經過整理和轉換使它面向主題，因為前台資料庫的數據是基於oltp操作組織優化的，這些可能不適合做分析，面向主題的組織形式才有利於分析。
多維數據模型就是說可以多維度交叉查詢和細分，應用一般都是基於聯機分析處理（online analytical process OLAP），面向特定需求群體的數據集市會基於多位數據模型構建
而報表展示就是將聚合數據和多維分析數據展示到報表，提供簡單和直觀的數據。
元數據，也叫解釋性數據，或者數據字典，會記錄數據倉庫中模型的定義，各層級之間的映射關系，監控數據倉庫的數據狀態和etl的任務運行狀態。一般通過元數據資料庫來統一存儲和管理元數據。
7. 什麼是數據倉庫，數據倉庫在哪裡保存數據。BI項目需要用到哪些技術
一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。先大概列一下互聯網行業數據倉庫、數據平台的用途：
整合公司所有業務數據，建立統一的數據中心；
提供各種報表，有給高層的，有給各個業務的；
為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；
為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；
分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；
開發數據產品，直接或間接為公司盈利；
建設開放數據平台，開放公司數據；
。。。。。。
上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；
其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；
建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。
整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：
邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。
我們從下往上看：
數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。
數據源的種類比較多：
網站日誌：
作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，
一般是在每台網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；
業務資料庫：
業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapRece來執行，而且需要Hadoop集群的每台機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構數據源海量數據交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。
當然，Flume通過配置與開發，也可以實時的從資料庫中同步數據到HDFS。
來自於Ftp/Http的數據源：
有可能一些合作夥伴提供的數據，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求；
其他數據源：
比如一些手工錄入的數據，只需要提供一個介面或小程序，即可完成；
數據存儲與分析毋庸置疑，HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基於結構化數據上的統計分析遠遠比MapRece要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼；
當然，使用Hadoop框架自然而然也提供了MapRece介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapRece來做分析與計算；Spark是這兩年非常火的，經過實踐，它的性能的確比MapRece要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》
實時計算部分，後面單獨說。
數據共享這里的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關系型資料庫和NOSQL資料庫；
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。
另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。
數據應用
業務產品
業務產品所使用的數據，已經存在於數據共享層，他們直接從數據共享層訪問即可；
報表
同業務產品，報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層；
即席查詢
即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；
這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。
即席查詢一般是通過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。
當然，你也可以使用Impala，如果不在乎平台中再多一個框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數據，都是通過將需要的數據同步到關系型資料庫中做OLAP，但如果數據量巨大的話，關系型資料庫顯然不行；
這時候，需要做相應的開發，從HDFS或者HBase中獲取數據，完成OLAP的功能；
比如：根據用戶在界面上選擇的不定的維度和指標，通過開發介面，從HBase中獲取數據來展示。
其它數據介面
這種介面有通用的，有定製的。比如：一個從Redis中獲取用戶屬性的介面是通用的，所有的業務都可以調用這個介面來獲取用戶屬性。
實時計算現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平台中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。
我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。
做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。
任務調度與監控在數據倉庫/數據平台中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；
這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平台的中樞，負責調度和監控所有任務的分配與運行。
前面有寫過文章，《大數據平台中的任務調度與監控》,這里不再累贅。
總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的數據平台中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。
8. 檢測到緩存溢出是何意思
一些Sasser代碼（可以說是插件或木馬之類）穿過未打補丁的防火牆,到達沒有防護的伺服器。當代碼進入沒有防護伺服器的內存時,它馬上執行緩存器溢出,將伺服器系統級的控制權交給了遠端的主機,實現在企業網內的遠程式控制制。
卡巴六正是針對Web瀏覽器或者其他最終用戶網路應用的的漏洞防禦，並可以檢測和防止受保護計算機上運行的任何應用遭受緩存溢出攻擊，防治計算機收到傷害，你拒絕的時候沒有「以後都這樣操作」的提示嗎？如果沒有，建議不要瀏覽該網頁了！
溫馨提醒：上網的時候最好不要用IE上網，因為80％病毒都是針對IE的（也就是WINDOW），如果使用第三方面的瀏覽器，將會大大降低中毒的幾率！
9. 典型的數據倉庫系統包括哪幾部分
1.數據源-> 2.ETL -> 3.數據倉庫存儲與管理-> 4.OLAP -> 5.BI工具
**數據源：**是數據倉庫系統的數據源泉,通常包括企業各類信息,包括存放於RDBMS中的各種業務處理數據和各類文檔數據；各類法律法規、市場信息和競爭對手的信息等判世等；
ETL工具（informatica，ssis，owb，datastage），以及該工具簡單講述特點。
DataStage是一套專門對多種操作數據源的數據抽取、轉換和維護過程進行簡化和自動化，並將其輸入數據集市或數據倉庫目標資料庫的集成工具。
它有四個組件:Administrator:用來管理project和環境變數。Manager:用於job表定義的引導引出。Designer:用來設計job。Direct:用運查看job運行日誌。
數據的存儲與管理：數據的存儲和管理是整個數據倉庫的核心，是關鍵。數據倉庫的組織管理方式決定了它有別於傳統資料庫，同時也決定了其對外部數據的表現形式。從數據倉庫的技術特點著手分析，來決定採用什麼產品和技術來建立數據倉庫，然後針對現有各業務系統的數據，進行抽取、清理，並有效集成，按照主題進行組織。數據倉庫按照數據的覆蓋范圍可以分為企業級數據倉庫和部門級數據倉庫（通常稱為數據集市）。
OLAP伺服器：
對需要的數據進行有效集成，按多維模型予以組織，以便進行多角度、多層辯耐次的分析，並發現趨勢。其具體實現可以分為：ROLAP（關系型在線分析處理）、MOLAP（多維在線分析處理）和HOLAP（混合型線上分析處理）。ROLAP基本數據和聚合數據均存放在RDBMS之中；MOLAP基本數據和聚合數據均存放於多維資料庫中；HOLAP基本數據存放於RDBMS之中，聚合數據存放於多維資料庫中。
前端工具：主要包括各查詢工具、數據分析工具、數據挖掘工具、種報表工具以及各種攜沖春基於數據倉庫或數據集市的應用開發工具。
數據分析工具主要針對OLAP伺服器。報表工具、數據挖掘工具主要針對數據倉庫。
10. 關於優化Oracle存儲過程的問題
你好：
您的程序我也看了。
先這么入手吧：
您的程序是包含在一個循環語句中，可否把循環語句的cursor單獨拉出來，查一下執行計劃：
selectdistinctv.procinstid_,v.value_,r.purc_report_id,r.purc_pro_id,r.purc_pro_name,t.team_name,r.purc_type,r.requi_form,r.build_name
fromcg_purchase_reportr,cg_bid_teamt,jbpm4_hist_varv
wherer.bid_team=t.bid_team_id
andr.purc_report_id=v.value_
andv.varname_='pkId'
andv.procinstid_like'requirementsReport%'
andr.purc_report_state=3;
一般來說對程序效率造成最大的問題的就是cursor，當然也包括了對INDEX列的DML。那我們先一步步來。您先查一下，給個截圖。或者簡單描述下您查到的執行計劃的結果。
-------------------------------------------------------------------------------------------------------------------------
另外， 指出一下（或者說探討一下）樓上wwtburning所提出的時間上用to_number, to_date的問題。 這個問題本身確實可能會造成效率下降， 但是不是由於使用了轉換， 您的代碼中全部都是 select __________ from al, 沒有用在 where句中， 就不可能通過index而造成影響。所以這個方向不需要考慮了。
------------------------------------------------------------------------------------------------------------------------
提2個問題：
您的cursor查詢結果是2000， 但是您的from 後面跟的幾個表的數據集是多大？如果可能， 可否給您的幾個表的索引一個截圖。目的是如果是driving cursor的效率不高， 那麼需要提升這個cursor的效率， 需要看下他的索引是怎麼寫的， 順便也可以了解一下有多少個索引。
您的這個過程中有少許幾個update語句，通過您的程序的命名法看出很多數據是為了商業報表而准備的。 這個您要更新的語句是staging table嗎，或者是數據倉庫嗎？ 索引是怎樣的？ 問這個問題是因為， 為報表而准備的數據在設計過程中為的是用報表的人可以讀的快，也就是說select盡量快， 因此， 如果我們第一步檢查cursor走不通， 就可能要考慮是否是您這個目標表的效率問題。