四月期間，驚傳某蘇州台商自境外移入 H7N9，當時不免讓人餘悸猶存，只因數年前 SARS 疫情爆發並肆虐，不僅在各地傳出確診甚至死亡病例，也曾上演駭人聽聞的封院故事，無論如何，大家都不想回到過去那段驚慌歲月。

令人稍感寬慰的是，透過黏膜、唾液等途徑在共住者之間傳播的 H7N9 病毒，雖然致死率不輸 SARS，但比較不會在短期內大規模集中爆發；然而有專家  提醒，H7N9 不乏進化後、再引起流感大爆發的「潛能」，尤其入秋期間，更宜小心謹慎，因此面對 H7N9 防疫工作，萬萬不能因公眾關注度轉淡而掉以輕心。

如何減緩 H7N9 的感染力與致死率？不可諱言，箇中主要癥結，仍繫於醫藥界的病毒研究成果，但扣除掉病毒研究，針對疫情防治、保障民眾生命與健康等事項，主管機關尚有另一項重大任務，即是組織「防疫大隊」，藉此在疫期爆發的早、中、後期，皆施以適當處置，力求讓傷害減損到最低程度。

比起十餘年前的 SARS，如今要想建立 H7N9 防疫大隊，不論主客觀條件，顯然都更為有利，主要關鍵就在於，近 1~2 年來風起雲湧的海量資料分析技術，一方面有助於打破由來已久的資料疆界，藉此讓散落於各個公民營機構的相關資料，得以整合與透通，利於被交互善用，二方面可用以彙集來自國內外的未結構化資料，譬如疫情相關新聞，與各項醫學報告，利於主管機關精確掌握 H7N9 疫情的最新趨勢脈絡；三方面則將結構化資料、非結構化資料，通通予以融會貫通，接著深入剖析這些海量資料，從中萃取出足以遏阻疫情擴散的關鍵因子。

對抗疫情，彷若犯罪偵防情節

稍早前，在本系列「迷思止步，資料庫應用大無限！」第五篇專欄文章，曾以「沒有好工具，豈能抓住魔鬼細節？」為題，闡述一家名為 Klout 的公司，如何透過 Hadoop、Hive 及 SQL Server 2012 等海量資料處理暨分析技術，成功發揮了「垃圾變黃金」的奇效，推出饒富吸引力的「社群媒體用戶影響力衡量」服務。

除此之外，此篇文章亦援引美國 CBS 電視公司製作的「疑犯追蹤 (Person of Interest)」影集，闡明情治機關可以借助海量資料分析技術，藉由眾多資訊的抽絲剝繭，有效制止犯罪活動，適時挽救無辜百姓的生命財產。

事實上，看似型態大不相同的 H7N9 防疫需求，裡頭同樣蘊含了許許多多的魔鬼細節，也頗適合依樣畫葫蘆，沿用海量資料分析技術來創造妙效。

比方說，意欲快速串接不同單位的資料，並一舉融合外部的非結構化資料、串流資料，用戶垂手可得的工具與利器，便可謂不少。職掌疫情的主管機關，即可透過 Microsoft Big Data 整合式平台，輔以適用於 SQL Server 或 SQL Server PDW 的 Hadoop 連接器，輕鬆整合 Hadoop 與資料倉儲、商業智慧解決方案，藉由結構化及未結構化資料來深入了解疫情發展狀況。

當然，疫情防治畢竟涉及人命關天，往往講求快、狠、準，務必爭取時效加緊設計並部署 MapReduce 程式，動員大量運算資源，並利用最短時間進行資料轉換與清理，倘若套用傳統佈建模式，少不得仍需要費時琢磨，恐對防疫成效產生延誤。此時用戶不妨善用 Windows Azure Service 平台，一方面獲取數百種應用程式、智慧型資料挖掘演算法 ，及 SQL Server Integration Services(SSIS)、Data Quality Services 等資料轉換及清理工具之豐富素材，二方面透過簡單易用的 HDInsight 服務，輕鬆配置整個 Hadoop 環境，藉由雲端服務開啟隨需擴充的方便之門，順勢化解防疫作戰的燃眉之急。

一旦建立海量資料運算環境，緊接著，相關人員亦無須歷經冗長的學習曲線，即能動用熟悉工具執行關鍵分析任務，一來可運用 Excel 的 Hive 增益集來分析 Hadoop 資料集，二來也可利用 SQL Server 2012 當中的 PowerPivot 或 Power View 機制，將 Hadoop 資料集予以視覺化並善加分析，透過這些途徑，即可迅速擷取防疫致勝的寶貴線索。

憑藉精準佈局，力阻疫情擴大

究竟這套奠基於海量資料技術的「防疫大隊」劇本，如何確保民眾的健康與安全？首先，透過衛生與出入境管理單位的異質資料整合，主管機關即可精確統計各縣市居民接觸疫區的頻率，從而針對頻度較高的縣市，強化早期篩檢的工作，並未雨綢繆準備相對大量疫苗，預先配置到這些轄區內的市立或署立醫療院所。

緊接著，主管機關亦可藉由新聞及醫療文獻的探索，愈步愈趨地緊盯疫情動向，繼而剖析各地醫院的醫療及隔離設施的整備度，藉以作為資源補強或調度的依據，以便於能靠著充分的準備，以及有條不紊的安置措施，為確診病例進行有效的診斷與隔離，使得病患獲致最悉心的照護，也一併降低其餘民眾的恐慌。由此可見，Big Data 不僅是企業增進盈利的法寶，也是確保國泰民安的關鍵技術之一，重要性不言可喻。

幾經業者長時間疾呼與鼓舞，現今完全不識 BI 為何物的企業，理應少之又少，姑且不論使用程度是深是淺，大多數企業或多或少，都已經採用相關工具，早就與 BI 結下了不解之緣。

既然眾多企業都已擁抱 BI，按理說，一群高階主管早已練就火眼金睛，足以在世局尚且渾沌不明之際，即可搶先洞察一切，進而做出犀利有效的決策，締造人人稱羨的營運績效。只不過，根據知名分析機構的報告顯示，綜觀目前企業組織當中的所有潛在使用者，認為 BI 技術真能滿足實際需求的比例，其實僅徘徊在約莫 28% 的低檔。

換言之，即使企業為了提昇決策品質與速度，以期在市場競局中脫穎而出，因而導入BI，但往往在上線使用後才乍然醒悟，原來理想與現實之間的落差甚大，挾著相較於預期目標三成不到的功效，確實難以拉高戰力指數。

凡事假手 IT，難免緩不濟急

為何如此？先回顧 BI 演進史。最古早的商業智慧，係將資料儲存在資料庫中，首當其衝的挑戰，即是大量運算之耗時甚鉅，再者，要求 Power User 個個都懂得使用 SQL 語法，也未免強人所難。此後進入線上分析處理 (OLAP) 世代，藉由 Cube 來取代關聯式資料表，作為驅動多維度資料模型之建立、以及資料彙總分析的軸心。

