很多大資料系統每天都會收集數pb的資料。這類系統通常主要用於查詢給定時間範圍內的原始資料記錄，並使用了多個資料過濾器。但是，要發現或識別存在於這些大型資料集中的唯一屬性可能很困難。
在大型資料集上執行執行時聚合（例如應用程式在特定時間範圍內記錄的唯一主機名），需要非常巨大的計算能力，並且可能非常慢。對原始資料進行取樣是一種發現屬性的辦法，但是，這種方法會導致我們錯過資料集中的某些稀疏或稀有的屬性。
我們在內部實現了乙個元資料儲存，可以保證實時發現大量來自不同監控訊號源的所有唯一屬性（或元資料）。它主要依賴於後端的elasticsearch和rocksdb。elasticsearch讓聚合可以查詢在乙個時間範圍內的唯一屬性，而rocksdb讓我們能夠對乙個時間視窗內具有相同雜湊的資料進行去重，避免了冗餘寫入。
我們提供了三種監控訊號源的元資料發現：指標、日誌和事件。
指標是週期性的時間序列資料，包含了指標名稱、源時間戳、map形式的維度和長整型數值，例如http.hits 123456789034877 host=a。
在上面的示例中，http.hits是指標名稱，1234567890是epoc utc時間戳，34877是長整型數值，host=a是維度鍵值對。我們支援發現指標名稱和帶有維度map的命名空間。
日誌是來自各種應用程式或軟體/硬體基礎設施的日誌行。
我們用以下格式表示日誌：
日誌對用例（也稱為命名空間）來說總是可發現的。每個日誌行都可以是某種特定型別，例如stdout或stderr。
日誌訊號的型別（也稱為名稱）也是可發現的，如上例所示，鍵值map也是可發現的。
事件類似於日誌和指標。它們可以被視為一種稀疏指標，表示為系統內的事件。它們是非週期性的。例如，路由器交換機變為不可用時會被記錄為事件。此外，它們可能會有點冗長，可能會包含大量的文字資訊用以說明事件期間發生了什麼。
事件的乙個簡單示例：
與日誌和指標類似，事件也有命名空間和名稱，兩者都是可發現的。可發現的字段鍵讓我們能夠在已知欄位上執行聚合操作，例如min、max和count。
下面的截圖突出顯示了我們的產品控制台中的發現屬性：
所有監控訊號最初都由我們的ingress服務例項負責接收。這些服務節點使用自定義分割槽邏輯將不同的輸入監控訊號（日誌、指標和事件）推送到kafka資料匯流排主題上。元資料儲存ingress守護程式負責消費這些監控訊號，然後將它們寫入到後端elasticsearch。
我們收集的監控訊號被推送到kafka匯流排上，它們是我們的源資料流。kafka的乙個優點是它提供了持久儲存，即使下游管道處於維護或不可用狀態。我們還在入口服務上使用自定義kafka分割槽器，以確保具有相同雜湊值的鍵始終位於相同的kafka分割槽上。不同的監控訊號內部使用不同的雜湊值。例如，我們使用基於命名空間+名稱的雜湊值來表示指標訊號，而日誌訊號則使用了基於「命名空間+維度」的雜湊值。這種分組有助於降低下游kafka消費者需要處理的資料量基數，從而有效地減少記憶體占用總量。
與我們的元資料儲存入口守護程序類似，還有其他一些消費者將原始監控訊號寫入到後端儲存，如hadoop、hbase、druid等。單獨的發現管道可以在隨後將這些原始監控訊號輸出，而無需執行昂貴的執行時聚合。
我們使用rocksdb作為元資料儲存的嵌入式資料快取，避免了對後端elasticsearch資料接收器的重複寫入。我們之所以選擇rocksdb，是因為它的基準測試結果非常令人滿意，並且具有很高的配置靈活性。
元資料儲存入口守護程式在處理記錄時，會將記錄的鍵雜湊與快取記憶體中已存在的雜湊進行對比。如果該記錄尚未載入到快取中，就將它寫入elasticsearch，並將其雜湊鍵新增到快取中。如果記錄已存在於快取中，則不執行任何操作。
rocksdb快取偏重於讀取，但在剛開始時（重置快取）時出現了一連串寫入。對於當前負載，讀取超過了50億，以及數千萬的寫入，大部分寫入發生在前幾分鐘。因此，在剛開始時可能存在消費者滯後的情況。對於較低的讀寫延遲，我們努力將所有快取資料儲存在rocksdb的記憶體中，以避免二次磁碟儲存查詢。我們還禁用了預寫日誌（wal）和壓縮。在基準測試中，我們發現16gb的記憶體就足以儲存雜湊值。
上圖表示寫入後端elasticsearch的文件數。峰值對應於重置快取記憶體之後的那段時間。
出於監控的目的，我們將所有rocksdb統計資料作為指標傳送到我們的監控平台中。
我們使用elasticsearch 6.x為後端聚合提供支援，用以識別監控訊號中的不同屬性。我們構建了乙個包含30個節點的elasticsearch集群，這些節點執行在配備了ssd和64 gb ram的主機上，並通過我們的內部雲平台來管理它們。我們為elasticsearch jvm程序分配了30 gb記憶體，其餘的留給作業系統。在攝取資料期間，基於監控訊號中的不同元資料對文件進行雜湊，以便唯一地標識文件。例如，根據命名空間、名稱和不同的維度對日誌進行雜湊處理。文件模型採用了父文件與子文件的格式，並按照命名空間和月份建立elasticsearch索引。
我們根據維度對根文件或父文件的document_id進行雜湊處理，而子文件則根據命名空間、名稱和時間戳進行雜湊處理。我們為每乙個時間視窗建立乙個子文件，這個時間視窗也稱為去抖動時段。去抖動時間戳是去抖動時段的開始時間。如果在去抖動期間發現了乙個子文件，這意味著子文件的命名空間和名稱的唯一組合與其父文件拓撲會一起出現。去抖動時間越短，發現唯一屬性的時間近似就越好。elasticsearch索引中的父文件和子文件之間存在1:n的關聯關係。
elasticsearch中的父子文件動態模板是這樣的：
子文件的模板是這樣的：
我們為elasticsearch集群維護了兩個負載均衡器（lb）。read lb ip（vip）用於客戶端節點，負責所有的讀取操作，write lb vip則用於資料節點。這樣有助於我們在不同的客戶端節點上執行基於聚合的計算，而不會給資料節點造成太大壓力。
如果你要頻繁更新同乙個文件，那麼elasticsearch不是最好的選擇，因為文件的片段合併操作非常昂貴。在出現高峰流量時，後台的文件片段合併會極大地影響索引和搜尋效能。因此，我們在設計文件時將其視為不可變的。
我們使用以下的命名法為elasticsearch集群建立索引：
例如，以下是後端elasticsearch伺服器的索引：
我們按照月份來維護索引，並保留三個月的索引。如果要清除索引，就直接刪除它們。
我們的發現服務是乙個作為docker映象進行部署的web應用程式，它公開了rest api，用於查詢後端元資料儲存。
發現服務提供的關鍵rest api包括：
我們的元資料儲存入口守護程式部署和託管在內部kubernetes平台（也稱為tess.io）上。元資料儲存入口守護程式的應用程式生命週期在kubernetes上作為無狀態應用程式進行管理。我們的託管kubernetes平台允許在部署期間自定義指標註解，我們可以在prometheus格式的已知埠上發布健康指標。監控儀錶盤和警報是基於這些執行狀況指標進行設定的。我們還在發現服務上公開了類似的指標，以捕獲錯誤/成功率和平均搜尋延遲。
目前，我們發現生產環境中觸發的大多數查詢的平均延遲為100毫秒。而且我們發現，跨命名空間觸發的查詢比基於目標命名空間的查詢要慢得多。
將發現功能與實際資料管道分離讓我們能夠快速深入了解原始監控資料。元資料儲存有助於限制需要查詢的資料範圍，從而顯著提高整體搜尋吞吐量。這種方法還可以保護原始資料儲存免受發現服務的影響，從而為後端儲存節省了大量的計算資源。
eBay是如何進行大資料集元資料發現的
很多大資料系統每天都會收集數pb的資料。這類系統通常主要用於查詢給定時間範圍內的原始資料記錄，並使用了多個資料過濾器。但是，要發現或識別存在於這些大型資料集中的唯一屬性可能很困難。在大型資料集上執行執行時聚合 例如應用程式在特定時間範圍內記錄的唯一主機名 需要非常巨大的計算能力，並且可能非常慢。對原...
eBay是如何進行大資料集元資料發現的
很多大資料系統每天都會收集數pb的資料。這類系統通常主要用於查詢給定時間範圍內的原始資料記錄，並使用了多個資料過濾器。但是，要發現或識別存在於這些大型資料集中的唯一屬性可能很困難。在大型資料集上執行執行時聚合 例如應用程式在特定時間範圍內記錄的唯一主機名 需要非常巨大的計算能力，並且可能非常慢。對原...
eBay是如何進行大資料集元資料發現的
很多大資料系統每天都會收集數pb的資料。這類系統通常主要用於查詢給定時間範圍內的原始資料記錄，並使用了多個資料過濾器。但是，要發現或識別存在於這些大型資料集中的唯一屬性可能很困難。在大型資料集上執行執行時聚合 例如應用程式在特定時間範圍內記錄的唯一主機名 需要非常巨大的計算能力，並且可能非常慢。對原...