2.2　最小化解釋耗時(shí)

解釋耗時(shí)代表數(shù)據(jù)科學(xué)家在建立洞察之前理解數(shù)據(jù)集細(xì)節(jié)所花費(fèi)的時(shí)間。這是提取洞察的第一步，較長的解釋耗時(shí)會(huì)影響整體的洞察時(shí)間。此外，對(duì)數(shù)據(jù)集的錯(cuò)誤假設(shè)會(huì)導(dǎo)致在洞察開發(fā)過程中出現(xiàn)多次不必要的迭代，并且會(huì)降低洞察的整體質(zhì)量。數(shù)據(jù)集的細(xì)節(jié)被劃分為三部分：技術(shù)元數(shù)據(jù)、操作元數(shù)據(jù)和團(tuán)隊(duì)元數(shù)據(jù)。如圖2-3所示。

2.2.1　提取技術(shù)元數(shù)據(jù)

技術(shù)元數(shù)據(jù)包括數(shù)據(jù)集的邏輯元數(shù)據(jù)和物理元數(shù)據(jù)。物理元數(shù)據(jù)包括與物理布局和持久性相關(guān)的細(xì)節(jié)。例如，創(chuàng)建和修改時(shí)間戳、物理位置和格式、存儲(chǔ)層級(jí)和保留細(xì)節(jié)。邏輯元數(shù)據(jù)包括數(shù)據(jù)集模式、數(shù)據(jù)源細(xì)節(jié)、生成數(shù)據(jù)集的過程，以及數(shù)據(jù)集的所有者和使用者。

技術(shù)元數(shù)據(jù)是通過抓取單個(gè)數(shù)據(jù)源來提取的，不一定要在多個(gè)數(shù)據(jù)源之間進(jìn)行關(guān)聯(lián)。收集技術(shù)元數(shù)據(jù)有三個(gè)關(guān)鍵挑戰(zhàn)：

格式不同

每個(gè)數(shù)據(jù)平臺(tái)存儲(chǔ)元數(shù)據(jù)的方式都不同。例如，Hadoop分布式文件系統(tǒng)（HDFS）元數(shù)據(jù)是按照文件和目錄的形式存儲(chǔ)的，而Kafka的元數(shù)據(jù)是按照主題的形式存儲(chǔ)的。創(chuàng)建一個(gè)適用于所有平臺(tái)的統(tǒng)一標(biāo)準(zhǔn)化元數(shù)據(jù)模型并非易事。典型的策略是應(yīng)用最小公分母，但這將導(dǎo)致抽象泄露。數(shù)據(jù)集按照不同的數(shù)據(jù)格式存儲(chǔ)在諸多存儲(chǔ)中，提取元數(shù)據(jù)需要不同的驅(qū)動(dòng)程序來連接和提取不同的系統(tǒng)。

模式推斷

不是自描述的數(shù)據(jù)集是需要推斷模式的。但是，數(shù)據(jù)集的模式難以提取，對(duì)于半結(jié)構(gòu)化數(shù)據(jù)集，難以進(jìn)行模式推斷。沒有通用的方法來實(shí)現(xiàn)對(duì)數(shù)據(jù)源的訪問和生成DDL（Data Definition Language，數(shù)據(jù)定義語言）。

跟蹤修改

元數(shù)據(jù)在不斷變化。鑒于數(shù)據(jù)集的高流失率和不斷增長的數(shù)量，保持元數(shù)據(jù)的更新是一個(gè)挑戰(zhàn)。

2.2.2　提取操作元數(shù)據(jù)

操作元數(shù)據(jù)由以下兩個(gè)關(guān)鍵部分組成。

沿襲

跟蹤數(shù)據(jù)集是如何生成的，以及它對(duì)其他數(shù)據(jù)集的依賴關(guān)系。對(duì)于一個(gè)給定的數(shù)據(jù)集，沿襲包括所有依賴的輸入表、派生表、輸出模型和儀表盤。它包括實(shí)現(xiàn)轉(zhuǎn)換邏輯以派生最終輸出的作業(yè)。例如，如果作業(yè)J讀取數(shù)據(jù)集D1并生成數(shù)據(jù)集D2，那么D1的沿襲元數(shù)據(jù)包含D2作為其下游數(shù)據(jù)集之一，反之亦然。

