205
SQL Server 2012研發團隊背後的故事
本文講的是SQL Server 2012研發團隊背後的故事,在切入正題之前，就讓浸泡在數據海洋裏的我們，看幾個並不陌生的場景吧。場景一：痛苦的升級
三十六歲的吳桐坡是一個電商網站的首席技術官，最近有點頭疼：業務旺季就在眼前，現在的內存、盤陣、操作係統和應用平台已經有點扛不住。老板卻已發話，今年要基於用戶消費行為的統計與分析，上線更多的新品類。唉，又要和部門裏的兄弟們熬夜了。好在之前做了不少準備工作，對這次升級的成本和問題心裏大概有底。“但過去幾年，哪次硬件變更和軟件升級沒出過岔子?我怎麼敢跟老板拍胸脯，說升級後的係統馬上能順利支持5000-6000次/秒的在線交易請求，而不影響任何業務?“
場景二：鬱悶的IT
修養很好的俞年發火了，讓這位年屆不惑、掌控某跨國餐飲連鎖品牌的職業經理人失控的原因很簡單，當他早上10點走進辦公室，沒有看到昨天的運營報表——這讓他想起昨晚從一位消息靈通的分析師朋友處得知，競爭品牌最近兩個月的營業額大幅超過自家，這是什麼原因?現在居然連頭一天的運營報表都沒正常出現，IT部門幹什麼去了?被俞年召來勐K一頓的IT經理任願也很鬱悶。“不知道為什麼，頭天晚上從各個營業點上傳來的原始數據，未按正常流程進行匹配和清洗，最終沒導入數據倉庫，導致今天早晨沒法生成報表，但老板也不至於這樣生氣吧?” 檢查數據集成進程時發現原先僅需半小時的一個步驟用了近兩小時，還是通不過，也找不出原因，鬱悶…
場景三：抓狂的網購
二十九歲的白領史博妍與姐妹們一樣，緊張的工作節奏讓她無暇逛街，幸好還有網購。作為每月在網購過千元的重度用戶，怎能錯過各大網店的春夏促銷?周末晚上，當她打開瀏覽器，卻發現最鍾愛的網店卻無法訪問，頁麵總是顯示“響應超時”，而且怎麼刷新也沒用。難道下周要穿著去年的衣服去拜訪客戶和“周末大轟趴”?這個假設讓她很抓狂，抓起了電話向網店客服投訴。數分鍾後，網店的數據庫管理員李易淩接到客服部門的排障需求，他能否在很短的時間裏，從海量的Query記錄中，找出那條引發故障的Query?
那些年，他們一起追尋的創新
您一定能猜到上麵的三個典型場景，就藏著SQL Server 2012研發團隊所要解決的三個典型問題，而解決這三個問題的主要團隊成員，就是微軟亞太研發集團服務器與開發工具事業部的一群年輕工程師們——而解決上述三個問題的功能分別是Distributed Replay、SQL Server集成服務(SSIS)和擴展事件(xEvent)。
正如微軟其他應用於關鍵業務的產品，SQL Server 2012功能設計的來源主要有三類，即麵向全球範圍內的最終用戶與分析師的調研、全球技術支持服務部門的反饋，以及開發團隊的前瞻性思考。
故事一：跨越七年的靈感
Distributed Replay、集成服務和擴展事件也不例外，而其中從需求發掘、設計產生到功能實現時間跨度最大的，是Distributed Replay。而這一特性的靈感在2005年左右，幾乎同時出現在姚鋼和王清越的腦海裏。
高級開發主管姚鋼現在已申請下Distributed Replay的專利，觸動他的是做SQL Server技術支持的六年經曆，“客戶經常在升級硬件和軟件過程中碰到各種問題，尤其是新硬件和操作係統環境中，數據引擎性能的下降讓他們很是撓頭。是不是能有一個功能，讓客戶提前知道升級後，可能遇到的各種狀況?“
而當時還在微軟總部從事SQL Server引擎性能優化的王清越也在想，“如果能開發一個工具，讓客戶在多線程、高並發度的環境下，模擬實際應用場景，從而實現在變更軟、硬件時預知這些變化對數據引擎性能的影響，不就能讓他們不再憂心升級後的變數麼?“
於是，當他們2008年加入SQL Server中國研發團隊後，這個想法很自然地被提到了SQL Server 2012產品規劃中。
讓姚鋼和王清越印象尤為深刻的是，2010年10月功能基本開發完成後，一位遠道而來的歐洲電子商務客戶提出，用他們的真實數據讓Distributed Replay模擬5000-6000次/秒在線交易請求的生產環境?開了幾個夜車後，兩周內姚鋼和同事們順利實現了客戶需求——這讓項目組也很是欣慰，因為雖然設計目標就是實現每秒5000-6000次的負載模擬，但此前還未在實驗室環境下得到過驗證。
隨著SQL Server 2012的上市，國內類似吳桐坡這樣需求的CTO們，將不用再為軟、硬件變更可能帶來的性能變化而煩惱了。
故事二：為了一致與可靠
SQL Server集成服務要解決的則是IT經理們不得不麵對的問題 —— 如何在有限時間和資源前提下，保證“數據的一致性和可靠性“，不至於當老板要看報告時，卻交不出來。在集成服務的項目經理卓偉雄看來，幫助兩個重量級本地客戶解決類似問題的經曆是在產品開發中最值得回味的，”這兩個客戶，一個來自保險業，一個來自連鎖餐飲業。他們處理數據的共同特征是，來自各個分支機構的數據都在晚上運行，而實際上每天晚上運行SSIS包的時間窗口其實很短。在決策層第二天到辦公室之前，數據平台要完成的事情有很多——首先是把數據從不同的來源取出，然後導入到數據倉庫。從數據倉庫到用戶能使用的報表，多維數據集等等時間的掌控很重要。而在SQL Server 2012之前，當SSIS包在抓取、導入過程中出了問題，管理員往往需要花費數十分鍾乃至幾個小時，逐一找出並解決SSIS包抓取失敗或延遲等問題。如果問題一多，第二天沒法交付報告就成了很自然的事。而現在，管理人隻需要通過預先建立的故障排除和性能調優功能，在SSIS包運行過程中，便能自動拿到最可能引發問題的事件記錄，而用戶可以馬上把這些事件交給相關的技術部門去解決。”
讓測試開發工程師吳曉晨記憶猶新的則是在最後測試階段，一個特殊的場景下運行新功能時，往往比平時慢2、3秒，但一位同事硬是堅持三、四周解決了這個問題，因為他們覺得“如果每個客戶都節約幾秒鍾，那麼全球來看就是一個了不得的大數字。”
故事三：DBA的黎明
擴展事件的誕生，是為了幫助李易淩這樣的數據庫管理員們。當碰到這樣的問題，他可以首先將當天的SQL Query(像場景三中的網店會有幾千種SQL Query)的響應時間分組求平均值，然後按組排序以迅速找到花費時間最長的那一組Query，接著打開這一組Query排序，便能找到花費時間最長、甚至是無法響應的Query，從而迅速找到問題根源並進行排除。更為重要的是，輕量化的擴展事件隻需很小的服務器資源開銷，就能抓取50GB的Trace包。
SQL Server 2012的發布，對負責擴展事件的開發主管徐進、測試主管陳玉祥來說同樣意義非凡——因為盡管從SQL 7.0時代就有了SQL Profiler工具，但直到SQL Server 2012有了擴展事件才高度滿足了數據庫管理員的大量真實需求。
最後更新：2017-10-06 17:33:23