50
技術社區[雲棲]
360度解析企業智能數據湖平台
本文根據DBAplus社群第86期線上分享整理而成。
講師介紹
張揚
DaoCloud售前技術支持
-
負責麵向企業用戶的DaoCloud應用雲平台整體解決方案交付。
-
曾任職IBM AICS雲服務項目，熟悉Cloud Infra和DevOps相關工作。個人公眾號：小張烤茄。
主題簡介：
1、數據湖概念解析
2、數據湖和數據倉庫的區別
3、現代化數據架構
4、DCE智能數據湖平台
一、數據湖概念
數據湖（Data Lake）的概念最早出現在 2011 年福布斯的一篇文章《Big Data Requires a big new Architecture》，該文章中主要提到數據倉庫存放的數據都是預先組織和處理過，分析方式也基本定型。但在大數據時代，數據量的龐大、數據來源和類型的多元化、數據價值密度低、數據增長快速等特性使得傳統的數據倉庫無法承載，因此需要一個新的架構來作為大數據的支撐。
數據湖是一種大型數據存儲庫和處理引擎，它能夠存儲大量各種類型的數據，擁有強大的信息處理能力和彈性擴展能力。在 IT 的價值已逐漸從應用往數據轉移的趨勢下（IT to DT），數據湖技術將是企業各類信息係統的核心部分，是進行科學研究和企業決策管理的重要技術手段。
1 數據湖的特點
-
全部采集（Collect Everything）
數據湖采集並存放任意類型和來源的數據。數據類型包含結構化、半結構化和非結構化等數據，數據來源可以是來自企業內部所生成的數據，也可以是來自外部公共數據。
-
隨處研究（Dive In Anywhere）
數據湖也是一個大數據分析平台，提供多種計算和調度框架，用戶可按照自己的需求和條件跨多種業務單元來對數據進行精煉、探索和分析。
-
靈活訪問（Flexible Access）
數據湖為多元化數據訪問提供一個共享的基礎架構，該架構包含數據存儲和數據分析兩個層麵，為大數據多種場景的提供基礎支撐。
2 數據湖的邏輯架構
-
所有從內部和外部獲取的結構化、半結構化和非結構化數據被存放在數據湖的持久層（Persitent Layer）；
-
數據科學家和分析師被授予持久層的訪問權限並使用分析沙箱（Analytics Sandbox）進行數據研究和實驗。數據分析師會將有商業價值的數據進行處理並創建新的數據源（Curated）以提供給業務分析師；
-
業務分析師繼續精煉已處理過的數據，他們會和數據管理團隊一起將這些數據轉換為更為容易操作和使用的數據，並存放在可操作層（Operational layer）以便得到更廣泛的使用。
二、數據湖和數據倉庫的區別
1 數據湖存放所有數據
在數據倉庫的建設過程中，相當多的投入會花在分析數據源、理解業務流程和數據模型建立上，目的是為了給最終的表報設計了一個高度結構化的數據原型，這種方式通常被用來簡化數據建模和節省數倉所需要的昂貴存儲空間。
數據湖則儲存所有的數據，不僅是現在需要用到的數據，也包含以後可能會用到或者壓根就用不到的數據。所有時間的數據都會被保存起來，使得企業能夠追溯到任意時間來數據分析。
存放全部數據的方式能夠被實現的是因為數據湖所需要的硬件通常與數倉需要的有很大不同。在數據湖中，使用一些廉價或已退役的服務器外加一些便宜的磁盤即可相當經濟的將數據湖擴展到 PB 級別，而數據倉庫一般都會使用高性能的服務器和高端集中式存儲。
2 數據化支持所有的數據類型
數據倉庫中的數據一般由業務係統導出，指標化後再導入數倉，數倉中的數據都經過高度結構化的處理，非傳統的數據如日誌、文本、圖片和影像等數據被大量忽略。這些非結構化數據的價值正在被持續的挖掘和發現，但使用數據倉庫來消費和存儲它們會比較困難且代價較高。
數據湖的儲存方式在包含傳統數據的同時也會包含這些非傳統的數據類型，它存放不論來源和結構的所有數據。數據在數據湖中保持他們原有的形態，直到準備被使用的時候才會進行轉換。
3 數據湖支持所有的用戶
在絕大多數的企業中，80%或更多的用戶是業務人員，他們關心的是業務報表及之中的關鍵性指標。數倉主要適合這些用戶，因為數倉中的數據都被結構化得很好，容易使用和理解。
另外10%的用戶會對數據做更多的分析。他們把數據倉庫作為數據來源但常常也需要回到原有係統中去獲取那些數倉沒有錄入的數據，更有些時候會去企業外去獲取一些數據。他們不僅僅隻關心業務報表，很多時候會基於自身需求去定義新的報表。數據倉庫雖然為他們提供源數據，但是在數據源不夠充足的情況下，這類人通常跨出數倉的界限去尋找數據。
剩下的10%用戶，會對數據進行更加深入的分析，他們可能創建全新的數據源來進行研究，混合很多不同類型的數據來應答新的問題。他們也會用到數據倉庫，但通常會因為他們所需要的數據遠遠超出數倉的範疇而忽略它。這些用戶包含數據分析師、統計學家乃至數據科學家，這類用戶可能會用到更加高級的分析工具和更佳全麵的數據源。
數據湖支持以上所有用戶的需求，滿足數據科學家在數據湖中對他們所需要的大量多元化數據進行分析的同時，其他的用戶也可以像平時一樣利用更加結構化的數據來查看圖表。
4 數據湖更容易適應變化
構建一個完善的數據倉庫在前期所需要的投入是可以想象的。原則上來說，一個好的數倉需要能夠適應變化，但因複雜的數據錄入流和為簡化分析和報表所做的一些工作，一旦需要變更數倉的時候則必須投入一些人力和時間。
很多業務層的問題沒辦法等到數倉團隊去完成數據倉庫的適配後再給出答案，這些快速增長的需求得以自助的方式來迅速給出應對。
在數據湖中，因為所有的數據以原始的方式存放並且在需要使用的時被轉換，用戶可以跳出數據倉庫的限製來使用全新的方式去瀏覽數據來尋求問題的解答。
如果數據瀏覽後發現數據是有價值且可以被重複利用的，那麼給予這些數據一個更加合適的使用模式（如將數據結構化之後導入到關係型數據中），使得它們能夠得到更加廣泛的使用。如果認為數據是沒用的，那就無需為這些數據去投入任何人力和時間成本。
5 數據湖提供更快的洞悉能力
因為數據湖包含所有數據和數據類型，並且它能夠讓用戶在數據經過清洗、轉換和結構化之前就訪問數據，這種方式使得用戶能夠比傳統的數據倉庫方式更快的得到結果。
在早期出於數據分析（計算）和存放（存儲）的成本考慮，數倉開發團隊不會對所有的數據來源來構建數據倉庫並進行分析。這好像讓用戶在一個固定的範圍內去瀏覽和使用他們能看到的數據。但業務人員卻不希望這樣，他們需要看到最全麵的運營報表和指標來輔助他們決策。
關注業務報表的人將可以從數據湖中利用更多的結構化數據視圖，就像跟之前在數據倉庫裏麵一樣。不同的是這些視圖作為元數據存放在數據湖中，而非經過開發者處理後比較死板的報表。
從對比來看數據湖似乎要比數據倉庫好很多，但就個人理解，數據湖並非用來替代數據倉庫，而是在大數據時代下對數倉的一種補充。兩者完全可以基於需求和場景來協同工作，而非二者必居其一。
三、現代化數據架構
大數據技術用來支撐和增強現代化的數據分析方式但並非要取代傳統的分析係統。我們需要的是一個現代化的數據架構，在包含數據湖所有好處的同時結合傳統關係型數據倉庫以及OLAP 引擎實現快速查詢和分析等功能，借此支持所有級別業務的數據消費，提供所有數據消費者所需要的能力。
上圖是 Hortonworks 公司基於 Hadoop 生態構建的數據湖提出的現代化數據架構（Morden Data Architecture），從南向北包含四個層麵：
-
數據采集層（Data Acquisition Layer）
數據采集層負責從數據源抽取和移動數據，並將數據存放到數據湖中。采集的數據源包括傳統的關係型或事務型係統、用戶獲取的數據、非結構化或半結構化數據、外部數據或流數據等。
-
數據監管層（Data Curation Layer）
數據監管層負責數據湖中的數據組織、定型並為其他層提供消費，包含數據標準化流程製定，數據創建、脫敏、清洗、轉換、維護、管理和展現等工作。
-
數據供應層（Data Provisioning Layer）
數據供應層采用更適用於業務報表和分析的傳統數據儲存方式，使用OLAP、數據倉庫和數據集市降低數據消費的複雜度並提供快速的交互式查詢和分析。
-
數據消費層（Data Consumption Layer）
數據消費層提供所有最終用戶的接口，對於不同用戶對數據的需求，大量和多元化的工具和技術會被用於該層。
四、DCE 智能數據湖平台
潮汐，是海水在天體引潮力作用下所產生的周期性運動，白天的漲落為潮，晚上的稱為汐。企業應用係統的運行也存在類潮汐現象，白天主要響應業務請求，晚上主要進行數據處理。
在“業務潮汐”和“數據湖泊”的理念下，DaoCloud 基於容器化技術引出“計算潮汐”的理念，並將此融入到DCE 應用雲平台中形成智能數據湖解決方案。
作為整個智能數據湖平台的核心，該平台通過采用基於 PaaS + Data Lake 的雙擎運轉模式打通底層硬件資源和頂層應用係統間的壁壘。白天業務繁忙時，會將更多的計算資源向業務應用傾斜，晚上進行大量數據處理時，則將計算資源分配給數據應用，以此來提高應用係統的彈性，實現資源的錯峰高效利用。
挖掘大數據的價值好比沙裏淘金，想從沙子中獲得更多的金子關係到兩點：淘金技術和沙子總量。
通過結合雲計算和大數據相關技術構建而成的智能數據湖，兼顧大規模、高彈性和可擴展的計算能力和存儲能力，計算能力提高“淘金技術”，存儲能力增加“沙子總量”，縮短數據生產到數據價值的路徑，快速體現數據資產價值，推動業務持續創新。
Q&A
Q1：數據湖和流處理是什麼關係？能在數據湖裏做流式計算嗎？
A1：數據湖包含分布式存儲和分布式處理引擎，流處理屬於其中的一種，數據湖中可以基於storm和Spark streaming實現流式計算。所以數據湖和流處理的關係是前者包含後者。
Q2：請問查詢MySQL 的時候用set value設置變量，然後查詢會有什麼負麵影響或者邊際效應？
A2：變量綁定主要是為了共享SQL，提高代碼的通用性和可讀性的同時減少SQL的硬解析。需要看一下MySQL有沒有類似Oracle Shared Pool的概念，如果有的話對性能方麵應該是正麵影響。
原文發布時間為：2016-12-27
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-13 08:42:40