轉載自https://mp.weixin.qq.com/s/321mkZsuxqXOme5hw_83mQ

網管產品需要從資料倉庫的角度來看，才能獲得完整的檢視。資料整合真正從大資料的角度來看，才能明白其中的挑戰。一個運行了20多年的資料架構，必然有其合理性。也正是因為年代久遠，存量過多，才導致舉步維艱。在Cloud和5G時代，超密度網路整合和大資料洞察需求給電信供應商帶來新的挑戰，從資料倉庫到資料湖，不僅僅架構的變革，更是思維方式的升級。本文嘗試梳理資料架構的演進過程。

 

 

  01

資料倉庫歷史沿革

 

1970年，關係資料庫的研究原型System R 和INGRES開始出現，這兩個系統的設計目標都是面向on-line transaction processing (OLTP)的應用。關係資料庫的真正可用產品直到1980年才出現，分別是DB2 和INGRES。

 

其他的資料庫，包括Sybase, Oracle, 和Informix都遵從了相同的資料庫基本模型。關係資料庫的特點是按照行儲存關係表，使用B樹或衍生的樹結構作為索引和基於代價的優化器，提供ACID的屬性保證。

 

到1990年，一個新的趨勢開始出現：企業為了商業智慧的目的，需要把多個操作資料庫中資料收集到一個數據倉庫中。儘管投資巨大且功能有限，投資資料倉庫的企業還是獲得了不錯的投資回報率。

 

從此，資料倉庫開始支撐各大企業的商業決策過程。資料倉庫的關鍵技術包括資料建模，ETL技術，OLAP技術和報表技術等。

 

目前主要的資料倉庫產品供應商包括Oracle、IBM、Microsoft、SAS、Teradata、Sybase、Business Objects(已被SAP收購)等。

 

電信行業是最早採用資料倉庫技術的行業之一。由於電信公司執行在一個快速變化和高速競爭的環境，擁有大量的客戶基礎，從而產生和儲存海量的高質量資料。

 

電信公司利用資料探勘技術降低營銷成本，識別欺詐，並更好地管理其電信網路。

 

 02

資料倉庫概念

 

資料倉庫之父Bill Inmon在1991年出版的“Building the Data Warehouse”一書中所提出的定義被廣泛接受——資料倉庫（Data Warehouse）是一個面向主題的（Subject Oriented）、整合的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的資料集合，用於支援管理決策(Decision Making Support)。

 

這是一個偏向學術的定義，卻非常準確的界定了資料倉庫與其他資料庫系統的本質區別。

 

“A data warehouseis a subject-oriented, integrated, time-variant, and nonvolatile collection ofdata in support of management’s decision-making process.”

—W. H. Inmon

 

要理解資料倉庫的概念，需要從與資料庫的系統的對比來看。

 

資料庫是作為“所有處理的單一資料來源”出現和定義的。

 

資料庫的出現有兩個驅動因素，第一是70年代以前大量應用程式和主檔案的分散存放導致一片混亂和大量冗餘資料。第二是直接存取儲存裝置的出現使得按記錄定址成為可能。基於DBMS的線上事務處理為商業發展開闢全新的視野。

 

資料庫系統的設計目標是事務處理。資料庫系統是為記錄更新和事務處理而設計，資料的訪問的特點是基於主鍵，大量原子，隔離的小事務，併發和可恢復是關鍵屬性，最大事務吞吐量是關鍵指標，因此資料庫的設計都反映了這些需求。

 

資料倉庫的設計目標是決策支援。歷史的，摘要的，聚合的資料比原始的記錄重要的多。查詢負載主要集中在即席查詢和包含連線，聚合等操作的複雜查詢。

 

相對於資料庫系統來說，查詢吞吐量和響應時間比事務處理吞吐量重要的多。

 

資料倉庫和資料庫系統的區別，一言蔽之：OLAP和OLTP的區別。資料庫支援是OLTP，資料倉庫支援的是OLAP。

 

 

對 OLTP 和OLAP 的區別還可以有一個維度，就是及時性需求。OLTP對事務的及時性需求較高，而OLAP 則不然。

——曹洪偉

 

資料倉庫一般基於資料庫實現，但是為部署和維護上是分離的。資料倉庫可以是基於關係資料庫實現的，這樣的資料倉庫被稱為ROLAP。資料倉庫也可以是基於多維資料結構實現的，這樣的資料倉庫被稱為MOLAP。

 

 03

