各位朋友，上午好。我是周衛林，Aloudata 的創始人和 CEO。今天我演講的主題是《NoETL 開啟自動化數據管理新時代》。在這個主題中，有兩個大家很熟悉的詞：ETL 和數據管理。但同時，也有兩個不太熟悉的詞：NoETL 和自動化數據管理。我們是否在創造一種新的概念？今天我將回答這個問題，并通過回答這個問題來解釋我們為什么要創立 Aloudata 這家公司，以及我們的定位是什么。

我在數據領域工作了 21 年，專注于大數據領域的學習、理解和問題解決。其中，我在阿里和螞蟻集團工作了 15 年，在阿里巴巴時期擔任數據倉庫架構師 5 年多，在螞蟻集團數據平臺部任負責人 9 年多。我對這個行業有比較深入的了解和實踐。

首先，我想從業務的角度來談談數據化運營和數字化轉型時公司面臨的典型應用場景和挑戰。每家公司都會通過指標進行經營管理，比如公司層面的 KPI 指標，如收入。這些指標不僅要監控當前進展，還要與同期值、與目標值比較，并且要細化到不同部門，比如線上銷售部門和線下銷售部門。

這些指標一旦細化到部門，就會進一步拆解成更具體的指標。然后，這些指標會與不同團隊綁定，例如渠道運營團隊、商家運營團隊、產品運營團隊和會員運營團隊。這樣，團隊可以通過 BI 平臺、AB 實驗平臺等找到業務問題和優化機會，并將這些機會通過不同的運營工作臺、營銷投放平臺等應用到業務系統中，從而推動業務的閉環發展。

總的來說，通過管理指標的方式，我們可以有效地管理業務。通過指標的上卷和下鉆的能力，和跨多主體的指標分析等數據協同，可以實現多團隊多組織的組織協同。

其次，我想從組織的角度來談談企業數據化轉型對組織能力結構的演化，我分三個階段進行介紹。

當企業處于信息化建設的成熟期，通常會在 IT 技術部內部分出兩層：一層是面向業務場景的業務技術團隊，例如面向商家事業部的商家技術部；另一層面向技術基礎設施的平臺技術團隊，負責數據中心的規劃、硬件設備的采購和平臺的運維監控等工作。

從信息化往數據化發展，在數據化管理的早期階段，組織結構中會增加一條專門負責 BI 的線，支持 BI 的數據技術團隊可能會外包給 DT（Data Technolog） 供應商。

隨著企業進入數智化運營的成熟期或中后期，不僅業務團隊內部會有分析師、數據科學家和業務算法專家，技術部內部也會有專門的數據團隊，甚至在業務技術團隊里部也會有數據和數據工程師，形成一個面向業務場景的技術特種部隊。這種組織體系結構是許多行業頭部公司和互聯網公司的常態。

通過上面從業務和組織兩個角度的介紹，我們可以進一步分析數智化運營對數據管理的挑戰。核心問題是隨著場景的增加，數據鏈路也在增長，導致數據管道的復雜性增加。就像上面介紹的那樣，由于越來越多的組織參與數據技術，這很容易導致數據管道的煙囪化，從而形成更為復雜的數據體系結構，進而導致數據交付效率和質量的雙下降。解決這些問題是當前數據管理面臨的主要挑戰。

首先，我們面臨的挑戰之一是數據可用性的風險。數據可用性的風險主要是數據產出時效和數據質量問題。數據時效指的是數據鏈路沒有延遲，可以按時交付，數據質量主要指的是數據的準確性和完整性。

在數據時效運維保障上有一個重要的概念是“任務基線”運維保障。當數據處理鏈路依賴加深且鏈路變長時，任務容易出現破線，當任務一旦破線且破線次數越來越多，定位和解決問題的難度也越來越大。例如，如果公司的管理層看板需要在早上八點準時更新，但由于上游任務的錯誤或延遲，數據無法及時提供，這就需要進行鏈路治理。在這種情況下，可能需要協調大量人員來解決問題，在大型金融機構，這種情況可能涉及上百人，需要拉群進行鏈路治理。這種做法的效果往往越來越差，因為靠人工在幾萬、幾十萬的任務里進行優化的代價和難度都非常大。這就形成了一個困境：如何有效保障數據的可用性。

