Connect(); 2016
第 31 卷，第 12 期
本文章是由機器翻譯。
智慧型應用程式 - 巨量資料開發變簡單了
由 Omid Afnan;2016
目前沒有商務討論巨量資料的概念為中心的大消息。電源公用程式、 醫療研究公司和慈善組織所示範的大規模資料來探索模式，使用的各種組織推算關聯性，並預測結果。線上服務的企業營運，是早期開發地面巨量資料和保持其最積極採納者。案例，例如產品建議、 詐騙偵測、 失敗預測和情感分析已成為 mainstays 的巨量資料革命。
巨量資料通常定義為具有 「 三個 V 的 「 特性 — 大量、 高速和各種不同。While 大型磁碟區是常見的巨量資料，無須採取到達幾近即時的資料關聯，而且巨量資料平均定義處理大型和變更各種不同格式和結構。事實上，在資料中的這些特性的其中任何一個可以著手與其他人建立的巨量資料案例通常後面緊接著在之後。超越 — 且越來越需要 — 從衍生值的資料都有三個 V 巨量資料增加興趣背後的動機。
資料科學、 統計分析和機器學習有所有喜歡更新的注意及成長，巨量資料的使用有真正已解除鎖定在分散式運算基礎的進階功能。這包括可以結合運算叢集的低成本的商用硬體的軟體堆疊的開發。相關聯的編譯器和工作排程器可讓運算工作負載分散到這類叢集。這樣可以放置接近資料的儲存位置，且許多伺服器來取得較高的效能彙總計算。這些巨量資料平台供內部使用，例如 Microsoft、 Yahoo 和 Google 公司所開發，但已成為可供公眾使用透過 Azure 資料湖 (ADL)、 Hadoop 和 Spark 的平台。
說也不奇怪，，，就開始使用巨量資料表示中建立這些新技術為基礎的資料平台的投資。在企業系統層級，也就是說，「 資料湖 」 簡介除了傳統資料倉儲。資料湖為基礎的概念很大的規模和原來的格式儲存各種資料類型。不同於資料倉儲模型擷取資料的第一次不含任何清除或格式化，和使用晚期繫結結構描述。這種架構需要採用新軟體平台，ADL、 Hadoop 或 Spark。資料開發人員，這表示需要學習新的程式設計模型和語言，同時處理更複雜的執行和偵錯的情況。
所幸，巨量資料的系統有這麼長的路。例如，假設您想要使用您在處理從線上購物網站收集資訊來建置產品建議系統。傳送電子郵件給升級先前購物模式為基礎的新產品的購物者為您的計劃。您也可以在客戶根據其他客戶的未在網站上購物時提供產品建議。這兩種案例完全符合巨量資料技術。直到最近，您就必須先選取特定的巨量資料堆疊、 設計和採購叢集硬體、 安裝微調軟體，然後您可以開始撰寫程式碼來收集、 彙總處理的資料。根據您的投資，您會可能覺得對您選擇此特定硬體和軟體堆疊已鎖定。
雖然堆疊像 Hadoop 與 Spark 變得更輕鬆地安裝和管理，來自巨量資料的雲端服務中會是更高的遊戲交換器。ADL 雲端服務，提供解決巨量資料問題所需的儲存和計算能力。更重要的是，它提供關鍵原則之一是巨量資料的開發需求，就可以輕鬆。
巨量資料取得更容易
ADL 是以雲端為基礎的環境，提供巨量資料的查詢服務。這表示您不需要設定及管理任何硬體。當您準備好要進行巨量資料的開發時，您只需在 Azure 上建立 ADL 帳戶和服務會負責配置儲存體、 運算和網路資源。事實上，ADL 更進一步，抽硬體檢視幾乎完全。ADL 儲存體 (ADLS) 擔任一個彈性的儲存體系統，以容納檔案任意大小和數目的自動縮放。這項資料 ADL 分析 (ADLA) 圖層上執行查詢和轉換會配置動態視特定的計算作業的伺服器。不需要建置或管理任何基礎結構 — 只要 ADLS 成擷取資料，並使用 ADLA 執行各種查詢。從開發人員的觀點來看，ADL 建立的項目外觀和行為很類似具有無限的儲存體和計算能力的伺服器。這是功能強大的簡化設定環境和了解執行模型。
下一步簡化來自 U SQL 語言。U SQL 是 SQL 和 C# 的唯一組合。宣告式的 SQL 架構用來建置查詢或指令碼。這個部分會隱藏複雜度，起因於幕後的分散式、 平行的實際執行環境。開發人員，您不必說如何產生的結果。指定所要的結果，以及執行的查詢計劃的系統圖表。這是相同 RDBMS 但不同於其他您可能要定義對應和減少階段，或管理各種類型的背景工作節點建立的巨量資料堆疊上的 SQL 會發生什麼事。ADL 編譯器、 執行階段和最佳化系統會建立產生所需的資料，以及可能的平行處理的資料執行這些步驟的所有步驟。
請注意，查詢可以實際上是一組非常複雜的資料轉換和彙總。事實上，開發程式 U SQL 巨量資料的工作是撰寫可能很複雜的指令碼重新圖形資料、 準備 BI 工具中的使用者互動或進一步處理之其他系統，例如機器學習平台。雖然許多轉換來進行內建的各種不同的資料格式的 SQL 語言建構和轉換可能需要有的功能加入自訂程式碼。這時候就需要 C# U sql，可讓您建立邏輯自訂，但仍可擴充整個基礎的平行處理環境。涵蓋在 Michael Rys 線上文章中，「 擴充性中 U SQL 巨量資料應用程式，「 深入 U SQL 擴充性 (msdn.com/magazine/mt790200)，這是此特殊問題的部分。
新增的支援，在開發工具，例如 Visual Studio 提供另一個重要的簡化︰ 能夠使用熟悉的工具和互動模型來建置您巨量資料的程式碼基底。在本文的其餘部分中，我會說明針對 U SQL 程式設計在 Visual Studio 和，連同先前所述的功能，它們如何提供重大的轉變的簡易整體的巨量資料的使用中提供的功能。
開發 U SQL
若要讓巨量資料開發容易，您開始能夠輕鬆地建構程式。U SQL 結合兩種非常熟悉的語言，做為起點的事實會很容易了解，並移除其中一個採用巨量資料的障礙。在 Visual Studio 這類開發工具，它也可以輕鬆地重複使用熟悉的體驗，例如內建支援 C# 開發和偵錯。Azure 資料湖 Tools for Visual Studio 外掛程式 (bit.ly/2dymk1N) 提供 IntelliSense、 方案管理、 範例程式碼和原始檔控制整合周圍的預期的行為。
因為 ADL 是雲端服務，Visual Studio 工具會在與 Azure 整合，透過伺服器和雲端總管繪製。必須擴充或變更其他的體驗︰ U SQL 的 IntelliSense 包括資料表和函式定義內 ADLS，提供其為基礎的適當完成定域機組中了解。另一個金鑰組的功能在於 [圖 1, ，這是一種查詢執行圖形平行分散式雲端環境中執行的在編譯查詢時，所造成。
.png "在 Visual Studio 中檢視 U SQL 作業圖形")
在 Visual Studio 中檢視 [圖 1 U SQL 作業圖形
當您開發 U SQL 指令碼時，則啟動它與您在其他語言。您建立新的專案，您可以在其中加入 U SQL 類型的檔案。您可以將程式碼片段插入至查詢檔案，讓您開始著手，或存取範例程式碼範例專案中。當您已經撰寫一些程式碼，您很自然的編譯和執行程式碼以尋找和修正任何錯誤，並測試您的邏輯。直到程式碼到達整體功能等級，這就會變成您在緊湊的迴圈。
此工作迴圈有一些巨量資料的複雜性。巨量資料叢集中的巨量資料的程式碼執行，因此現有的情況是在叢集中執行其程式碼的開發人員。這通常需要的安裝和維護開發叢集。它也可能需要較長的時間進行提交、 執行和接收結果的完整週期。在此情況下緊湊的迴圈變成太慢。有些技術叢集中的 「 一箱 」 安裝可供使用。這可能需要特殊的安裝工具，但可能會安裝在您使用的開發機器上。
U SQL 提供編譯器和執行階段，可在本機電腦上執行，以簡化這種情況。執行計劃 （包括程度的平行處理原則、 資料分割，因此這類項目上） 的本機電腦和以雲端為基礎的環境可能大不相同時，計算和資料的 「 流程 」 圖形將會相同。因此，雖然在本機執行的效能將無法在雲端服務中的比較，它會提供功能的偵錯經驗。本機執行必要的工具已安裝的 Azure 資料湖工具 Visual Studio 外掛程式，並會立即。他們也將安裝的 NuGet 封裝，並從命令列執行用於自動化用途。
在本機執行環境看起來像 ADLA 的其他帳戶。您可以在資料湖分析] 區段，其中列出您以雲端為基礎的帳戶下的 [伺服器總管] 視窗中看到它。提交對話方塊上顯示選項清單上的目標帳戶的標籤 「 （本機）。 」 T他的本機帳戶可以有真正的帳戶擁有的所有子節點。這表示您可以定義中繼資料物件，例如資料庫、 資料表和檢視。您也可以註冊 C# 程式庫來支援 U SQL 指令碼有使用者定義的程式碼執行。這是為了提供完整的可測試性的定域機組環境 U SQL 程式碼的同位檢查。
U SQL 開發迴圈則看起來很像其他語言。您可以建立 U SQL 專案並足夠的程式碼準備就緒後，您可以編譯來找出語法錯誤。您也可以執行在本機偵錯 (F5)，而不需要 Visual Studio 中偵錯 (Ctrl + F5) 命令執行完成。這將會在檔案 ingestions （U SQL 中擷取命令），公開執行階段錯誤，例如資料剖析問題很常見的偵錯案例。在任何時間點，您可以切換提交 ADLA 帳戶在 Azure 中執行程式碼。請注意，這會產生查詢的整體時間為基礎的費用。
管理資料
假設資料集的巨量資料案例通常是過大而無法使用在開發電腦上，您需要管理測試及偵錯資料。為了處理這種常見方式是參考資料檔案的相對路徑。U SQL 編譯器會解譯相對路徑，從指定的執行環境的預設儲存體的根目錄。每個 ADLA 帳戶具有預設儲存體帳戶與它相關聯 （您可以看到這在伺服器總管] 視窗中）。在雲端中執行，此根目錄中找到的檔案路徑。在本機執行時搜尋路徑，以顯示在工具的全域資料根目錄底下 |選項 |Azure 資料湖。
進行開發，常見的作法是指定的檔案存在於本機和雲端中的相對路徑。指令碼接著可以執行而不需修改這兩個在本機或做為提交到 ADLA。在 Azure 中已存在的輸入的資料的情況下，您可以下載檔案的一部分。在 Visual Studio 中的 ADL 體驗可讓您執行這項操作，從工作圖形或檔案總管] 巡覽至檔案 （從伺服器總管] 中的儲存體帳戶的內容功能表），然後選取 [下載] 選項。如果資料還不存在，則必須建立測試檔案。資料準備就緒之後，可以和之前一樣繼續本機開發迴圈。
使用使用者定義的程式碼進行偵錯
U SQL 可讓您使用 C# 定義的客戶程式碼的事實導入了其他的偵錯功能。簡言之，C# 擴充功能必須註冊 ADLA 帳戶將會執行相關的查詢中的資料庫中。前面提過，也做法是在本機執行案例中使用 「 （本機） 」 的帳戶。一般情況下會建立另一個 C# 類別庫專案 （沒有 ADL 區域下的這個專案類型），然後將它登錄。
另外還有另一個簡單的方法，來定義使用者程式碼，並讓 Visual Studio 為您管理註冊。您會發現，在 U SQL 專案中，每個檔案會自動擁有與其相關聯的程式碼後置檔案。這是您可以在其中加入程式碼的簡單的延伸模組，並不是要與其他專案共用的 C# 檔案。在幕後建立程式庫、 註冊及取消註冊您的提交之查詢的執行期間，將管理 Visual Studio。同樣地，這是藉由 「 （本機） 」 帳戶，以及。
不論如何建立使用者定義的程式碼，它可以在本機環境中執行時偵錯與其他 C# 程式碼類似。可以在 C# 程式碼中設定中斷點、 檢查堆疊追蹤，變數保存或檢查，依此類推。開始偵錯 (F5) 命令就會啟動這項功能。
大規模偵錯
到目前為止，我所討論的功能，可讓您建置 U SQL 程式碼專案中的，指定資料來源、 編譯和在本機執行，並逐步執行 C#。如果您想要"，似乎比其他每一種語言我裡的程式碼 」，太棒了 ！ 我說過的目標是使用原本就複雜的分散式、 平行執行環境，並使其看起來像是您的撰寫語言桌面應用程式。我也討論過有點如何管理資料來源和 C# 之間本機的程式碼中的延伸模組和雲端環境。現在，讓我們聊聊指定唯一的巨量資料的作業，小數位數 （也就表示在雲端中執行） 的偵錯。
如果您有跟著開發您的程式碼及本機電腦上偵錯的方法，然後此時您或許已經知道的任何邏輯錯誤，取得您想要的輸出。換句話說，您的商務邏輯應該音效。巨量資料，，您將有龐大的資料量，且資料的格式可能會改變。請記住在資料湖架構中，原生格式儲存資料，並在稍後指定結構。這表示無法假設資料是正確格式，直到之後處理它之內。
現在，當您在雲端中大規模執行測試的程式碼，並嘗試處理所有的資料，您會看到新的資料並叫用之前未發現的問題可能會開始。此外，您的查詢編譯、 最佳化及分散可能是數百或數千個節點，其中每個部份資料執行邏輯的一部分。但是如果其中一個這些區塊的工作失敗，無法復原的方式，如何您可以找出哪些改變？
第一種，U SQL 和 ADLA 協助您進行這是要管理錯誤報告，如您所預期的工作服務會。如果發生例外狀況外使用者程式碼，則錯誤訊息中隨附的堆疊追蹤，而且從違反節點收集及儲存針對原本的工作 （查詢送出） 的詳細的資料。現在，當您在 Visual Studio 或 Azure 入口網站中檢視工作，您會立即顯示資訊時發生錯誤。不是需要剖析記錄檔或 stdout 檔案，並嘗試解密錯誤的位置。
更有趣且常見的案例是當您的自訂程式碼，且有發生失敗。例如，您要剖析二進位檔案格式與您自己的擷取程式，並且會在作業執行到一半的特定輸入。在此情況下，ADLA 一次會為您會執行許多工作。成功的查詢執行圖形部分，程式碼影像或中繼資料都不會保留在系統中。不過，如果頂點 （執行個體中執行圖形的節點） 失敗，並在使用者程式碼部分錯誤，則二進位可執行檔和輸入的資料會保留一段時間，以允許偵錯。中所示，此功能與 Visual Studio 中，整合 [圖 2。
.png "對失敗的端點，以在本機偵錯")
[圖 2 對失敗的端點，以在本機偵錯
按一下 [偵錯] 按鈕啟動的二進位檔、 資源和資料檔的複本從失敗的頂點到本機電腦。複製下載後，暫存的專案建立，並在 Visual Studio 的新執行個體中載入。您現在已失敗節點的可執行檔版本，而且可以執行所有一般偵錯您所預期，例如執行例外狀況、 將中斷點放在 C# 程式碼，以及檢查變數。請記住用來執行巨量資料作業的叢集中的個別端點實際商用伺服器，而且可能會類似於您的開發電腦。您也會有您的電腦上的本機的 U SQL 執行階段，因為這項功能會成為可能。
一旦您已經在本機電腦上偵錯問題，您將個別更新您的程式碼。專案和偵錯執行個體中所示的程式碼會從先前執行的查詢的成品，而且本機所做的變更。如果您有已註冊的程式庫的 C# 程式碼，，將需要重新建置並更新 ADLA 中的程式庫。如果您的 U SQL 指令碼或程式碼後置檔案，則您必須更新您的專案進行變更。
總結
巨量資料平台已經非常特殊的系統需要學習新的概念、 模型和技術。大部分早期採用者必須追根究底去了解這些系統，先進行設定的內部運作，然後要能夠在這些環境中進行程式設計的相關的原因。雖然欄位具有往前移動以點，安裝這些平台變得更簡單，更大的 shift 正在進行中。當今的機會是 leapfrog 巨量資料服務模型，其中系統抽象概念是在較高層級的定域機組中。這可讓環境的設定，巨量資料的一般，更有影響力的結果會是已大幅簡化的開發模型。
Azure 資料湖和 U SQL 的結合可簡化執行模型，程式設計典範和用來開發巨量資料的查詢和應用程式的工具。這有雙重讓更多開發人員若要開始利用巨量資料，以及為開發人員更快速地建置更複雜的巨量資料解決方案的效果。ADL 支援大量的支援工作流程管理、 資料移動、 商務智慧視覺效果和更多的分析服務在 Azure 中。U SQL 時啟動的巨量資料應用程式開發的最佳位置，查看其他服務隨著您的需要增長。
Omid Afnan 是在分散式的運算系統和相關的開發人員工具鏈的實作上使用 Azure 大數據小組的首席程式經理。 他會存在，及在中國運作。與他連絡 omafnan@microsoft.com。
感謝下列 Microsoft 技術專家來檢閱這份文件︰ Yifung 連結