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。通常來說備份要注意歸檔和檔期當前數據的分區還原等。