sqlserver數據倉庫

1. 如何在sql Server中構建數據倉庫

如何在SQL Server中構建數據倉庫 - MSSQL教程 - 編程入門網

http://www.bianceng.cn/database/SQLServer/200712/6434.htm

2. sqlserver資料庫實體文件太大如何清理

你什麼意思？
是你的mdf大嗎？mdf大說明數據多，你可以適當優化資料庫表結構，如果仍然很大，就要考慮建數據倉庫，或者，歷史數據平時查詢使用很少，可以把舊數據導出來，把原庫中的刪了，
如是ldf大，說明生成的事務日誌多，重新考慮你的備份計劃。

3. SQL Server資料庫和MySQL資料庫有什麼區別

1，優點分析：MYSQL短小精悍，容易上手，操作簡單，免費供用的。相對其它資料庫有特色又實用的語法多一些。SQL怎麼也算是大型資料庫，穩定，能做一般大系統的數據倉庫，運行速度明顯比MYSQL快N多（海量數據下這個優勢顯而易見）。

2，缺點分析：MYSQL難擔當大系統的數據倉庫，運行速度慢，不夠穩定，有掉線的情況。SQLSERVER價格貴（當然沒說5元盜版），使用起來比MYSQL要難一些，畢竟東西大了說道多點。

3，按你的補充（如何登錄）：MySQL自己有文字界面客戶端，用起來咋說也沒滑鼠點方便（不過習慣了也好），當然配對MYSQL有專業的客戶端軟體，我是用SQLYOG519版的，各種操作真的是很方便的說。SQLSERVER 就用自帶的查詢分析器登錄了：）兩者的前提是資料庫服務都帶打開，而且你得知道安裝時的用戶名密碼哦：）

對於程序開發人員而言，目前使用最流行的兩種後台資料庫即為MySQL and SQLServer。這兩者最基本的相似之處在於數據存儲和屬於查詢系統。你可以使用SQL來訪問這兩種資料庫的數據，因為它們都支持ANSI-SQL。還有，這兩種資料庫系統都支持二進制關鍵詞和關鍵索引，這就大大地加快了查詢速度。同時，二者也都提供支持XML的各種格式。除了在顯而易見的軟體價格上的區別之外，這兩個產品還有什麼明顯的區別嗎？在這二者之間你是如何選擇的？讓我們看看這兩個產品的主要的不同之處，包括發行費用，性能以及它們的安全性。

根本的區別是它們遵循的基本原則

二者所遵循的基本原則是它們的主要區別：開放vs保守。SQL伺服器的狹隘的，保守的存儲引擎與MySQL伺服器的可擴展，開放的存儲引擎絕然不同。雖然你可以使用SQL伺服器的Sybase引擎，但MySQL能夠提供更多種的選擇，如MyISAM,Heap, InnoDB, and BerkeleyDB。MySQL不完全支持陌生的關鍵詞，所以它比SQL伺服器要少一些相關的資料庫。同時，MySQL也缺乏一些存儲程序的功能，比如MyISAM引擎聯支持交換功能。

發行費用：MySQL不全是免費，但很便宜

當提及發行的費用，這兩個產品採用兩種絕然不同的決策。對於SQL伺服器，獲取一個免費的開發費用最常的方式是購買微軟的Office或者VisualStudio的費用。但是，如果你想用於商業產品的開發，你必須還要購買SQL Server StandardEdition。學校或非贏利的企業可以不考慮這一附加的費用。

性能：先進的MySQL

純粹就性能而言，MySQL是相當出色的，因為它包含一個預設桌面格式MyISAM。MyISAM資料庫與磁碟非常地兼容而不佔用過多的CPU和內存。MySQL可以運行於Windows系統而不會發生沖突，在UNIX或類似UNIX系統上運行則更好。你還可以通過使用64位處理器來獲取額外的一些性能。因為MySQL在內部里很多時候都使用64位的整數處理。Yahoo!商業網站就使用MySQL作為後台資料庫。

