計算機處理能力，云存儲容量和使用率以及網絡連接性在不斷提升，而這一切正在使大多數公司當前的數據泛濫成潮——大量詳細信息川流不息，如客戶的個人資料、銷售數據、產品規格，處理步驟等等。各種不同格式和不同來源的數據相繼產生，包括物聯網設備、社交媒體網站、銷售系統和內部協作系統。

 

盡管為簡化關鍵業務信息的收集，存儲和評估而設計的工具和技術的數量有所增加，但許多公司仍不確定如何更好地處理這些數據。業務領導者和IT領導者指出，他們因應對這一切而應接不暇——數量龐大且種類繁多，信息遍歷內部和外部網絡的速度以及管理所有這些業務智能的成本。漸漸地，他們要承擔更加復雜的任務：從所有這些業務信息中獲取重要的洞察。

 

這些高管必須大規模且快速地擴展數據管理方面的基礎設施。在這方面，有一類新興的數據管理技術的前景十分廣闊——數據湖。這些存儲平臺旨在保存，處理和分析結構化和非結構化數據。它們往往與傳統的企業數據倉庫（EDW）結合使用，但總的來說，它們的運營成本比企業數據倉庫要低。之所以能節省成本是因為這些公司可以使用價格低廉且易于獲得的硬件，同時也因為它們不需要在歸納時對數據集編制索引，也不需要做存儲方面的準備工作。數據以其本機格式（native format）保存并且僅在需要時才進行重新配置。關系數據庫也必須得到管理，可以將其當作數據湖平臺的一部分進行管理，但這只是為了讓最終用戶更輕松地訪問某些數據源。

 

數據湖有很多特點備受各大公司青睞。由于數據以“原始”格式加載，而不是在進入公司系統時進行預先配置，因此它們的使用方式不僅限于基本的采集。例如，有這樣一群數據科學家，他們并不確切知道自己在尋找什么，但他們可以快速查找和訪問數據而無需考慮格式。誠然，對希望創建可靠的高級分析程序的數據科學家來說，一個得到完善維護和管治的“原始數據區”簡直就是金礦。隨著這些公司不再滿足于小型試點項目而紛紛擴大數據湖的使用范圍，它們或許能夠為業務用戶建立“自助”選項，從而可以生成自己的數據分析和報告。

 

但是，要做到這幾點十分耗時且復雜——將數據湖與技術體系結構的其他要素集成，為全公司的數據湖的使用制定合適的規則，確定能為部署數據湖提供各種必要支持的產品、人才和能力并從中實現商業利益。例如，這些公司往往缺乏某些數據管理方法方面的專業知識，而這就需要找到精通新興數據流技術（例如Flume和Spark）的員工。

 

在許多情況下，這些公司紛紛放慢腳步。它們轉而依靠升級技術架構的久經考驗的方法，例如，參與有關最佳設計，產品和供應商的冗長的內部討論，如果沒有制定一個合適的解決方案，那就不急于創建數據湖解決方案。同時，他們也會錯失部署支持數字銷售和市場營銷以及新產品開發的高級分析程序的機會。

 

公司應該在數據湖的設計和部署中采用敏捷方法——先試行一系列技術和管理方法并對其進行測試和完善，然后才能獲得最佳的數據存儲和訪問流程。這樣做的公司可以跟上快速變化的數據監管和合規標準的要求，例如，于2018年5月生效的《通用數據保護法規》。也許更為重要的是，它們比競爭對手更快使市場獲得分析驅動的洞察，同時大大降低了管理數據架構的成本和復雜性。

 

 

•著陸區和原始數據區。在第一階段，數據湖是與核心IT系統分開創建的，數據湖可作為低成本且可擴展的“純捕獲”環境。數據湖是公司技術棧中的一個稀薄的數據管理層，這一層可以無限期存儲原始數據，然后再備用于計算環境中。組織可以部署數據湖而不會對現有的體系結構產生什么影響。如果公司不希望產生數據沼澤，那么它們早期就需要強有力的治理，包括嚴格的數據標記和分類。

 

•數據科學環境。在下一階段，組織可以開始更積極地將數據湖用作實驗平臺。數據科學家可以輕松且快速地訪問數據并且可以致力于運行數據實驗并分析數據，而不是僅僅專注于數據的收集。在這樣一個沙箱（sandbox）中，他們可以使用未做任何更改的數據來創建分析程序的原型。他們可以在數據湖旁邊部署一系列開源且商業化的工具，從而創建所需的測試平臺。

 