為了解決這個問題，我們可以將任務分為兩個階段：開發態和運行態。在從開發態變更到運行態的過程中，很重要的是把基線管控列入發布管控，事前階段確保基線設置的合理性至關重要，比如如果沒有經驗的人直接設定了任務的下游基線，比如說八點鐘要完成，但實際上他們并沒有客觀地評估這個基線是否可行，一旦上線可能就會出現延遲故障，就會觸發報警，這就是一個典型的問題。

另外，在事中階段，可能沒有設置預警和告警規則，或者當需要告警時聯系不上相關責任人，所以這種情況就是典型的基線運營巡檢需要處理的問題，一旦出現問題后，需要進行復盤，找出問題的根本原因。

這種機制可以幫助解決一部分數據時效性問題，但是造成時效性問題的還有可能是數據質量問題，比如說，上游的任務出錯導致下游受影響，或者任務雖然正常運行，但產出的數據是錯誤的。這種情況下，問題發現得太晚，需要回溯上游數據，這會影響下游的任務執行，造成下游產出數據延遲。

要控制數據質量問題造成的數據可用性影響，涉及到數據質量控制（DQC）、數據任務調度配置、數據鏈路異常恢復和數據影響面評估等復雜問題，又需要一個更大更完整的數據可用性保障體系，需要制定一個數據可用性保障全景圖的規劃，這種規劃從 DataOps 的角度來看，包括研發階段，如開發、設計、測試、發布和運維等階段，從數據管理和數據架構的角度，你需要將其分成不同的等級、維度和方面，比如研發規范、數據質量要求、成本控制和安全合規等要求，通過這些功能和平臺能力來確保數據的高可用性。

數據可用性保障功能規劃全景圖這個需求一方面是由問題倒逼出來的，比如故障復盤；另一方面是當企業進入數智化運營階段，數據已經直接參與到業務中了。例如在金融行業使用數據進行風控，做授信準入；例如在營銷場景，數據可以用來影響廣告投放和推廣，當數據進入業務鏈路時，如果數據不準確，將直接影響業務效果，甚至導致業務無法開展。在這種情況下，數據技術體系與業務技術體系是融合的，從開發運維一體化的角度來看，DataOps 體系需要與 DevOps 體系對接打通，因此 DataOps 體系的發展可以從邏輯上學習 DevOps 的體系結構，借鑒引用完善形成 DataOps 體系，形成數據可用性保障功能規劃全景圖。

以上我們分析的是數據管理的第一項挑戰——風險。

數據管理的第二項挑戰是成本。隨著企業產生的數據量的增加，表的數量也在增多，這背后意味著需要更多的計算存儲資源。隨著表和任務的增加，人力成本和技術要求也在不斷提高。一個運行五年以上的數據平臺，表數量和存儲的增長曲線會越來越陡峭，數據倉庫各分層的存儲占用也會隨之增加，尤其是應用層，因為企業內部對數據的使用越來越廣泛，在組織結構上，業務技術部門和數據分析團隊的參與使得表的數量持續增加，應用層的增長速度會明顯快于中間層，形成 數據倉庫“頭大腳輕”的現象。

面對這種情況，成本管理成為一個挑戰。傳統的做法是采用運動式治理，例如數據模型重構或數據倉庫重構。但是，對于運行了五年或更長時間的數據倉庫系統，由于表的數量龐大，進行重構的難度非常大，甚至不可能實現。因為在十萬張表的數據量級下，靠 ETL 架構師的個人能力已經無法看全了。

在業務領域，我們可以使用大數據和 AI 的技術去解決復雜業務問題，比如會員運營、商品交叉銷售這樣的一些場景。那么為什么不能用大數據和 AI 的方法來解決數據平臺內部的問題呢？

