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。一般來講備份要注意歸檔和檔期當前資料的分割槽還原等。