GooDs: Organizing Google’s Datasets

<閱讀筆記>

參與了dantezhao的一個論文閱讀計劃 paper-notes

將閱讀成果分享到博客

Google Dataset Search (GooDs)是一個以元數據的形式管理數據集的企業內部系統
這篇論文介紹了GooDs的設計和用途

帶著問題閱讀：
1. what: GooDs系統是做什么的  
2. why: 為什么需要GooDs系統  
3. how: GooDs系統是如何設計的

0. 摘要

0.1 文章目標

• 探討實現數據管理所面臨的技術挑戰 (Challenges)

從億萬級數據源爬取和推斷元數據

維持大規模元數據目錄的一致性

使用元數據為用戶提供服務

• 對于打造大規模企業級數據管理系統的借鑒意義

1. 引言

1.1 企業數據管理的兩種形式

• Enterprise Data Management (EDM)

生成數據集和管理數據集都在一套系統內

系統本身限制了數據的生產和流轉

• Data Lake

與EDM不同的是，Data Lake采取事后(post-hoc)模式  

不介入數據的生產和使用

只為已經生成的數據提供一套有效的管理工具

所以這是一種事后(post-hoc)行為

lake的比喻很形象，數據不斷生成和累積匯聚成湖，查找數據就像從湖中釣魚("fish the right data")  

1.2 Google Dataset Search (GooDs)

• GooDs是一個靜默的服務者

GooDs的全稱是Google Dataset Search，但它的功能不限于search

GooDs采用了類似Data Lake的形式，對數據進行事后(post-hoc)管理

post-hoc將在文中多次出現，強調GooDs是靜默的輔助工具

作者還用非侵擾(non-intrusive)表明GooDs既不影響數據本身，也不影響數據的生產者和使用者

1.3 GooDs的運作機制

[站外圖片上傳中...(image-d1e2c9-1561642798984)]

圖：GooDs設計概覽

• 分層介紹

1) GooDs持續地爬取(crawls)各類存儲系統和業務線，
從中發現數據集(datasets)并收集數據集的元數據(datasets)信息和使用情況(usage)
(見圖最底層)  

2) GooDs將元數據聚合為一個中央目錄(central catalog)，同時把特定數據集的元數據與其他數據集的信息相互關聯
(見圖中間層)  

3) GooDs用這套目錄的信息構建搜索、監控和數據流可視化等工具，
從而為Google工程師提供數據管理服務
(見圖最上層)

• 關于元數據(metadata)

1) 元數據信息的一個來源是直接從數據源收集

2) 元數據的另一個來源是對數據內容的推斷(inference)：
    a. 處理附加的數據源，如日志、數據集所有者和項目信息等
    c. 分析數據集的內容
    d. 收集GooDs使用者輸入

3) GooDs收集的元數據可能包括：
   a. 數據所有者 (owners)
   b. 訪問時間 (time of access)
   c. 內容特征 (content features)
   d. 生產管線的訪問記錄  (accesses by production pipelines)

1.4 GooDs提供的一些工具

• dashboard 儀表板

展示所有數據集  

提供多條件檢索  

可以橫跨不同的存儲系統  

可以獲得數據集和所有依賴的數據集

• monitor 監控

監控內容特征：如大小、數值的分布、是否可用  

在特征發生意外改變時通知數據所有者

• provenance 數據血緣關系

生成某個數據集的上游數據
  
依賴某個數據集的下游數據  

• search engine 搜索引擎

縮小搜索范圍

• GooDs API

通過暴露接口，所有的團隊都能為元數據目錄做貢獻，形成一種crowd-sourced(眾包)的方式

數據使用者能夠共享和交換數據集的信息

2. GooDs系統的技術挑戰

2.1 天量數據規模

GooDs系統為超過260億個數據集建立了索引

260億這個數字僅包括對全體google員工開放權限的數據集

如果GooDs為更高級別權限的數據集建立索引，同時支持更多存儲系統，規?？赡茉?60億的基礎上翻倍
(double in the number of datasets)

即使每秒處理一個數據集，260億也需要一千臺并行的機器運轉300天