雖然相較於傳統關聯式資料表，OLAP Cube 蘊含的資料結構，確實更契合 BI 主題，但論及 Cube 建立、資料匯入、分析程式執行，乃至於報表產出，整段歷程，仍不可免俗夾雜技術門檻，以一個不諳資訊或統計的高階主管而言，要他重頭到尾親力親為，跑出能作為決策參考的 BI 報表，幾乎是不可能的任務，因此必須由 IT 人員代為操刀。

然而這般模式潛藏諸多盲點，因而削弱或壓抑BI應用成效。首先，IT 人員普遍處在緊繃的作業環境，上至幫公司打造黃金十年的應用開發，下至幫同仁排除 PC 故障，不論價值高低，樣樣都得攬在身上，在左支右絀之下，怎有餘力快速處理報表作業？如此一來，倘若高階主管亟欲體檢當下促銷活動成效，趕緊搶在黃金時間調整戰術，藉以截長補短，恐怕很難如願以償，終至任由計畫趕不及變化，眼睜睜錯失大好商機。

其次，人非聖賢，任誰都有思慮欠周、或者溝通表達不良的時刻，不論是日理萬機的高階主管、負責執行計畫的行銷人員，乃至於產出報表的 IT 人員，任何一個環節的疏漏，那怕只是屈屈一兩個欄位，都將導致報表不敷需求，此時又得拜託 IT 人員在百忙之中撥出空檔，再跑一次分析，無異又是蹉跎光陰！

自助式分析＋互動性報表，打造勝利方程式

要想填補上述種種缺憾，顯然需要在 BI 分析載體之上，加入快速的資料探索、視覺化功能等元素，唯有如此，才得以真正賦予使用者深入的洞察力，藉此營造「自助式 BI」環境，好讓使用者無須事事勞煩 IT 人員，信手拈來皆能獨力擷取商業智慧。

微軟的 SQL Server，無疑正是融合這些元素的巧妙工具。首先，它提供 Tabular 技術，讓所有層級的使用者，都能從任何來源存取與混搭整合資料，從而建立富含吸引力的報告或分析應用程式，更難能可貴的是，使用者還可透過 Excel 2013 或 SharePoint 2013 等熟悉工具，輕易發揮協同合作、共享智慧等妙效；因此，透過該項技術的使用，可為一些嫻熟 Excel (或 SharePoint )、但卻不懂資料庫的人們，搭起一道自助式商業智慧的天梯。

其次，微軟伴隨 SQL Server 2012 的推出，提供了一項名為 Power View 的全新報表分析工具，它是一項可適用於 Excel 2013 與 SharePoint 2013 的 SQL Server 2012 SP1 Reporting Services 增益集功能，憑藉著 Silverlight 視覺化技術的運用，並整合 BISM 表格式模型高效能運算能力，讓使用者得以享有高度互動性的網路式拖放資料查詢、視覺化功能與簡報經驗，以便於加快思考速度，獲致全新洞察力。探究其奧妙，乃在於任何使用者只要短短幾秒鐘，都能依照自己的想法，輕鬆建立報告，建完後若欲變更資料欄位、抑或改變資料外型，僅需數個簡單步驟，就能得償所願，更令人嘖嘖稱奇的是，Power View 另提供了功能強大的時間播放軸，以利使用者更加耳聰目明，能夠迅速辨別大勢所趨，或是揪出一些本不易察覺的異狀。

總括而論，Power View 可支援多圖多表匯出到 PowerPoint，再加上這些圖表數據，都連結到 BISM Tabular 或 PowerPivot 資料源，意謂由此產生的簡報深具互動性，絕非靜止不動的格局，其間任何一個表格或圖形，都可因為即時連結資料庫，反應當下真實數字。

即有電子商務業者，看出 BISM Tabular 與 Power View 的玄妙之處，於是善用 SQL Server 架設即時戰情中心，每當推出促銷方案，便由行銷人員透過簡單設定，自行產出相關分析報表，俾使決策者能猶如觀看股市行情般，在第一時間掌握該方案的銷售數字跳動，縱使靈機一動浮現其他分析需求，簡報者也能隨即切換至其他欄位，幫助決策者綜觀全局，以便於明快下達戰術修正指令，將資源火力集中在易於展現成效之標的，追求專案成效的最佳化。自助式分析、互動性報表之重要性，著實可見一斑。

隨著新版個資法上路，面對嚴苛罰則，任憑神經再怎麼大條的企業，想必都不會視而不見，即使未必會立即為此斥資購進大把資訊安全配備，但最起碼，針對個人資料或機敏資料的集結處、也就是資料庫系統，進行必要的安全控制，即可謂事不宜遲。

一旦有效落實資料庫安控，IT 管理者即可快速掌握並處理重大安全違規事件，不容竊賊任意搬走個資資產，並可保留完整跡證，以作為日後訟訴或求償之用；依此看來，稽核與加密等兩項攸關資料庫安控的舉措，顯然有其執行必要。

既然非做不可，多數企業也都願意展開相關評估，且評估的起點，經常都是資料庫加密，主因在於，一般從事IT、安控或稽核的人員都認為，只要做好帳號與權限控管，再針對個資進行加密處理，可謂終極保護措施。惟評估到最後，加密通常被順延至最末執行項目，只因它對於應用服務效能影響甚大，同時需要配合改寫應用程式的改寫、變更連線方式，具有較高複雜性。

那麼，相對不複雜的資料庫稽核，無疑成為企業務必優先執行的要務；但其實此事亦非輕而易舉，不僅如同加密，也會影響應用效能，只是程度較輕而已，甚至由於資料稽核功能需求經常被過度放大(例如判斷黑白名單等等)，徒然加重管理負擔，使得部分 IT 管理者仍然敬謝不敏，百般不願採取稽核措施，就算形勢使然不得不做，也會降低稽核等級，僅記錄諸如系統開關機、特權使用者登入等基本資訊。

做稽核拖垮效能？因資料庫而異！

持平而論，稽核作業必定會影響資料庫性能，連帶拖累前端執行的應用程式，著實無可避免；但即使如此，不同廠牌資料庫系統所受的影響程度，其實並不一致，企業若能從中取其輕，即可把負面效應減至最低。

以微軟 SQL Server 為例，縱使執行稽核，對於應用效能的衝擊亦屬輕微，能夠有效化解管理者的疑慮。只因該資料庫奠基 Windows 平台，彼此系出同門、兄友弟恭，著眼於整體系統的最佳化運作，資料庫面對 OS 的資源定位，始終保持最理想的協調性，所以即便資料庫性能因稽核而稍受影響，OS 仍可掌握足夠資源，撐住前端應用程式的運行效率，不致牽一髮而大動全身。