資料倉庫架構

 

資料倉庫是一種體系結構，而不是一種技術。資料倉庫最為核心的內容分類兩部分：

 

1. 基於關係資料庫的多維建模（RDBMS-based dimensional modeling）

    

2. 基於資料立方體的OLAP查詢（cube-based OLAP）

 

 

資料倉庫體系結構包含了從外部資料來源或者資料庫抽取資料的ETL工具。ETL還負責資料的轉換，清洗，然後載入到資料倉庫的儲存中。一般來說，資料都會載入到存取速度較慢的儲存中，以原始資料的方式儲存下來。

 

為了提高查詢效率，原始資料會按主題分類，以聚合的方式儲存到資料集市中，稱之為聚合資料。

 

參見下圖，原始資料往往有多條聚合路徑，時間維度是一個最基本的內建聚合路徑，行政級別劃分也是一種常見的聚合路徑，產品屬性也是常見的聚合路徑。

 

 

資料倉庫體系結構中還包括前端的查詢工具，報表工具和資料探勘工具，被稱為front-end。

 

最後也是最重要的是，資料倉庫體系結構中都會包含一個構建資料倉庫的元資料倉庫。

 

元資料倉庫包括資料庫schema，view，用於ETL的metadata，用於資料聚合的metadata，用於報表呈現的metadata和SQL模板等。資料倉庫往往採用meta data driven的架構設計，這個元資料倉庫就至關重要。

 

上文中提到的維度的概念。維度(dimension)是觀察事物的角度，也是資料庫事實表中用來描述資料分類的層次結構。維度在資料中就是表示為列，在SQL中用作過濾和分組。

 

像上圖這樣對資料進行多個維度的抽象並藉助於資料庫的select，group by等基本操作形成的OLAP多維資料操作（roll up，drill down，slice and dice，pivot）被稱為多維資料模型。

 

為了方便複雜分析和視覺化呈現，資料倉庫中資料往往以多維模型建模。每一個維度被稱為一個層級，三個維度構成一個數據立方體。維度也通常用來過濾和分組，所以資料立方體稱之為group by的並。

 

OLAP也被稱為在基於資料倉庫多維模型的基礎上實現的面向分析的各類操作的集合。

 

04

資料立方體

 

資料立方體只是多維模型的一個形象的說法。立方體其本身只有三維，但多維模型不僅限於三維模型，可以組合更多的維度。

 

但一方面是出於更方便地解釋和描述，同時也是給思維成像和想象的空間；另一方面是為了與傳統關係型資料庫的二維表區別開來，於是就有了資料立方體的稱呼(見下圖)。

 

 

OLAP的操作是以查詢——也就是資料庫的SELECT操作為主，但是查詢可以很複雜，比如基於關係資料庫的查詢可以多表關聯，可以使用COUNT、SUM、AVG等聚合函式。

 

OLAP的多維分析操作包括：鑽取（Drill-down）、上卷（Roll-up）、切片（Slice）、切塊（Dice）以及旋轉（Pivot），逐一解釋如下：

 

Roll up (drill-up): summarize data by climbing up hierarchy or by dimension reduction
Drill down (roll down): reverse of roll-up,from higher level summary to lower level summary or detailed data, or introducing new dimensions
Slice and dice: project and select 
Pivot (rotate): reorient the cube, visualization, 3D to series of 2D planes

 

看了上圖中資料立方體的各種操作，有人覺得還是很抽象。下面給一個SQL的例子，說明資料立方體的具體操作。

 

select//公式必須配合group by使用
    tmp.time,
    tmp.id1,
    tmp.id2,
    SUM(counter1) counter1,
    SUM(counter2) counter2
from//雙層SQL，實現聚合路徑
    (
        select//trunc實現時間維度的變化
                trunc( p.time, 'min' ) time,
                "country".country_id id1,
                "city".city_id id2,
                SUM(p.counter1) counter1,
                SUM(p.counter2) counter2
        from
             table "country"，
             table "city"，

             table p

        where//選擇計算的城市
                "city".city_id in ( '北京','上海','廣州' )
                and time >= to_date('2016/01/01 00:00:00', 'yyyy/mm/dd hh24:mi:ss')
                and time < to_date('2017/01/01 00:00:00', 'yyyy/mm/dd hh24:mi:ss')
        group by//改變行政維度
                trunc( p.period_start_time, 'mi' ),
                "country".country_id,
                "city".city_id
    ) tmp