所以我們的思路就是用數據治理數據，用行為來改變行為。

具體來說就是像業務場景里我們對用戶打標簽形成用戶畫像一樣，我們也可以對數據資產進行刻畫，給它打上標簽。打標簽可以有不同的角度，簡單舉幾個例子，比如看數據的健康度，可以從穿透率、覆蓋率、復用率和重復率等角度來打分，建立健康度儀表盤。

同樣，類似于業務側的會員運營體系會管理會員的生命周期，我們也可以建立數據資產的治理和運營體系，對數據資產進行生命周期管理。通過數據資產運營體系的運營動作，比如說組織“下存儲送計算”這樣的活動，給數據存儲治理優秀的團隊獎勵更多的計算資源。另外可以建立數據資產健康度的紅黑榜，通過這樣的方式進行效果量化和展示，就可以比較好地促進各個數據團隊落實和優化長效治理機制。

數據管理的第三大挑戰是效率。不同于“風險”挑戰和“成本”挑戰，如果是站在我們過往的經驗里，我覺得“效率”挑戰這個事情是無解的，為什么呢？因為效率這個問題反映在多個層面。

首先，需求響應效率逐漸降低，原因在于當前的數據需求變得更加靈活，但平臺卻越來越復雜，從數據技術的角度來看，同樣的需求，滿足需求的周期正在變長，這是大家都有的體感。

其次，數據研發協同的效率也在下降。以數據模型重構為例，數據中間層重構完成后，需要讓下游數據切換到新的中間層上，這個過程耗時很長。例如，在 8 月份，舊的中間層可能有 2000 張表，四個月后，可能只遷移了 60 張表，而新的中間層的表數量從 500 張增加到 1800 張。這是因為在進行中間層重構時，下游的末端節點可能不屬于你的團隊，這個團隊有業務需求需要優先滿足，而無法跟重構節奏同頻。這就進入了一個進退兩難的窘境：下游數據尚未切換，舊的中間層無法廢棄，中間層團隊需要同時維護二套數據鏈路。

再來看研發時間問題。隨著需求和 ETL 工作量呈指數型增長，運維和答疑的工作量也在同步增加。這意味著在工程量增加的同時，花在運維上的成本也在增加，導致研發投入相對減少，效率進一步降低。

“效率”挑戰背后的原因非常復雜。

首先，數據工程師與其他技術工程師有所不同。例如，如果是負責會員系統或交易系統的 Java 工程師，系統調用次數的增加會直接證明我的技術價值和技術能力，從而有助于我的職業晉升。然而，對于數據倉庫的架構師和 ETL 工程師來說，他們的工作被下游依賴得再多，也不容易直接體現技術深度。這是因為數據倉庫本質上是一個 Serverless 平臺，其穩定性和計算能力主要由計算存儲引擎團隊負責，尤其是在大數據和分布式計算普及后，系統的彈性擴容變得非常簡單，ETL 工程師只需確保作業正確執行和模型設計合理。更多的下游依賴不僅不能體現技術深度，還帶來了更大的運維工作量和更多的責任，這就導致數據技術體系從“我為人人，人人為我”的模式轉變為“人人為我，我為自己”。這種變化導致了每個團隊只負責自己的部分，不再承擔整體責任。

其次，從下游的角度來看，如果我負責風控或營銷業務，我需要為我的業務數據的質量和完整性負責。如果上游數據提供者不承擔相應責任，我怎么能放心使用他們的數據呢？這種情況下，業務數據團隊可能會選擇構建自己的數據鏈路，從而確保全鏈路質量，這種做法類似于農耕時代的自產自銷。

最后，數據團隊的去中心化趨勢是不可逆的。隨著業務數智化程度的加深，業務與數據相互融合，業務團隊內部自然而然地會培養數據意識，提出更多數據化業務需求，這類業務需求也是數據需求，二者往往是不可分割的，這就要求業務技術團隊也需要有數據處理能力，因此一個數據化業務需求涉及多個不同團隊的協同，而協同問題的解決往往是非常棘手的，這背后是組織架構和文化問題。當問題發展到這一階段時，你會發現這種問題似乎無解，因為作為數據技術團隊的一員，我們很難解決這些 CTO 或 CEO 層面的問題。