反觀其餘若干資料庫，與作業系統之間並無兄弟邦誼，對於資源定位，難免顧念自身需求而「狼吞虎嚥」，將大把資源據為己用，譬如從整個系統 2GB 記憶體中拿走多達 1.9GB，按此比例原則，資料庫本身的效能良窳，就會對整體應用效能產生重大影響，若因執行稽核而拖慢資料庫腳步，便將產生骨牌效應，讓前端執行的應用程式效能下降得更厲害。

稽核尚且如此，論及衝擊更為劇烈的加密，其實也有相同問題。如果是 SQL Server，運用內建加密功能，即可對機密資訊產生保護，亦可拜相對精準的 OS 資源定位所賜，不致對應用執行效率構成重大衝擊；至於其他資料庫，如前所述，礙於框限的資源比重頗大，其本身若因加密而拖累效能，與之配合的前端應用程式，在更無豐沛資源庇蔭下，所受衝擊自然更大。

稽核記錄化為報表　需加購額外工具？

多數情況下，只要談到資料庫稽核，都意指進出資料庫的存取記錄，這些記錄是以一條條 Log 呈現，為可視化程度不高的 Raw Data，必須被轉化為報表，方能產生管理價值。

對於許多資料庫用戶，欲將 Log 轉成為符合安全規範要求的各式稽核報表，要嘛即需向資料庫廠商追加採購相關工具或應用程式，要嘛就得花更多錢，引進報表軟體或BI系統，以便產出更美觀的報表；但無論如何，兩者都涉及額外預算，企業老闆未免會花得心甘情願，即使咬牙放行，對於 IT 人員又不免徒增管理負擔，凡此種種，亦是導致資料庫稽核「不甚討喜」的因素之一。

然 SQL Server 本身內含 SQL Server Audit 元件，用戶無須額外採購，即可依據個資法等資安規範，輕鬆將資料庫的行為記錄轉製為稽核報表，舉凡有權限的使用者存取或登入失敗記錄、系統管理權限使用記錄、資料庫結構調整記錄…等等，都能化為清晰可見的管理資訊，便於推動後續審計作業；倘若管理者需要獲得更加美侖美奐的報表，亦可動用 SQL Server 內建的 Reporting Services，一樣不需額外花費。

更有甚者，用戶可將 SQL Server 納為 System Center 集中管制的一環，據此發揮實更大範圍的個資管控效益；例如結合 Sharepoint 實現「資料不落地」妙效，結合 Active Directory 實施更精準的權責區分，亦可藉由資料庫稽核、伺服器、網路登入等多方記錄的交互比對，讓安全違規事件更加無所遁形。

回顧 2012 年，若欲推選 IT 熱門話題，大家理應不會否認，「海量資料（Big Data）」絕對名列前茅；經過一整年，人們接收的相關訊息、參與過的論壇，可謂不知凡幾，也因而有所體悟，大量非結構化資料裡頭果真的蘊藏無窮瑰寶，企業一旦善加分析運用，便可從中挖掘出關鍵數據，發揮點石成金之妙效，制定出一擊奏效的商業決策。

然而一缸子對海量資料多所吹捧的素材，其間縱使夾雜令人稱奇的案例，但畢竟那是別人家的成功故事，與普羅大眾的認知情境，似乎仍有一段不小距離，談得再多，也像是高來高去的神話，尚不足以內化為閱聽者的基本能量；尤其海量資料分析一事，不時牽涉諱莫如深的技術門檻，以及龐大的 IT 運算資源需求，無疑更讓不少人倒抽涼氣，直嘆眼前的成功之路，真的不太好走。

所幸在若干廠商的努力下，海量資料這個堪稱玄妙的黑盒子，已一步步地獲得拆解，對於有心擷取商機資訊的企業來說，著實是莫大福音。

生活週遭，盡是絕佳演繹

在過去幾個月內，無論富商巨賈、市井小民，都曾關注兩件大事，一是由歐巴馬與羅姆尼聯手上演的白宮寶座爭奪戰，另一則是強片如雲的第 85 屆奧斯卡金像獎。這兩大盛事即使南轅北轍，但都是萬眾矚目的焦點，甚至圍繞於多數民眾之生活週遭，成為驅動喜怒哀樂的重要元素。

可以想見，如果能將海量資料分析技術，套用於美國總統大選、奧斯卡得獎名單之預測，不僅可因饒富趣味讓人融入其中，其間抽絲剝繭的分析歷程，對於尚在修習 Big Data 學分的商業人士，也會是一場絕佳的示範與演繹，稱得上是珍貴教材。有鑑於此，微軟研究院決定把握難得機會，從運用 SQL Server 的商業智慧技術著手，分析大量非結構性資料，為世人提前預測兩場盛事的結果。

正所謂世事無絕對，未來的局勢如何演變，沒人說得準，因此不論是預測下屆白宮主人，抑或小金人得主，皆須征服許多變幻莫測的因子，難度甚高，所以對於微軟研究院，兩場預測絕非只是炫技，而是極其嚴苛的考驗，甚至稱得上是華麗的豪賭，預測準確度的高低，不僅影響世人對於 SQL Server 的信賴，亦牽動企業對於海量資料的投入熱忱。

面對 2012 年總統大選，微軟研究院先是採用一個通用的資料驅動模型，接著運用以往的投票結果，佐以就業率及經濟指標等數據，建立一套基線，再切換至大量市場預測及民調數字，甚至納入 Xbox Live 數據進行即時分析，據以預測全美 50 州暨哥倫比亞特區的投票結果；結果針對這 51 個地域，命中了其中的 50 個，準確率高達 98%，打出漂亮一役。

相較於總統大選，奧斯卡獎項的預測難度可說更高，只因其缺乏歷史票選紀錄或經濟指標等具參考效力的數據，所以微軟研究院決定採用票房收入、電影評選等這類非統計數據，並大量使用「預測市場（Predict Market）」網站的資訊，以及網友在各個社群媒體上討論的內容，試圖深入探究入圍影片與各類討論主題之相互關聯，作為主要的分析依據，更與微軟 Office 團隊合作開發「奧斯卡票選預測 App」。由此觀之，此次仍由 SQL Server 擔綱演出的奧斯卡預測任務，更像是名符其實的海量資料分析大秀。

微軟研究院所提出的預測結果，分別是最佳影片的「亞果出任務」（機率 92%）、最佳導演的「林肯」史蒂芬史匹柏（機率 89%）、最佳男主角的「林肯」丹尼爾戴路易斯（機率 99%），以及最佳女主角的「派特的幸福劇本」珍妮佛勞倫斯（機率 71%）；最終謎底揭曉，4 項大獎命中率達 75%，雖因漏失台灣之光李安而小有遺憾，但瑕不掩瑜，已足夠教人為之折服。

資訊匯聚應用高潮迭起

歷經兩場神乎其技的預測，等於是昭告世人，運用傳統資料庫處理結構化資料的時代，真的已經過去，只因伴隨著數位裝置及網路應用的發達，舉凡圖片、影音、網頁留言、發票採購、簡報檔等無法透過數字化儲存分析的內容大肆崛起，這些內容埋藏著掌握商業脈動的重要訊息，企業唯有善加彙整與分析，方能萃取商業價值，並發展成具決策導向的重要資訊！

