Amundsen 是來自Lyft 開源的元數據管理、數據發現平臺，功能點很全，有一個比較全的前端、後端以及數據處理框架。在這篇文章中，咱們將深刻討論Amundsen的架構，解釋該工具如何使數據發現大衆化，並闡述在設計這個產品時所面臨的挑戰。最後，咱們將重點介紹早期應用者的傑出貢獻，並總結Amundsen的將來路線圖。前端
像Lyft這樣的現代數據驅動公司，平臺上的每一個交互都由數據提供驅動力。複雜的數據生成、ETL數據加工流程和分析帶來的挑戰，使元數據變得很是重要。此外，數據源類型也在不斷增長。Lyft兼容的數據源包括：Redshift，Presto，Hive，PostgreSQL中的SQL表和視圖，以及諸如Mode，Superset和Tableau等商業智能工具中的儀表板。隨着數據源的不斷增加，弄清楚存在哪些數據源，如何訪問以及這些數據源中哪些信息可用，變得愈來愈困難。node
Amundsen的出現，改變了這個困難的局面。而自從Lyft發佈這個產品數據發現解決方一年後，Lyft將Amundsen的全部代碼庫公開，以此來探索多種擴展可能和改進，並創建了一個不斷壯大的開源社區。git
1.認識Amundsen
下圖顯示了Amundsen在Lyft的架構。Amundsen採用微服務架構，由五個主要組件組成：程序員
1. 元數據服務github
元數據服務處理來自前端服務以及其餘微服務的元數據請求。默認狀況下，持久層是Neo4j，但能夠替換。數據庫
2. 搜索服務後端
搜索服務由ElasticSearch提供支持，處理來自前端服務的搜索請求。默認狀況下，由ElacticSearch提供搜索引擎，但能夠替換。跨域
3. 前端服務緩存
前端服務託管Amundsen的網絡應用程序。安全
4. 數據生成器
數據生成器是一個通用的數據提取框架，可從各類來源提取元數據。
5. Common
是一個代碼庫分支，存儲Amundsen的全部微服務的通用代碼。
1.1 組件一：元數據服務
Amundsen的元數據服務提供有關數據源的元數據。此元數據顯示在前端服務的Web應用程序中，Lyft的其餘服務也能夠使用。元數據服務當前支持三種類型的數據源：
表格資源源，包括元數據，如表名、描述、列名、相關統計信息及其餘內容。
用戶資源表明單個用戶或團隊用戶，包括如姓名、團隊信息和聯繫信息等元數據。
儀表板資源（當前開發中）。
在內部，元數據服務經過代理和RESTAPI服務請求，鏈接持久層。默認狀況下，持久層由開源圖數據庫Neo4j提供支持。該服務還能夠配置Apache Atlas（元數據引擎）。與Apache Atlas系統的集成歸功於早期開放源碼軟件的貢獻。
Amundsen將元數據實體建模爲一個圖，在引入更多實體時能夠方便地擴展模型。包含表、列和Schema的全部實體，都是經過表示它們之間關係的邊緣鏈接起來的。每一個實體還提供一個惟一的資源ID以供識別。
Lyft目前使用Neo4j社區版本3.3.5來承載元數據。每四個小時將Neo4j圖備份到Amazon S3中。
1.2 組件二：搜索服務
Amundsen的搜索服務提供API，用於將資源編入搜索引擎中，並知足來自前端服務的搜索請求。
與元數據服務相似，搜索服務經過代理與不一樣的搜索引擎進行交互。默認狀況下，搜索服務集成ElasticSearch 6.x，但也能夠集成Apache Atlas，提供與Solr相似的搜索功能。
目前，Amundsen支持多種搜索模式，以提供更靈活的搜索體驗：
常規搜索：返回與給定搜索詞和特定資源類型最相關的結果。
類別搜索：篩選第一個搜索詞與給定的元數據類別匹配的資源（如搜索database：hive），而後根據相關性返回與第二個搜索詞匹配的結果。
通配符搜索：容許用戶對不一樣資源執行通配符搜索。
1.3 組件三：前端服務
Amundsen前端服務由兩個不一樣的部分組成：
用於客戶端渲染的React應用程序。
用於服務請求的Flask服務器，充當元數據或搜索服務請求的媒介。
React應用程序用TypeScript編寫，利用Redux管理應用程序狀態，並遵循「Ducks」模塊化方法進行代碼結構化。引入Redux-Saga做爲中間件，來有效管理異步請求對應用程序狀態的反作用。
Babel用於跨不一樣ECMAScript標準轉換源代碼，Webpack用於打包源代碼，Jest用於單元測試。應用程序還使用NPM來管理依賴。
考慮到開源社區，Amundsen的前端應用程序是高度可配置的。經過功能標記和各類配置變量來適配不一樣組織的獨特需求。例如，在Lyft，提取員工數據做爲用戶資源並將其編目。意識到並不是全部組織都有集成員工數據的狀況，所以與用戶資源相關的功能在默認狀況下隱藏在應用程序的用戶界面中，但能夠使用功能標記打開。
1.4 組件四：數據生成器
數據生成器是Amundsen的ETL提取框架，它的產生是受到Apache Gobblin的高度啓發。ETL有相應的組件，即提取，轉換和加載，用於處理記錄級操做。組件Task控制全部三個組件。Job是數據生成器中最高級別的組件，控制Task和Publisher。Job在客戶端用來啓動ETL做業。
在數據生成器中，每一個組件都高度模塊化。使用基於名稱空間的配置和HOCON（人爲優化配置對象表示法），使數據生成器高可用和插件化。例如，在提取器內使用轉換，或在提取器內使用提取器。
提取器從源中提取記錄。但這並不意味着它僅支持ETL中的pull模式。例如，從消息傳遞總線中提取記錄則是ETL中的push模式。
轉換器從提取器或轉換器自己獲取記錄（經過Chained轉換器）來轉換記錄。
加載程序直接從轉換器或提取器獲取記錄，並將它們加載到暫存區。因爲加載程序在記錄級別操做，所以沒法支持原子性。
發佈服務器是可選組件。一般的用法是在job級別支持原子性，且/或提供對大批量加載到sink的支持。
下圖顯示了一個數據生成器做業如何從Hive元存儲中獲取元數據並將該元數據發佈到Neo4j的示例。每一個不一樣的元數據源均可以經過不一樣的數據生成器做業獲取。
在Lyft，使用Apache Airflow做爲數據生成器的編排引擎。每一個數據生成器job都將是DAG（有向無環圖）中的單個任務。每種類型的數據資源都將有一個單獨的DAG，由於它可能必須以不一樣的時間運行。
2. Amundsen如何將數據發現大衆化
2.1 顯示異構數據資源的相關數據
在Lyft，最初將Amazon Redshift做爲主要數據倉庫。最終，從Redshift遷移到了Hive。隨着時間的流逝，數據的數量、複雜性和廣度成幾何增加。到如今，Hive中的數據量達到了十萬個表，而Redshift中的數據量則達到了數千個。
隨着Lyft的發展，尋找相關數據源變得愈來愈重要，但隨着數據格局變得愈來愈零散、複雜和孤立，這也成爲一個更大的挑戰。如今，Amundsen使Lyft的全部員工（重新員工到對數據生態系統有豐富經驗的員工）都可以快速、獨立地找到成功完成平常任務所需的數據資源。
Lyft的數據倉庫存儲在Hive，全部物理分區存儲在S3中。Lyft的用戶很是依賴Presto做爲Hive表的實時查詢引擎，由於它們共享同一個Hive元存儲庫。經過Presto的每一個查詢都記錄到Hive表中以便進行審計。在Lyft，若是想向用戶展現最重要或最相關的表格，能夠利用Databuilder框架來構建查詢使用率提取器，經過提取器解析查詢日誌以獲取表使用率數據。而後，以Elasticsearch表文檔的方式將該表使用信息持久化。這些信息可幫助搜索服務根據數據庫訪問日誌中的使用狀況排名顯示最相關的表。
2.2 將不一樣的數據資源與人關聯
數據全部權可能會使用戶感到困惑。例如，不少資源沒有人負責。該問題與難以找到數據這一事實交織在一塊兒，Amundsen試圖以可擴展的方式解決的問題。查找數據的許多過程都包含人與人之間的互動。雖靈活，但容易出錯，而且不可擴展。除非碰巧知道可用問誰，不然很是耗時。
Amundsen經過在用戶和數據資源之間創建關係來解決此問題，而且經過暴露這些關係來共享部落知識。如下是Amundsen中用戶我的資料的示例。
目前，用戶與資源之間的關係分爲三種類型：已關注、已擁有和已使用。經過公開此信息，經驗豐富的用戶將本身成爲其團隊中其餘成員以及具備相似職務的其餘員工的有用數據資源。例如，新員工能夠訪問Amundsen並搜索其團隊中經驗豐富的用戶，或進行相似分析的其餘員工。而後，新員工將可以查看他們能夠考慮更深刻地研究哪些資源，或者與該人聯繫以獲取更多指導。爲了使這些部落知識更容易找到，還在內部員工目錄的我的資料頁面上添加了一個連接，它能夠連接到每一個用戶的Amundsen我的資料。
此外，還已經開始構建通知功能，若是缺乏現有的元數據上下文，該功能將容許用戶向數據資源全部者請求進一步的信息。例如，若是某個表缺乏描述，用戶能夠直接向Amundsen中該表的全部者發送請求，要求全部者添加該表的描述。
2.3 將豐富的元數據與數據資源關聯
捕獲數據資源ABC（應用程序上下文、行爲、更改）的元數據可提升用戶的工做效率。但願捕獲對每種類型的數據資源都有意義的全部元數據。如下展現表格詳細信息頁面示例，以下所示：
上表頁面有兩種類型的元數據：
程序方式展現
描述
數據範圍或水印
表格統計
擁有者
常用的用戶
表的源代碼
生成表格的應用程式（如Airflow DAG）
表的記錄數
手動添加展現
描述
標籤
擁有者
某些元數據（如描述、標籤和全部者）能夠經過程序方式和手動方式進行管理。要將其餘元數據吸取到Amundsen中，開發人員只需利用數據構建器的框架就可進行。他們能夠重用現有的提取程序，也能夠根據訪問源數據的元數據所需的接口構建新的提取程序和模型。
2.4 設計挑戰
跨不一樣組織擴展索引元數據
將元數據索引入Amundsen中有Pull和Push兩種方式：
Pull：經過爬網程序從源中拉取按期更新元數據。
Push：數據源（如數據庫）將元數據push消息隊列（如Kafka），下游源能夠訂閱並消費更改。
在啓動開發Amundsen時，最初考慮了Push方式，可是Lyft纔剛剛開始構建基於Kafka的可靠消息傳遞平臺。結果，構建了數據提取庫數據構建器，經過Pull將元數據索引到Amundsen中。不過，Pull是不可擴展的，由於Lyft內的不一樣組織更願意Push元數據到Amundsen。Push模型的好處是容許對元數據進行近實時索引。結果，Lyft目前正在轉入混合模型：組織將可以基於預約義的schema將元數據推送到Kafka 的topic中，而Amundsen的數據構建器仍會經過平常的Airflow DAG拉取元數據。
2.5 刪除和清除陳舊的數據
Amundsen當前不提供元數據版本控制。當Databuilder Airflow DAG完成時，將最新的元數據插入到圖中。最初，沒有刪除過期的元數據，所以當從數據存儲中刪除表時，該表的元數據在Amundsen中仍然存在。這給用戶帶來了一些困惑，所以在DAG工做流中添加了一個單獨的圖形清理Airflow任務以刪除過期的元數據。從長遠來看，計劃向數據集添加版本控制，以便用戶能夠看到數據集的演變方式，而不只僅是查看元數據的當前或最新快照。
2.6 使用圖模型進行數據建模
Amundsen選擇了圖形數據模型來表示其元數據。圖形數據模型不是大多數應用程序的經常使用選擇，可是它很是適合Amundsen，由於它處理實體之間的許多關係。圖形數據模型用於表示實體（點）和關係（邊）之間的關係。藉助此特性，當引入更多實體時，能夠輕鬆擴展模型。在圖形數據建模中，須要作出的設計決策之一是肯定是將新信息添加爲實體的屬性仍是做爲新實體。在Amundsen中，最後決定添加一個新實體做爲默認選擇，由於這爲與其餘實體創建關係提供了機會。
2.7開源社區
做爲開源軟啓動的一部分，Lyft於2019年2月將Amundsen的代碼存儲庫公開。從那時起，Lyft一直與ING和Square等公司的一些早期使用者的優秀工程師合做。用戶不只限於這些組織。對於未列出的，敬請諒解。
Amundsen兼容行業中一些流行的數據倉庫，包括但不限於：Snowflake，Hive，Redshift，Postgres，Presto等。
截止到今天，有幾家公司在生產中使用了Amundsen，有20多我的向Amundsen貢獻了源碼，包括對有價值的功能的支持，例如BigQuery和Redshift（Databuilder）的新提取器，支持Amundsen與Apache Atlas集成（元數據服務和搜索服務）和Markdown格式支持，以便用戶UI界面中進行描述編輯。在撰寫本文時，Lyft擁有60+公司和250名用戶的活躍社區，也歡迎其餘人加入。
3．將來
向前邁進，Lyft目前正在努力進行許多改進，並但願與社區一塊兒解決新功能。Lyft的路線圖目前包括：
搜索和資源頁面UI / UX從新設計
電子郵件通知系統
索引儀表板（Superset，Mode Analytics，Tableau等）
血緣關係整合
Granular ACL（訪問控制）
更多詳細信息，請查看Amundsen的開源路線圖文檔。Amundsen已在Lyft投入生產運行了一年多，在Lyft內部大約有1000名周活躍用戶。對於數據科學家、研究科學家和數據工程師等技術角色，Lyft具備極高的滲透率（90 +％），同時市場營銷和社區合做夥伴等業務用戶也使用Lyft的產品。
將來，Lyft將繼續與內部和外部不斷髮展的社區合做，以改善數據發現體驗並提升用戶的工做效率。最後但並不是最不重要的一點，請經過開源代碼Slack channel加入社區。
欲瞭解智領雲更詳細的信息，請點擊【閱讀原文】
福利
掃描添加小編微信，備註「姓名+公司職位」，加入【大數據學習交流羣】，和志同道合的朋友們共同打卡學習！
關於智領雲
武漢智領雲科技有限公司於2016年成立於武漢光谷，專一於大數據、雲計算領域的核心技術研發。公司創始團隊成員來自於推特（Twitter）、蘋果（Apple）和藝電（EA）等硅谷知名企業，擁有多年的雲計算和大數據系統的軟件開發、項目運做和公司管理的經驗。公司已經得到了數千萬元國內外著名風險投資機構及天使投資人的投資。公司研發的BDOS（大數據操做系統）採用業界領先的容器技術對大數據系統須要的各類組件進行標準化和產品化，在統一的雲平臺架構下運行，爲物聯網、機器學習、人工智能、商業智能、互聯網應用提供全面的大數據平臺及運維支持，快速高效地實施、開發和管理一個企業級的大數據系統。BDOS使用戶可集中精力在業務邏輯上而無須考慮系統底層技術細節，極大地提升了大數據及人工智能應用的開發效率，下降運維成本，持續高效地實現大數據價值。
推薦閱讀：
本文分享自微信公衆號 - 開源村OSV（osvosvosv）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。