對元數據的推斷(inference)也因為計算量呈指數級增長而完全不可行

2.2 多樣性

數據集以各種格式存儲，來自各式存儲系統，多樣性成為數據統一管理問題之一

GooDs需要將各種格式的數據以同一種形式展示給用戶

數據集的類型和大小不同或者元數據的類型不同，抽離元數據的成本也會不同

GooDs系統在推斷元數據的時候，需要考量元數據的成本和收益

多樣性也體現在數據集的相互關系中，而數據集的相互關系反過來影響元數據在GooDs目錄的計算和存儲

2.3 目錄條目(Catalog Entries)的變動

GooDs目錄條目中，每天約有5%左右的數據集被刪除

優先計算哪些數據集的元數據，將哪些數據集加入目錄，都會受到新舊數據集交替的影響

生存周期time-to-live(TTL)長的數據集相對比較重要

短周期數據集可能關聯長周期數據集，所以GooDs系統不可能排除短周期數據集

2.4 元數據的不確定性

GooDs系統采取事后(post-hoc)非侵入(non-invasive)的方式，無法全程把握數據集的產生

GooDs根據已有數據推斷和計算出的元數據，在一定程度并不精準

2.5 計算數據集重要性

推算數據集對使用者的重要性和在網頁檢索中推算網頁的重要性不同

網頁用于排序和檢索的許多特性（如錨文本anchor text），數據集并不具備

不過數據集可以提供結構性的上下文，這是網頁所沒有的

數據集之間的唯一聯系就是來源關聯，而這種關聯并不能完全決定數據集的重要性

為哪些數據集優先計算元數據，也可以作為數據集重要性的一項參考

2.6 復原數據集語義

數據集的語義可以通俗地理解為數據集的某項內容代表了什么

文中舉的例子是，從一個數據集中推斷出一批整型數值代表了地理坐標的ID

這樣的數據集語義，在用戶檢索地理數據時就能排上用場

將無意義的原始數據升華為包含意義的內容對推斷元數據非常有用

但是發現數據集語義本身也是一項非常困難的工作

3. GooDs系統的目錄(Catalog)

Google內部每個存儲系統都可能維護著自己的catalog，每個catalog還會有自己的metadata

數據在不同的數據集和存儲系統之間自由流轉是常態

GooDs所做的就是為所有存儲系統和數據集建立統一的目錄

Catalog上的一條記錄稱之為條目(entry)，原則上每個entry對應一個數據集(dataset)的元數據

當出現一些特征相似度高的集群時，GooDs會將它們歸并為一個集群(cluster)，建立單個條目(entry)

集群的一個典型例子就是相同數據集的不同版本

3.1 元數據(Metadata)

• 概要

終于講到了GooDs系統的關鍵要素————元數據(metadata)

元數據(metadata)包含很多信息，總結起來就是用于描述數據集的信息，即"數據的數據"

• 元數據的來源

元數據的途徑有兩種：

第一種可以通過直接訪問獲?。?
GooDs系統在爬取數據集的時候，會順帶獲取一些元數據，如數據集的大小、所有者、訪問權限等

但是數據集并沒有保存所有的元數據信息，比如生成數據集的作業(jobs)，數據集的訪問者等

不能從數據集直接獲取的元數據往往存在于日志中

第二種通過GooDs系統計算得出：

GooDs除了爬取獲得元數據外，還會通過推斷(inference)獲取元數據

[站外圖片上傳中...(image-774b58-1561642798984)]

Table2: 元數據(Metadata)和元數據組(Metadata Group)

• 基礎元數據(Basic Metadata)

包括時間戳、文件格式、所有者、訪問權限等

基礎元數據一般由GooDs系統爬取存儲系統直接獲得，無需推斷

GooDs的其他模塊通常將基礎元數據作為行為依據之一

• 數據血緣/數據譜系(Provenance)

GooDs中的元數據血緣關系來自數據集的生產和消費過程、數據集上下游依賴

GooDs通過分析生產日志來確定元數據的血緣信息

GooDs用時間順序決定依賴關系，即晚發生的依賴于早發生的

在計算血緣關系時，GooDs為了效率可能會犧牲信息的完整性