總結一下，我們面臨的挑戰是：在風險、效率和成本之間很難達到平衡，甚至兩者之間的平衡都難以實現。這正是 Aloudata 創立的出發點——通過技術創新，來解決這一數據管理的困局。

要解決這個問題，我們首先需要明確其產生的根因。技術是為了服務業務的，隨著互聯網和移動互聯網的興起，數據需求從穩態需求轉變為敏態需求，這導致我們的 ETL 工程量的指數級增長。

但我們 ETL 工程師的人數和能力卻是有上限的。因此我們上面提到的大型企業為了應對數據挑戰而實施的諸多策略與機制都是不斷把功能做得更多更全，把制度和規范制定的更多更全，卻無法從根本上解決數據管理的困境。

因此我們需要跳出傳統的 ETL 工程師驅動的模式，尋找全新的思路。

我們認為，數據管理的本質是追求一份統一的數據資產。如果我們能夠實現“一份數據資產”這種干凈的狀態，那么數據的管理問題、效率問題以及成本問題自然可以得到全面解決。但如何實現這一目標呢？是在物理上、邏輯上或在某個局部實現“一份數據資產”嗎？

Aloudata 給出的解決方案，就是我們首倡的 NoETL 概念。其核心目標有三個：看得清，管得住和變得動。即可以更清晰地看到數據流動，更有效地管控數據口徑，以及更靈活地應對業務需求的變化。

“看得清”，需要元數據。類比業務側通過構建商家畫像和用戶畫像從而實現智能運營，通過元數據我們可以創建一份對數據的畫像，通過血緣分析讓數據資產看得清。

“管得住”，數據管理的關鍵不在于管理數據和表本身，而是管理數據的業務含義，即數據口徑，也就是業務語義，因為真正的資產價值是數據口徑和業務語義，代表的是業務知識的沉淀。表里的數據只不過是業務語義的計算結果的固化。

“變得動”，是最具挑戰性的，因為它涉及到組織協同，是一個復雜的問題。比較可行的解決方案是數據虛擬化，我打個比喻，方便大家理解。在商業世界中，存在著線下零售和線上零售。線下零售的邏輯非常類似于傳統 ETL 的邏輯，即通過多層數據搬運，例如一級批發商、二級批發商到零售商，以滿足客戶需求。在門店，為了滿足業務場景，往往需要備足貨物，這就導致了庫存積壓。為什么呢？因為為了業務的靈活性，你必須備足夠的貨，而這些貨物不可能全部被購買，總會有庫存，從而導致經濟性下降。

那么，線上零售是如何操作的呢？線上零售的邏輯是，商家發布商品，形成商品庫，消費者通過搜索商品庫找到商品加入購物車，下單，商品隨后被配送。在這個過程中，庫存問題會得到極大的緩解，而商品送達的及時性問題，則可以通過物流端的優化來解決，例如通過設置中央倉或前置倉來提高物流效率。

我們提出的 NoETL 理念，類似于線上零售，即基于數據虛擬化的自動化 ETL 編排，旨在通過重構 ETL 和數據管理方式來實現這一目標。這種方式類似于企業從物理搬運轉向虛擬化邏輯構建的過程。

正如電商世界中的三種模式：從線下到線上、只做線上（完全虛擬化），以及從線上到線下。我們的理解是，虛擬化與傳統數倉的方式需要結合起來，根據企業的特點來實施，這看起來是一種比較穩妥且可持續迭代的方法。我們已經有許多客戶采用這樣的方法來應用和實施數據虛擬化技術。

Aloudata的 NoETL 理念與 Data Fabric 不謀而合。Data Fabric 的核心在于引入了一個切片，這個切片位于業務場景與數據之間，通過語義化的交付方式，旨在快速滿足業務需求并隔離背后的復雜性。在當前的數據管理和分析領域，虛擬化技術的應用日益重要。這種技術允許我們在沒有物理移動數據的情況下進行信息流的管理，類似于電商平臺在處理商品信息流時的方式。這種方法不僅提高了效率，還簡化了數據處理流程。

