SQL Server資料倉庫的基礎架構規劃
問題
SQL Server資料倉庫具有自己的特徵和行為屬性,有別去其他。從這個意義上說,資料倉庫基礎架構規劃需要與標準SQL Server OLTP資料庫系統的規劃不同。在本文中,我們將介紹在計劃資料倉庫時應該考慮的一些事項。
解決
SQL Server 資料倉庫系統引數
資料倉庫本身有自己的引數,因此每個資料倉庫系統都有自己獨特的特性。在決定資料倉庫系統的基礎結構時,必須評估許多引數。在這些引數中,主要引數是資料量、報告複雜性、使用者、系統可用性和ETL。
資料量
正如你可能知道的,資料量是大資料的七個屬性之一。與事務系統不同,資料倉庫系統傾向於儲存歷史資料以及具有多個域和系統的資料。這意味著資料倉庫中的資料量將會很大,並且會快速增長。
報表複雜性
在資料倉庫的情況下,報表有四種類型:描述性、診斷性、預測性和說明性。資料倉庫是分析的框架,這意味著報告使用者應該有執行特別查詢的選項。此外,還有一些報表將使用具有不同型別連線的大量表和大量聚合。
通常,資料倉庫解決方案必須支援以下查詢型別的組合:
- 簡單: 使用一個事實表和幾個維度表進行相對直接的Select 查詢。
- 中等: 重複執行包含聚合或多個連線的查詢
- 複雜: 具有複雜聚合、連線和計算的特殊查詢(ad-hoc)。此外,這類查詢還包含資料探勘和預測分析
使用者數量
通常,資料倉庫的使用者數量少於事務系統。然而,由於大型查詢是在相當長的一段時間內出於分析目的而執行的,因此併發性是一個問題。
可用性
Sometimes, depending on the geography distribution of data warehouse users, there is a need to have operating system time slots. Also, planned down time and unplanned outages can affect Availability.
有時,根據資料倉庫使用者的地理分佈,需要有作業系統的時差。此外,計劃停機時間和意外停機也會影響可用性。
ETL
ETL ( Extract-Transformation-Load ):是資料倉庫的一個基本元件。對於一些資料倉庫,每日ETL就足夠了。實際上,大多數資料倉庫ETL都屬於這一類。有些資料倉庫在白天有幾個ETL作業,而其他ETL作業將在非高峰時間執行。在一些情況下,一些資料倉庫需要實時資料。
從這些引數可以看出,資料倉庫系統可以是這些引數的多個複雜性的組合。因此,很難判斷資料倉庫屬於哪一類。
下表包含這些不同規模的系統引數
Parameter \ Scale | Small | Medium | Large |
---|---|---|---|
資料量 | Less than 1 TB | 1 to 10 TB | More than 10 TB |
報表複雜度 | Simple – 60 % Medium – 30 % Complex – 10 % | Simple – 50 % Medium – 40 % Complex – 10 % | Simple – 20 % Medium – 50 % Complex – 30 % |
使用者數量 | 100 Users 10 Concurrent users | 1000 Users 100 – 200 concurrent users | 1000 concurrent users |
可用性 | Typical business hours | 1-2 hrs of down time | 24x7 |
ETL | One ETL per day | Intra Day ETL | Real Time Data |
由於很難選擇資料倉庫的規模,通過檢視上面的引數,您可以瞭解資料倉庫的規模。
負載型別
在分析資料倉庫的容量之後,下一步是分析資料倉庫的工作負載。資料倉庫的典型工作負載是ETL、資料模型和報告。
ETL
通常,ETL從事務系統、異構源中提取資料,並對其進行轉換,以適應資料倉庫這個分析平臺。在提取階段,源系統將有IO和記憶體負載。由於不應該也不能中斷源系統,因此需要對提取進行適當的計劃,以使其不會影響源系統。轉換通常發生在資料倉庫端。因為轉換需要更多的計算能力,這意味著CPU的消耗將隨著記憶體的使用而增加。資料的載入還需要資料倉庫系統上更多的IO。由於資料來自多個源,在ETL過程中,網路頻寬通常是網路管理員關心的問題。
Data 模型
在大多數技術中,會在資料倉庫之上建立一個額外的層,以提高報告和分析的效能。例如,對於SQL Server SSAS多維資料集,SSAS 扁平資料集,同時對於Oracle, Hyperion資料集是可用的。在這個層中,資料將從資料倉庫讀取並處理到資料模型層。在ETL之後,需要處理這些資料模型以保持資料同步。在這個模型層中,將儲存聚合的資料,因此資料模型的處理是高CPU和IO操作。此外,聚合是記憶體密集型操作。
資料倉庫結構分層
一圖勝千言
報表和分析
告和分析是終端使用者的端點。在報告的情況下,報告更有可能收集大量資料。如果報表正在使用資料模型,那麼報表伺服器端就會出現問題。在分析的情況下,如果使用資料探勘演算法,會消耗高CPU,因為資料探勘演算法消耗CPU。
此外,還有一些選項,如報表平臺中的資料驅動訂閱和標準訂閱,特別是在SQL Server reporting Services (SSRS)的情況下。由於報告是寫到磁碟上的,如Word、Excel或PDF檔案,IO的使用率可能相當高。
運維工作負載
除了資料倉庫平臺上的典型操作之外,還需要完成其他維護任務。
重建索引
索引用於更好的資料檢索效能。由於對資料倉庫的寫操作較少,管理員可以選擇建立許多索引。此外,對於資料倉庫,可以建立columnstore索引。當存在這些索引時,需要重新構建索引,以避免索引碎片並提高總體效能。如前所述,資料倉庫中可能有大量的索引,資料量很大,因此在重建索引時,流程可能會消耗大量的CPU和IO。
數倉的索引與事務性的索引建立有很大不同,更多關注減少非聚集索引的方式。
備份
資料備份不是“必需的”,因為資料通常是從其他源系統生成的。備份也是“必需的”,如果需要,它可以幫助恢復,而不是從頭開始重建所有東西。由於資料倉庫通常具有大量的資料,因此備份會在系統上使用大量的CPU和IO。一般來講備份要注意歸檔和檔期當前資料的分割槽還原等。