• 結構信息(Schema)

Google內幾乎所有結構化數據集都是基于serialized protocol buffer編碼的

推斷數據集使用了哪種形式的protocol buffer編碼會產生多個結論

GooDs系統把所有可能的protocol buffer形式都記錄在元數據中

• Content summary

Content summary按照字面直譯為內容摘要反而不容易理解

實際上，元數據記錄的content summary可以看成一套數據的關鍵字合集

文中舉了三個summary的例子：
a) 抽樣(sampling)產生的frequent token
b) 分析字段(fields)得出的鍵(key for data)
c) 有校驗和(checksums)的fingerprints

GooDs通過summary來判斷來自不同數據集的內容或者字段是否相似和相等，

• 用戶注釋(User-provided annotations)

一般用戶做注釋都是為了明確告知數據集的使用者有必要知曉的信息

GooDs的元數據通過分析注釋來優化排序或者規避數據隱私

• 語義學信息(Semantics)

數據集的語義學信息可以幫助理解數據集

如果數據集使用了特定的protocol buffer，GooDs可以分析源碼提取有用的備注(comment)信息

本段中舉了個例子，比如數據集中一個名為"mpn"的字段，通過分析備注，發現mpn是"http://Model Product Number"的縮寫
這就是獲取備注(comment)信息在語義學方面的作用

Google的知識圖譜可以作為一個資源庫，GooDs系統將數據集內容與知識圖譜匹配，識別不同字段中包含什么樣的條目信息(如位置信息，業務信息)

• 其他

除上述類型的元數據外，GooDs系統還會將以下信息作為元數據的內容：
a) 獲取一個標識，通過該標識可以確認擁有數據集的團隊(team)
b) 數據集所屬項目的描述
c) 數據集元數據的變更歷史

此外，GooDs允許團隊在目錄添加自定義的元數據，從而為所有使用者提供統一管理元數據的平臺

3.2 數據集群(cluster)

• 數據集重復問題

GooDs目錄上的260億個數據集并非完全獨立，很多數據集存在內容重復，比如：

a) 相同數據集的不同版本  

b) 相同數據集復制到不同的數據中心  

c) 大數據集被切分為小數據集  

...   

• 數據集集群化的好處

針對上述問題，將類似數據集歸納為集群有如下好處：

a) 為用戶提供合乎邏輯的數據集分組

b) 只需計算集群中的少量數據集的元數據，節約計算成本

• 集群化的技術考量

將數據集集群化的計算成本要足夠低，才值得使用

生成集群的計算成本不能高于重復計算相似數據集的成本

• 根據路徑(path)層級(hierarchies)生成集群

數據集的路徑可以提供劃分集群的思路  

某個數據集路徑  
dataset/2015-10-10/daily_scan

按天分類  
dataset/2015-10-<day>/daily_scan

按月份和日期分類  
dataset/2015-<month>-<day>/daily_scan  

• 多粒度的半網格結構(granularity semi-lattice)

[站外圖片上傳中...(image-484ea3-1561642798984)]

Figure 2展示了兩種層次的集群劃分：按天劃分和按版本號劃分

[站外圖片上傳中...(image-45cada-1561642798984)]

Table 3展示了構建集群所依賴的數據集維度

從數據集的路徑抽離出不同維度(dimensions，如日期、版本號)
為每個數據集構建一個半網格(semi-lattice)結構  

在Figure 2所示的半網格結構中，非葉子節點代表了數據集的分組依據  

• 集群的日常更新和重復映射問題

如果分組情況每天計算和更新，可能造成用戶每天都看到不同的集群  

為了解決這個問題，GooDs只為每個半網格的頂層元素創建條目(entry)  

如Figure 2，目錄將只有頂層的條目/dataset/<date>/<version>，
對應網格底層的三個數據集  

采用這種方式可以保證每個數據集只映射到一個集群，
總的集群條目數量也會下降

• 集群的元數據

[站外圖片上傳中...(image-d42c85-1561642798984)]

Figure 4 將3個數據集的元數據匯總成集群元數據

GooDs系統通過匯總集群中各個數據集的元數據，生成該集群的元數據  