數(shù)據(jù)分析統(tǒng)計(jì)

跟蹤可用性和質(zhì)量指標(biāo)。它捕獲數(shù)據(jù)集的列級(jí)和數(shù)據(jù)集全局特征，還包括捕獲完成時(shí)間、處理的數(shù)據(jù)以及與管道相關(guān)的錯(cuò)誤信息的執(zhí)行統(tǒng)計(jì)。

操作元數(shù)據(jù)不是通過連接到數(shù)據(jù)源產(chǎn)生的，而是通過跨多個(gè)系統(tǒng)將元數(shù)據(jù)狀態(tài)拼接在一起產(chǎn)生的。例如，在Netflix中，數(shù)據(jù)倉庫由大量存儲(chǔ)在Amazon S3（通過Hive）、Druid、ElasticSearch、Redshift、Snowflake和MySQL中的數(shù)據(jù)集組成。查詢引擎（即Spark、Presto、Pig和Hive）用于使用、處理和生成數(shù)據(jù)集。

考慮到多種不同類型的數(shù)據(jù)庫、調(diào)度器、查詢引擎和商業(yè)智能（BI）工具，如何在不同的處理框架、數(shù)據(jù)平臺(tái)和調(diào)度系統(tǒng)中弄清整體數(shù)據(jù)流和沿襲是一個(gè)挑戰(zhàn)。鑒于處理框架的多樣性，挑戰(zhàn)在于將細(xì)節(jié)拼接在一起。從代碼中推斷沿襲并非易事，特別是對(duì)于UDF、外部參數(shù)等。

復(fù)雜性的另一個(gè)方面是獲得完整的數(shù)據(jù)沿襲。由于訪問數(shù)據(jù)事件的日志數(shù)量可能非常大，因此傳遞閉包的大小可能也非常大。通常，要在沿襲關(guān)聯(lián)的完整性和效率之間進(jìn)行權(quán)衡，通過只處理日志中數(shù)據(jù)訪問事件的抽樣，并且只在幾跳內(nèi)實(shí)現(xiàn)下游和上游關(guān)系的具體化，而不是計(jì)算真正的傳遞閉包。

2.2.3　收集團(tuán)隊(duì)知識(shí)

團(tuán)隊(duì)知識(shí)是元數(shù)據(jù)的重要組成部分。隨著數(shù)據(jù)科學(xué)團(tuán)隊(duì)的發(fā)展，將這些細(xì)節(jié)持久化地保存下來供他人利用至關(guān)重要。團(tuán)隊(duì)知識(shí)有4類：

• 用戶以注釋、文檔和屬性描述的形式定義元數(shù)據(jù)。這些信息是通過社區(qū)的參與和協(xié)作創(chuàng)建的，通過鼓勵(lì)對(duì)話和對(duì)所有權(quán)的自豪感來創(chuàng)建一個(gè)自我維護(hù)的文檔存儲(chǔ)庫。
• 業(yè)務(wù)分類規(guī)則或術(shù)語表，以業(yè)務(wù)直觀的層次結(jié)構(gòu)關(guān)聯(lián)和組織數(shù)據(jù)對(duì)象和指標(biāo)。此外，還有與數(shù)據(jù)集相關(guān)聯(lián)的業(yè)務(wù)規(guī)則，如測試賬戶、策略賬戶等。
• 數(shù)據(jù)集在合規(guī)性、個(gè)人識(shí)別信息（PII）數(shù)據(jù)屬性、數(shù)據(jù)加密要求等方面的狀態(tài)。
• 機(jī)器學(xué)習(xí)增強(qiáng)元數(shù)據(jù)的形式，包括最常用的表、查詢等，再加上檢查源碼，提取任何一條附帶的注釋。這些注釋往往質(zhì)量很高，其詞法分析可以提供捕捉模式語義的短語。

在收集團(tuán)隊(duì)知識(shí)時(shí)，有三個(gè)比較大的挑戰(zhàn)：

• 很難讓數(shù)據(jù)用戶輕松直觀地分享團(tuán)隊(duì)知識(shí)。
• 元數(shù)據(jù)的形式是松散自由的，但是又必須進(jìn)行驗(yàn)證以確保正確性。
• 信息的質(zhì)量難以核實(shí)，特別是在信息相互矛盾的情況下。