本文根據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