集群的元數據以實時計算的方式產生，用于區分通過分析推斷得出的元數據  

• 數據集在集群中的分布

[站外圖片上傳中...(image-4268a3-1561642798984)]

Figure 3 用柱狀圖的方式展示了數據集在集群中的分布情況

集群化可以將"物理"集群壓縮為"邏輯"集群

極大地降低了元數據的計算成本  

用戶可以通過集群更方便地查閱GooDs系統的目錄  

4 后端實現(Backend Implementation)

本節主要討論：

GooDs系統目錄(catalog)的物理結構  

向目錄中不斷增加新模塊的方法  

目錄數據的一致性  

目錄的容錯機制

4.1 目錄存儲(Catalog storage)

• Bigtable的行存儲

a) 目錄使用Bigtable作為存儲中介

Bigtable是一種可伸縮的，鍵值對存儲系統

在目錄中，Bigtable中的一行代表一個數據集或一個集群

Bigtable提供了單行事務一致性(per-row transactional consistency)  

數據集路徑或者集群路徑作為這一行的鍵  

通過這種方式，數據集對應單行，無需查找多余信息

b) GooDs系統中與單行單個數據集處理方式相左的特性

數據集提取半網格結構時，將多行信息整合到邏輯數據集中

累計同個集群中不同數據集的元數據  

不過這種元數據累加并不需要強一致性

• Bigtable的列族(column families)

一張Bigtable表格包含多個獨立的列族  

GooDs的Bigtable中還設置了一些獨立列族專門進行批量處理(高壓縮率，非內存駐留)  

只能通過批處理任務訪問的數據就存在這些列族中  

比如GooDs系統中最大的列族，就包含了用于計算血緣圖譜的原始血緣數據

這些血緣數據內容不直接面向前端，僅為部分集群提供服務，因而可以高度壓縮

• 元數據在Bigtable中的存儲

在目錄的Bigtable中，每行存儲兩種元數據信息： 

a) 數據集的元數據 

b) 狀態元數據(status metadata)：對某個數據集處理后生成的結果

• 狀態元數據(status metadata)

狀態元數據列出了用于處理條目的(entry)每一個模塊

狀態元數據可能包含時間戳，成功狀態，錯誤信息等內容

GooDs使用狀態元數據協調模塊的執行

狀態元數據也可以檢測系統，比如通過成功狀態觀察數據集，收集出現次數最多的錯誤碼

與Bigtable的臨時數據模型配合，狀態元數據還能用于調試(debugging)  

通過配置Bigtable，保留若干代的狀態元數據

這些代際數據能夠揭示模塊的歷史表現

4.2 批量任務的性能和調度(Batch job performance and scheduling)

• 任務分類和系統可擴展性

GooDs系統的任務可以分為兩大類

1) 數量龐大的各類批處理任務

2) 少數為前端和API提供服務的任務

GooDs系統具有可擴展性，為爬取新增資源提供了便利，如：
a) 新增的數據源
b) 血緣信息和其他元數據信息
c) 新的分析模塊

• GooDs系統對任務的安排

運行時間長達幾天的任務會被分配到距離數據集最近的地理位置

所有任務都獨立運行，不限制先后順序或是否并發

如果任務中斷，系統可以將其臨時下線

• 任務中的模塊(modules)

每個任務都可能包括一個或多個模塊，如爬蟲或分析器

模塊通常會依賴其他模塊，如等待其他模塊的計算結果

模塊之間通過狀態元數據協調執行順序，粒度精確到Bigtable中的一行

如果模塊A必須在模塊B之前處理某行數據，
模塊B會檢查該行的狀態元數據，是否標記為被模塊A成功處理
如果模塊A尚未處理，模塊B會跳過該行，在下次運行時再重新檢查，
如果模塊A重新處理了該行，模塊B也會重新處理，以保證元數據最新

模塊也會使用自身的狀態元數據以避免在設定時間窗口內重復處理數據

大多數任務每天運行，并在24小時候內完工

GooDs會優化超時運行的任務，或者使用并行任務分攤工作量

