資料湖是一種不斷演進中、可擴充套件的大資料儲存、處理、分析的基礎設施；以資料為導向，實現任意**、任意速度、任意規模、任意型別資料的全量獲取、全量儲存、多模式處理與全生命週期管理；並通過與各類外部異構資料來源的互動整合，支援各類企業級應用。
用阿里的資料架構圖來說:
簡單來說，資料湖的定義就是原始資料儲存區。 雖然這個概念國內談的少，但絕大部分網際網路公司都已經有了。國內一般把整個hdfs叫做數倉（廣義），即存放所有資料的地方。
資料湖最早是2023年由pentaho的首席技術官james dixon提出的乙個概念，他認為諸如資料集市，資料倉儲由於其有序性的特點，勢必會帶來資料孤島效應，而資料湖可以由於其開放性的特點可以解決資料孤島問題。
為什麼不是資料河？
因為，資料要能存，而不是一江春水向東流。
為什麼不是資料池？
因為，要足夠大，大資料太大，一池存不下。
為什麼不是資料海？
因為，企業的資料要有邊界，可以流通和交換，但更注重隱私和安全，「海到無邊天作岸」，那可不行。
所以資料要能「存」，資料要夠「存」，資料要有邊界地「存」。企業級的資料是需要長期積澱的，因此是「資料湖」。
同時湖水天然會進行分層，滿足不同的生態系統要求，這與企業建設統一資料中心，存放管理資料的需求是一致的。熱資料在上層方便流通應用，溫資料、冷資料位於資料中心的不同儲存介質之中，達到資料儲存容量與成本的平衡。
但隨著資料湖在各類企業的應用，大家都覺得：嗯，這個資料有用，我要放進去；那個資料也有用，我也要放進去；於是把所有的資料不假思索地扔進基於資料湖的相關技術或工具中，沒有規則不成方圓，當我們認為所有資料都有用時，那麼所有的資料都是垃圾，資料湖也變成了造成企業成本高企的資料沼澤。
需要具備把各種資料來源接入整合到資料湖中的能力。資料湖的儲存也應該是多樣的，比如hdfs、hive、hbase等等。
治理能力的核心是維護好資料的元資料（metadata）。強制要求所有進入資料湖的資料必須提供相關元資料，應該作為最低限度的治理管控。沒有元資料，資料湖就面臨成為資料沼澤的風險。更豐富的功能還包括：
如果把整個網際網路想象成乙個巨大的資料湖。那麼，之所以人們可以這麼有效的利用這個湖中的資料，就是因為有了google這樣的搜尋引擎。人們可以通過搜尋，方便地找到他們想要的資料，進而進行分析。搜尋能力是資料湖的十分重要的能力。
對資料的使用許可權進行管控，對敏感資料進行脫敏或加密處理，也是資料湖能商用所必須具備的能力。
資料質量是分析正確的關鍵。因此必須對進入資料湖中的資料的質量情況進行檢驗。及時發現資料湖中資料質量的問題。為有效的資料探索提供保障。
首先，把所有原始資料都儲存下來的想法，要基於乙個前提，就是儲存成本很低。而今資料產生的速度越來越快、產生的量越來越大的情況下，把所有原始資料，不分價值大小，都儲存下來，這個成本在經濟上能不能接受，可能需要打乙個問號。
其次，資料湖中存放這各類最原始的明細資料，包括交易資料、使用者資料等敏感資料，這些資料的安全怎麼保證？使用者訪問的許可權如何控制？
再次，湖中的資料怎麼治理？誰對資料的質量、資料的定義、資料的變更負責？如何確保資料的定義、業務規則的一致性？
資料湖的理念很好，但是它現在還缺乏像資料倉儲那樣，有一整套方**為基礎，有一系列具有可操作性的工具和生態為支撐。正因如此，目前把hadoop用來對特定的、**值的資料進行處理，構建資料倉儲的模式，取得了較多的成功；而用來落實資料湖理念的模式，遭遇了一系列的失敗。這裡，總結一些典型的資料湖失敗的原因：
資料沼澤：當越來越多的資料接入到資料湖中，但是卻沒有有效的方法跟蹤這些資料，資料沼澤就發生了。在這種失敗中，人們把所有東西都放在hdfs中，期望以後可以發掘些什麼，可沒多久他們就忘那裡有什麼。
資料泥團：各種各樣的新資料接入進資料湖中，它們的組織形式、質量都不一樣。 由於缺乏用於檢查，清理和重組資料的自助服務工具，使得這些資料很難創造價值。
缺乏自助分析工具：由於缺乏好用的自助分析工具，直接對資料湖中的資料分析很困難。一般都是資料工程師或開發人員建立乙個整理後的小部分資料集，把這些資料集交付給更廣泛的使用者，以便他們使用熟悉的工具進行資料分析。這限制了更廣泛的人參與到探索大資料中，降低了資料湖的價值。
缺乏建模的方**和工具：在資料湖中，似乎每一項工作都得從頭開始，因為以前的專案產生的資料幾乎沒有辦法重用。 其實，我們罵資料倉儲很難變化以適應新需求，這其中有個原因就是它花很多時間來對資料進行建模，而正是有了這些建模，使得資料可以共享和重用。資料湖也需要為資料建模，不然每次分析師都得從頭開始。
缺少資料安全管理：通常的想法是每個人都可以訪問所有資料，但這是行不通的。企業對自己的資料是有保護本能的，最終一定是需要資料安全管理的。
乙個資料湖搞定一切：大家都對能在乙個庫中儲存所有資料的想法很興奮。然而，資料湖之外總會有新的儲存庫，很難把他們全都消滅掉。 其實，大多數公司所需的，是可以對多種儲存庫聯合訪問功能。是不是在乙個地方儲存，並不是那麼重要。
其二是非易失和隨時間變化，資料倉儲儲存了過去每一天的快照且通常不更新，使用者可以在任一天向前或者向後對比資料的變化；
其三是面向主題，根據業務對資料進行有效的編碼，讓理論最佳值在應用中落地。
資料湖，準確說，其出發點是補全資料倉儲實時處理能力、互動式分析能力等新技術缺失的情況。其最重要的特點，就是豐富的計算引擎：批處理、流式、互動式、機器學習，該有的，應有盡有，企業需要什麼，就用什麼。資料湖也有三個特徵：
資料湖和數倉，就是原始資料和數倉模型的區別。因為數倉（狹義）中的表，主要是事實表-維度表，主要用於bi、出報表，和原始資料是不一樣的。
為什麼要強調資料湖呢？
真正的原因在於，data science和machine learning進入主流了，需要用原始資料做分析，而數倉的維度模型則通常用於聚合。
資料湖是開放、自助式的（self-service）：開放資料給所有人使用，資料團隊更多是提供工具、環境供各業務團隊使用（不過集中式的維度表建設還是需要的），業務團隊進行開發、分析。
也就是組織架構和分工的差別 —— 傳統企業的資料團隊可能被當做it，整天要求提數，而在新型的網際網路/科技團隊，資料團隊負責提供簡單易用的工具，業務部門直接進行資料的使用。
從傳統集中式的數倉轉為開放式的資料湖，並不簡單，會碰到許多問題
資料管理：多個團隊使用資料，如何共享資料成果（比如畫像、特徵、指標），避免重複開發
這也是目前各大網際網路公司都在改進的方向！
2023年，大資料databricks公司首次提出了湖倉一體（data lakehouse）概念，希望將資料湖和資料倉儲技術合而為一，此概念一出各路雲廠商紛紛跟進。
data lakehouse（湖倉一體）是新出現的一種資料架構，它同時吸收了資料倉儲和資料湖的優勢，資料分析師和資料科學家可以在同乙個資料儲存中對資料進行操作，同時它也能為公司進行資料治理帶來更多的便利性。
1) 目前資料儲存的方案
現在許多的公司往往同時會搭建數倉、資料湖這兩種儲存架構，乙個大的數倉和多個小的資料湖。這樣，資料在這兩種儲存中就會有一定的冗餘。
2) data lakehouse（湖倉一體）
data lakehouse的出現試圖去融合數倉和資料湖這兩者之間的差異，通過將數倉構建在資料湖上，使得儲存變得更為廉價和彈性，同時lakehouse能夠有效地提公升資料質量，減小資料冗餘。在lakehouse的構建中，etl起了非常重要的作用，它能夠將未經規整的資料湖層資料轉換成數倉層結構化的資料。
依據databricks公司對lakehouse 的定義：一種結合了資料湖和資料倉儲優勢的新正規化，解決了資料湖的侷限性。lakehouse 使用新的系統設計：直接在用於資料湖的低成本儲存上實現與資料倉儲中類似的資料結構和資料管理功能。
湖倉一體，簡單理解就是把面向企業的資料倉儲技術與資料湖儲存技術相結合，為企業提供乙個統一的、可共享的資料底座。
避免傳統的資料湖、資料倉儲之間的資料移動，將原始資料、加工清洗資料、模型化資料，共同儲存於一體化的「湖倉」中，既能面向業務實現高併發、精準化、高效能的歷史資料、實時資料的查詢服務，又能承載分析報表、批處理、資料探勘等分析型業務。
湖倉一體方案的出現，幫助企業構建起全新的、融合的資料平台。通過對機器學習和ai演算法的支援，實現資料湖+資料倉儲的閉環，提公升業務的效率。資料湖和資料倉儲的能力充分結合，形成互補，同時對接上層多樣化的計算生態。
資料分析 概要
隨著網際網路的日益繁榮以及人工智慧的不斷火熱，我們會產生大量的資料，這些資料背後隱藏著大量的有用 核心的資訊。比如說通過蒐集 京東 天貓等購物資料，可以大概了解使用者喜歡購買哪些商品，從而構建知識圖譜，然後通過系統推薦演算法給使用者推薦一些商品，從而促進消費。因此，資料分析也越來越有地位，當然資料分...
mosquitto概要分析 常用資料結構
1.主要資料結構 struct mosquitto mosquitto internal.h 儲存客戶端連線的所有資訊 struct mosquitto db mosquitto broker.h 對所有內部資料的統一管理，儲存所有客戶端，訂閱關係，可是為資料倉儲 struct mosquitto ...
storage功能概要分析
storage初始化註冊 其對於tracker做客戶端處理 1 storage程序main storage func init storage func init tracker get my server id tracker get storage id tcpsenddata nb track...