SSIS工程師為您揭秘SQL Server數(shù)據(jù)流
我們在操作SQL Server數(shù)據(jù)庫的過程中，常常會聽到“數(shù)據(jù)流”這個術(shù)語，那么到底什么是數(shù)據(jù)流呢？本文我們就介紹一下數(shù)據(jù)流的相關(guān)知識，本文是轉(zhuǎn)載的一位SSIS工程師的文章，接下來就讓我們一起來了解一下這部分內(nèi)容吧。
數(shù)據(jù)流一瞥
SSIS的引擎（engine）是內(nèi)存式（in-memory）的：從源（source）讀數(shù)據(jù)，在內(nèi)存中執(zhí)行package，再把結(jié)果寫到端（destination）。盡量不碰外存是其高性能的原因之一。很多以前使用ETL（Extract-Transform-Load）工具的人需要對此調(diào)整觀念：那些工具先把數(shù)據(jù)加載到數(shù)據(jù)庫里再做SQL轉(zhuǎn)換，其實是ELT（Extract-Load-Transform）。Matt講了個很有趣的案例：有位客戶的package以前運行只要幾分鐘，自從服務(wù)器升級到新機器后竟然更慢了，要花一個小時。那個package很簡單，只是源到端拷貝，中間沒有轉(zhuǎn)換（transform），因此客戶很生氣。
Matt他們急忙去會診，才發(fā)現(xiàn)這個package的源和端以前就在它所運行的那臺機器上，在美國； 后來升級了的機器在中國，源和端都跑到了中國來，而package還是在美國那臺機器上運行。結(jié)果這個package所做的就是從中國讀出若干GB的數(shù)據(jù)到美國的內(nèi)存，再拷回中國……Matt說，類似的客戶問題其實并不少見。SSIS在設(shè)計時（design time）階段就確定了數(shù)據(jù)流的元數(shù)據(jù)（metadata）。它在運行之前就精確知道了運行時的列將有多寬，轉(zhuǎn)換需要多少內(nèi)存，等等。
數(shù)據(jù)流水線（pipeline）
當數(shù)據(jù)流啟動時，源就開始把一行行數(shù)據(jù)填到一個類似桶的緩存（buffer）中。源根本不知道下游是什么。一旦緩存滿了，桶就隨著流水線流到下游組件（component）上，同時引擎抓一個新的空緩存過來給源。源根本不知道這一切，它只是不斷地填桶。有時源填了太多的桶，轉(zhuǎn)換和端都來不及應(yīng)付了；此時引擎會啟動反壓（backpressure）機制，讓源睡眠。
等到流水線又有空間之后，源被喚醒繼續(xù)填桶。其實在實現(xiàn)上，源甚至都不知道自己被催眠過（好可憐）……直到所有源數(shù)據(jù)行都發(fā)光了，源才在最后一個緩存上貼個“行集末（End Of Rowset）”的標簽，把它發(fā)出去，告訴下游組件再沒有新數(shù)據(jù)了。
轉(zhuǎn)換與緩存拷貝
SSIS的高性能有部分歸功于它在內(nèi)存使用上比較聰明。在緩存之間拷貝數(shù)據(jù)是耗時的，因此引擎會盡量減少緩存拷貝。按照緩存使用的不同，可將眾多轉(zhuǎn)換組件分為三類。
第一類是同步（synchronous）轉(zhuǎn)換，它們一般逐行對數(shù)據(jù)做就地修改，從不拷貝緩存。它們有可能增加新行，比如數(shù)據(jù)轉(zhuǎn)換（Data Convert）和派生列（Derived Column）轉(zhuǎn)換，而仍然是同步的：引擎事先確定了新列將加在哪里，提前就在緩存里加了空列，只是上游組件看不到這些空列罷了。
異步（asynchronous）轉(zhuǎn)換會動態(tài)創(chuàng)建新緩存，包括兩小類: 部分阻塞（Partially Blocking）轉(zhuǎn)換，一伺新緩存滿了就把它輸出，比如聯(lián)合全體（Union All）組件接受多個輸入流，一旦從各輸入得到了足夠多的行就把它輸入到一個新緩存里。由于要拷貝數(shù)據(jù)，這種轉(zhuǎn)換比同步轉(zhuǎn)換慢；但和全阻塞（Blocking）轉(zhuǎn)換相比就好多了。排序（Sort）、聚集（Aggregate）這些全阻塞轉(zhuǎn)換在接收完所有輸入行之前，是不會輸出一行的。這是由運算本身的特點決定的：不到看到所有數(shù)據(jù)，是無法確定哪個是最小值的。
因此，在使用全阻塞轉(zhuǎn)換時要格外審慎，尤其是數(shù)據(jù)量很大時。一旦內(nèi)存用完，緩存被置換到硬盤上，性能就完了。要想提高數(shù)據(jù)流性能，最好設(shè)法從package中去除全阻塞轉(zhuǎn)換。
線程機制
要理解數(shù)據(jù)流，還需要了解其線程機制。流水線在運行時被分成若干執(zhí)行樹（Execution Trees）。每個創(chuàng)建新緩存的組件就是一棵新執(zhí)行樹的起點；因此起點要么是個數(shù)據(jù)源，要么是個異步轉(zhuǎn)換。下圖的數(shù)據(jù)流中有5棵執(zhí)行樹，如藍箭頭所示。引擎限定了每棵樹中最多工作的緩存數(shù)（目前定為五個），一旦更多緩存進來，就啟動反壓。注意到多播（Multicast）和條件分割（Conditional Split）轉(zhuǎn)換都是同步的，它們在分割數(shù)據(jù)流時并不創(chuàng)建新緩存；引擎只是創(chuàng)建了一些能映射到同一塊內(nèi)存的虛擬緩存。所以即使你多播20次也不會看到內(nèi)存消耗增多。
此圖修改自Matt的幻燈片
值得一提的是，數(shù)據(jù)流線程調(diào)度在SQL 2008版本中被改進了：在2005版中，每棵樹只分到一個線程執(zhí)行，其問題是對于圖中右邊那種較長的樹，雖然樹里都是一序列同步轉(zhuǎn)換，但每次只能在樹中移動一個緩存，執(zhí)行完它之后才能開始執(zhí)行下一個緩存。很多人為了打碎較長的執(zhí)行樹，就在中間插入一個單輸入的聯(lián)合全體（Union All）組件，由于它是異步的，就能間接引入另一個線程。
而現(xiàn)在，我們在2008版中改為讓每個緩存上都有一個線程在執(zhí)行，這樣一棵樹中就可以有多個線程在執(zhí)行?？赡艿谝粋€線程先把一個緩存進行了三個轉(zhuǎn)換， 然后第二個線程撿起這個緩存繼續(xù)向下游轉(zhuǎn)換，同時第一個線程開始撿起下一個緩存。這樣就再也不需要上述間接的方法了。
關(guān)于SQL Server數(shù)據(jù)流的相關(guān)知識就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！
【編輯推薦】
分享到微信 
分享到微博
