問題
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。一般來講備份要注意歸檔和檔期當前數據的分區還原等。