值此時刻，企業需要一個穩健可靠的分析工具，藉以輕鬆駕馭結構化、非結構化的資料訊息。以名列 Gartner 2012「商業智慧」領導者象限的微軟而論，不僅在其 Office、SQL Server、SharePoint 等高普及率產品中，持續導入商業智慧功能服務，並推出以雲端為基礎的資料市集（DataMarket），俾使用戶能直接存取、購買、分析任何儲存在託管雲或公有雲裡的資料，進而彈性調整 IT 運算資源，提升商務決策的參考價值及穩定性，凡此種種，都有助於資訊匯聚（Information Aggregation）之技術應用推向另一高峰，協助孕育更多「料事如神」的企業。

對於絕大多數企業，資料庫系統就好比發電機，各式應用服務，都因為它所提供的資料儲存與管理，因而獲致動能，進而繁衍生生不息的力量。

如此重要的系統一旦生病，無法正常滿足應用服務之所需，導致企業賴以維持生計的營運活動，被迫陷入停擺，接踵而至的災難，將比電影情節更加驚悚，無異是一場巨大浩劫。因此企業 IT 團隊每逢挑選資料庫系統時，除了關切運作效能、平台整合性、程式語言整合性、工具整合性、高可用度、產品價格外，也一定會把安全性這個指標，納入評估重點。

只不過，說到資料庫系統的安全與穩定，其實是一個大哉問，企業無從獲得經過嚴謹實測的報告，少了參考依據，自然難以精確評斷各大廠牌產品之優劣，所以到頭來，又淪為資料庫管理（DBA）憑印象編撰故事的場景，往往因承襲了若干老 DBA 的共同記憶，便不假思索為某些系統冠上「固若金湯」的美名。

有褒、自然也有貶，某些資料庫系統運氣不太好，老是被部分 DBA 評為不安全、不穩定，建議應用系統團隊另作他想，能不採用、就不採用！當然，每個廠牌系統都可能不幸成為這個倒楣鬼，SQL Server 也不例外。

GUI 增添不穩定變數？

被某些 DBA 視為不穩定的 SQL Server，其實某種程度上，揹負了非戰之罪。此乃由於，部分 DBA 生性念舊且謹慎，認為圖形介面（GUI）徒增人為操作不當的疑慮，干擾因素太多，為求穩定，理應採取具備「閒人勿近」意味的命令行介面（CLI），才足以趨吉避凶，而 SQL Server 的友善 GUI 介面就可能為此而背負了不應該有的原罪！

SQL Server 的友善 GUI 真的犯大忌？很顯然的，部分 DBA 真的誤會了，友善的 GUI 操作源自於 Windows 作業系統，SQL Server 構築在 Windows 平台上，所以產生了容易進入與執行操作的連結想像。否則以眾家系統運用的資料存取方式與技術來看，相似度如此之高，為何其他品牌在於穩定性並無太多疑慮，而 SQL Server 卻容易予人誤解，癥結很可能都在於大家對 Windows 作業系統相對比較熟悉��想像。

但如果只因這些理由，就加以蓋棺論定，坦白說也失之偏頗。首先，SQL Server 隨著版本演進，已擁有愈趨完善的資訊安全功能，以 SQL Server 2012 為例，單單藉由預設為關閉的內建服務 Configuration Manager （註：用戶只啟用所需服務），就足以強化資訊安全的部署，將介面區攻擊減至最低，即使作業系統處在 GUI 環境，也有高度的安全保障，絕不像部分人對 GUI 作業環境所以為的如此不堪。

其次，如果 DBA 仍對 GUI 不放心，其實也可將 Windows 作業系統調整為 CLI 模式，關鍵就在於 Windows 的 Server Core，而且做法並不難。以 Windows Server 2012 為例，可在一開始安裝過程中，即藉由工具列上的 PowerShell 圖示選擇「以系統管理員身分執行」，或是已經採用 GUI 的過程中，透過管理員的儀表板，選擇「移除角色及功能」，不管是事前或事中，都可以將 Windows 的使用者介面，轉為簡潔的 CLI 作業系統環境。

資料庫安不安全，數字說分明！

持平而論，Windows、Unix 或 Linux 等作業系統的安全與否，牽涉到一些由來許久的觀感問題，即使 Windows Server 2012已致力營造安全無虞的使用環境，仍是信者恆信、不信者恆不信，似乎多言無益；但既然談論資料庫安全，其實應回歸問題原點，認真檢視資料庫系統本身的安全設計，才不致模糊焦點。

舉例來說，McAfee 是一家浸淫資安領域多年的業者，擁有不俗的市場口碑，旗下 Lab 定期發布的威脅報告，便具有參考價值。在今年第三季，其便針對市場上 6 個被慣常採用的商用或開原碼資料庫，發表了最新觀察到的安全漏洞，結果顯示，被若干 DBA 視為無堅不摧的「優質」商用資料庫系統，以及坐擁龐大開發社群，被視為甚具安全免疫能力的開原碼資料庫系統，竟然雙雙上演漏洞百出的驚悚戲碼。[註]

上述的商用系統，在短短一季時間，接連出現兩個足以釀成零日攻擊的弱點，回顧資料庫安全漏洞發展史，可謂前所未見的異常現象，這也意謂著，該系統已成為眾多網路攻擊者眼中的頭號獵物，爾後恐將面臨巨大挑戰。至於上述的開原碼系統，漏洞數量高居所有資料庫之冠，更意謂其用戶陷入危機而不自知。

反觀 SQL Server，則以屈指可數的零星漏洞數量屈居末位，同時都已獲得微軟快速處理，顯見這個被若干 DBA 視為相對不安全的系統，其用戶平日曝露的風險，遠較其他資料庫為低。換言之，假使企業昧於體察事實，反將潛藏安全疑慮之標的列為首選，恐招惹更多禍害進門，不能不慎！

曾有 DBA 說得貼切，SQL Server 無論在帳號管理、資料傳輸、備份加密等方面的表現，隨著版本更新，都一次比一次更加到位，不管你是否認同這些進步成果，但自從 SQL Server 鮮少爆發相關安全事故的優良歷史來看，領先業界的安全性是不爭的事實。

註: 原始資料來源請參考 McAfee Labs, https://blogs.mcafee.com/enterprise/mc afee-labs-q3-threats-report

不可諱言，人們熱衷談論海量資料時，腦海中所浮現之標的，有很大一部分，似乎都指向當前風起雲湧的社群媒體，因為它蘊藏了最為真實不虛的消費者意向，對於企業而言，若想了解需求的變更、以及群眾影響力，對口耳相傳的宣傳方式究竟有何影響，都可望藉由社群媒體得到解答。