這些額外添加的任務，以24小時為周期處理，
專門處理新增目錄行或者重新處理超出時間窗口的數據

• 重要數據集優先處理

在大量新數據集涌入系統的時候，
系統分析器(Schema Analyzer)作為最重量級的任務，
往往需要幾天甚至幾周才能跟上進度，

為了保證最重要的數據集不被忽略，
那些用戶加注釋或者血緣集中度高的數據集標注被標注為"重要"

每個任務將分成兩個實例，
一個實例只處理重要數據集，
另一個實例處理所有數據集，并在一天的末尾處理一小部分重要數據集

實踐中，通過網絡爬取，保證最重要的那部分數據被充分覆蓋率并且持續更新，
足以應對大多數的用戶場景

• 數據盲寫

負責爬取數據的任務通常使用盲寫(blind write)的方式向目錄添加數據

Bigtable不區分插入和更新

這種無指令(no-op)方式比讀取目錄后再進行反連接(anti-join)操作更高效

某些情形應當禁用無指令存儲，否則會導致依賴的模塊重新運行或者阻塞垃圾回收

4.3 容錯機制(Fault tolerance)

因為數據集數量龐大種類繁多，GooDs系統遇到了各種問題

• 獨立數據集和相互依賴的數據集

模塊處理相互獨立的數據集時：
錯誤信息會記錄在單個數據集的狀態元數據上；
如果狀態元數據顯示某個模塊錯誤終止，將觸發一定次數的重試

模塊處理相互依賴的數據集時：
錯誤信息會記錄在任務(job)的狀態元數據上

例如：
有血緣關聯的模塊，
將一個數據集任務鏈接(dataset-job link)納入血緣圖譜前，
首先會查看這個任務鏈接的時間戳(timestamp)，
只有時間戳比模塊的最近成功執行時間(last successful execution)更晚，
模塊才會整合該任務鏈接

上述方法有些保守，如果模塊的最近一次執行有部分失敗，
系統可能會重復執行一些Bigtable的錄入；
但是這種方法能夠保證血緣圖譜的正確性，
因為Bigtable的錄入是冪等的；
同時這種方法允許系統將任務血緣信息記錄為"已消費"，
"已消費"屬性在垃圾回收中非常重要

• 模塊依賴庫依賴造成的問題

一些用于檢測數據集內容的模塊會使用各種庫(libraries)  

每個庫都有可能專門用于處理特定的文件類型  

庫有時會崩潰或者陷入死循環  

但是由庫帶來的問題并不能徹底消除，
因為系統不允許長時間運行的分析任務崩潰或掛起

一些危險的任務會被沙盒封裝到單獨的進程中，
看門狗線程會將長期停滯的任務轉為崩潰狀態，
這樣管線上的其他任務能夠繼續運轉

• 目錄(catalog)的多地冗余

系統會在不同的地理位置冗余多份目錄(catalog)

在master節點進行錄入時，會同步在其他地方復制

4.4 元數據的垃圾回收(metadata)

• 垃圾回收策略的演進

GooDs系統每天都會吸收和生產大量數據，
其中相當一部分是臨時數據

只要模塊已經消費了數據集關聯的元數據并更新了目錄，
系統就可以刪除目錄上那些對應數據集已經被刪除的條目

系統初始階段，系統使用了簡單保守的垃圾回收策略，
一條數據記錄一周不再更新才會被刪除

這種保守策略導致了若干起目錄嚴重臃腫的問題，
使我們意識到有必要采取激進的垃圾回收策略

早期曾有兩次，系統被迫中止了所有的爬蟲和垃圾回收無關的分析模塊，
直到數天后才從故障中恢復

• 垃圾回收機制的三大約束條件(constraints)

在實踐中，GooDs系統垃圾回收系統的使用總結了一些實用經驗

1) 對Bigtable中一行數據做刪除時，刪除條件最好的表達方式是說明性的斷言，
斷言中使用其他模塊對該行數據訪問和更新時記錄的元數據和狀態信息；
如：該數據集已從存儲系統中刪除，
血緣相關的另一個模塊(已成功結束)對其最近更新的血緣信息進行過處理。