group by//行政維度可以不變
    tmp.time,
    tmp.id1,
    tmp.id2

 

OLAP的優勢是基於資料倉庫面向主題、整合的、保留歷史及不可變更的資料儲存，以及多維模型多視角多層次的資料組織形式，如果脫離的這兩點，OLAP將不復存在，也就沒有優勢可言。

 

基於多維模型的資料組織讓資料的展示更加直觀，它就像是我們平常看待各種事物的方式，可以從多個角度多個層面去發現事物的不同特性，而OLAP正是將這種尋常的思維模型應用到了資料分析上。

 

05

資料庫建模

 

如果把多維資料模型對映到關係資料庫和SQL查詢上（ROLAP），資料庫該如何設計呢？

 

大多數資料倉庫都採用“星型模型”來表示多維資料模型。在星型模型中，只有一個事實表，並且每一個維度有一個單獨的表。

 

事實表中的每一個元組都是一個外來鍵指向維度表的主鍵。每一個維度表的列是組成這個維度的所有屬性。如下圖所示。

 

 

另外一個常見的資料庫設計方法是“雪花模型”。雪花模型通過定義單獨的維度表，改進了星型模型中沒有明確提供維度層級的問題。是謂維度表的正則化，如下圖。但星型模型更適合瀏覽維度層級。

 

 

除了事實表和維度表，資料倉庫還需要建立pre-aggregation 表用於儲存挑選的摘要資料。

 

06

大資料架構

 

1010data公司高階軟體工程師ADAM JACOBS博士在ACM通訊發表的《大資料病理學》指出大資料的病理在於分析而不在於儲存——我們期望從成年累月積累的資料中在幾分鐘或者幾秒內獲得分析結果！

 

其實作者指出了關係資料庫的在大資料時代的病理，如下圖所示一個數據倉庫分析操作的SQL在資料量超過100萬條記錄時的效能表現。

 

The pathologies of big data are primarily those of analysis.

 

 

因此，資料倉庫被認為是對資料庫查詢效能問題的一個解決方案。在90年代，人們已經都面臨一個數據爆炸的挑戰，為了解決那個時代的“大資料”問題，資料倉庫應運而生。

 

在1980s早期，大資料是指資料集超出了磁帶機的處理能力。

在1990s，大資料是指資料集超出了Microsoft Excel或者桌面PC的處理能力。

今天，大資料是指資料集超出了關係資料庫的處理能力。

 

站在大資料時代回望資料架構的發展歷史，然後從技術的角度思考大資料的定義：

 

當前流行的技術處理不了的資料，都是大資料。

 

資料倉庫的本質是把資料變小，一般有兩個方法：

第一是通過抽取，轉換，載入，清洗。

第二是通過pre-aggregation獲得資料的一份單獨拷貝。因此資料倉庫被定義為：

 

為了方便查詢分析，把資料從關係資料庫中單獨拷貝一份出來，然後通過ETL或者ELT轉換。

 

對於大資料，僅僅簡單構建一個數據倉庫是不夠的。資料應該如何結構化才能更便於分析？資料庫和分析工具應該如何設計才能更高效的處理大資料？

 

意識到大資料固有的時間屬性和空間屬性，是我們理解關係資料庫處理大資料時存在效能問題的重要前提。

 

如果說資料是我對世界的觀察記錄的話，大資料是我們對世界在時間和/或空間維度的重複觀察。這就是大資料的時空特點，也是資料倉庫多維模型的構建原理。

 

當今的主流資料庫模型是關係資料庫，並且該模型顯式地忽略表中的行的順序。這將不可避免導致應用以非順序的方式查詢資料。

 

在這種情況下，傳統的資料架構可以通過引入快取的方式緩解效能問題，而大資料則會大大放大了次優訪問模式對效能的影響。

 

如下圖所示隨機訪問和順序訪問的差別。

 

 

因此我們要引入，也是我們要推導的結論：逆正則化（逆規範化）和順序儲存，不可更改資料集（append only，immutable data set）。順著儲存棧往下走，直到資料儲存格式。

 