有業者看準這個趨勢，開始推出「社群媒體用戶影響力衡量」服務，旨在讓這些流竄於社群網路的原始資料，轉化為客戶、品牌業者及合作夥伴的參考資訊，再據此擬定行動方案。一家取名自「影響力 (Clout)」諧音字的 Klout 公司，便是從事此類服務；它就好比一個能將「垃圾變黃金」的魔術師，可以把過去乏人聞問的資料，轉變為企業賴以決勝的利器。

時至今日，Klout 每天協助客戶深入瞭解數百TB資料，這些資料源自於 15 個領先業界的社群網路，包括知名的 Facebook、LinkedIn。其主要分析標的，涵蓋了社群網路上動輒逾十億則的龐大訊息，這些訊息係由上億人共同產生，他們包括了 Klout 成員，以及在社交網站上與成員來往的人，但不管是誰， Klout 都為這些人逐一建立索引，再以為基礎，演算各個成員在網路上的影響力，並以 1~100 分的級距來評定影響力的強弱。

綜上所述，Klout 所需分析的資料量，比起大多數企業的資料處理需求，無疑更加巨大；Klout 一方面需致力滿足客戶所要的資料分析深度，二方面又需符合草創的預算限制，左思右想，遂決定以開放原始碼 Apache Hadoop 作為基礎架構，針對大型資料集進行分散式處理，其間包含了用以儲存各個社交網路資料的獨立資料庫。另外，Klout 也採用自訂的 Web 服務，內含許多獨特的商業邏輯，藉此向資料庫擷取資料，再以混搭整合資料型式提供服務。

架構失當，海量資料難煉黃金

然而，維護 Hadoop 與自訂 Web 服務，不僅讓 Klout 團隊承受沈重作業負擔，且一陣忙亂之餘，也無法獲得預期成效。譬如，要從 Hadoop 存取詳細資訊，尚需搭配額外開發作業，而且資訊極為混亂，經常欠缺使用者所欲尋找的細節；此外，查詢處理時間長達數分鐘到數小時不等，效率明顯不佳。

抓不出細節，查詢處理時效又慢，實令 Klout 飽嚐苦果，因此下定決心更換基礎架構，只因開放原始碼工具集對於 BI 分析，效率實在過於低落，若無更佳選擇，即使海量資料在手亦難提煉黃金。幾經思考，其選擇以 Hive 技術建立資料倉儲，彙整由 Hadoop 代管之全部資料；同時導入 SQL Server 2012 企業版資料庫，將透過箇中 Analysis Services 功能進行多維度線上分析處理 (MOLAP)。Klout 高階主管透露，之所以選定 SQL Server 2012，無非是看重它與第三方軟體的絕佳相容性，很適合用來管理 Klout 的所有商業邏輯，保存細節並加速分析，確保滿足海量資料所需之查詢效能。

值得一提，SQL Server 2012 內含的 AlwaysOn 功能，亦使 Klout 受用無窮，以此輕鬆將資料庫複寫到次要系統，順勢實現資料高可用度的目標。

如今，這個植基於 SQL Server 2012 的 MOLAP 模型，每天負責分析多達 350 億列資料，查詢回應時間從不超過 10 秒，更使得 Klout 原本耗費在管理商務邏輯與資料連線的冗長時間，就此蒸發不見，輕而易舉讓深藏在 Hadoop 的資料細節，全都被曝露出來，終至將海量資料的潛力發揮到極致。

即使整個社會，亦可因 Big Data 得利

上述例子，相當發人深省。就好比一個人若只以裸眼直視海量資料，則不僅看得慢，也未必能端詳箇中玄機，但如果搭配高倍數顯微機，情況便將徹底改觀；任何亟欲洞燭機先、決勝千里的企業，是否需要部署強大工具，答案已顯而易見！

而 Big Data 的好處，不但適用於企業一己利益，對於整個社會國家、民眾福祉，亦可望發揮關鍵助力。例如美國 CBS 電視公司製作的「疑犯追蹤 (Person of Interest)」，雖不過是一齣影集，然其故事情節，絕對有可能發生在現實世界。

劇中一位深居簡出的億萬富豪，為政府開發一套可偵測「有計畫性或經謀略策劃的犯罪」之電腦，大至諸如 911 的恐怖攻擊，小到一般人的暴力犯罪，皆可加以掌握。富豪將情報分為「攸關 (Relevant)」、「非攸關 (Irrelevant)」兩大類，僅將前項資料呈報予有關當局，至於非攸關清單，原本必定於每晚刪除，然富豪後來體悟到，非攸關資料亦有助於制止犯罪活動，挽救無辜百姓的生命財產，於是他利用程式中的一個後門，取得「社會安全號碼」資訊，以此號碼來追蹤加害者與受害者。

緊接著，以富豪為首的團隊，屢屢在肇事者即將出手的千鈞一髮之際，及時遏止犯罪事故的發生。此一場景看似虛擬夢幻，惟只要援引 Klout 前例，採用諸如 Hadoop、Hive 及 SQL Server 2012 等海量資料處理暨分析技術，其實絕對有可能付諸實踐。

絕大多數的企業應用系統，都會隨著時間演進，因而累積大量資料，這些資料都需要被整理為有用資訊，才可成為彌足珍貴的數位資產；在此情況下，賴以管理大量資料的資料庫系統，確實是企業資訊之命脈，除須擁有不容閃失的高穩定度外，當然也應該擁有優異的運作效能。

因此，多數 DBA 都不會懷疑，懂得選擇一套高效能的資料庫，絕對是他們職涯當中重要的必修學分，否則萬一挑到效能不彰的系統，導致企業應用服務無法流暢運行，進而惹得公司從上到下怨聲載道，這個罪名對於 DBA 來說，無疑是不可承受之重。

儘管市場上資料庫品牌為數不多，但要想評斷它們孰優孰劣，似乎也沒那麼容易。因為資料庫效能測量環境，需要在相同的商用負載執行情境下，動用時間、人力、財力、能力等可觀資源堆砌而成，而且不論是壓力測試或單元測試，其過程都務求擬真徹底，任何環節都不容疏漏，如此才能確保測試結果的精準度；這一切的一切，顯然並非輕而易舉之事。

既然執行測試大不易，部分 DBA 寧可選擇抄捷徑，聽取幾個前輩與同業的意見，就這麼演化出一套似是而非的邏輯，未經詳細驗證，直接就認定某某品牌資料庫為首選，心想反正有人強力推薦，其效能勢必出類拔萃，用了準沒錯。

殊不知別人用得虎虎生風的系統，到了自己的環境，卻未必盡如人意；DBA 這才有所頓悟，下回面臨資料庫品牌的抉擇之際，還是得老老實實走完概念驗證 (POC) 程序，眼見為憑最重要，不要繼續人云亦云。

表面看來，這個遲來的頓悟似乎有理，但倘若主其事的 DBA 依舊思路閉塞，未能釐清一些基本課題，縱使做足了 POC，恐怕也未必能覓得最佳資料庫。

