『壹』 怎麼實現兩個資料庫的同步
同步兩個SQLServer資料庫
如何同步兩個sqlserver資料庫的內容?程序代碼可以有版本管理cvs進行同步管理,可是資料庫同步就非常麻煩,只能自己改了一個後再去改另一個,如果忘記了更改另一個經常造成兩個資料庫的結構或內容上不一致.各位有什麼好的方法嗎?
一、分發與復制
用強制訂閱實現資料庫同步操作. 大量和批量的數據可以用資料庫的同步機制處理:
//
說明：
為方便操作,所有操作均在發布伺服器(分發伺服器)上操作,並使用推模式
在客戶機器使用強制訂閱方式。
二、測試通過
1:環境
伺服器環境:
機器名稱： zehuadb
操作系統：windows 2000 server
資料庫版本：sql 2000 server 個人版
客戶端
機器名稱：zlp
操作系統：windows 2000 server
資料庫版本：sql 2000 server 個人版
2:建用戶帳號
在伺服器端建立域用戶帳號
我的電腦管理->本地用戶和組->用戶->建立
username:zlp
userpwd:zlp
3:重新啟動伺服器mssqlserver
我的電腦->控制面版->管理工具->服務->mssqlserver 服務
(更改為：域用戶帳號,我們新建的zlp用戶 .zlp,密碼:zlp)
4:安裝分發伺服器
a:配置分發伺服器
工具->復制->配置發布、訂閱伺服器和分發->下一步->下一步(所有的均採用默認配置)
b:配置發布伺服器
工具->復制->創建和管理發布->選擇要發布的資料庫(sz)->下一步->快照發布->下一步->選擇要發布的內容->下一步->下一步->下一步->完成
c:強制配置訂閱伺服器(推模式,拉模式與此雷同)
工具->復制->配置發布、訂閱伺服器和分發->訂閱伺服器->新建->sql server資料庫->輸入客戶端伺服器名稱(zlp)->使用sql server 身份驗證(sa,空密碼)->確定->應用->確定
d:初始化訂閱
復制監視器->發布伺服器(zehuadb)->雙擊訂閱->強制新建->下一步->選擇啟用的訂閱伺服器->zlp->下一步->下一步->下一步->下一步->完成
5:測試配置是否成功
復制監視器->發布衿?zehuadb)->雙擊sz:sz->點狀態->點立即運行代理程序
查看：
復制監視器->發布伺服器(zehuadb)->sz:sz->選擇zlp:sz(類型強制)->滑鼠右鍵->啟動同步處理
如果沒有錯誤標志(紅色叉)，恭喜您配置成功
6:測試數據
在伺服器執行:
選擇一個表，執行如下sql: insert into wq_newsgroup_s select '測試成功',5
復制監視器->發布伺服器(zehuadb)->sz:sz->快照->啟動代理程序 ->zlp:sz(強制)->啟動同步處理
去查看同步的 wq_newsgroup_s 是否插入了一條新的記錄
測試完畢，通過。
7:修改資料庫的同步時間,一般選擇夜晚執行資料庫同步處理
(具體操作略) :d
/*
注意說明：
伺服器一端不能以(local)進行數據的發布與分發,需要先刪除注冊，然後新建注冊本地計算機名稱
卸載方式：工具->復制->禁止發布->是在"zehuadb"上靜止發布,卸載所有的資料庫同步配置伺服器
注意：發布伺服器、分發伺服器中的sqlserveragent服務必須啟動
採用推模式: "d:microsoft sql servermssql epldataunc" 目錄文件可以不設置共享
拉模式:則需要共享~!
*/
少量資料庫同步可以採用觸發器實現,同步單表即可。
三、配置過程中可能出現的問題
在sql server 2000里設置和使用資料庫復制之前，應先檢查相關的幾台sql server伺服器下面幾點是否滿足：
1、mssqlserver和sqlserveragent服務是否是以域用戶身份啟動並運行的（.administrator用戶也是可以的）
如果登錄用的是本地系統帳戶local，將不具備網路功能，會產生以下錯誤:
進程未能連接到distributor '@server name'
(如果您的伺服器已經用了sql server全文檢索服務, 請不要修改mssqlserver和sqlserveragent服務的local啟動。
會照成全文檢索服務不能用。請換另外一台機器來做sql server 2000里復制中的分發伺服器。)
修改服務啟動的登錄用戶，需要重新啟動mssqlserver和sqlserveragent服務才能生效。
2、檢查相關的幾台sql server伺服器是否改過名稱(需要srvid=0的本地機器上srvname和datasource一樣)
在查詢分析器里執行:
use master
select srvid,srvname,datasource from sysservers
如果沒有srvid=0或者srvid=0（也就是本機器）但srvname和datasource不一樣, 需要按如下方法修改:
use master
go
-- 設置兩個變數
declare @serverproperty_servername varchar(100),
@servername varchar(100)
-- 取得windows nt 伺服器和與指定的 sql server 實例關聯的實例信息
select @serverproperty_servername = convert(varchar(100), serverproperty('servername'))
-- 返回運行 microsoft sql server 的本地伺服器名稱
select @servername = convert(varchar(100), @@servername)
-- 顯示獲取的這兩個參數
select @serverproperty_servername,@servername
--如果@serverproperty_servername和@servername不同(因為你改過計算機名字),再運行下面的
--刪除錯誤的伺服器名
exec sp_dropserver @server=@servername
--添加正確的伺服器名
exec sp_addserver @server=@serverproperty_servername, @local='local'
修改這項參數，需要重新啟動mssqlserver和sqlserveragent服務才能生效。
這樣一來就不會在創建復制的過程中出現18482、18483錯誤了。
3、檢查sql server企業管理器裡面相關的幾台sql server注冊名是否和上面第二點里介紹的srvname一樣
不能用ip地址的注冊名。
（我們可以刪掉ip地址的注冊，新建以sql server管理員級別的用戶注冊的伺服器名）
這樣一來就不會在創建復制的過程中出現14010、20084、18456、18482、18483錯誤了。
4、檢查相關的幾台sql server伺服器網路是否能夠正常訪問
如果ping主機ip地址可以，但ping主機名不通的時候，需要在
winntsystem32driversetchosts (win2000)
(win2003)
文件里寫入資料庫伺服器ip地址和主機名的對應關系。
例如：
127.0.0.1 localhost
192.168.0.35 oracledb oracledb
192.168.0.65 fengyu02 fengyu02
202.84.10.193 bj_db bj_db
或者在sql server客戶端網路實用工具里建立別名，例如:
5、系統需要的擴展存儲過程是否存在(如果不存在，需要恢復):
sp_addextendedproc 'xp_regenumvalues',@dllname ='xpstar.dll'
go
sp_addextendedproc 'xp_regdeletevalue',@dllname ='xpstar.dll'
go
sp_addextendedproc 'xp_regdeletekey',@dllname ='xpstar.dll'
go
sp_addextendedproc xp_cmdshell ,@dllname ='xplog70.dll'
接下來就可以用sql server企業管理器里[復制]-> 右鍵選擇 ->[配置發布、訂閱伺服器和分發]的圖形界面來配置資料庫復制了。
下面是按順序列出配置復制的步驟:
1、建立發布和分發伺服器
[歡迎使用配置發布和分發向導]->[選擇分發伺服器]->[使"@servername"成為它自己的分發伺服器,sql server將創建分發資料庫和日誌]
->[制定快照文件夾]-> [自定義配置] -> [否,使用下列的默認配置] -> [完成]
上述步驟完成後, 會在當前"@servername" sql server資料庫里建立了一個distribion庫和 一個distributor_admin管理員級別的用戶(我們可以任意修改密碼)。
伺服器上新增加了四個作業:
[ 代理程序歷史記錄清除: distribution ]
[ 分發清除: distribution ]
[ 復制代理程序檢查 ]
[ 重新初始化存在數據驗證失敗的訂閱 ]
sql server企業管理器里多了一個復制監視器, 當前的這台機器就可以發布、分發、訂閱了。
我們再次在sql server企業管理器里[復制]-> 右鍵選擇 ->[配置發布、訂閱伺服器和分發]
我們可以在 [發布伺服器和分發伺服器的屬性] 窗口-> [發布伺服器] -> [新增] -> [確定] -> [發布資料庫] -> [事務]/[合並] -> [確定] -> [訂閱伺服器] -> [新增] -> [確定]
把網路上的其它sql server伺服器添加成為發布或者訂閱伺服器.
新增一台發布伺服器的選項：
我這里新建立的jin001發布伺服器是用管理員級別的資料庫用戶test連接的，
到發布伺服器的管理鏈接要輸入密碼的可選框, 默認的是選中的，
在新建的jin001發布伺服器上建立和分發伺服器fengyu/fengyu的鏈接的時需要輸入distributor_admin用戶的密碼。到發布伺服器的管理鏈接要輸入密碼的可選框，也可以不選，也就是不需要密碼來建立發布到分發伺服器的鏈接(這當然欠缺安全，在測試環境下可以使用)。
2、新建立的網路上另一台發布伺服器(例如jin001)選擇分發伺服器
[歡迎使用配置發布和分發向導]->[選擇分發伺服器]
-> 使用下列伺服器(選定的伺服器必須已配置為分發伺服器) -> [選定伺服器](例如fengyu/fengyu)
-> [下一步] -> [輸入分發伺服器（例如fengyu/fengyu）的distributor_admin用戶的密碼兩次]
-> [下一步] -> [自定義配置] -> [否，使用下列的默認配置]
-> [下一步] -> [完成] -> [確定]
建立一個資料庫復制發布的過程:
[復制] -> [發布內容] -> 右鍵選擇 -> [新建發布]
-> [下一步] -> [選擇發布資料庫] -> [選中一個待發布的資料庫]
-> [下一步] -> [選擇發布類型] -> [事務發布]/[合並發布]
-> [下一步] -> [指定訂閱伺服器的類型] -> [運行sql server 2000的伺服器]
-> [下一步] -> [指定項目] -> [在事務發布中只可以發布帶主鍵的表] -> [選中一個有主鍵的待發布的表]
->[在合並發布中會給表增加唯一性索引和 rowguidcol 屬性的唯一標識符欄位[rowguid],默認值是newid()]
(添加新列將: 導致不帶列列表的 insert 語句失敗,增加表的大小,增加生成第一個快照所要求的時間)
->[選中一個待發布的表]
-> [下一步] -> [選擇發布名稱和描述] ->
-> [下一步] -> [自定義發布的屬性] -> [否，根據指定方式創建發布]
-> [下一步] -> [完成] -> [關閉]
發布屬性里有很多有用的選項：設定訂閱到期(例如24小時)
設定發布表的項目屬性:
常規窗口可以指定發布目的表的名稱，可以跟原來的表名稱不一樣。
下圖是命令和快照窗口的欄目
( sql server 資料庫復制技術實際上是用insert,update,delete操作在訂閱伺服器上重做發布伺服器上的事務操作
看文檔資料需要把發布資料庫設成完全恢復模式，事務才不會丟失
但我自己在測試中發現發布資料庫是簡單恢復模式下，每10秒生成一些大事務，10分鍾後再收縮資料庫日誌，
這期間發布和訂閱伺服器上的作業都暫停，暫停恢復後並沒有丟失任何事務更改 )
發布表可以做數據篩選，例如只選擇表裡面的部分列:
例如只選擇表裡某些符合條件的記錄, 我們可以手工編寫篩選的sql語句:
發布表的訂閱選項，並可以建立強制訂閱:
成功建立了發布以後,發布伺服器上新增加了一個作業: [ 失效訂閱清除 ]
分發伺服器上新增加了兩個作業:
[ jin001-dack-dack-5 ] 類型[ repl快照 ]
[ jin001-dack-3 ] 類型[ repl日誌讀取器 ]
上面藍色字的名稱會根據發布伺服器名,發布名及第幾次發布而使用不同的編號
repl快照作業是sql server復制的前提條件,它會先把發布的表結構,數據,索引,約束等生成到發布伺服器的os目錄下文件
(當有訂閱的時候才會生成, 當訂閱請求初始化或者按照某個時間表調度生成)
repl日誌讀取器在事務復制的時候是一直處於運行狀態。(在合並復制的時候可以根據調度的時間表來運行)
建立一個資料庫復制訂閱的過程:
[復制] -> [訂閱] -> 右鍵選擇 -> [新建請求訂閱]
-> [下一步] -> [查找發布] -> [查看已注冊伺服器所做的發布]
-> [下一步] -> [選擇發布] -> [選中已經建立發布伺服器上的資料庫發布名]
-> [下一步] -> [指定同步代理程序登錄] -> [當代理程序連接到代理伺服器時:使用sql server身份驗證]
(輸入發布伺服器上distributor_admin用戶名和密碼)
-> [下一步] -> [選擇目的資料庫] -> [選擇在其中創建訂閱的資料庫名]/[也可以新建一個庫名]
-> [下一步] -> [允許匿名訂閱] -> [是，生成匿名訂閱]
-> [下一步] -> [初始化訂閱] -> [是，初始化架構和數據]
-> [下一步] -> [快照傳送] -> [使用該發布的默認快照文件夾中的快照文件]
(訂閱伺服器要能訪問發布伺服器的repldata文件夾，如果有問題，可以手工設置網路共享及共享許可權)
-> [下一步] -> [快照傳送] -> [使用該發布的默認快照文件夾中的快照文件]
-> [下一步] -> [設置分發代理程序調度] -> [使用下列調度] -> [更改] -> [例如每五分鍾調度一次]
-> [下一步] -> [啟動要求的服務] -> [該訂閱要求在發布伺服器上運行sqlserveragent服務]
-> [下一步] -> [完成] -> [確定]
成功建立了訂閱後，訂閱伺服器上新增加了一個類別是[repl-分發]作業(合並復制的時候類別是[repl-合並])
它會按照我們給的時間調度表運行資料庫同步復制的作業。
3、sql server復制配置好後, 可能出現異常情況的實驗日誌:
1.發布伺服器斷網,sql server服務關閉,重啟動,關機的時候,對已經設置好的復制沒有多大影響
中斷期間,分發和訂閱都接收到沒有復制的事務信息
2.分發伺服器斷網,sql server服務關閉,重啟動,關機的時候,對已經設置好的復制有一些影響
中斷期間,發布伺服器的事務排隊堆積起來
(如果設置了較長時間才刪除過期訂閱的選項, 繁忙發布資料庫的事務日誌可能會較快速膨脹),
訂閱伺服器會因為訪問不到發布伺服器,反復重試
我們可以設置重試次數和重試的時間間隔(最大的重試次數是9999, 如果每分鍾重試一次,可以支持約6.9天不出錯)
分發伺服器sql server服務啟動,網路接通以後,發布伺服器上的堆積作業將按時間順序作用到訂閱機器上:
會需要一個比較長的時間(實際上是生成所有事務的insert,update,delete語句,在訂閱伺服器上去執行)
我們在普通的pc機上實驗的58個事務100228個命令執行花了7分28秒.
3.訂閱伺服器斷網,sql server服務關閉,重啟動,關機的時候,對已經設置好的復制影響比較大,可能需要重新初試化
我們實驗環境(訂閱伺服器)從18:46分意外停機以, 第二天8:40分重啟動後, 已經設好的復制在8:40分以後又開始正常運行了, 發布伺服器上的堆積作業將按時間順序作用到訂閱機器上, 但復制管理器里出現快照的錯誤提示, 快照可能需要重新初試化,復制可能需要重新啟動.(我們實驗環境的機器並沒有進行快照初試化,復制仍然是成功運行的)
4、刪除已經建好的發布和定閱可以直接用delete刪除按鈕
我們最好總是按先刪定閱，再刪發布，最後禁用發布的順序來操作。
如果要徹底刪去sql server上面的復制設置, 可以這樣操作:
[復制] -> 右鍵選擇 [禁用發布] -> [歡迎使用禁用發布和分發向導]
-> [下一步] -> [禁用發布] -> [要在"@servername"上禁用發布]
-> [下一步] -> [完成禁用發布和分發向導] -> [完成]
我們也可以用t-sql命令來完成復制中發布及訂閱的創建和刪除, 選中已經設好的發布和訂閱, 按屬標右鍵可以[生成sql腳本]。(這里就不詳細講了, 後面推薦的網站內有比較詳細的內容)
當你試圖刪除或者變更一個table時，出現以下錯誤
server: msg 3724, level 16, state 2, line 1
cannot drop the table 'object_name' because it is being used for replication.
比較典型的情況是該table曾經用於復制，但是後來又刪除了復制。
處理辦法：
select * from sysobjects where replinfo >'0'
sp_configure 'allow updates', 1
go
reconfigure with override
go
begin transaction
update sysobjects set replinfo = '0' where replinfo >'0'
commit transaction
go
rollback transaction
go
sp_configure 'allow updates', 0
go
reconfigure with override
go
『貳』 「開源」數據同步ETL工具，支持多數據源間的增、刪、改數據同步
bboss數據同步可以方便地實現多種數據源之間的數據同步功能，支持增、刪、改數據同步，本文為大家程序各種數據同步案例。
使用Apache-2.0開源協議
通過bboss，可以非常方便地採集database/mongodb/Elasticsearch/kafka/hbase/本地或者Ftp日誌文件源數據，經過數據轉換處理後，再推送到目標庫elasticsearch/database/file/ftp/kafka/mmy/logger。
數據導入的方式
支持各種主流資料庫、各種es版本以及本地/Ftp日誌文件數據採集和同步、加工處理
支持從kafka接收數據；經過加工處理的數據亦可以發送到kafka；
支持將神鏈單條記錄切割為多條記錄；
可以將加工後的數據寫入File並上傳到ftp/sftp伺服器；
支持備份採集完畢日誌文件功能，可以指定備份文件保存時長，定期清理超過時長文件；
支持自動清理下載完畢後ftp伺服器上的文件;
支持excel、csv文件採集（本地和ftp/sftp）
支持導出數據到excel和csv文件,並支持上傳到ftp/sftp伺服器
提供自定義處理採集數據功能，可以自行將採集的數據按照自己的要求進行處理到目的地，支持數據來源包括：database，elasticsearch，kafka，mongodb，hbase，file，ftp等，想把採集的數據保存到什麼地方，有自己實現CustomOutPut介面處理即可。
支持的資料庫： mysql,maridb，postgress,oracle ,sqlserver,db2,tidb,hive，mongodb、HBase等
支持的Elasticsearch版本： 1.x,2.x,5.x,6.x,7.x,8.x,+
支持海量PB級數據同步導入功能
支持將ip轉換為對應的運營商和城市地理坐標位置信息
支持設置數伏鎮據bulk導入任務結果處理回調函數，對每次bulk任務的結果進行成功和失敗反饋，然後針對失敗的bulk任務通過error和exception方法進行相應處理
支持以下三種作業調度機制：
bboss另一個顯著的特色就是直接基於java語言來編寫數據同步作業程序，基於強大的java語言和第三方工具包，能夠非缺瞎粗常方便地加工和處理需要同步的源數據，然後將最終的數據保存到目標庫（Elasticsearch或者資料庫）；同時也可以非常方便地在idea或者eclipse中調試和運行同步作業程序，調試無誤後，通過bboss提供的gradle腳本，即可構建和發布出可部署到生產環境的同步作業包。因此，對廣大的java程序員來說，bboss無疑是一個輕易快速上手的數據同步利器。
如果需要增量導入，還需要導入sqlite驅動：
如果需要使用xxjob來調度作業任務，還需要導入坐標：
本文從mysql資料庫表td_cms_document導入數據到es中，除了導入上述maven坐標，還需要額外導入mysql驅動坐標(其他資料庫驅動程序自行導入)： mysql 5.x驅動依賴包
mysql 8.x驅動依賴包(mysql 8必須採用相應版本的驅動，否則不能正確運行)
私信回復：數據同步ETL工具
或訪問一飛開源：https://code.exmay.com/
『叄』 萬字詳解ETL和數倉建模
ETL是數據抽取（Extract）、轉換（Transform）、載入（Load ）的簡寫，它是將OLTP系統中的數據經過抽取，並將不同數據源的數據進行轉換、整合，得出一致性的數據，然後載入到數據倉庫中。簡而言之ETL是完成從 OLTP系統到OLAP系統的過程
數據倉庫（Data Warehouse DW）是基於OLTP系統的數據源，為了便於多維分析和 多角度展現將其數據按特定的模式進行存儲而建立的關系型資料庫，它不同於多維資料庫，數據倉庫中的數據是細節的，集成的，數據倉庫是面向主題的，是以 OLAP系統為分析目的。它包括星型架構與雪花型架構，其中星型架構中間為事實表，四周為維度表， 類似星星；雪花型架構中間為事實表，兩邊的維度表可以再有其關聯子表，而在星型中只允許一張表作為維度表與事實表關聯，雪花型一維度可以有多張表，而星型 不可以。考慮到效率時，星型聚合快，效率高，不過雪花型結構明確，便於與OLTP系統交互。在實際項目中，我們將綜合運用星型架構與雪花型架構。
即 確定數據分析或前端展現的某一方面的分析主題，例如我們分析某年某月某一地區的啤酒銷售情況，就是一個主題。主題要體現某一方面的各分析角度（維度）和統 計數值型數據（量度），確定主題時要綜合考慮，一個主題在數據倉庫中即為一個數據集市，數據集市體現了某一方面的信息，多個數據集市構成了數據倉庫。
在 確定了主題以後，我們將考慮要分析的技術指標，諸如年銷售額此類，一般為數值型數據，或者將該數據匯總，或者將該數據取次數，獨立次數或取最大最小值 等，這樣的數據稱之為量度。量度是要統計的指標，必須事先選擇恰當，基於不同的量度可以進行復雜關鍵性能指標（KPI）等的計算。
在 確定了量度之後我們要考慮到該量度的匯總情況和不同維度下量度的聚合情況，考慮到量度的聚合程度不同，我們將採用「最小粒度原則」，即將量度的粒度設置 到最小，例如我們將按照時間對銷售額進行匯總，目前的數據最小記錄到天，即資料庫中記錄了每天的交易額，那麼我們不能在ETL時將數據進行按月或年匯總， 需要保持到天，以便於後續對天進行分析。而且我們不必擔心數據量和數據沒有提前匯總帶來的問題，因為在後續的建立CUBE時已經將數據提前匯總了。
維 度是要分析的各個角度，例如我們希望按照時間，或者按照地區，或者按照產品進行分析，那麼這里的時間、地區、產品就是相應的維度，基於不同的維度我們可 以看到各量度的匯總情況，我們可以基於所有的維度進行交叉分析。這里我們首先要確定維度的層次（Hierarchy）和級別（Level）（圖 四：pic4.jpg），維度的層次是指該維度的所有級別，包括各級別的屬性；維度的級別是指該維度下的成員，例如當建立地區維度時我們將地區維度作為一 個級別，層次為省、市、縣三層，考慮到維度表要包含盡量多的信息，所以建立維度時要符合「矮胖原則」，即維度表要盡量寬，盡量包含所有的描述性信息，而不 是統計性的數據信息。
還有一種常見的情況，就是父子型維度，該維度一般用於非葉子節點含有成員等情況，例如公司員工 的維度，在統計員工的工資時，部 門主管的工資不能等於下屬成員工資的簡單相加，必須對該主管的工資單獨統計，然後該主管部門的工資等於下屬員工工資加部門主管的工資，那麼在建立員工維度 時，我們需要將員工維度建立成父子型維度，這樣在統計時，主管的工資會自動加上，避免了都是葉子節點才有數據的情況。
另外，在建立維度表時要充 分使用代理鍵，代理鍵是數值型的ID號碼，好處是代理鍵唯一標識了每一維度成員信息，便於區分，更重要的是在聚合時由於數值型匹 配，JOIN效率高，便於聚合，而且代理鍵對緩慢變化維度有更重要的意義，它起到了標識 歷史 數據與新數據的作用，在原數據主鍵相同的情況下，代理鍵起到了 對新數據與 歷史 數據非常重要的標識作用。
有時我們也會遇到維度緩慢變化的情況，比如增加了新的產品，或者產品的ID號碼修改了，或者產品增加了一個新的屬性，此時某一維度的成員會隨著新的數據的加入而增加新的維度成員，這樣我們要考慮到緩慢變化維度的處理，對於緩慢變化維度，有三種情況：
在確定好事實數據和維度後，我們將考慮載入事實表。
在公司的大量數據堆積如山時，我們想看看裡面究竟是什麼，結果發現裡面是一筆筆生產記錄，一筆筆交易記錄… 那麼這些記錄是我們將要建立的事實表的原始數據，即關於某一主題的事實記錄表。
我 們的做法是將原始表與維度表進行關聯，生成事實表（圖六：pic6.jpg）。注意在關聯時有為空的數據時（數據源臟），需要使用外連接，連接後我們將 各維度的代理鍵取出放於事實表中，事實表除了各維度代理鍵外，還有各量度數據，這將來自原始表，事實表中將存在維度代理鍵和各量度，而不應該存在描述性信 息，即符合「瘦高原則」，即要求事實表數據條數盡量多（粒度最小），而描述性信息盡量少。
如果考慮到擴展，可以將事實表加一唯一標識列，以為了以後擴展將該事實作為雪花型維度，不過不需要時一般建議不用這樣做。
事 實數據表是數據倉庫的核心，需要精心維護，在JOIN後將得到事實數據表，一般記錄條數都比較大，我們需要為其設置復合主鍵和索引，以為了數據的完整性和 基於數據倉庫的查詢性能優化，事實數據表與維度表一起放於數據倉庫中，如果前端需要連接數據倉庫進行查詢，我們還需要建立一些相關的中間匯總表或物化視圖，以方便查詢。
在構建數據倉庫時，如果數據源位於一伺服器上，數據倉庫在另一 伺服器端，考慮到數據源Server端訪問頻繁，並且數據量大，需要不斷更新，所以可以建立准備區資料庫（圖七：pic7.jpg）。先將數據抽取到准備 區中，然後基於准備區中的數據進行處理，這樣處理的好處是防止了在原OLTP系統中中頻繁訪問，進行數據運算或排序等操作。例如我們可以按照天將數據抽取 到准備區中，基於數據准備區，我們將進行數據的轉換，整合，將不同數據源的數據進行一致性處理。數據准備區中將存在原始抽取表，一些轉換中間表和臨時表以 及ETL日誌表等。
時間維度對於某一事實主題來說十分重要，因為不同的時間有不同的統計數據信息，那麼按照時間記錄 的信息將發揮很重要的作用。在ETL中，時間戳有其特殊的 作用，在上面提到的緩慢變化維度中，我們可以使用時間戳標識維度成員；在記錄資料庫和數據倉庫的操作時，我們也將使用時間戳標識信息，例如在進行數據抽取 時，我們將按照時間戳對OLTP系統中的數據進行抽取，比如在午夜0：00取前一天的數據，我們將按照OLTP系統中的時間戳取GETDATE到 GETDATE減一天，這樣得到前一天數據。
在對數據進行處理時，難免會發生數據處理錯誤，產生出錯信息，那麼我們 如何獲得出錯信息並及時修正呢? 方法是我們使用一張或多張Log日誌表，將出錯信息記錄下來，在日誌表中我們將記錄每次抽取的條數，處理成功的條數，處理失敗的條數，處理失敗的數據，處 理時間等等，這樣當數據發生錯誤時，我們很容易發現問題所在，然後對出錯的數據進行修正或重新處理。
在對數據倉庫進行 增量更新時必須使用調度（圖八：pic8.jpg），即對事實數據表進行增量更新處理，在使用調度前要考慮到事實數據量，需要多長時間更 新一次，比如希望按天進行查看，那麼我們最好按天進行抽取，如果數據量不大，可以按照月或半年對數據進行更新，如果有緩慢變化維度情況，調度時需要考慮到 維度表更新情況，在更新事實數據表之前要先更新維度表。
調度是數據倉庫的關鍵環節，要考慮縝密，在ETL的流程搭建好後，要定期對其運行，所以 調度是執行ETL流程的關鍵步驟，每一次調度除了寫入Log日誌表 的數據處理信息外，還要使用發送Email或報警信息等，這樣也方便的技術人員對ETL流程的把握，增強了安全性和數據處理的准確性。
ETL構建數據倉庫需要簡單的五步，掌握了這五步的方法我們將構建一個強大的數據倉庫，不過每一步都有很深的需要研究與挖掘，尤其在實際項目中，我們要綜合考慮，例如如果數據源的臟數據很多，在搭建數據倉庫之前我們首先要進行數據清洗，以剔除掉不需要的信息和臟數據。
總之，ETL是數據倉庫的核心，掌握了ETL構建數據倉庫的五步法，就掌握了搭建數據倉庫的根本方法。不過，我們不能教條，基於不同的項目，我們還將要進行 具體分析，如父子型維度和緩慢變化維度的運用等。在數據倉庫構建中，ETL關繫到整個項目的數據質量，所以馬虎不得，必須將其擺到重要位置，將ETL這一 大廈根基築牢。
如果ETL和SQL來說，肯定是SQL效率高的多。但是雙方各有優勢，先說ETL，ETL主要面向的是建立數據倉庫來使用的。ETL更偏向數據清洗，多數據源數據整合，獲取增量，轉換載入到數據倉庫所使用的工具。比如我有兩個數據源，一個是資料庫的表，另外一個是excel數據，而我需要合並這兩個數據，通常這種東西在SQL語句中比較難實現。但是ETL卻有很多現成的組件和驅動，幾個組件就搞定了。還有比如跨伺服器，並且伺服器之間不能建立連接的數據源，比如我們公司系統分為一期和二期，存放的資料庫是不同的，數據結構也不相同，資料庫之間也不能建立連接，這種情況下，ETL就顯得尤為重要和突出。通過固定的抽取，轉換，載入到數據倉庫中，即可很容易實現。
那麼SQL呢？SQL事實上只是固定的腳本語言，但是執行效率高，速度快。不過靈活性不高，很難跨伺服器整合數據。所以SQL更適合在固定資料庫中執行大范圍的查詢和數據更改，由於腳本語言可以隨便編寫，所以在固定資料庫中能夠實現的功能就相當強大，不像ETL中功能只能受組件限制，組件有什麼功能，才能實現什麼功能。
所以具體我們在什麼時候使用ETL和SQL就很明顯了，當我們需要多數據源整合建立數據倉庫，並進行數據分析的時候，我們使用ETL。如果是固定單一資料庫的數據層次處理，我們就使用SQL。當然，ETL也是離不開SQL的。
主要有三大主流工具，分別是Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation.還有其他開源工具，如PDI(Kettle)等。
DW系統以事實發生數據為基礎，自產數據較少。
一個企業往往包含多個業務系統，均可能成為DW數據源。
業務系統數據質量良莠不齊，必須學會去偽存真。
業務系統數據紛繁復雜，要整合進數據模型。
源數據之間關系也紛繁復雜，源數據在加工進DW系統時，有些必須遵照一定的先後次序關系;
流水事件表：此類源表用於記錄交易等動作的發生，在源系統中會新增、大部分不會修改和刪除，少量表存在刪除情況。如定期存款登記簿;
常規狀態表：此類源表用於記錄數據信息的狀態。在源系統中會新增、修改，也存在刪除的情況。如客戶信息表;
代碼參數表：此類源表用於記錄源系統中使用到的數據代碼和參數;
數據文件大多數以1天為固定的周期從源系統載入到數據倉庫。數據文件包含增量，全量以及待刪除的增量。
增量數據文件：數據文件的內容為數據表的增量信息，包含表內新增及修改的記錄。
全量數據文件：數據文件的內容為數據表的全量信息，包含表內的所有數據。
帶刪除的增量：數據文件的內容為數據表的增量信息，包含表內新增、修改及刪除的記錄，通常刪除的記錄以欄位DEL_IND='D'標識該記錄。
可劃分為： 歷史 拉鏈演算法、追加演算法(事件表)、Upsert演算法(主表)及全刪全加演算法(參數表);
歷史 拉鏈：根據業務分析要求，對數據變化都要記錄，需要基於日期的連續 歷史 軌跡;
追加(事件表)：根據業務分析要求，對數據變化都要記錄，不需要基於日期的連續 歷史 軌跡;
Upsert(主表)：根據業務分析要求，對數據變化不需要都要記錄，當前數據對 歷史 數據有影響;
全刪全加演算法(參數表)：根據業務分析要求，對數據變化不需要都要記錄，當前數據對 歷史 數據無影響;
所謂拉鏈，就是記錄 歷史 ，記錄一個事務從開始，一直到當前狀態的所有變化信息(參數新增開始結束日期);
一般用於事件表，事件之間相對獨立，不存在對 歷史 信息進行更新;
是update和insert組合體，一般用於對 歷史 信息變化不需要進行跟蹤保留、只需其最新狀態且數據量有一定規模的表，如客戶資料表;
一般用於數據量不大的參數表，把 歷史 數據全部刪除，然後重新全量載入;
歷史 拉鏈，Upsert,Append,全刪全加;載入性能：全刪全加，Append，Upsert， 歷史 拉鏈;
APPEND演算法，常規拉鏈演算法，全量帶刪除拉鏈演算法;
APPEND演算法，MERGE演算法，常規拉鏈演算法，基於增量數據的刪除拉鏈演算法，基於全量數據的刪除拉鏈演算法，經濟型常規拉鏈演算法，經濟型基於增量數據的刪除拉鏈演算法，經濟型基於全量數據的刪除拉鏈演算法，PK_NOT_IN_APPEND演算法，源日期欄位自拉鏈演算法;
此演算法通常用於流水事件表，適合這類演算法的源表在源系統中不會更新和刪除，而只會發生一筆添加一筆，所以只需每天將交易日期為當日最新數據取過來直接附加到目標表即可，此類表在近源模型層的欄位與技術緩沖層、源系統表基本上完全一致，不會額外增加物理化處理欄位，使用時也與源系統表的查詢方式相同;
此演算法通常用於無刪除操作的常規狀態表，適合這類演算法的源表在源系統中會新增、修改，但不刪除，所以需每天獲取當日末最新數據(增量或全增量均可)，先找出真正的增量數據(新增和修改)，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新的增量數據作為開鏈數據插入到目標表即可。
此類表再近源模型層比技術緩沖層、源系統的相應表額外增加兩個物理化處理欄位START_DT(開始日期)和END_DT(結束日期)，使用時需要先選定視覺日期，通過START_DT和END_DT去卡視覺日期，即START_DT'視覺日期';
此演算法通常用於有刪除操作的常規狀態類表，並且要求全量的數據文件，用以對比出刪除增量;適合這類演算法的源表在源系統中會新增，修改，刪除，每天將當日末最新全量數據取過來外，分別找出真正的增量數據(新增，修改)和刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新增量數據中真正的增量及刪除數據作為開鏈數據插入到目標表即可，注意刪除記錄的刪除標志DEL_IND會設置為『D』;
此類表在近源模型層比技術緩沖層，源系統的相應表額外增加三個物理化處理欄位START_DT(開始日期)，ENT_DT(結束日期)，DEL_IND(刪除標准)。使用方式分兩類：一時一般查詢使用，此時需要先選定視角日期，通過START_DT和END_DT去卡視角日期，即START_DT『視角日期』，同時加上條件DEL_IND 'D';另一種是下載或獲取當日增量數據，此時就是需要START_DT'視角日期' 一個條件即可，不需要加DEL_IND 'D'的條件。
此演算法通常用於流水事件表，適合這類演算法的源表在源系統中不會更新和刪除，而只會發生一筆添加一筆，所以只需每天將交易日期為當日的最新數據取過來直接附加到目標表即可;
通常建一張名為VT_NEW_編號的臨時表，用於將各組當日最新數據轉換加到VT_NEW_編號後，再一次附加到最終目標表;
此演算法通常用於無刪除操作的常規狀態表，一般是無需保留 歷史 而只保留當前最新狀態的表，適合這類演算法的源表在源系統中會新增，修改，但不刪除，所以需獲取當日末最新數據(增量或全量均可)，用於MERGE IN或UPSERT目標表;為了效率及識別真正增量的要求，通常先識別出真正的增量數據(新增及修改數據)，然後再用這些真正的增量數據向目標表進行MERGE INTO操作;
通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據轉換加到VT_NEW_編號;另一張名為VT_INC_編號，將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增和修改)放入VT_INC_編號，然後再用VT_INC_編號對最終目標表進行MERGE INTO或UPSERT。
此演算法通常用於無刪除操作的常規狀態表，適合這類演算法的源表在源系統中會新增、修改，但不刪除，所以需每天獲取當日末最新數據(增量或全增量均可)，先找出真正的增量數據(新增和修改)，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新增量數據作為開鏈數據插入到目標表即可;
通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據轉換加到VT_NEW_編號;另一張名為VT_INC_編號，將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增和修改)放入VT_INC_編號，然後再將最終目標表的開鏈數據中的PK出現在VT_INT_編號中進行關鏈處理，然後將VT_INC_編號中的所有數據作為開鏈數據插入最終目標表即可。
此演算法通常用於有刪除操作的常規狀態表，並且要求刪除數據是以DEL_IND='D'刪除增量的形式提供;適合這類演算法的源表再源系統中會新增、修改、刪除，除每天獲取當日末最新數據(增量或全量均可)外，還要獲取當日刪除的數據，根據找出的真正增量數據(新增和修改)以及刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務時間)，然後再將增量(不含刪除數據)作為開鏈數據插入到目標表中即可;
通常建三張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據 (不含刪除數據)轉換載入到VT_NEW_編號;第二張表名為VT_INC_編號，用VT_NEW_編號與目標表中的昨日的數據進行對比後找出真正的增量數據放入VT_INC_編號;第三張表名為VT_DEL_編號，將刪除增量數據轉換載入到VT_DEL_編號;最後再將最終目標表的開鏈數據中PK出現在VT_INC_編號或VT_DEL_編號中的進行關鏈處理，最後將VT_INC_編號中的所有數據作為開鏈數據插入最終目標表即可;
此演算法通常用於有刪除操作的常規狀態表，並且要求提供全量數據，用以對比出刪除增量;適合這類演算法的源表在源系統中會新增、修改、每天將當日末的最新全量數據取過來外，分別找出真正的增量數據(新增、修改)和刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效記錄)進行關鏈操作(即END_DT關閉到當前業務時間)，然後再將最新數據中真正的增量數據(不含刪除數據)作為開鏈數據插入到目標表即可;
通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新全量數據轉換到VT_NEW_編號;另一張表名為VT_INC_編號,將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增、修改)和刪除增量數據放入VT_INC_編號，注意將其中的刪除增量數據的END_DT置以最小日期(借用);最後再將最終目標表的開鏈數據中PK出現再VT_INC_編號或VT_DEL_編號中的進行關鏈處理，然後將VT_INC_編號中所有的END_DT不等於最小日期數據(非刪除數據)作為開鏈數據插入最終目標表即可;
此演算法基本等同與常規拉演算法，只是在最後一步只將屬性非空即非0的記錄才作為開鏈數據插入目標表;
此演算法基本等同於基於增量數據刪除拉鏈演算法，只是在最後一步只將屬性非空及非0的記錄才作為開鏈數據插入目標表;
此演算法基本等同於基於全量數據刪除拉鏈演算法，只是在最後一步只將屬性非空及非0的記錄才作為開鏈數據插入目標表;
此演算法是對每一組只將PK在當前VT_NEW_編號表中未出現的數據再插入VT_NEW_編號表，最後再將PK未出現在目標表中的數據插入目標表，以保證只進那些PK未進過的數據;
此演算法是源表中有日期欄位標識當前記錄的生效日期，本演算法通過對同主鍵記錄按這個生效日期排序後，一次首尾相連行形成一條自然拉鏈的演算法
『肆』 ETL過程的數據清洗和整合
主要目的是記錄ETL流水線過程中所有質量單元出現的錯誤時間。也可用於其他應用之間傳輸數據的集成應用中。
如圖：
錯誤事件事實表：
主表。包含錯誤日歷日期，錯誤產生的批處理作業以及產生錯誤的單元模塊。
每個錯誤在表中用一行表示。
包含一個單列的主鍵，作為錯誤時間的鍵。
批處理維度:
可以泛華為針對數據流的處理步驟，而不僅僅是針對批處理。
錯誤事件細節事實表：
每行確定與錯誤有關的某個特定記錄的個體欄位。因此某個高級別的錯誤事件事實表中的一行激活的復雜結構或業務規則對應錯誤細節事實表中的多行。
審計維度用於後端裝配ETL系統的每個事實表。
在貨運事實表將按照批處理文件每天更新一次，假設一天的工作順利進行沒有產生錯誤標記，此時將建立唯一的一行審計維度，將被附加到今天所載入的所有事實行。所有的分類，分數，版本號都將相同
假設出現異常情況，則需要不止一個審計維度行用於標記這一情況。
重復數據刪除：需要考慮保留那些數據
匹配和數據保留：按照來自所有可能源系統的列值並且清楚的定義了優先順序的業務規則，用於確保每個存在的行具有最佳的保留屬性。
一致性處理包含所有需要調整維度中的一些或者所有列的內容以與數據倉庫中其他相同或者類似的維度保持一致的步驟。
建立一致性維度的過程需要採用敏捷方法，對兩個需要一致性處理的維度，他們必須至少有一個具有相同名稱和內容的公共屬性。
數據倉庫-概述-讀書筆記一
數據倉庫-DW/BI架構對比-讀書筆記二
數據倉庫-事實表/維度表技術-讀書筆記三
維度處理-數據倉庫-讀書筆記(四)
數據倉庫-高級事實表技術-讀書筆記五
數據倉庫-高級維度表技術-讀書筆記六
數據倉庫，零售業務舉例，維度模型設計4步驟，讀書筆記（七）
數據倉庫-零售業務舉例維度表設計細節-讀書筆記（八）
數據倉庫-零售業務舉例如何提高倉庫擴展能力-讀書筆記（九）
數據倉庫-零售業務中庫存如何設計-讀書筆記(十)
如何使用緩慢變化維技術
數據倉庫-訂單管理應該注意那些
ETL中前期數據分析、變化數據探測，數據獲取 注意事項
數據倉庫基礎概念分享
數據倉庫工具箱
如果您覺得我用心了，覺得您有所收獲，麻煩關注下我吧，您的關注就是我的動力，因為有你，我就不是一個人在前行。
『伍』 Etl工具將sqlserver數據同步到oracle設計說明
軟體說明
通過etl工具定時將SqlServer指定的表數據同步到oracle資料庫
在資料庫建立增刪改的觸發器。觸發器將變更放到臨時表裡。
通過etl工具讀取臨時表同步給oracle
優點：兄緩笑比較實時
缺點：哪蘆影響到業務系統，因為需要在業務系統建立觸發器
實例說明：
例如在sqlserver有一張用戶表（sys_user）需定時同步oracle資料庫的用戶表，
包括新增、刪除、修改同步
給同步的表建三類觸發器：
insert觸發器：向表中插入數據時被觸發；
update觸發器：修改表中數據時被觸發；
delete觸發器：從表中刪除數據時被觸發。
以sqlserver的用戶表舉例，
Sqlserver的sys_user表，有兩個欄位id，name
具體流程：
以新增數據舉例
Ø 一、在sqlserver新建觸發器trigger_sysuser_insert
if (object_id('trigger_sysuser_insert') is not null)
drop trigger trigger_sysuser_insert
go
create trigger trigger_sysuser_insert
on sys_user --表名
for insert --插入後觸發
--instead of insert --插入前觸發,使用插入前觸發時,不執行默認插入
as
--開始執行邏輯
declare @id int, @name varchar(20);
select @id = id, @name = name from sys_user; -------------- inserted 存放了當前插入的值
--select @name,@age
---創建臨時表
if not exists (select * from sysobjects where id = object_id('##sys_user_insert')
and OBJECTPROPERTY(id, 'IsUserTable') = 1)
create table ##sys_user_insert
(
id int,
name varchar(32)
);
insert into ##sys_user_insert (id,name) values(@id,@name);
go
在sys_user新增數據時會被觸發，將新增的數據加入臨時表##sys_user_insert，此時
的臨時表 ##sys_user_insert會增加一條記錄
Ø 二、配置elt流程
節點1 從臨時表讀取數據，寫入數據流
節點2 從數據流獲取數據寫入oracle
節點3 從sqlserver的臨時表刪除已經被同步的記錄
Ø 三、建立作業調度
設置調度周期
適用增量數據同步
在要同步的源表羨含里有時間戳欄位，每當數據發生新增，時間戳會記錄發生變化的時間，etl工具根據時間范圍定時同步數據
優點：基本不影響業務系統
缺點：要求源表必須有時間戳這一列，適用增量場景，修改、刪除不太適用
定時清空oracle數據源，將sqlserver的數據全盤拷貝到oracle數據源。一般用於數據量不大，實時性要求不高的場景。
優點：基本不影響業務系統，開發、部署都很簡單
缺點：效率低
Etl流程
結論
准能現場數據同步，涉及增、刪、改的同步，比較適用觸發器的方式進行數據同步，但觸發器仍會存在失效的情況，若現場有數據質量系統，定期數據稽核，查缺補漏，保證兩邊資料庫的一致性；
『陸』 如何實現多個系統間的數據同步
像這樣的需求，完全可以考慮上數據中心，用ETL作數據同旦梁姿步。
好處自然是可以把項目做大，可擴模絕展性強。
甲方是否同意就看你們的市場和渣判售前了