資料領域概念橫行?讓我們從本質出發
技術領域每隔幾年就會出現一堆新的概念,概念剛出的時候都有一個非常清晰的錨點,在某個層面提出更優的解決辦法。資料領域也不例外,從最早的資料庫、資料倉儲、資料集市、到資料湖、湖倉一體、資料中臺、以及最近出鏡率較高的DataMesh、Data Fabric。我們需要從變化中找到一些不變的東西,最底層的邏輯是企業越來越重視資料,希望透過資料探勘價值,在這個過程中:
1、範圍逐步擴大:資料不再是部門級別的專享福利,而應該輻射到全企業;
2、方式逐步增多:以固定報表為始,自助式分析、機器學習等多元化方式逐步加入。
以上兩點都建立在兩個基礎之上,即資料是可信的 、資料獲取是高效的(包括系統間流轉資料的高效、業務人員用資料也是高效的)。
除資料庫外,其他的所有概念,都是以挖掘資料價值為導向, 所提出的資料架構實施方法,本質都在解決、資料可信度問題(質量與標準)、高效用數問題(更高效的找到資料、更便捷的用到資料)
一、資料庫 vs 資料倉儲 vs 資料集市
資料倉儲:Bill Inmon在1991年著作《建立資料倉儲》一書中,給出了資料倉儲的定義,資料倉儲是企業資料儲存的集合,用於支援管理決策,有四個核心特點,面向主題的、可整合的、相對穩定的、反映歷史變化的。
資料倉儲建模的方法論主要包括ER模型、維度模型、Data Vault模型(ER模型的衍生),這些方法論的主要作用是描述資料表如何在倉庫中進行組織,其中維度建模是應用最廣的一種資料倉儲建模方法。
面向主題的:區別於資料庫,資料庫圍繞應用系統功能、流程來進行設計,支援完成交易活動。但資料倉儲以分析需求為牽引,將多個資料來源在更高層次進行整合、抽象,資料圍繞主題來組織。
可整合的:資料倉儲可以將不同來源、不同儲存方式的資料整合至資料倉儲。
相對穩定的:資料倉儲中的資料不允許修改,主要支援查詢。
反映歷史變化的:資料倉儲中的資料保留歷史快照,能反映資料的變化。
資料庫是一個軟體、工具,用於儲存資料,主要應用場景是作為交易系統(應用系統)的資料儲存,資料庫中的表設計也是儘量避免冗餘,基於3NF的方式進行設計;資料倉儲匯聚多個系統的資料,按照主題域、主題、業務過程進行組織,表是透過引入冗餘進行設計,面向分析場景應用。
傳統關係型資料庫能幹資料倉儲的事兒嗎?答案是能幹,資料倉儲更像是一個邏輯概念,應用了資料倉儲方法論進行組織,用於資料分析決策的都可以稱為資料倉儲,它並不繫結底層技術選型,並且在大資料體系沒出現之前,就是這麼幹的。
初期:支援業務流程的關係型資料庫和麵向分析的資料庫共用一個例項,但歷史資料使用頻率很低,卻佔用了大量的儲存,從成本、效率上都不划算。
中期:支援業務流程的業務資料庫和麵向資料分析的資料庫做了物理上的分離,但仍然用傳統關係型資料庫做支撐。
現在:最後隨著資料越來越多,以及多個系統間的資料融合需求也越來越多,業務對資料時效性的需求也越來越高,以hadoop為代表的技術應運而生,也逐步被廣泛應用。目前最常見的就是,業務系統資料儲存基於傳統關係型資料庫進行構建,面向分析的資料倉儲基於hadoop技術體系構建。
資料倉儲建設過程中,為了讓邏輯更清晰,除了垂直分域/分主題以外,還會水平分層,在大的建模方法論作為一級框架下,分層各有差異,最常見的有ODS-DWD-DWS-ADS,阿里的one-data體系ODS-CDM-ADS,我們要明白分層的初衷:
1、分解問題,將複雜的指標計算逐步拆解為各個小問題。
2、更好的邏輯複用。
3、更清晰的資料呼叫關係。
而資料集市的概念,更傾向於是資料倉儲的一層,即資料應用層,面向某個特定組織、業務場景的指標資料,類似ADS。
二、資料湖 vs 資料倉儲
資料湖概念辨析以及常見技術通覽
資料湖被首次提出是在2010年的Hadoop World大會上,區別於資料倉儲的高度結構化結構,資料湖強調原汁原味的資料,希望企業資料如同小溪一般,源源不斷的將資料流入到資料湖,使用者可以直接基於資料湖裡的資料提取、萃取這些資料。後來各個頂級公司也都給出了自己的理解,但資料湖應該具備的能力都指向了以下三點:
1、資料湖可以儲存任何型別的資料,包括結構化、半結構化、非結構化。
2、資料湖可以支援多種計算場景,包括BI分析、機器學習。
3、資料湖支援任意規模資料的儲存。
辯論最多的就是資料湖和資料倉儲的區別和聯絡,有很多的聲音說資料湖是資料倉儲的下一個階段,但並非如此。
從價值主張上看,二者都是一種資料價值挖掘的構建方法。
從形式上看,資料湖強調資料的原汁原味,而資料倉儲強調高度結構化和預定義。有一個形象的比喻,資料湖是水池,資料倉儲是瓶裝礦泉水。
從儲存內容上看,資料湖不限制儲存的資料型別,裝置資料、社媒資料、應用資料等照單全收,而資料倉儲強調業務系統內結構化的關係型資料。
至於網上其他的對比,包括儲存的價效比(湖高倉低),資料質量(湖差倉好)、面向使用者(倉僅面向業務分析、湖面向分析、開發和資料科學家)等等,我認為過於片面,比如在雲原生的背景下,資料倉儲也可以選擇物件儲存、透過資料快取技術加速查詢,既做到了低成本,也做到了高效。資料倉儲和資料湖是從資料的角度出發, 一種構建的方法論,而不應與技術做繫結。
三、湖倉一體、資料中臺
lake house 湖倉一體概念在2020年也逐步被提起,資料庫中的資料高度規範化、價值密度高,但缺少一定的靈活性,即建模的過程中這個資料可被應用的場景已經被提前設計;資料湖的資料種類多、價值密度低、保持了一定了靈活性,但缺少規範化。在湖倉一體的架構中,資料倉儲作為資料湖上長出來的一個個小房子,抽取湖中的資料、基於資料倉儲建模方法論組織資料、面向業務應用資料,同時呢,二者間的後設資料可以聯動,共享資料目錄;資料倉儲的資料也會根據熱度沉降到湖中。目前來看營銷較多,見到的應用案例較少
針對資料中臺,網上有一個資料中臺的企業級定義,“聚合和治理跨域資料,將資料抽象封裝成服務,提供給前臺以業務價值的邏輯概念“,我們可以看出中臺有這樣幾個特點或目標,
1、基於集中化的資料架構採集跨域資料、消除資料孤島。
2、對資料進行加工並形成資料資產。
3、提供元件化能力可以快速加工資料應用產品。
4、提供API化的資料服務。
資料中臺可以分兩個部分來看,缺一不可,第一,資料中臺提供一套工具,可以支援企業完成跨域資料的整合、更便捷的資料管理、資料開發、資料建模、以及資料服務編排。第二圍繞業務場景,基於這套工具能力完成資料能力的建設。如果脫離了業務,僅落地工具毫無意義。所以中臺更像是一個集大成者,從散亂資料到業務場景的端到端一站式解決方案。
發展到資料中臺、湖倉一體這一階段,對資料規範化、資料管理的重視程度越來越高:
1、更強調資料標準、資料質量在開發過程中的落標,將質量問題在操作的各個環節落地,做到前向的資料治理,提高資料的可信度;
2、提供資料目錄,將資料資產化,解決了日常經營過程中找數的問題;
3、透過多元化的資料服務,如和自助分析工具、機器學習平臺、報表工具等聯動來解決用數的問題。
四、Data Fabric vs Data Mesh
資料倉儲、資料湖、資料中臺是典型集中式的資料架構建設方法,在當下應用系統多雲分佈的背景下,每日需要大量的資料被搬遷,隨著需求的增多,企業需要為新增和存量運維付出高昂的成本。Data Fabric在這樣的背景下被提了出來,核心點是透過虛擬化和主動後設資料驅動的手段,實現資料來源的快速連線,將搬運資料改為連線資料。資料虛擬化技術遮蔽了各種資料來源複雜性和差異性,無需移動、複製資料即可整合多個資料來源,在記憶體中進行資料的組合、準備和轉換,並以需要的格式呈現資料。
Data Mesh是由Zhamak Dehghani提出,”由領域驅動的分析資料架構,資料被視為產品,並歸屬於最熟悉,最可能消費資料的團隊“,現代資料業務已經演化為按照經營領域來組織產品團隊,但資料仍然是集中管理,造成了交付的遲緩和較高的成本。Data Mesh使資料產品的所有者承擔起資料質量的責任,對領域的資料由足夠的主導權、決策權,在相同的治理體系下管理資料,並透過標準化的方式保證資料服務的互通性
相比於Data Fabric,Data Mesh更像是從組織層面解決異構資料環境的資料管理問題。而Data Fabric是以”連線資料“的思想,透過資料虛擬化技術節約異構環境找數、用數、管數的問題。
五、寫到最後的一點思考
無論是集中式還是分散式,無論是透過技術手段驅動還是透過組織轉型約束,企業越來越重視資料的作用,也逐步有了管理資料的意識,很多企業透過設立CDO、以及資料管理組織來牽頭資料能力建設,也落地了一系列資料平臺工具、大資料能力來支援這一建設過程,在資料這條路上,企業一直在探索一個答案,來回答這樣的問題:
1)如何讓更多的人用到可靠資料。
2)如何提供更多元的方式用到可靠資料。
3)如何用更低成本、高效的方式用到可靠資料。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2926735/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 為什麼我們能從行話術語中發現領域模型? - mathiasverraes模型
- Facebook全年成果總結:我們在AI領域的行動從未停止AI
- 行業本質:我們在做產品&辦公室裡的木匠行業
- 領域模型的核心本質是什麼?模型
- 領域驅動系列:三種領域邏輯組織模式的本質模式
- 大資料引領我們走向資料智慧化時代大資料
- 從Android執行時出發,打造我們的脫殼神器Android
- 資料分析滲透到劇本創作領域
- 資訊領域核心技術扼在美國手裡,我們該何去何從?
- 從入門到研究,人工智慧領域最值得一讀的10本資料人工智慧
- 讓我們來深入淺出block吧BloC
- 讀書系列-《解構領域驅動》-領域概念
- 測試領域的發展和學習(我們都是溫水的青蛙)
- “執行力”的本質是“領導力”(轉)
- 實用領域,三類可以讓大資料發揮價值的途徑!大資料
- SAP智慧領域概念區分
- 從紅黑樹的本質出發,徹底理解紅黑樹!
- 讓我們重視程式執行效率 (轉)
- Python可以從事資料分析領域的工作嗎?Python
- 領域驅動設計核心概念
- 我們從雲端計算中領悟到的10件事
- 機器學習和資料科學領域,推薦幾本學習書單機器學習資料科學
- 機器學習這10年我們能在各自的領域做點什麼?機器學習
- 詳細分析 Java 中實現多執行緒的方法有幾種?(從本質上出發)Java執行緒
- 資料結構之Stack | 讓我們一塊來學習資料結構資料結構
- 資料結構之Queue | 讓我們一塊來學習資料結構資料結構
- 資料結構之Set | 讓我們一塊來學習資料結構資料結構
- Graph Embedding在人力資本領域的應用
- 有些大資料,我們們床上說……大資料
- 從Chat-GPT瞭解技術概念及醫療領域應用GPT
- DDD學習(二)—— 領域建模重要概念
- 工控領域的組態軟體概念
- 我們能從庫克身上學到的幾條領導理念
- 機器學習和資料科學領域必讀的10本免費書籍機器學習資料科學
- 資料結構之LinkedList | 讓我們一塊來學習資料結構資料結構
- 從概念到實踐,我們該如何構建自動微分庫
- 中國創客:智慧硬體領域弄潮兒給我們的啟示
- 想從事資料科學領域,需要多少數學知識?資料科學