2) 因為Bigtable不區分插入和更新，從目錄中刪除一條記錄時，
必須保證其他正在運行的模塊沒有將這條數據的部分信息重新插入目錄，
這種情況被稱為"dangling rows"

3) 所有其他模塊都必須獨立于垃圾回收模塊，并和垃圾回收同時運行

• 垃圾回收的非事務性(non-transactional)

Bigtable支持"conditional mutation"，
即根據指定的條件斷言刪除或更新一條數據，遵循事務原則

所有模塊的更新都要依賴未被刪除的單條記錄，
Bigtable的conditional mutation帶來了極大的日志結構讀取開銷

GooDs系統優化了設計，允許所有垃圾回收以外的模塊進行非事務(non-transactional)的更新

垃圾回收在兩階段發生：

a) 第一階段，垃圾回收使用聲明斷言的方式刪除一條數據，
此時數據并沒有真正刪除，而是被標記了一個墓碑(tombstone)

b) 第二階段，24小時之后，如果該行數據仍然符合刪除標準，
垃圾回收會真正刪除這行數據，否則將墓碑移除

與此同時，其他模塊遵從下列規則：

a) 可以進行非事務更新

b) 更新時忽略標記了墓碑的數據

c) 模塊的單次迭代不能存活超過24小時

這種設計在保證了系統高效的同時，也能夠滿足垃圾回收的三大約束條件

5 GooDs系統的前端，為目錄服務(Front end: serving the catalog)

前幾節內容主要關注了GooDs系統目錄的創建和維護，

本節主要講述與元數據相關的服務

5.1 數據集基本信息頁(Dataset profile pages)

• 展示

輸入路徑，得到數據集或集群的元數據展示在HTML頁面

在本文第三節介紹的大部分元數據信息都會被展示

用戶可以通過編輯元數據的特定部分，討論或修改目錄中的元數據信息

• 信息量

展示在頁面的元數據信息必須兼顧完整性和合理的信息含量

為了不讓用戶被信息淹沒，同時避免大量數據的傳輸，
GooDs系統使用本文3.2節介紹的機制，將血緣元數據離線壓縮

如果血緣數據的壓縮版本仍然很大，系統只能保留最新的記錄

• 與各類的工具的交叉關聯

數據集的信息頁會將元數據與其他工具交叉關聯

比如某個數據集的信息頁，會將血緣元數據，
和任務中心(job-centric tools)的任務詳情頁相關聯，
這些任務生產了當前數據集，
任務中心就是管理任務的工具

又如架構(schema)元數據會和代碼管理工具連接，
代碼管理工具中有當前架構的定義

同時，這些工具又回鏈到GooDs系統，幫助用戶獲取數據集的更多信息

• 代碼段工具(access snippets)

信息頁同時提供了多語言的代碼段工具(access snippets)來訪問數據集的內容

GooDs為特定數據集定制代碼段，
用戶可以復制粘貼代碼段到特定的開發環境

代碼段的目標是補充信息頁的元數據內容：

元數據提供了數據集內容的架構級信息，

而代碼段提供了通過代碼快速訪問和分析數據集實際內容的途徑

5.2 數據集搜索(Dataset search)

• 關鍵字查詢和索引

數據集檢索允許用戶通過簡單的關鍵字查詢找到數據集

搜索服務依賴常規的倒排索引實現文件檢索

每個數據集都被視為一個文件(document)，
系統從數據集的元數據子集中提取索引令牌(index token)，
每個令牌都會關聯索引的特定部分，
如path開頭關聯的是索引的路徑

索引令牌的提取視查詢類型而定

以路徑為例，
數據集的路徑按分隔符拆分，每個令牌對應它在路徑中的位置,
如"a/x/y/b"會映射到索引令牌"a","x","y","b"，并且順序不變

protocol buffer的名稱也用相同的方式索引，
用戶可以搜索到schema匹配特定protocol buffer命名空間的所有數據集

• 打分函數(scoring function)

關鍵字搜索到數據集是第一步驟，
第二步驟是生成一個打分函數來為匹配的數據集排序

GooDs系統會根據用戶的使用經驗不斷調整打分函數

