第一部分　數(shù)據(jù)發(fā)現(xiàn)自助服務(wù)

第2章　元數(shù)據(jù)目錄服務(wù)

假設(shè)一個數(shù)據(jù)用戶準(zhǔn)備開發(fā)一個收入儀表盤。通過與數(shù)據(jù)分析師和科學(xué)家交談，用戶發(fā)現(xiàn)了一個包含客戶賬單記錄相關(guān)細(xì)節(jié)的數(shù)據(jù)集。在這個數(shù)據(jù)集中，有一個稱為“計費率”的屬性。這個屬性的意義是什么？它是事實的來源，還是從另一個數(shù)據(jù)集衍生而來的？他們還會遇到各種其他問題。比如：數(shù)據(jù)的模式是什么？誰負(fù)責(zé)管理這些數(shù)據(jù)？這些數(shù)據(jù)是如何轉(zhuǎn)換的？數(shù)據(jù)質(zhì)量的可靠性如何？數(shù)據(jù)什么時候刷新？等等。企業(yè)內(nèi)部并不缺乏數(shù)據(jù)，但是如何使用數(shù)據(jù)來解決業(yè)務(wù)問題是當(dāng)前的一大挑戰(zhàn)。這是因為以儀表盤和機(jī)器學(xué)習(xí)模型的形式構(gòu)建洞察需要對數(shù)據(jù)屬性（稱為元數(shù)據(jù)）有清晰的理解。在缺乏全面的元數(shù)據(jù)的情況下，人們可能對數(shù)據(jù)的意義及質(zhì)量做出不準(zhǔn)確的假設(shè)，從而產(chǎn)生不正確的洞察。

如何獲取可靠的元數(shù)據(jù)是數(shù)據(jù)用戶的痛點。在大數(shù)據(jù)時代之前，數(shù)據(jù)在被添加到中央倉庫之前先經(jīng)過整理——元數(shù)據(jù)的模式、沿襲、所有者、業(yè)務(wù)分類等詳細(xì)信息首先被編目。這就是所謂的即寫模式（schema-on-write），如圖2-1所示。如今，使用數(shù)據(jù)湖的方法是首先聚合數(shù)據(jù)，然后在使用時推斷數(shù)據(jù)細(xì)節(jié)。這就是所謂的即讀模式（schema-on-read），如圖2-2所示。因此，數(shù)據(jù)用戶沒有管理良好的元數(shù)據(jù)目錄可以使用。復(fù)雜性的另一個維度是給定數(shù)據(jù)集的元數(shù)據(jù)是孤立的。例如，考慮存儲在MySQL事務(wù)數(shù)據(jù)庫中的銷售數(shù)據(jù)集。為了在數(shù)據(jù)湖中獲得這些數(shù)據(jù)，需要在Spark上編寫ETL作業(yè)，并在Airflow（一個開源的任務(wù)調(diào)度框架）上進(jìn)行調(diào)度。轉(zhuǎn)換后的數(shù)據(jù)交由TensorFlow ML模型使用。每個框架都有自己端到端元數(shù)據(jù)的局部視圖。考慮到用于數(shù)據(jù)持久性、任務(wù)調(diào)度、查詢處理、服務(wù)數(shù)據(jù)庫、機(jī)器學(xué)習(xí)框架等的技術(shù)種類繁多，加之缺乏端到端元數(shù)據(jù)的單一規(guī)范化表示，因此數(shù)據(jù)用戶使用這些數(shù)據(jù)變得更加困難。

圖2-1：傳統(tǒng)的即寫模式方法，其中在將數(shù)據(jù)模式和其他元數(shù)據(jù)寫入數(shù)據(jù)倉庫之前首先生成元數(shù)據(jù)目錄

圖2-2：現(xiàn)代大數(shù)據(jù)方法，先聚合數(shù)據(jù)湖中的數(shù)據(jù)，然后在讀取數(shù)據(jù)時推斷數(shù)據(jù)模式和其他元數(shù)據(jù)屬性

理想情況下，數(shù)據(jù)用戶應(yīng)該擁有一個元數(shù)據(jù)目錄服務(wù)，該服務(wù)提供跨多個系統(tǒng)和孤島的端到端元數(shù)據(jù)層。該服務(wù)創(chuàng)建了單一數(shù)據(jù)倉庫的抽象，并且是唯一的事實來源。此外，目錄應(yīng)該允許用戶使用團(tuán)隊知識和業(yè)務(wù)上下文來豐富元數(shù)據(jù)。元數(shù)據(jù)目錄還可以作為一個集中式服務(wù)，各種計算引擎可以使用它來訪問不同的數(shù)據(jù)集。該服務(wù)的成功標(biāo)準(zhǔn)是減少數(shù)據(jù)的解釋耗時。這樣可以加快對合適數(shù)據(jù)集的識別速度，并消除由于對可用性和質(zhì)量的錯誤假設(shè)而導(dǎo)致的不必要迭代，從而減少洞察的整體時間。