一文讀懂 Data Mesh
將一個系統置於恆定的約束之下可能會導致脆弱性的進化。-- C.S. Holling, ecologist
成為一個資料驅動的組織是許多公司的戰略目標之一,因為資料驅動的好處顯而易見: 基於資料和個性化提供最好的客戶體驗; 透過資料驅動的最佳化降低運營成本和時間; 給予員工具有趨勢分析和商業智慧的力量。然而,儘管在構建資料平臺方面付出了越來越多的努力和投資,仍然會發現結果並不理想。
當前的技術進步解決了資料處理計算的規模問題,但還有問題懸而未決: 資料產生場景的變化、資料來源的擴散、資料用例和使用者的多樣性以及對變化的反應速度。Data Mesh或許可以解決這些問題。
1. 資料是什麼?
資料到底是什麼意思?又是一個“每個人心中都有一個哈姆雷特”的問題。資料通常被分為運算元據和分析資料。從資料庫的視角來看,即我們常說的OLTP和OLAP。一般地,運算元據位於服務提供業務功能的資料庫中,具有事務性質,保持當前狀態並服務於執行業務的應用程式的需求。分析資料是隨著時間的推移對業務事實的時間和聚合檢視,透過建模以提供回顧性或未來的洞察力,訓練機器學習模型或為分析報告提供資訊。
當前的技術、架構和組織的狀態導致了這兩個資料領域的分歧,存在兩個層次,整合而又分離。這種分歧往往會導致架構的脆弱性。也導致了ETL 和不斷增長的迷宮般資料管道的複雜性。對於許多試圖連線這兩個領域的人來說,資料從運算元據領域流動到分析資料領域,然後再返回運算元據領域。
分析資料領域主要有兩個體系結構和技術棧: 資料湖和資料倉儲,而資料湖支援資料科學的訪問模式,資料倉儲支援分析和商業智慧報告訪問模式。而實踐中常常出現,資料倉儲試圖搭載資料科學的工作流,資料湖又試圖服務於資料分析師和商業智慧。
2. 資料領域面臨的挑戰
首先,資料平臺的發展大約經歷了三個階段:
1,專有的企業資料倉儲和商業智慧平臺。這是一個價格昂貴的解決方案,給公司留下了大量的技術債務; 成千上萬的無法維護的 ETL 、表格和報告中的技術債務,同時只有少數專業人員能夠理解,導致對業務的積極影響沒有得到充分實現。
2,以資料湖為靈丹妙藥的大資料生態系統。複雜的大資料生態系統和由高度專業化的資料工程師組成的資料團隊長期執行批處理作業,創造了資料湖怪物,充其量只能讓一小部分研發分析成為可能,承諾過多而實現不足。
3,目前的資料平臺與前兩個階段或多或少有些相似,具有現代化的轉變: (a)使用諸如 Kappa 這樣的架構實現實時資料可用性的流,(b)將資料轉換的批處理和流處理這樣的框架統一起來,以及(c)完全接受基於雲的儲存、資料管道執行引擎和機器學習平臺的管理服務。
顯然,第三代資料平臺正在彌補前幾代的一些差距,如實時資料分析,以及降低管理大資料基礎設施的成本,但是,仍然存在著諸多的挑戰。
2.1 中心化架構的挑戰
資料平臺從企業的各個角落攝取資料,包括執行業務的操作和事務系統,或者增加企業知識的外部資料提供者。例如,在流媒體業務中,資料平臺負責獲取大量資料: “媒體播放器表現”、“使用者如何與播放器互動”、“播放的歌曲”,以及業務上的“標籤”、與藝術家之間的“交易”,以及外部市場研究資料,如“人口統計”資訊。清理、豐富源資料並將其轉換為可信賴的資料,以滿足不同使用者的需求。這將嘗試將使用者的操作流程和行為重構為聚合檢視。
資料平臺為具有不同需求的各種消費者提供資料集服務。這包括從分析性消費到探索資料,從基於機器學習的決策制定,到總結業務表現的商業智慧報告。單一資料平臺承載並擁有邏輯上屬於不同領域的資料,例如“播放事件”、“銷售指標”、“藝術家”、“專輯”、“標籤”、“音訊”、“播客”、“音樂事件”等來自大量不同領域的資料。
儘管我們已經成功地將領域驅動設計和有界上下文應用到軟體系統中,但是在很大程度上忽略了資料平臺中的領域概念,從面向領域的資料所有權轉移到集中領域不可知的資料所有權。這種中心化架構可以適用於擁有較少不同消費案例且較簡單領域的組織,但是對於擁有豐富領域、大量來源和不同消費者集合的企業來說,難以滿足需求,原因如下:
無處不在的資料和資料擴散: 隨著越來越多的資料變得無處不在,在一個平臺的控制下消費所有資料並在一個地方協調它的能力會降低。
組織的創新和消費者的激增: 組織對快速實驗的需求引入了大量的用例來消費來自平臺的資料。這意味著資料聚合、預測和切片上的轉換越來越多,這些轉換用來滿足創新的測試和學習週期。滿足使用者需求的長響應時間歷來是組織摩擦點,目前仍然如此。
2.2 流水線耦合的挑戰
通常,資料平臺會被分解為資料處理階段的流水線。一條流水線,在高層次上實現了資料處理技術實現中的功能內聚,即攝取、準備、聚合、服務等。這種方式提供了一定程度的規模化,但將團隊分配到流水線的不同階段,有一個固有的限制,會導致交付變慢。流水線的各個階段之間具有高耦合性,以交付獨立的功能。
許多資料平臺提供了通用的和基於配置的資料攝取服務,可以處理諸如輕鬆新增新的資料來源或修改現有的資料來源以最小化引入的擴充套件開銷。但是,這並不會消除使用者引入新資料集導致端到端依賴關係的管理。雖然在表面上,流水線架構看起來好像已經達到了一個架構的規模化水平,但實際上,整個流水線平臺必須改變以迎合新功能的最小單元: 解鎖一個新的資料集,並使其可用於新的或現有的消費者。這限制了對新消費者或新資料來源實現高速規模化的能力。
2.3 資料所有權的挑戰
資料所有權與如何組織構建並擁有資料平臺的團隊有關。所謂的資料團隊是由專業化的資料工程師和資料產品經理組成,通常是孤立於業務組織的獨立單位,儘管會缺乏業務和領域知識,但在使用大資料工具方面有技術專長。資料團隊需要消費來自其他團隊的資料,而那那些團隊可能沒有提供有意義的、真實的和正確資料的動機。資料團隊對資料來源的領域知道的有限,並可能缺乏專業的領域知識,卻需要為各種各樣的需求提供資料,無論是操作性資料還是分析性神經,而不需要清楚地瞭解資料的應用。
資料平臺團隊處於中間位置,只能全力以赴為所有來源和消費提供合適的資料。但實際上,資源的限制和不均衡,往往導致研發團隊和業務經理會另起爐灶,造成與資料團隊的緊張關係進一步加劇。這樣的組織結構缺乏擴充套件性,也沒有提供建立一個資料驅動組織所承諾的價值。
3 面對挑戰的資料平臺
鑑於此,資料平臺正規化的轉變是必要的。資料平臺或許應該是分散式領域驅動架構、自服務平臺設計和產品思維與資料的融合。去中心化的資料平臺,需要顛倒我們對資料的看法,即它的本地性和所有權。領域需要以一種易於使用的方式託管和服務它們的領域資料集,而不是將資料從各自領域流向集中的資料湖。
3.1 資料與領域驅動架構的融合
領域驅動設計深刻影響了系統架構的思維方式,進而影響了組織建模。它透過將系統分解為圍繞業務域的分散式服務,從而成為微服務架構的誘因之一。它從根本上改變了團隊的形式,使得團隊可以獨立自主地擁有領域能力。
奇怪的是,在涉及到資料時,業務領域的概念被忽略了。DDD 在資料平臺中最接近的應用是讓資料來源的系統發出它們的業務領域事件 ,並讓資料平臺消化它們。但之後,領域的概念和不同團隊對領域資料的所有權就丟失了。這需要我們的思維從傳統的ETL和事件流轉變為跨所有領域的推拉模型。在面向領域的資料平臺中,一個領域而不是流水線階段。
有些領域自然地與資料來源保持一致。領域的源資料集表示了業務的事實和現實,業務事實最好以業務領域事件的形式表示,可以作為時間戳事件的分散式日誌進行儲存和服務,以供任何授權使用者訪問。領域捕獲的資料非常接近資料起源的業務系統。領域和資料來源系統之間往往沒有一對一的對映,通常有許多系統可以提供屬於某個領域的部分資料。因此,存在許多資料來源對齊的資料集,最終需要聚合到一個內聚的領域資料集中。源域資料集是最基礎的資料集,更改的頻率較低,因為業務事實不會經常更改。這些領域資料集預計將被永久捕獲和提供,以便隨著組織發展其資料驅動和智慧服務,它們總是可以回到業務事實,並建立新的聚合或預測。
有些領域與消費密切相關,消費者領域資料集可以滿足一組緊密相關的用例。雖然資料集所有權從中心化平臺委託給各個領域域,但仍然需要清理、準備、聚合和服務資料,流水線的使用也是如此。
3.2 資料與產品思維的融合
將資料所有權和流水線分配到業務領域,人們會更關切對分散式資料集的可訪問性、可用性和協調性,這就是產品思維和學習方法派上用場的地方。把資料資產作為產品,把組織的其他資料科學家、機器學習和資料工程師作為客戶。
任何技術產品的一個重要品質是取悅消費者,為消費者提供最佳的使用者體驗,領域資料產品需要具備以下基本要素:
可發現:一個常見的實現是擁有所有可用資料產品的登錄檔、資料目錄及其元資訊,例如它們的所有者、來源、譜系、樣本資料集等。
可定址:一旦發現一個資料產品,它應該有一個唯一的地址,以API方式訪問它。根據底層儲存和格式,可能對其資料採用不同的命名約定。
可信賴:資料產品的所有者圍繞資料的真實性提供一個可接受的SLA,以及如何近似地反映已經發生的事件的真實性,或者所產生洞察力的高可能性。提供資料來源和沿襲作為與每個資料產品相關聯的後設資料,有助於使用者進一步確信資料產品及其是否適合他們的特定需求。
自描述:高質量的產品可以被獨立地發現、理解和消費,資料模式是提供自助服務資料資產的起點。
互操作:跨領域資料有效關聯的關鍵是遵循某些標準和協調規則。這樣的標準化屬於全域性治理,以支援多領域資料集之間的互操作性。這種標準化工作的常見問題是欄位型別格式化、識別跨領域的多義詞、資料集的地址約定、常見後設資料欄位、事件格式等。
安全性:對於每個領域的資料產品,訪問控制都是以更細的粒度應用的。訪問控制策略可以集中定義,但在訪問每個單獨的資料集產品時應用。SSO和RBAC是實現產品資料集訪問控制的一種簡便方法。
3.3 資料與自助服務的融合
將領域不可知的基礎設施功能收集和提取到資料基礎設施平臺中,解決了重複設定資料流水線引擎、儲存和流式計算的需要。資料基礎設施團隊可以提供必要的技術,而各個領域需要這些技術來捕獲、處理、儲存和服務它們的資料產品。將資料基礎設施構建為平臺的關鍵在於:
不包括任何特定於領域的概念或業務邏輯,保持其與領域無關;
確保平臺隱藏了所有潛在的複雜性,並以自助服務的方式提供資料基礎設施元件。
自助式資料基礎設施可以降低“建立新資料產品的準備時間”,例如,透過配置和指令碼自動化完成資料攝入,資料產品建立指令碼及生成框架,自動將資料產品註冊到目錄中,等等。雲作為底層,可以降低提供對資料基礎設施按需訪問的操作成本和工作量。
這樣的新型資料平臺, 被業界命名為“Data Mesh”。Data Mesh 平臺是一個分散式資料架構,透過共享和協調的自助服務資料基礎設施來實現互操作性,進而實現集中治理和標準化。
4. 什麼是Data Mesh?
Data Mesh是現代資料管理的一種戰略方法,也是加強組織數字化轉型的一種方法,它集中於提供有價值且安全的資料產品。Data Mesh是超越利用資料倉儲和資料湖的資料管理方法,強調組織靈活性,透過授權資料生產者和資料消費者的訪問來管理資料,資料所有權分配給特定於領域的團隊,這些團隊將資料作為產品提供、擁有和管理。
4.1 Data Mesh 與 資料湖
資料湖是一種技術方法,其主要目標是作為一個單一的儲存,以儘可能簡單的方式將資料轉移到中央團隊負責管理的地方。雖然資料湖可以提供顯著的業務價值,但它們也存在許多問題。主要的問題是,一旦資料被移動到湖中,它就失去了上下文,例如,可能有許多檔案包含客戶的定義,一個來自物流系統,一個來自支付,一個來自營銷,哪一個適合使用呢?此外,資料湖中的資料沒有經過預處理,因此不可避免地會出現資料問題。然後,資料使用者通常必須與資料湖團隊聯絡,以理解和解決資料問題,這將成為使用資料回答初始業務問題的瓶頸。
相比之下,Data Mesh不僅僅是技術,它結合了技術和組織,包括資料所有權、資料質量和資料自治。因此,資料消費者對資料質量和資料所有權有著清晰的認識,資料問題可以更有效地發現和解決,最終可以使用和信任資料。
資料湖不再是Data Mesh的中心,而是將資料湖的一些原則應用於面向資料來源的領域資料產品。然而,無論是用於資料產品的內部實現,還是作為共享資料基礎設施的一部分,人們仍然繼續使用資料湖工具。Data Mesh是把領域資料產品作為第一類關注點,把資料湖工具和管道作為第二類關注點。同樣的原則也適用於用於業務報表和視覺化的資料倉儲。它只是Data Mesh上的一個節點,可能位於面向消費者的網路邊緣。也就是說, 將大資料整體分解成一個協調、協作和分散式的資料網格生態系統。
4.2 Data Mesh 與 Data Fabric
Data Fabric 側重於各種技術能力的整合,這些技術能力相互協作為終端使用者生成一個介面。許多Data Fabric 的支持者透過像機器學習這樣的技術來實現自動化,使得終端使用者能夠以更簡單的方式訪問資料。對於簡單的資料使用來說,這是很有價值的,但是對於更復雜的情況,或者需要將業務知識整合到資料中的情況,那麼 Data Fabric 的侷限性就會變得明顯。
可以說,Data Fabric 可以用作 Data Mesh 自助服務平臺的一部分,在這個平臺中,Data Fabric 將資料公開給領域,這些領域可以將其業務知識嵌入到最終的資料產品中。
Data Mesh的目標是為從分析資料和歷史事實中獲得價值創造一個基礎,這些資料和歷史事實在規模上適應於資料場景的不斷變化、資料來源和消費者的擴大化、用例需要的轉換和處理的多樣性以及對變化的反應速度。
5 Data Mesh 的 四個核心原則
Data Mesh 的四項核心原則作為一個整體是必要且充分的,使規模具有彈性,同時解決不相容資料的孤立問題或運營成本增加的問題。
5.1 領域驅動的資料所有權和資料架構
要理解什麼是領域域驅動資料,必須知道領域是什麼。在Data Mesh 中,領域是負責資料管理的相關資料和建立的業務功能,負責聚合、轉換和向終端使用者提供資料。最終,該領域將其資料作為資料產品公開,其整個生命週期由該領域自身所有。
也就是說,Data Mesh 的核心是建立去中心化並把責任分配給最接近資料的人,以支援持續的變化和可擴充套件性。那麼,如何分解和去中心化資料生態系統的組成部分及其所有權呢?包括分析資料、後設資料和為其服務所需的計算。
為了促進這種分解,需要一個按領域排列分析資料的架構。在此架構中,領域與組織其餘部分的介面不僅包括操作能力,還包括對該領域所服務的分析資料的訪問。這意味著必須消除耦合,以使領域服務於它們的分析資料,並使計算資料的程式碼獨立於其他領域。為了擴充套件,必須支援領域團隊在其操作或分析資料系統的釋出和部署方面的自主性。當然,每個領域可以依賴於其他領域的操作和分析資料端點。
5.2 資料即為產品
發現、理解、信任並最終使用高質量資料是個重要的問題,隨著提供資料領域的團隊數量增加,這個問題只會隨著Data Mesh而惡化,這就是領域自治的結果。資料即產品原則是為了解決資料質量和資料豎井問題而設計的,例如 Gartner 所說的暗資料——資訊資產組織在日常業務活動中收集、處理和儲存,但通常不能用於其他目的。領域提供的分析資料必須被視為一種產品,資料的消費者應該被視為客戶。
領域資料產品所有者必須深入瞭解誰是資料使用者,他們如何使用資料,以及對使用資料感到舒適的方法是什麼。這種對資料使用者的深入瞭解導致了滿足需求的資料產品介面設計,所有資料產品都可以開發支援標準化介面。資料使用者和產品所有者之間的對話是建立資料產品介面的必要部分。每個領域將包括資料產品開發人員的角色,負責構建、維護和服務領域的資料產品,資料產品的開發人員將與該領域的其他開發人員一起工作。每個領域團隊可以提供一個或多個資料產品,還可以組建新的團隊來服務那些自然不適合現有領域的資料產品。本質上,資料質量的問責制向上遊轉移,儘可能接近資料來源。
資料產品是網格上的節點,它封裝了功能所需的三個結構元件,作為產品提供對領域分析資料的訪問。
程式碼: 它包括(a)負責消費、轉換和服務上游資料的資料流水線的程式碼 (b)提供資料訪問、語義和語法模式、可觀測性指標和其他後設資料的 API 程式碼; (c)執行功能特性的程式碼,如訪問控制政策、合規性、出處等。
資料和後設資料: 根據領域資料的性質及其消費模型,資料可以作為事件、批處理檔案、關係表、圖表等,同時保持相同的語義。為了使資料可用,有一組相關的後設資料,包括資料計算文件、語義和語法宣告、質量指標等; 資料固有的後設資料,例如其語義定義,後設資料用於實現預期行為的特徵,例如訪問控制策略。
基礎設施: 基礎設施元件支援構建、部署和執行資料產品的程式碼,以及儲存和訪問大資料及後設資料。
總的來說,資料產品由領域生產,由下游領域或使用者使用,以創造業務價值。資料產品不同於傳統的資料集市,因為它們是獨立的,本身負責與確保資料保持最新有關的安全、來源和基礎設施等方面的問題。資料產品支援明確的所有權和責任,可以由其他資料產品或最終消費者直接使用,以支援商業智慧和機器學習活動。
5.3 自助式的資料平臺
領域團隊能夠自主地擁有資料產品的唯一方法是訪問基礎設施的高階抽象,從而消除提供和管理資料產品生命週期的複雜性。這就需要一個新的原則,自服務資料基礎設施作為一個平臺,支援領域自治。
自助式資料基礎設施由許多功能組成,領域的成員可以輕鬆地使用這些功能來建立和管理其資料產品。自助式平臺功能按照模型中的呼叫分為多個類別或平面,每個平面服務於不同的使用者配置檔案。一個平面類似於網路中的控制層和資料層。自助式資料平臺由一個基礎設施工程小組提供支援,該小組的主要任務是對所使用的各種技術進行管理和操作。這是一種關注點分離,領域團隊關注資料,自助式資料平臺團隊關注技術。自助服務資料平臺的度量標準是領域的自主性。
也就是說,可以將資料平臺視為已經存在的用於執行和監視服務的交付平臺擴充套件。然而,當前用於運算元據產品的底層技術堆疊與資料服務的交付平臺非常不同,也是大資料技術棧與業務系統平臺的分歧。例如,業務領域域團隊可能服務部署為 Docker 容器,交付平臺使用 K8s, 然而,資料產品可能將其流水線程式碼作為一個 Hadoop叢集上的作業執行。這是兩套完全不同的基礎設施,而DataMesh 需要這種級別上的互操作性和互連性,在合理的地方趨於一致。
5.4 聯邦體系的治理
傳統的資料治理往往被看作是資料創造價值的阻礙因素。DataMesh 透過將治理關注點嵌入到領域的工作流中,資料治理有許多方面,使用度量和報告必須成為這個定義的一部分。資料的使用量以及如何使用這些資料是理解資料產品的價值從而獲得成功的關鍵點。
Data Mesh的實現需要一個治理模型,該模型包括領域自治、標準化的互操作性、動態拓撲結構,最重要的是平臺自動執行決策,可以稱之為聯邦計算的治理。一個由領域資料產品所有者和資料平臺產品所有者聯盟領導的決策模型,擁有資料所有權和領域本地決策權,同時建立並遵守一套全域性規則,即一套適用於所有資料產品及其介面的規則,以確保生態系統的健康和互操作性。這個團隊有一個艱鉅的任務: 維持集權和地方分治之間的平衡,哪些決策需要本地化到每個領域,哪些決策需要全域性化到所有領域。最終,全域性決策只有一個目的,即透過發現和組合資料產品,建立互操作性和複合網路效應。
一個支援性的組織結構、激勵模式和架構是聯邦治理模式發揮作用的必要條件: 在尊重地方領域自主性的同時,達成全域性互操作性的決策和標準,並有效地執行整體策略。在所有領域及其資料產品的平臺實施和執行的全域性標準化內容與留給領域決定的內容之間取得平衡或許是一門藝術。
6. Data Mesh的實現
Data Mesh的實現為那些希望在不確定的經濟環境中蓬勃發展的組織提供了靈活性,所有組織都需要能夠以低成本、高回報的方式來應對環境的變化。引入新的資料來源、需要遵守不斷變化的法規要求或滿足新的分析要求,這些都是促使組織資料管理活動發生變化的驅動因素。當前的資料管理方法通常基於複雜的、高度整合的 ETL,這些 ETL 位於業務系統和分析系統之間,需要努力及時變化以支援業務需求。Data Mesh為資料管理提供了一個更具彈性的方法,以有效地應對這些變化。
Data Mesh是一種涉及人、過程和技術的社會化技術方法,需要在人、過程和技術的所有三個維度上對組織進行變革,可能會將70% 的精力花在人員和流程上,30% 的精力花在技術上。人員從中心化的資料團隊分散到各個領域,現有的工作人員對於採用Data Mesh的成功至關重要,他們擁有的知識和技能會做出貢獻。因此,管理層級和獎勵機制也發生了變化。為了促進可持續和敏捷的資料架構,需要在組織內部進行流程更改。考慮資料治理,將需要圍繞資料策略定義、實現和執行的新流程,這將影響訪問和管理資料的流程,以及將該資料作為業務流程的一部分進行利用。
技術能力是實現和運營Data Mesh的關鍵,可能需要新技術的原因如下:
減少跨技術開發的摩擦,這些新技術的互操作性可能是至關重要的。
使領域能夠自給自足,並將重點放在第一類關注點上,即資料而不是技術。
允許線上購買新的資料平臺,並且可以無縫地公開這些平臺所暴露的資料
支援跨Data Mesh的治理報告,例如資料產品使用情況、遵守標準情況和資料產品反饋。
在構建Data Mesh生態系統的時候,一個關鍵的 Data Mesh 實現原則是透過利用現有的投資來連線資料來源: 資料湖或資料倉儲; 雲或內部設施等。在生成跨所有不同資料集的連線之後,下一個目標是為業務和分析團隊建立一個用於查詢資料的介面,稱之為邏輯域。需要的所有資料都駐留在各自的領域中,領域團隊有權自主工作。透過自助服務的概念,資料使用者可以獨立完成更多的工作。下一步是如何將資料集轉換為資料產品。然後,使用資料產品建立一個庫或資料產品目錄。建立資料產品是一項強大的功能,使資料消費者能夠非常快速地從發現過渡到構想以及洞察。
事實上,Data Mesh 可能並不適合於每個組織,可能主要針對那些在運營和環境中遇到不確定性和變化的大型組織。如果組織在資料方面的需求很小,而且這些資料需求不會隨著時間的推移而改變,那麼Data Mesh可能是一個不必要的開銷。
7 小結
面對資料產生場景的變化、資料來源的增長和擴散、資料用例和使用者的多樣性以及對變化的反應速度,當前的資料平臺或資料中臺面臨著較大的挑戰,而Data Mesh 或許是解決這些問題的一種嘗試。
為了面對這些挑戰,以實現規模化的承諾,同時提供使資料質量和完整性保證,任何Data Mesh的實現都體現了四個基本原則:
面向領域的分散資料所有權和體系結構
資料作為產品
自助資料基礎設施作為平臺
聯邦計算治理
一句話,Data Mesh是現代資料管理的一種戰略方法,也是加強組織數字化轉型的一種方法,它集中於提供有價值且安全的資料產品。
來自 “ 喔家ArchiSelf ”, 原文作者:半吊子全棧工匠;原文連結:https://mp.weixin.qq.com/s/01ZbSWoF1jLcmjWpi4TOJQ,如有侵權,請聯絡管理員刪除。
相關文章
- 乾貨|一文讀懂 Spring Data Jpa!Spring
- 一文讀懂mavenMaven
- 一文讀懂ServletServlet
- 一文讀懂 NPM 版本NPM
- 一文讀懂Ka/Ks
- 一文讀懂微核心
- 一文讀懂 Apache PulsarApache
- 一文讀懂eBPF/XDPeBPF
- 一文讀懂特徵工程特徵工程
- 一文讀懂“負載均衡”負載
- 一文讀懂野指標指標
- 一文讀懂web組態Web
- 一文讀懂:GBDT梯度提升梯度
- 一文讀懂「雲託管」
- 一文讀懂Lua元表
- 一文讀懂 Kubernetes APIServer 原理APIServer
- 一文讀懂Spring整合RedisSpringRedis
- 一文讀懂擁塞控制
- 一文讀懂支付系統
- 一文讀懂前端快取前端快取
- 【Flutter】一文讀懂混入類MixinFlutter
- 一文讀懂Go Http Server原理GoHTTPServer
- 一文讀懂元宇宙的特徵元宇宙特徵
- 一文讀懂git核心工作原理Git
- 一文讀懂Kafka副本機制Kafka
- 一文讀懂鏈路追蹤
- 一文讀懂Apache Flink技術Apache
- JVM(2)--一文讀懂垃圾回收JVM
- 一文讀懂系列-JVM垃圾收集JVM
- Half-Edge-Mesh-Data-StructureStruct
- 一文讀懂HyperWorks的耦合求解功能
- 一文讀懂 Kubernetes 儲存設計
- 一文讀懂Python中的對映Python
- 一文讀懂微搭低程式碼
- 一文讀懂JAVA多執行緒Java執行緒
- 一文讀懂BeanFactory和FactoryBean區別Bean
- 一文讀懂 MongoDB驅動程式 APIMongoDBAPI
- 一文讀懂 Redis 分散式部署方案Redis分散式