打分函數的幾個設計經驗：

a) 數據集的重要性依賴于它的類型：

比如打分系統認為Dremel Table比file dataset重要，
因為Dremel Table需要用戶注冊，使其對更多用戶可見

b) 關鍵字匹配的重要性依賴于索引的位置

比如匹配數據集路徑的關鍵字，
比匹配讀寫數據集任務的關鍵字重要性更強

c) 血緣譜系(lineage fan-out)是數據集重要性的重要指標

數據集的讀取任務越多，下游數據集越多，則數據集越重要；
這個準則有時會給一些數據集打出不合理的高分，
這些數據集可能只是被大量的內部管線間接訪問，
但是對大多數用戶沒用，比如Google的網頁爬取信息

d) 帶有用戶描述信息的數據集重要性更高

除了上述幾點，打分函數還會參考其他信號作為打分依據

• facet

在關鍵字檢索之外，GooDs系統還會展示元數據的facets

如數據集的所有者，數據集的文件類型等

這些facet能幫助用戶構建更好的搜索關鍵詞

5.3 團隊儀表板(Team dashboards)

GooDs系統的儀表板是一個可配置的一站式數據集展示窗口，
能夠顯示某個團隊生成的所有數據集和每個數據集的元數據

GooDs系統自動更新儀表板的內容

用戶可以將儀表板頁面嵌入其他文件并將儀表板與他人共享

GooDs系統還提供了監控數據集特定屬性并警示的功能

用戶可以通過極少的操作自行設置需要監控的屬性

除了預設的監控屬性，GooDs系統還能夠通過分析趨勢，
自動監控數據集的一些公共屬性

6 經驗總結(lessons learned)

• 隨著使用不斷演進(evolve as you go)

GooDs系統期初的設計只是為數據集提供一個目錄，
隨著不斷使用，GooDs系統也演化出各種用途：

1) 監測protocol buffer 
protocol buffer可能包含隱私信息

使用GooDs系統，工程師可以找到所有符合敏感protocol buffer的數據集

一旦有違規，GooDs系統會提醒數據集所有者


2) 重新查找數據集(re-find datasets)  

工程師經常會生成一些測試數據集，但是事后忘記了數據集路徑，

通過GooDs系統的關鍵字查詢，能夠找回這些數據集


3) 讀懂老代碼(understand legacy code)  

老代碼因缺乏最新的文檔而難讀

工程師通過GooDs系統提供的血緣圖譜，
能夠找到老代碼之前的執行過程以及輸入輸出數據集，
從而幫助理解老代碼的邏輯


4) 標注數據集(bookmark datasets)  

數據集的信息頁可以作為數據集天然的信息展示窗口

用戶可以標注信息頁并將數據集與其他用戶共享


5) 注釋數據集(annotate datasets)  

GooDs目錄類似中轉樞紐，數據集注釋得以在不同的團隊之間共享

• 在排序中使用某個領域特有的信號(use domain-specific signals for ranking)

本文第二節中提到，數據集排序問題有自己的特性，
與其他領域的排序不同（如網頁排序）

根據GooDs系統的使用經驗，
不同數據集之間的血緣關系就為排序提供了領域特有的信號

比如很多團隊會為主數據集(master dataset)生成多個非規范化(denomalized)的版本

這些非規范化版本的數據集和主數據集匹配相同的關鍵字

但是顯而易見，GooDs系統會在常規查詢或者元數據提取中給主數據集更高的排序

• 預見并處理非常規數據集(expect and handle unusual datasets)

目錄中龐大的數據集數量在GooDs系統早期產生了許多意外場景

在經驗中GooDs系統形成了處理非常規數據集的策略：
首先提供最簡單的特定問題解決方案，
接著在必要時歸納出同一類問題的總體解決方案

• 按需導出數據(export data as required)

GooDs目錄的存儲中介是鍵值對存儲系統，
搜索服務依賴的是傳統倒排索引，
二者均不適合對血緣圖譜可視化或者執行復雜的路徑查詢

為了滿足上述需求，
GooDs系統會將目錄數據按主謂賓的三元組結構(subject-predicate-object triples)導出