評估資料庫效能，需隨情境而調整

不可否認，在若干 DBA 的印象中，提到效能評價，部分執行於 UNIX 環境的資料庫品牌，始終凌駕於 SQL Server 之上，殊不知近期一些用戶端系統的資料庫測試比較，
SQL Server 反而是輸少贏多的；關鍵除在於 SQL Server 效能的持續提升外，另透過 
SQL Server 的記憶體優化技術 xVelocity 大幅提升查詢效能，針對大量交易系統則採用 Snapshot Isolation 隔離層級有效降低 Block 的發生，更搭配分割資料表卓越功能，以致讓 SQL Server 在各大戰役中無往不利。

值得一提的，SQL Server 2012 內建 Distributed Replay 功能，可有效模擬大量資料對 SQL Server 進行壓測，無需購買昂貴軟體，亦使 SQL Server 在校能或性價比上大幅超越對手。SQL Server 憑藉友善與完整的管理工具，搭配相對容易取得的專業諮詢服務，即不難被調校出優異狀態，反觀其餘資料庫系統，除了效能有待商榷外，DBA 意欲覓得正確資源，將之調校出應有表現，本身即是一大挑戰。

資料庫技術發展數十載，相關技術已經相當成熟，倘若不同廠牌系統並肩而坐，各方皆在相同情境標準的設定下，再佐以應有的專業調優設定，有些時候確實會出現效能難分軒輊的場景，只因眾家系統所運用的資料存取方式與技術，相似度極高，影響所及，彼此之間性能好壞之差別，也可能不甚明顯；換言之，不論是特定資料庫系統長期被人奉為上上之選，抑或 SQL Server 曾被誤解為效能有待加強，說穿了，全都是偽命題，與實情並不吻合。

所有商用資料庫一字排開，SQL Server 的效能表現鮮少居於劣勢，優異的表現亦是備受肯定。既然環顧各家資料庫的處理效能，SQL Server 始終名列前茅，所以在客觀條件相同的前提下，DBA 的評選標準就很簡單，何者的總體持有成本(TCO)最低，便是不二選項，因為就算費盡心力追逐高價系統，也無法換取更佳效能。

效能疲軟，未必是資料庫闖的禍

不可否認，雖然眾家資料庫體質雷同，但只要分別被投放到不同應用環境，實際效能表現總是天差地遠，有的健步如飛，有的卻步履蹣跚；但即使發生後者現象，難道就可對該資料庫系統大加撻伐？非也！絕大多數情況下，原因並不在於系統先天不良，而是其他後天不良因素惹的禍。

如同前述，各資料庫賴以讀寫資料的方法，其實都很類似，因此它們所面臨的效能瓶頸，自然如出一轍，都很容易受限於伺服器、儲存設備或 SAN 交換器等硬體 I/O，所以在大多數情況下，或許僅須將硬體更換為優規設備，就能化解效能疲弱之病態。

只不過，有時換了機器，資料庫運行速度卻未見提升，其癥結顯然就不在 I/O 瓶頸之上，可能源自於低效的查詢，或是應用程式本身的設計不良；值此時刻，DBA 即應保持淡定，先以抽絲剝繭方式找出問題根源，再將練就多時的調優技巧施展開來，看看是要將資料庫的邏輯加以正規化，改採更具效率的索引設計與查詢設計，或是設法分解並隔離慢速的 SQL 查詢，總之用盡一切的力量，將惱人的效能問題加以革除。

若形容資料庫管理員 (Database Administration；DBA) 是企業 e 化的重要功臣之一，其實並不為過；主因在於，唯有底層資料庫系統能夠正常運轉，也才能確保上層應用服務得以順利推行，兩者唇齒相依，顯見資料庫確實極為重要。

在此前提下，肩負著資料庫系統安裝與設定、容量規劃、應用架構設計、資料庫物件管理、儲存空間管理、安全管理、備份與復原、效能監控與調優、調度作業、網路管理、可用度暨延展性管理、故障排除等重大使命的 DBA，對於企業資料庫系統的選用，自然擁有很大的話語權。

甚至在某些狀況下，單憑部分 DBA 一人意志，即可發揮「愛之欲之生，恨之欲之死」效果，使得特定的資料庫產品，能夠與企業的應用服務環境長廂左右，至於其他的資料庫產品，那怕功能齊備、性能優異、穩定度高超、價錢又漂亮，公司內部人人皆曰可用，但他老兄硬是獨排眾議，始終被拒於門外。

看似複雜的事物，未必難如登天

探究部分 DBA 之所以固執己見，道理其實很簡單，即是捍衛既得利益，唯恐他在公司的「存在感」，可能由於資料庫系統的轉換，而變得蕩然無存。 

這些 DBA 很瞭解他個人心路歷程，也藉由過往經驗的累積，知道應該在哪些地方築起門檻，突顯一種艱深晦澀的氛圍，進而連同系統與個人，皆被形塑「無可取代」的刻板印象；意即唯獨這套資料庫系統，可以將關鍵應用任務執行得又快又好，但由於該系統的技術底蘊太深，而它所依附的Unix作業系統，學問又太過艱難，面對這個「生人勿近」的環境，唯獨 DBA 有能力身涉險境、排除萬難，駕馭這套甚難馴服的複雜系統。

反觀微軟的 SQL Server，多數 DBA 心知肚明，隨著 AlwaysOn、ColumnStore 等眾多嶄新功能的加入，不管在於穩定性、效能等各個方面，都已非昔日吳下阿蒙，要想支撐企業關鍵應用任務的運行，肯定沒問題。但由於 SQL Server 進入門檻相對較低，資源取得相對容易，又有相對龐大的生態體系 (Eco-system) 在背後撐腰，所以企業一旦採用這套系統，若干DBA便擔心無法突顯個人價值，因為隨時都有一缸子好手，可以取自己而代之。

然而這般論述，果真存在不少謬誤之處。首先，某些被部分 DBA「奉為神主牌膜拜」的資料庫系統，最困難的地方，乃在於它要被安裝到 Unix 作業系統的過程；因為 Unix 可分為多個門派，假設裝載到AIX，所需具備的知識與經驗，肯定與 HP-UX、Solaris 多所不同，倘若欠缺相關知識與經驗，當然不知從何下手，就會視它為艱深難懂之物。

這些資料庫之所以「難」，只是難在這個地方，其餘部分都還好；因此若干 DBA 如果僅想以偏概全、突顯身價，就算可以一時奏效，也很難持續得逞，原因是現今資訊太過發達，很難有任何資訊死角，可以一直被隱匿下去。

你真的低估 SQL Server 了！

其次，Unix-based 資料庫系統通常都安裝在昂貴機器，可能光是一條 RAM 就得要價 5~6 萬元，致使硬體升級淪為一件「恐怖」的事；所以，它無法像是 SQL Server，只要效能變慢，就直接換機器，而必須倚賴 DBA 實施優化手段。