•為數據倉庫減輕負載。再下一階段，數據湖已開始與現有的企業數據倉庫（EDW）集成。只要利用與數據湖有關的低存儲成本，公司就可以容納“冷”（很少使用，休眠或不活動的）數據。它們可以使用這些數據來生成洞察而不必擔心迫近或超出存儲限制，也不必大幅增加傳統數據倉庫的大小。同時，公司可以在現有的企業數據倉庫中持續高強度地提取關系數據，而這些企業數據倉庫可以處理這些關系數據。它們可以將強度較低的提取和轉換任務遷移到數據湖，例如，“大海撈針”式的搜索，在這種搜索類型中，數據科學家需要清除數據庫以查找傳統索引結構無法支持的查詢。

 

•數據操作的關鍵組成部分。一旦公司進入了部署和開發這一階段，流經公司的許多信息很可能正在通過數據湖。數據湖成了數據基礎設施的核心部分，取代了現有的數據集市或運營數據存儲并實現了數據即服務。企業可以充分利用數據湖技術的分布式特性及其處理計算密集型任務的能力，例如執行高級分析或部署機器學習程序所需的任務。有些公司可能決定在數據湖之上創建數據密集型應用程序（例如，性能管理儀表板）。或者它們可以實施應用程序編程接口，以便無縫地將從數據湖資源中獲得的洞察與從其他應用程序中獲得的洞察無縫地結合起來。

 

公司將數據湖從簡單的著陸區（landing zone）擴展到數據基礎設施的關鍵組件所需的時間和能力將因其目標和出發點而異。在發展的各個階段，公司都需要研究與這些因素相關的復雜問題——數據集的大小和種類，數據管理中的現有功能，業務部門中的大數據專業知識水平以及IT組織中的產品知識。例如，當前環境中的分析工具有多復雜？公司是使用傳統的開發工具和方法，還是使用較新的工具？公司通常需要多少個并發數據用戶？工作負載是否得到動態管理？最終用戶需要多長時間才能訪問數據？在數據湖開發流程的各個階段，公司可能會被各種細節弄得焦頭爛額并失去動力。IT組織或業務部門的領導者不可避免地要去處理其他“緊急”項目。

 

但是，當IT和業務領導者根據敏捷開發模型回答這樣那樣的問題時，他們就可以加快數據湖從“科學項目”到完全集成了數據基礎架構的組件的過程。根據我們的經驗，敏捷方法有助于公司在數月（而非數年）的時間內從數據湖中獲得優勢。快速取得成果并證明近期的影響，這有助于使IT領導者和業務領導者參與并專注于數據管理方面的問題，從而限制這樣的需求——未來的返工和與數據填充以及對管理和訪問數據湖相關的協議進行無休止的調整。敏捷方法可以使IT和業務主管意見一致。這種協作不僅對于確定數據湖的技術路線至關重要，而且對創建有利于數據的工作環境以及基于數據洞察抓住新的商機都是至關重要的。

 

 

大多數組織都了解在軟件開發環境中對敏捷方法的需求。但鮮有組織在數據管理的環境中應用敏捷。通常，IT組織會牽頭審核潛在的技術和方法來創建數據湖，而很少聽取業務部門的意見。在敏捷方法中，IT領導者和業務領導者共同概述和解決相關技術和設計問題。例如，企業是使用一攬子解決方案來創建數據湖，還是將其托管在云端（使用私有服務器、公共服務器或混合異地服務器）？如何填充數據湖，即哪些數據集將流入數據湖，什么時候流出數據湖？理想情況下，數據湖的填充應該基于使用的輕重緩急并分多次完成，而不是一次性花大量的精力來連接數據湖內所有的相關數據流。

 

實際上，最成功的數據湖先行企業正在使用“業務支持（business back）”的方法來設計數據湖，而不是首先考慮技術因素。這些先行者正在確定業務部門可以從數據湖中獲得最大價值的方案，然后將這些方案納入存儲解決方案的設計（或重新設計）和部署決策中。然后，這些公司將根據需要用特定組或用例的數據來漸漸填充數據湖。公司沒有全力采用一種指定的解決方案，而是試行了不同提供商的兩個或三個最終候選方案，以評估其產品的實際性能，集成的簡易性和可擴展性。

 

這種靈活的部署方法可以確保盡早發現性能或實施方面的難題。這還包含了業務部門的反饋。隨著數據湖的填充，分析和存儲技術的變革以及業務需求的發展，這也為敏捷開發團隊騰出了修改流程和數據管理協議的空間。

 