GooDs系統會將這項元組數據導入到一個基于圖形的存儲系統，
支持路徑查詢并暴露更適合可視化的API

如果用戶需要更強大的查詢能力，現有存儲系統無法支持，
最簡單的方式就是將目錄數據導出到一個合適的專門引擎中

• 保證可恢復性(ensure recoverability)

從數以十億計的數據集提取元數據的計算成本非常高

穩定狀態下，GooDs系統在單日內處理一天量的新數據集

丟失或損毀目錄的重要部分可能需要數周恢復，
而且部分元數據在數據丟失后無法重現計算

為了保證可恢復性，GooDs系統將Bigtable設置為保留若干天內的滾動窗口快照

GooDs系統自身也有有量身定制的恢復方案：

a) 新設一個進程，在獨立的目錄，專門為重要的數據集拍攝快照

b) 另一個進程則備份目錄中提供信息頁的子集，
在主目錄掉線時數據集信息頁服務仍然可用

c) 此外，GooDs自身也啟用了數據集監控服務，
保證盡早檢測到數據損毀或丟失

上述措施都是在修復目錄的經驗中總結出的方案，
其中有一些曾導致用戶交互服務出現嚴重中斷事故

7 相關研究(related work)

這一節列舉了一些類似的數據管理系統

這些系統中的某些用途和GooDs系統差不多，
但是GooDs系統還需要從各方面解決自身面臨的需求痛點

• 數據湖(data lake)

GooDs系統可以看做一個數據湖，一種用于存儲海量數據且訪問便捷的倉庫，
數據在生成的時候無需重新分類

GooDs是用于組織和索引數據湖的系統，這個數據湖包含了Google內部所有的數據集

其他公司也有類似的系統，
Google與之不同的地方在于數據湖的規模和post-hoc的元數據推斷方式

• 元數據的生成方式不同

DataHub, Microsoft Azure Marketplace等數據集版本管理系統中，
數據集所有者可以選擇主動參與元數據的生成

GooDs系統采用了post-hoc方式生成目錄，
工程師在生成和維護數據集的時候無需考慮GooDs系統的存在

• 數據集與網頁表格的不同

有一些系統可以從html頁面中提取表格

GooDs系統處理的數據集和這些表格中的數據結構不同

這些表格數據沒有元數據，而元數據對于數據集又想當重要

• 快速和高效的搜索

Spyglass等系統提供了強大的基于元數據的搜索功能

GooDs系統處理的數據集不在一個存儲系統中，
沒有足夠多的現成元數據，
而且GooDs系統旨在提供比搜索更豐富的功能

• 對超大數據集進行索引和搜索

已經有研究在探索對超大數據集進行索引和搜索

GooDs系統需要解決本文第二節中列舉的各類問題

如果GooDs要搜索數據集的實際內容而不是元數據時，
這些研究或許相關性更大

• 血緣關系管理

PASS和Trio等系統也會維護文件的血緣關系，
但是前提是這些血緣信息都是已知的或者能夠從訪問數據的進程中獲得

GooDs系統需要依賴一些微弱的信號推斷血緣信息，
但是卻將血緣信息當做數據集排序的強信號

8 結論和展望(conclusions and future work)

• 總結

本文介紹的數據管理系統，可訪問企業內部數以十億計的數據集的元數據

• 挑戰

1) 對數據集全排列，鑒別重要數據集，數據集的排序方法是否和網頁排序方法類似

2) 完善元數據需要依賴各種資源和信息

3) 理解隱含在數據集中的語義信息能為用戶提供更有效的搜索服務，
而對語義的理解也需要借助其他資源比如Google的知識圖譜(Knowledge Graph)

4) 數據集產生的時候就在GooDs上注冊能夠保持目錄更新，
而這種方式需要修改現有的存儲系統，與GooDs非侵入式的理念沖突，
如何結合非侵入式和侵入式仍然有待解決

• 期望

希望類似GooDs的數據管理系統能夠助推數據導向型公司培養一種數據文化

企業將數據當作企業核心資產，發展出類似"代碼規約"的"數據規約(data discipline)"