是時候放棄關係資料庫了。

 

簡單解釋一下逆正則化（逆規範化）。經典關係資料庫介紹的所有正規化指導思想都是正則化，減少重複資料，如果重複，則單獨建立一個表，使用外來鍵關聯，目的是節省儲存空間（那個時候儲存很昂貴）。

 

逆正則化則是允許列之間的重複。如下圖所示。

 

 

我有一個看法，NoSQL的鍵值儲存即是用極簡的非結構化來實現結構化儲存的逆規範化。

 

鍵值儲存是極簡的結構化，也是極簡的非結構化。

 

關於順序儲存，不可更改資料集，可以參考Pat Helland《Immutability Changes Everything》，和我上面的介紹是一致的。

 

關於傳統關係資料庫的討論還有資料庫知名專家，2015年圖靈獎得主Michael Stonebraker撰寫的《One Size Fits All》，分別從資料倉庫和流處理兩個方面探討了資料庫25年來一招不變的靈丹妙藥已經不再適合現在的業務發展。

 

文章的中心思想和Pat Helland提出lambda架構也有異曲同工之妙。

 

 

speed layer
(i) compensates for the high latency of updates to the serving layer 
(ii) deals with recent data only

 

serving layer
(i) indexes the batch views 
(ii) Can be queried in low-latency, ad-hoc way

 

batch layer
(i) managing the master dataset (an immutable, append-only set of raw data),
(ii) pre-compute the batch views

 

Lambda架構統一了傳統資料倉庫時代的半實時線上查詢，剛剛興起的實時流處理（Online ），和批處理資料分析（Offline），給資料架構的設計人員提供了一個全面的參考。

 

再結合半結構化，結構化資料儲存，SQL and No-SQL混合，我們可以得到下面一個典型的資料架構：

 

 

上面的討論是架構的微觀考慮，讓我們回到大資料架構的巨集觀指導上來。

 

目前業界對大資料的一個共識的定義是5個V。如下圖所示。

 

從技術的角度需要專注於其中的三個V，通過閱讀大量文獻，我得到下面一個範型：

1. 借力開源軟體處理資料多樣性挑戰

2. 使用分散式技術解決資料容量問題

3. 使用實時流處理技術解決資料速度問題

 

 

傳統的OLAP 而言，實時性需求不明顯，實時分析的強需求是導致大資料技術的一個原因。

——曹洪偉

 

基於此，我個人推薦的大資料架構是BDAS, the Berkeley Data Analytics Stack。這個架構中不僅包含上面提到的三個思考維度，還提供了整個大資料架構blueprint。內容很多，使用時各個擊破，在此不贅述。

 

 

談了那麼多，總結一下大資料架構的幾個要點：

• 分散式計算

• 實時流處理

• Online和Offline

• SQL和No-SQL：混合架構也是演進路徑之一

• 逆正則化（逆規範化）和順序儲存，不可更改資料集

 

07

資料湖架構

 

Pentaho的CTO James Dixon 在2011年提出了“Data Lake”的概念。在面對大資料挑戰時，他聲稱：不要想著資料的“倉庫”概念，想想資料 的“湖”概念。資料“倉庫”概念和資料湖概念的重大區別是：資料倉庫中資料在進入倉庫之前需要是事先歸類，以便於未來的分析。這在OLAP時代很常見，但是對於離線分析卻沒有任何意義，不如把大量的原始資料線儲存下來，而現在廉價的儲存提供了這個可能。

 

Nearly unlimited potential for operational insight and data discovery. As data volumes, data variety, and metadata richness grow, so does the benefit.

 

形象的來看，如下圖所示，資料湖架構保證了多個數據源的整合，並且不限制schema，保證了資料的精確度。資料湖可以滿足實時分析的需要，同時也可以作為資料倉庫滿足批處理資料探勘的需要。資料湖還為資料科學家從資料中發現更多的靈感提供了可能。

 

 

和資料倉庫對比來看，資料倉庫是高度結構化的架構，資料在轉換之前是無法載入到資料倉庫的，使用者可以直接獲得分析資料。而在資料湖中，資料直接載入到資料湖中，然後根據分析的需要再轉換資料。

 

 

下面我整理了資料倉庫和資料湖在多個維度的詳細對比。

 

 