隨著數據湖漸漸從試驗項目轉變為數據體系結構的核心元素，業務和技術領導者必須重新考慮其治理策略。具體來說，隨著數據在數字世界中得到快速收集和使用，這些領導者必須學會在這兩者之間取得平衡——傳統數據監管的剛性與對靈活性的需求。在敏捷的治理方法中，企業可以在新的資源進入數據湖時進行充分地監督，從而避免傳統數據倉庫所需的一些更嚴格的工程實踐，然后根據業務需求確定最佳規則和流程以尋求最佳解決方案。例如，即使某類數據的業務案例仍在確認中，數據科學家仍可以自由地研究數據。同時，如果用例沒有堅實的根基，一線用戶很可能會面臨更嚴格的管控。

 

但是，至少，公司應該指定某些人來負責管理數據集和流程，以便明確職責并快速做出與數據源和訪問權限有關的決策。由于數據不是預先構造的，因此公司還希望捕獲流入數據湖中的所有數據源（在數據湖本身內或在單獨的注冊表中）的元數據并為所有利益相關者維護一個中央數據目錄。此外，公司在使用數據管理協議時可能需要重新配置訪問權限，同時要牢記與保存個人身份信息有關的各種法規要求和隱私問題。數據負責人必須將這些訪問權限傳達給所有的利益相關者。

 

 

我們不妨思考一下一家跨國銀行是如何在其數據湖開發中應用敏捷原則的。該銀行一直面對幾個關鍵的數據難題：低質量的業務信息、沒有足夠的專家來管理不同格式的數據集、陳舊的數據倉庫技術以及千余個數據源。這個系統混亂不堪。該銀行必須將傳入的數據集輸入到四個數據倉庫層（輸出傳遞、標準格式、主題層和應用程序層）以及在創建任何可用的報告之前，它都必須對這些層進行結構化。

 

除了這些技術難題之外，銀行的業務和IT領導者并沒展開合作，這加劇了該公司的數據問題。數據存儲于隔離的系統中，因此重要的業務信息往往一直無法得到使用。但是，由于業務部門和IT部門之間的協調和溝通不暢，它們要求訪問某些數據集時無法得到快速響應。它們將數據管理視為“IT的工作”；業務領導者對這個話題諱莫如深，因此極力表達他們的數據需求。

 

該銀行的高管們擔心失去客戶，這在一定程度上歸因于該公司無法熟練地管理數據。他們決定使用數據湖技術來嘗試簡化數據集的提取，結構化和傳遞。為了跟上軟件開發人員的工作速度，該公司使用了敏捷開發模型并分階段推出了數據湖項目。

 

高管們召集了一個由業務部門和IT組織的課題專家組成的敏捷的數據團隊，此舉的目的是先本著提高數據質量和數據訪問的目的考慮各種用例的業務影響，然后再確定公司就哪些領域對數據湖進行初步訪問。

 

實施敏捷的數據團隊對業務用戶進行了深入的訪談以確定現有數據管理實踐中的各種痛點和機遇。該團隊計劃在為期四個月的窗口期內發布大量新的數據服務和應用程序——此舉是為了實施新的數據管理工具，與業務部門一起開發數據交付服務并根據客戶的反饋意見完善流程。啟動敏捷數據項目的最初幾個月里，該銀行就能夠將與特定業務用例相關的數據加載到一個公共環境中并發現為業務部門提供服務所需的關鍵數據元素。

 

業務取得了引人注目的成果，這些成果使該銀行在接下來數月將數據湖的使用范圍擴展到其他領域。從預先為所有數據按結構編排到只為已得到使用的數據記錄后端的過程，這樣的轉變十分重要。銀行能夠打破數據孤島。如今，銀行可以在一個地方找到系統的信息，而且員工能夠訪問各種各樣的數據（人口、地理、社交媒體等），從而無死角地查看客戶。業務部門和IT部門之間的協作得到了加強，員工和客戶的滿意度也得到了提升。

 

有越來越多的公司在試驗數據湖，它們希望在信息流中獲得固有優勢，因為這些信息流易于訪問，而且其存儲成本要比傳統倉庫中的數據便宜。但是，與任何新技術的部署一樣，這些公司將需要重新構想各種系統，流程和治理模式。安全協議，人才庫和企業體系結構的創建將不可避免地存在問題，這些問題不僅可以確保技術棧內部的靈活性，還可以確保業務職能的靈活性。我們的經驗表明，采用敏捷方法實施數據湖有助于公司快速且高效地學習新事物。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。