在 NoETL 的整體思路下，我們推出了三款產品。旨在幫助數據團隊不再進行復雜重復和不經濟的層層數據處理，而是首先明確業務的數據口徑，然后再構建相應的數據集和指標，以及實現更加智能的數據管理。

Aloudata AIR 是一款邏輯數據平臺。AIR 的典型場景是企業的業務開展可能存在多個云平臺或多個區域的數據中心，特別是在涉及跨境和合規問題時，我們的解決方案能夠支持多云環境下的數據集成與查詢。這種多云聯合分析的場景，可以有效應對合規監管等需求，允許企業靈活地進行數據分析和決策支持。

AIR 的另一個典型的應用場景是大型集團公司，這些公司下屬有多個不同的業務實體。在這種結構中，各個子公司可能各自擁有獨立的數據倉庫。總公司層面如何有效訪問和管理這些分散的數據成為一個挑戰。通過數據虛擬化，總公司可以無需物理遷移所有數據，而是通過虛擬化技術直接訪問和分析各子公司的數據，極大地簡化了數據管理和分析過程。

在先進制造領域，一家擁有眾多工廠的企業，每家工廠的需求各不相同，簡單地用一套方法管理所有工廠顯然不是最佳選擇，因此每家工廠可能都有自己的信息化系統和數據分析平臺，企業可以通過虛擬化技術訪問和分析各個工廠的數據。

這些場景展示了數據虛擬化在現代企業中的強大應用潛力，特別是在處理復雜的數據結構和多源異構環境中，提供了一種高效、靈活的解決方案。

第二款產品 Aloudata CAN 是一款 NoETL 的自動化指標平臺。指標的應用覆蓋了從管理層看板到部門看板，再到運營活動和業務閉環運營的全過程。這種基于指標的管理方式，能夠有效支持企業的決策和運營。我們從 NoETL 的角度出發，關注的是如何通過自動化技術來優化指標的生產、消費和統一管理。這種方法的核心在于通過定義清晰的語義，對數倉中間層和應用層進行建模，然后通過自動化構建和物化加速實現指標的定義、開發、管理、消費的一體化。

Aloudata BIG 是基于算子血緣解析能力的主動元數據平臺。正如我前面介紹的，在處理大規模數據時，如何有效管理和利用這些數據成為了一個挑戰。這就需要一個強大的 DataOps 體系來支持，該體系包含了數百個功能項，但真實場景下，并非所有數據需求都需要完整走過這些功能流程。因此，基于具體的業務場景進行數據需求的分類和分級，選擇合適的流程至關重要。

這種流程的設計和實施，最終都依賴于元數據的支持。沒有元數據的驅動，平臺只是一個簡單的工具箱，無法有效地支持研發過程和數據管理。數據管理的理念、思想和控制能力必須體現在研發流程中，我們需要利用元數據來引導研發流程并實現研發流程的智能化，如果缺乏這樣的能力，再多的工具也只是堆砌，無法形成真正的數據管理解決方案。例如在實施 DataOps 體系時，一個關鍵的環節是模型的 Review，包括判斷模型是否符合要求以及是否存在重復或需要優化，這需要一套基于元數據的算法來實現。

上述三款產品均在頭部金融企業的生產場景中獲得了驗證。

最后我想分享一下 NoETL 的本質， 傳統數據管理體系是通過 ETL 工程師來驅動的。隨著數據需求的大幅增長，數據鏈路的日益復雜，ETL 工程師在數量和能力上都存在上限。在這種情況下，我們只能通過 NoETL 來重塑數據管理，NoETL 的本質是自動化，而 ETL Agent 是這種自動化的終極實現，成為推動整個新一代自動化數據管理的關鍵。

希望我的分享能對大家有所幫助，謝謝大家。