當提及軟體的性能，SQL伺服器的穩定性要比它的競爭對手強很多。但是，這些特性也要付出代價的。比如，必須增加額外復雜操作，磁碟存儲，內存損耗等等。如果你的硬體和軟體不能充分支持SQL伺服器，我建議你最好選擇其他如DBMS資料庫，因為這樣你會得到更好的結果。

安全功能

MySQL有一個用於改變數據的二進制日誌。因為它是二進制，這一日誌能夠快速地從主機上復制數據到客戶機上。即使伺服器崩潰，這一二進制日誌也會保持完整，而且復制的部分也不會受到損壞。

在SQL伺服器中，你也可以記錄SQL的有關查詢，但這需要付出很高的代價。

安全性

這兩個產品都有自己完整的安全機制。只要你遵循這些安全機制，一般程序都不會出現什麼問題。這兩者都使用預設的IP埠，但是有時候很不幸，這些IP也會被一些黑客闖入。當然，你也可以自己設置這些IP埠。

恢復性:先進的SQL伺服器

恢復性也是MySQL的一個特點，這主要表現在MyISAM配置中。這種方式有它固有的缺欠，如果你不慎損壞資料庫，結果可能會導致所有的數據丟失。然而，對於SQL伺服器而言就表現得很穩鍵。SQL伺服器能夠時刻監測數據交換點並能夠把資料庫損壞的過程保存下來。

根據需要決定你的選擇

對於這兩種資料庫，如果非要讓我說出到底哪一種更加出色，也許我會讓你失望。以我的觀點，任一對你的工作有幫助的資料庫都是很好的資料庫，沒有哪一個資料庫是絕對的出色，也沒有哪一個資料庫是絕對的差勁。我想要告訴你的是你應該多從你自己的需要出發，即你要完成什麼樣的任務？而不要單純地從軟體的功能出發。

如果你想建立一個.NET伺服器體系，這一體系可以從多個不同平台訪問數據，參與資料庫的管理，那麼你可以選用SQL伺服器。如果你想建立一個第三方站點，這一站點可以從一些客戶端讀取數據，那麼MySQL將是最好的選擇。

4. SQLSERVER大資料庫解決方案

在微軟的大數據解決方案中，數據管理是最底層和最基礎的一環。

靈活的數據管理層，可以支持所有數據類型，包括結構化、半結構化和非結構化的靜態或動態數據。

在數據管理層中主要包括三款產品：SQLServer、SQLServer並行數據倉庫和

Hadoop on Windows。

針對不同的數據類型，微軟提供了不同的解決方案。

具體來說，針對結構化數據可以使用SQLServer和SQLServer並行數據倉庫處理。

非結構化數據可以使用Windows Azure和WindowsServer上基於Hadoop的發行版本處理;而流數據可以使用SQLServerStreamInsight管理，並提供接近實時的分析。

1、SQLServer。去年發布的SQLServer2012針對大數據做了很多改進，其中最重要的就是全面支持Hadoop，這也是SQLServer2012與SQLServer2008最重要的區別之一。今年年底即將正式發布的SQLServer2014中，SQLServer進一步針對大數據加入內存資料庫功能，從硬體角度加速數據的處理，也被看為是針對大數據的改進。

2、SQLServer並行數據倉庫。並行數據倉庫(Parallel Data Warehouse Appliance，簡稱PDW)是在SQLServer2008 R2中推出的新產品，目前已經成為微軟主要的數據倉庫產品，並將於今年發布基於SQLServer2012的新款並行數據倉庫一體機。SQLServer並行數據倉庫採取的是大規模並行處理(MPP)架構，與傳統的單機版SQLServer存在著根本上的不同，它將多種先進的數據存儲與處理技術結合為一體，是微軟大數據戰略的重要組成部分。