總結起來，資料湖架構有一下幾個顯著的特點：

 

1. 資料儲存：大容量低成本

    

2. 資料保真度：資料湖以原始的格式儲存資料

    

3. 資料使用：資料湖中的資料可以方便的被使用

    

4. 延遲繫結：資料湖提供靈活的，面向任務的資料繫結，不需要提前定義資料模型

 

 

當然，對於資料湖架構的批評也是不絕於耳。有人批評說，彙集各種雜亂的資料，應該就是資料沼澤。Martin Fowler也對資料湖中資料的安全性和私密性提出了質疑。

 

08

電信運營大資料特點

 

電信運營大資料對應於TMN/FCAPS模型中的電信裝置管理資料。如下圖所示。

 

• Fault Management

• Configuration Management

• Accounting Management

• Performance Management

• Security Management

 

電信運營資料的特點是資料多樣化要求不高，大多數資料是結構化資料，資料容量要求不是特別高，資料的實時處理要求最高。

 

 

電信執行資料架構強調演進。步步為營，向前相容，不是一蹴而就的。

 

 

09

演進路徑實踐

 

現在的架構是一個典型的資料倉庫架構。如下圖所示。現在的架構設計有以下幾個要點：

 

• ROLAP：基於Oracle資料庫，但並沒有用Oracle的資料倉庫，單獨構建資料倉庫。

   

• Meta Data Driven的架構設計：Meta Data覆蓋整個資料pipe。當新的資料需要整合，只需要編輯新的Meta Data，系統不需要做任何改變。

   

• Schema設計：主要有兩類表：原始資料表和聚合表； 每類表都有三層結構：表，用作聚合的檢視，用作報表的檢視。不同的應用使用不同的檢視來操作資料。當原始的資料表結構變化時，可以根據需要更改不同層次的檢視。

   

• Schema的演化。這是一個比較大的主題，關係資料是schema on write的，任何列的增加都需要alter表結構，這會帶來客戶系統很長時間的downtime。因此原始表採用1000列的設計（Oracle支援的最大列數），並且列只增加，不減少，避免了資料庫schema的變化，降低不同release之間migration的成本。

   

• 資料儲存：定期清除原始資料，只保留聚合資料。

 

 

為什麼現在的架構需要演進呢？

 

首先當前架構面臨擴充套件性的挑戰。資料庫擴充套件性主要依賴於Oracle RAC解決方案，Oracle RAC不是一個線性的擴充套件方案，同時也增加了很多管理和維護成本。並且由於硬體的限制，垂直性擴充套件不是一個長期的解決方案。

 

其次，當前的儲存成本太昂貴，因此去IOE成為目標。

 

第三，實時處理需求也是驅動架構演進的重要因素。

 

然後，架構變成了這樣子：

 

 

傳統 SQL 基於雲平臺重新定義為 NewSQL，那麼 Data Warehouse 也可以重新定義 New Data Warehouse。

——曹洪偉

 

這樣的架構是不是New Data Warehouse，我不知道，可能是。在這樣的架構下，最大的變化就是更換Oracle資料為HDFS，並使用SQL on Hadoop（比如Hive SQL，Spark SQL）等保持SQL介面，維持了前端分析引擎的不變。Meta Data部分依然保持了原來的資料建模，並沒有改變資料整合方式。這樣的架構繼承了經典的倉庫架構，提高系統擴充套件性，在滿足業務需求的同時，最大化的保護已有投資。

 

在架構演進這個過程中，有一些lesson learned：

 

• SQL on Hadoop是必須的。客戶希望保持SQL介面的連續性。

   

• 混合資料倉庫架構：針對不同的業務採用不同儲存方案（Oracle 和 HDFS），資料量大的採用HDFS儲存，資料量不夠大的（不存在擴充套件性挑戰的）可以依然使用關係型資料庫。

   

• 逆規範化對效能的影響重大。通過對逆規範設計，可以達到關係資料庫的查詢效能。但是對於逆規範化是否存在其他影響，還需要研究。

   

• 相對於sequence files 和RC files，ORC檔案格式的效能是最好的。

   

• 實時pipe使用storm和Kafka實現。

 

就像 NewSQL 那樣，可以有 New Data Warehouse 的。就是 Data Warehouse與雲端計算的融合，即資料倉庫的儲存層在雲平臺，採用分散式系統。

 