前述觀點，潛藏了兩個迷思。第一，那些可以安裝在 Unix OS 的資料庫系統，說到調優，雖然難免有其學習門檻，但絕非難如登天，所以部分 DBA 不應藉此高估自身功力；第二，導致 SQL Server 效能弱化的原因，固然可能有很大機會，是與 Disk I/O 息息相關，看似可憑藉硬體更換而獲致重大改善，但有些效能瓶頸，其實是因為語法不佳所致，如果不解開這個死結，縱使換置性能強大的硬體，也未必能提高系統執行效率。

這也意謂著，DBA 可別把 SQL Server 低估為「一經安裝，爾後可以什麼事都不做」，它依然需要被調優，而且這些優化措施可謂易學難精，不管是 Windows 作業系統內建的效能監視器，乃至��� SQL Server 裡頭的 DBCC CHECKTABLE、Profiler 或 DTA，樣樣都得融會貫通，而且只要善用優化技巧，前後改善的幅度相當大。

舉例來說，為了確保交易與交易之間互不干擾，通常企業選擇會在資料庫層面執行隔離性保證、或採用 Lock 陳述式，藉以針對資料庫或相關欄進行鎖定，同一時間僅允許一個交易做寫入或讀取。

但以隔離性保證而論，倘若野心太大，想一舉清除 Dirty Read、Unrepeatable Reads、Phantom Reads 或 Lost Updates 等所有疑慮，因而採取 Serializable 最嚴格等級來執行完全鎖定；如此一來，所有交易都得循序排隊，一個接著一個來，難免會對效能構成嚴重衝擊，而且不是更換強大硬體就可以解決的，此時就得考驗 DBA 的智慧與功力，才能找出最佳的改善之道。

由此可見，作為一個 SQL Server 資料庫的 DBA，光是面對系統慘遭鎖死之現象，其間所蘊含的調優空間，便已十分遼闊，只要做得好，就是個足以發光發熱的舞台，並無身價大減的疑慮。

某家企業的 IT 主管，最近真的很頭痛，因為在 3 年以前，為了不想支付每年超過 20% 的沈重財務負擔，因而中斷了資料庫系統的維護；如今有一個非常重要的修補程式，非拿到不可，但為了續約取得後續維護的資格與資源，竟然需要把去 3 年的空窗一次補足，想當然爾，老闆不會同意。

當這名主管心煩於 Patch 更新的節骨眼，好不容易培養的 DBA，卻在此時遞出辭呈，少了這名大將，其餘同仁光是把不同資料統整到資料庫，都未必能萬無一失，更遑論在 Unix 作業環境下 Command Line、寫 Coding，對他們來說，簡直像是另一星球的語言。

眼看著，當初大費周章建構的關鍵任務資料庫，已瀕臨無以為繼。既然該公司駕馭這套資料庫系統及 Unix OS 的能力，其實不算高明，為何當初做出這個選擇？主管回答，在他的記憶裡，過去企業都拿它執行關鍵任務，自己照做準沒錯；至於微軟的 SQL Server，雖然人才不虞匱乏，就連剛畢業的年輕人也能快速上手，但它好像總是為中小企業所用，或出現在一些非屬關鍵的 Web 應用場域，所以並未納入選項。

該主管受到既定印象的限制，生怕因改變帶來風險，不得不捨近求遠、捨易求難，棄大多數人常用的 SQL Server 於不顧，轉而花費更多心力，追逐門檻較高的昂貴資料庫系統。這樣的選擇，到底是對是錯，主要癥結就落在「SQL Server 能否勝任關鍵任務」之上，為了求得最終解答，我們只需要看兩件事，第一，現在的 SQL Server 有無足夠的功能特質，可以為關鍵任務系統的提供明顯貢獻？第二，究竟有無大型企業機構，真的將 SQL Server 部署在攸關財產生計的關鍵應用場域？  

憑藉三大功能，搞定關鍵任務

在闡述 SQL Server 主要功能之前，得先追根究底，為何 SQL Server 容易給人「中小企業用戶滿天下」的印象？說穿了，這純粹只是比例問題，因為就 SQL Server 2012 而論，可分為企業版、商業智慧版、標準版，從基本款到進階款一應俱全，因此用戶結構相當多元，裡頭大約只有兩成比重，落在所謂金字塔頂端企業。 

至於其他資料庫，因產品結構側重高階定位，賣不進中小企業，所以客戶十之八九都是大型企業。由此觀之，SQL Server 只是因為 Base 過大，才稀釋了大型客戶的佔比，絕非僅能適用於中小型商業環境，此乃天大的誤會。

回歸功能面，SQL Server 2012 最能給予關鍵任信心的特質，不外三大項目，分別是高可用性 (AlwaysOn)、高效能資料查詢 (ColumnStore)以及企業級資訊安全控制功能。首先在 AlwaysOn 部分，主要是透過迅速容錯移轉並修復裝置的能力，使得不管是意料之外、或規劃之中的停機時間，都可壓到極為短暫的地步，在此強力呵護下，包含應用服務的可用性、資料的保護，都絕對不會出亂子。

有關 ColumnStore，乃是 SQL Server 首度採用資料行存放區索引模式，進而將星狀聯結 (Star join) 及類似查詢的作業效率，整整拉高了百倍之多，得以營造閃電般快速的查詢效能，再加上它擅於壓縮，可減少 5 成以上的資料成長量，幫助 ERP 等需要密集使用  I/O 的工作卸除重擔，從而展現驚人的效能增幅。

在於資訊安全控制方面，SQL Server 除了藉由加密功能保護機敏資料外，亦可根據使用者定義區分權責，幫助企業管理者輕鬆做好資料權限控管，並且提供莫大的稽核彈性，好讓稽核人員可輕易確保法務遵循。

既然 SQL Server 可確保重要應用服務不中斷，可讓關鍵程式啟動疾速效能，又有助於消弭組織資訊安全或法務遵循之疑慮，再加上龐大生態系統從旁撐腰，很顯然的，它已經網羅所有關鍵元素。

知名企業用戶，豈會冒險賭注？

說起 SQL Server 的關鍵應用案例，持平而論，隨便就可端出一缸子。穩居市佔龍頭的元大寶來證券，必須針對不容任何閃失的客服系統，建立強力後盾，於是採用 SQL Server 2012，並善用 AlwaysOn 技術，實現 2 秒內異地備援換手之妙效；使該公司得以憑藉牢靠穩固的客服中心，擄獲廣大客戶的忠誠度。

永豐銀行引領全球之先，將 Temenos 核心系統建構於微軟 Windows Server 及 SQL Server 平台，完整支援消費金融與企業金融等關鍵業務，營造高達 4~5 成的 TCO 精省效果，且一併解決舊系統在於人才斷層、開發暨維運成本節節攀高等挑戰。更重要的，該行全新的核心銀行系統，可順暢支援尖峰期每天高達 200 萬筆的交易負載，連帶證明 SQL Server 在穩定性、高效能和安全性的表現，確實禁得起金融業關鍵應用之嚴苛考驗。