3、Hadoop on Windows。微軟同時在Windows Azure平台和WindowsServer上提供Hadoop，把Hadoop的高性能、高可擴展與微軟產品易用、易部署的傳統優勢融合到一起，形成完整的大數據解決方案。微軟大數據解決方案還通過簡單的部署以及與Active Directory和System Center等組件的集成，為Hadoop提供了Windows的易用性和可管理性。憑借Windows Azure上基於Hadoop的服務，微軟為其大數據解決方案在雲端提供了靈活性。

5. 資料庫與數據倉庫的區別

資料庫是面向事務的設計，數據倉庫是面向主題設計的。資料庫一般存儲在線交易數據，數據倉庫存儲的一般是歷史數據。

「與時間相關」：資料庫保存信息的時候，並不強調一定有時間信息。數據倉庫則不同，出於決策的需要，數據倉庫中的數據都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對於決策者意義是不同的。

「不可修改」：數據倉庫中的數據並不是最新的，而是來源於其它數據源。數據倉庫反映的是歷史信息，並不是很多資料庫處理的那種日常事務數據（有的資料庫例如電信計費資料庫甚至處理實時信息）。因此，數據倉庫中的數據是極少或根本不修改的；當然，向數據倉庫添加數據是允許的。

拓展資料：

數據倉庫的出現，並不是要取代資料庫。數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型資料庫」。

目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。

6. 資料庫 與 數據倉庫的本質區別是什麼

資料庫與數據倉庫的本質差別如下：
1、邏輯層面/概念層面：資料庫和數據倉庫其實是一樣的或者及其相似的，都是通過某個資料庫軟體，基於某種數據模型來組織、管理數據。但是，資料庫通常更關注業務交易處理（OLTP），而數據倉庫更關注數據分析層面（OLAP），由此產生的資料庫模型上也會有很大的差異。
2、資料庫通常追求交易的速度，交易完整性，數據的一致性等，在資料庫模型上主要遵從範式模型（1NF，2NF，3NF等），從而盡可能減少數據冗餘，保證引用完整性；而數據倉庫強調數據分析的效率，復雜查詢的速度，數據之間的相關性分析，所以在資料庫模型上，數據倉庫喜歡使用多維模型，從而提高數據分析的效率。
3、產品實現層面：資料庫和數據倉庫軟體是有些不同的，資料庫通常使用行式存儲，如SAP
ASE，Oracle,
Microsoft
SQL
Server，而數據倉庫傾向使用列式存儲，如SAP
IQ，SAP
HANA。

7. 請問數據倉庫都用什麼建立

1、首先你得搞清楚建設數倉的目的是什麼

是偏向於整合各系統數據，為數據分析決策服務，還是偏向於快速的完成分析決策需求？

如果是前者，那麼在數據倉庫建模的時候一般會選擇ER建模方法；

如果是後者，一般會選擇維度建模方法。

• ER建模：即實體關系建模，由數據倉庫之父BIll Inmon提出，核心思想是從全企業的高度去設計三範式模型，用實體關系描述企業服務。主張的是自上而下的架構，將不同的OLTP數據集中到面向主題的數據倉庫中。

• 維度建模：由Kimball提出，核心思想是從分析決策的需求出發構建模型。這種模型由事實表和維表組成，即星型模型和雪花模型。Kimball倡導自下而上的架構，可以針對獨立部門建立數據集市，再遞增的構建，匯總成數據倉庫。

2、其次你得進行深入的業務調研和數據調研

• 業務調研：深入的業務調研能使你更加明確數倉建設的目的；同時也利於後續的建模設計，隨著調研的開展，如何將實體業務抽象為數倉模型會更加明朗。
  

• 數據調研：各部門或各科室的數據現狀了解，包括數據分類、數據存儲方式、數據量、具體的數據內容等等。這對後續的主數據串聯或者維度一致性處理等等都是必須的基礎。

3、然後是數據倉庫工具選型

• 傳統型數據倉庫：一般會選擇第三方廠家的資料庫和配套ETL工具。因為有第三方支持，相對有保障；但缺點也很明顯，受約束以及成本較高。
  