對應用側而言， 原有的方式依舊有效，這樣就不會資產浪費，而是有效的繼承， 也是通往資料湖的一個較穩妥的步驟。

——曹洪偉

 

老曹這麼一說，豁然開朗。我們在談資料倉庫架構向大資料架構演進的時候，其實我們在談New Data Warehouse架構。

 

就像當初資料倉庫的出現是對資料庫系統存在的限制進行補充一樣，目前的大資料平臺是對資料倉庫系統存在的問題進行補充。

 

他們的技術思路，技術架構，使用者需求某種程度上是一致的，或者說核心的思想是一致的。不一致的地方僅僅是為了滿足效能而做的技術方案的調整。

 

首先看資料整合架構。如下圖，基於Hadoop的資料整合架構和基於關係資料庫的傳統資料整合架構是一致的。

 

不同地方在於由於資料量的增大，左邊的架構採用具有逆正則化（逆規範化）和順序儲存，不可更改資料集等特點的Hadoop平臺儲存資料。

 

 

其次看資料分析方法。雖然說基於Hadoop的資料整合架構採用了Hadoop資料儲存平臺（內建MapRdecue資料處理引擎）。

 

其資料操作，資料分析方法在思想上是一致的——從大量的資料集中獲得由價值的資訊——如下圖所示，資料倉庫的操作語句（group-by-aggregation）與MapRdecue的操作函式對應關係。

 

 

所以MapRdecue的核心思想就是在資料分片的基礎上把資料倉庫中的group-by-aggregation操作轉換成分散式執行，MapRdecue和傳統資料倉庫的思想是一致的。

 

The Map-Reduce programming model provides a good abstraction of group-by-aggregation operations over a cluster of machines.

The programmer provides a map function that performs grouping and a reduce function that performs aggregation. 

The underlying run-time system achieves parallelism by partitioning the data and processing different partitions concurrently using multiple machines.

 

所謂創新，繼承和發展，大概如此吧。怪不得Michael Stonebraker撰文《MapReduce: A major step backwards》指出MapReduce是一個巨大倒退，並引發了他和DeWitt之間的大論戰。

 

Google在2010年還為MapRdecue申請了專利，但我認為MapReduce不算是重大基礎性創新，本質上還是雲時代的資料倉庫技術（New Data Warehouse）。但其作為Google三架馬車的風頭讓人們大大忽略了傳統資料倉庫的技術思想，誤導了很多年輕學子的技術崇拜。

 

所以本文嘗試提供一個技術脈絡：Data Warehouse->New Data Warehouse->Data Lake，闡述大資料技術背後的技術架構演進，拋磚引玉，歡迎批評指正。

 

A giant step backward in the programming paradigm for large-scale data intensive applications.

 

Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago.

 

To draw an analogy to SQL, map is like the group-by clause of an aggregate query. Reduce is analogous to the aggregate function (e.g., average) that is computed over all the rows with the same group-by attribute. 

 

在New Data Warehouse架構的基礎上，如何向Data Lake演進？對電信行業來說，NFV和SDN正在推動電信網路裝置控制平面和資料平面的分離，電信裝置資料會走向資料湖架構。

 

電信裝置資料融合，運營資料融合，最終會走向一個大融合。總結起來，電信大資料對於資料湖架構的擁抱，來自於以下四個方面的驅動。我用四個推導公式，如下：

 

• 5G->BigData (Semi-Structured and Unstructured) -> Modern Data Architecture for Enterprise -> Data Lake Storage Architecture -> Data Lake

• Cloud -> Network Function Cloudification -> Network Function Virtualization -> stateless VNF -> Distributed Sharing Storage -> Data Lake

• Distributed analytics -> Data Lake

• Hierarchy architecture -> Flat operations architecture -> Data Lake

 

我們嘗試過在資料載入過程中自學習的產生資料庫schema，證明這個思路是可行的。基於結構化的資料，這個過程非常容易。但對於非結構化的資料，還是存在很大的挑戰。

 

使用機器學習的方式，模型訓練成本恐怕和人工抽取schema的工作量是相當大的。但是我也看到在一些CMDB的資料庫宣稱已經支援資料庫schema的自動升級，等我調研一下再說。

 

來源：data-lake

 

作者：石頭