在食品業界素有高知名度的味全，基於大中華區營運推展需求，對於 SAP ERP 倚賴至深，因此該系統棲身的基礎環境，必須具備 100% 的穩定和可靠，因為一年動輒百億的營業額週轉，可不是開玩笑的。味全歷經審慎評估，決定選用 SQL Server 2012，無非是看上其唯一預設將所有索引或資料表啟用壓縮功能之特質，果不其然，它沒讓該公司失望，SAP 環境中不管是 BSIS、GLPCA、ACCTIT 或 MSEG 等資料表，儘管急速壓縮到原來 10~15% 大小，效能卻反而提升。

這些知名企業，將一些不容任何差錯的關鍵任務，交付於微軟 SQL Server，藉此建構驅動營運成長的軸心；事實上，他們都有部分系統，依然運行在執行 Unix OS 的資料庫系統之上，然而近幾年卻已大幅轉變，開始在其關鍵任務系統上採用 SQL Server，這難道只是憑藉一股冒險賭注？絕對不是！他們的故事，確實蘊含了發人深省的意涵。

不可諱言，「海量資料」是當前最具吸睛效果的 IT 話題之一；只因多數企業意識到，其賴以提振營運績效的致��密碼，僅有某部分被蘊含於 ERP 或 CRM 等結構化資料，其餘更大的一塊瑰寶，竟潛藏在文字、影像、聲音甚或網頁等大量非結構化資料，這些海量資料就像是豐盛的寶庫，以往未曾有效開採，今後必須勤加蒐集、整合並分析，才不致暴殄天物。

正因如此，舉凡 Hadoop、MapReduce 等攸關海量資料的技術辭彙，開始成為人們熱切追逐的焦點。但問題來了，Hadoop 這個被視為足以取代 ETL 的技術，絕非三兩下就能輕易上手，要考慮的因素著實不少，而企業縱使有幸突破這些障礙，又得面臨另一大難關，那就是「錢」！為了每月、每季甚至每半年才來這麼一次的 Big Data 分析，就得大手筆斥資建立分散式處理架構？好比為了應付偶一為之的淘金需求，就砸下重金興建礦場，ROI 是否划算，顯得值得商榷。

全球競局如此激烈，凡事都不容磋跎猶豫，企業理應趕緊從海量資料挖寶，但卻又礙於諸多阻撓而遲遲未能出手，如何是好？為此，微軟 (Microsoft) 提供一系列解決方案，期望幫助企業快速獲取必備工具，從此再無後顧之慮，恣意坐享淘金樂趣！

SQL Server，營造最友善的分析環境

事實上，企業費盡千辛萬苦鑽研海量資料淘金之術，目的就在於修成正果，妥善呈現最終分析結果；而 SQL Server 堪稱迄今最被廣為使用、也最易上手的商業智慧 (BI) 與報表工具，能有效提供海量資料分析服務，進而幫助企業，從繁複資料淬煉過濾出寶貴資訊。

SQL Server 足以承先啟後，其中一頭介接後端 Hadoop 運算架構，另一端則可銜接 Office、SharePoint 或 Reporting Service 等前端呈現工具，使得原本頗為艱澀的海量資料處理結果，得以化繁為簡，藉由直覺互動、親和易懂的風貌，清清楚楚展現在使用者眼前。

尤其最難能可貴的是，任何前端使用者皆可透過自我服務，從 SQL Server 的身上取得分析成果，完全無需勞駕 IT 人代為處理；也難怪若干網購平台的行銷人員，在推出 Campaign 後短短 4 小時內，就能鉅細靡遺地向老闆回報成果，即使老闆不厭其煩探究主要消費者族群分布，究竟落在哪一性別、哪些地區、哪些年齡層，行銷人員都可立即轉換分析維度，輕鬆給出明確答案。

當然，多以非結構化型態呈現的海量資料，與傳統結構化資料有所歧異，倘若沿襲過去關聯式資料慣用的 Raw-based 資料頁擺放模式，則 I/O 與搜尋速度恐將「遲緩」到令人不敢領教的地步；有鑑於此，SQL Server 2012 轉而採取 ColumnStore Index 索引方式，藉此發揮 10 倍以上的增速效果，讓使用者得以快速查詢海量資料，絕不拖泥帶水。

取道公有雲服務，快速挺進 Hadoop

海量資料的奧妙精深之處，其實就在於分散式處理，而 MapReduce 即是實現這個精髓的關鍵技術；只不過，多數程式開發人員有苦難言，撰寫 MapReduce 程式的難度不低，可稱得上艱困任務。

所幸微軟運用累積多時的資料採礦 (Data Mining)、Bing 搜尋等經驗與知識，將原本繁複的 MapReduce 演算法則化為 Template，統一集結於一個函式庫，成為 Windows Azure Marketplace 之中的一支「App」；有了這套垂手可得的法寶，程式開發人員無需絞盡腦汁從零開始，便可快速動手打造 MapReduce 程式。

既然是分散式處理環境，可以想見，在 Hadoop 架構裡頭，一定擁有許許多多的運算節點，此時也需要由 System Center 坐鎮指揮，有效管理眾多節點。

而為了協助企業卸除沈重的 Hadoop 建置成本壓力，微軟別出心栽在 Windows Azure 公有雲端平台上提供 Hadoop 租用服務，使得企業不必投資布建大量伺服器及資料庫，就可隨租即用獲取必要資源，執行海量資料運算任務，開創「數字煉金」的終南捷徑。

不可否認，任何分散式處理環境都有其臨界點，不可能漫無止境地擴張下去，微軟一路橫跨本地資料庫、私有雲、公有雲與混合雲，提供全方位海量資料解決方案，正足以幫助企業卸除臨界壓力，為偌大的海量資料分析需求，找到宣洩的出海口！

T-Drive 計畫，堪稱經典應用案例

持平而論，不少供應商端出的海量資料解決方案，屢屢讓人為之目炫神迷，但說到實作案例，卻未必能講出幾件；微軟則不然，透過北京的 T-Drive 及Urban Planning 案例，即已充分顯露深厚的海量資料功力。

時值 2009~2010 年期間，微軟研究院與北京市政府合作，為該市 33,000 輛計程車部署 GPS 裝置，期望汲取駕駛人的智慧及經驗，進而針對持續累積的龐大導航數據進行分析，一方面找出最佳的行車路徑，二方面發掘交通瓶頸。

爾後發現，北京市區最明顯的交通瓶頸，出現在北四環路，主因在於天通苑、來廣營等兩個地區的居民，皆以此為出入幹道，無怪乎經常出現塞車情況，非得另闢其他出口，方能分散龐大車流量。北京市政府遂根據 GPS 海量資料分析結果，決定新建長達 1.7 公里的北湖渠西路，此舉果真一擊中的，有效化解交通堵塞難題，因而造福廣大市民。