• NoSQL型數據倉庫：一般是基於hadoop生態的數據倉庫。hadoop生態已經非常強大，可以找到各種開源組件去支持數據倉庫。缺點是需要招聘專門人士去摸索，並且相對會存在一些未知隱患。

4、最後是設計與實施

• 設計：包括數據架構中的數據層次劃分以及具體的模型設計；也包括程序架構中的數據質量管理、元數據管理、調度管理等；
  

• 實施：規范化的項目管理實施，但同時也需記住一點，數據倉庫不是一個項目，它是一個過程。

8. sql server 2008 r2 數據倉庫怎樣畫出事實表和維度表

可以通過SQL SERVER的數據轉換服務轉為excel，在SQL SERVER的企業管理器裡面，右鍵「所有任務」-「附加資料庫」，找到這個mdf文件然後確定。下一步就是轉換了。在SQL SERVER的企業管理器裡面，選擇要轉換的資料庫，「所有任務」-「導出資料庫」，源數據不用動，下一步目的數據，驅動選擇帶excel字樣的那個，下幾步選擇好要轉換的資料庫表。然後就可以了，有問題再追問吧，望採納。
謝謝，對照你的回答，有幾個問題！1、我沒有找到企業管理器，我用對象資源管理器附加的資料庫，2、在對象資源管理器里，右擊要導出的資料庫，沒有找到新建任務，有「任務」一欄，在這一欄里有導出數據，但跟你說的不一樣，也沒導出成功！

9. 資料庫和數據倉庫有甚麼區分

資料庫（Database）是依照數據結構來組織、存儲和管理數據的倉庫，它產生於距今510年前，隨著信息技術和市場的發展，特別是210世紀910年代以後，數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。資料庫有很多種類型，從最簡單的存儲有各種數據的表格到能夠進行海量數據存儲的大型資料庫系統都在各個方面得到了廣泛的利用。數據倉庫，英文名稱為Data
Warehouse，可簡寫為DW或DWH。數據倉庫是為企業所有級別的決策制定進程提供支持的所有類型數據的戰略集合。它是單個數據存儲，出於分析性報告和決策支持的目的而創建。
為企業提供需要業務智能來指點業務流程改進和監視時間、本錢、質量和控制。

10. 數據倉庫與ODS的區別，數據倉庫和ODS並存方案

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在互聯網行業，就以互聯網行業來說。先大概列一下互聯網行業數據倉庫、數據平台的用途：

• 整合公司所有業務數據，建立統一的數據中心；

• 提供各種報表，有給高層的，有給各個業務的；

• 為網站運營提供運營上的數據支持，就是通過數據，讓運營及時了解網站和產品的運營效果；

• 為各個業務提供線上或線下的數據支持，成為公司統一的數據交換與提供平台；

• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

• 開發數據產品，直接或間接為公司盈利；

• 建設開放數據平台，開放公司數據；

• 。。。。。。




• 上面列出的內容看上去和傳統行業數據倉庫用途差不多，並且都要求數據倉庫/數據平台有很好的穩定性、可靠性；但在互聯網行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線；




• 其實，互聯網行業的數據倉庫就是所謂的敏捷數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務；




• 建設敏捷數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，如果一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和用戶瀏覽軌跡模型；基於公司核心用戶數據建立的用戶模型），其它的業務一般都採用維度+寬表的方式來建立數據模型。這塊是後話。




• 整體架構下面的圖是我們目前使用的數據平台架構圖，其實大多公司應該都差不多：




• 邏輯上，一般都有數據採集層、數據存儲與分析層、數據共享層、數據應用層。可能叫法有所不同，本質上的角色都大同小異。




• 我們從下往上看：




• 數據採集數據採集層的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。





• 數據源的種類比較多：




• 網站日誌：




• 作為互聯網行業，網站日誌占的份額最大，網站日誌存儲在多台網站日誌伺服器上，




• 一般是在每台網站日誌伺服器上部署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開發，然後配置到調度系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。