傳統(tǒng)企業(yè)很多在轉(zhuǎn)型做大數(shù)據(jù)，在技術(shù)層面上從互聯(lián)網(wǎng)公司學(xué)到不少，改革也可謂大刀闊斧，就幾年時(shí)間，很多傳統(tǒng)企業(yè)的數(shù)據(jù)倉(cāng)庫(kù)全部從小型機(jī)轉(zhuǎn)到了X86，現(xiàn)在做數(shù)據(jù)處理和分析如果不提hadoop甚至有點(diǎn)落伍了。

應(yīng)該來(lái)說(shuō)，現(xiàn)在搞一套大數(shù)據(jù)平臺(tái)其實(shí)已經(jīng)不是難事，但如果企業(yè)希望能基于新的大數(shù)據(jù)平臺(tái)快速的進(jìn)行創(chuàng)新，事情就并不像想象的那么簡(jiǎn)單，你會(huì)發(fā)現(xiàn)，換了平臺(tái)以后，雖然數(shù)據(jù)增加了，創(chuàng)新的可能性增加了，但很多數(shù)據(jù)工作效率卻比以前降低了，從采集、開(kāi)發(fā)、分析、挖掘、運(yùn)維不一而足，我們?cè)诳吹靡?jiàn)的成本上的確降低了，但看不見(jiàn)的成本卻在大幅提升。

從平臺(tái)的角度講，由于技術(shù)組件的多樣化，開(kāi)源化，技術(shù)的復(fù)雜性大幅提升，企業(yè)能得到的標(biāo)準(zhǔn)化服務(wù)能力肯定是下降了，為了保障服務(wù)的連續(xù)性，企業(yè)必然要花更多的其它成本去做補(bǔ)償，比如不少技術(shù)組件甚至業(yè)界也沒(méi)多少人用過(guò)，企業(yè)只能硬著頭皮自己去抗，難度可想而知。

從工具的角度看，當(dāng)前各種技術(shù)組件的配套設(shè)施并不完備，我們不再擁有像PL/DEV這種完美的ORACLE第三方客戶(hù)端軟件，得自己重新開(kāi)發(fā)一套客戶(hù)端工具來(lái)跑腳本，比如針對(duì)HIVE的運(yùn)行工具，但這些客戶(hù)端工具的開(kāi)發(fā)也是摸著石頭過(guò)河，體驗(yàn)顯然也是沒(méi)法跟以前相比的。

互聯(lián)網(wǎng)公司對(duì)于新產(chǎn)品的競(jìng)爭(zhēng)力有個(gè)公式：競(jìng)爭(zhēng)力=（新產(chǎn)品體驗(yàn)-老產(chǎn)品體驗(yàn)）-替換成本，因此，要推廣一個(gè)體驗(yàn)還不如老工具的東西對(duì)于大數(shù)據(jù)平臺(tái)運(yùn)營(yíng)人員來(lái)講也是非常艱難，當(dāng)然不僅是開(kāi)發(fā)工具，還包括監(jiān)控工具、優(yōu)化工具等等。

從管理的角度看，更是要建立一套適應(yīng)新的大數(shù)據(jù)平臺(tái)運(yùn)營(yíng)的組織、機(jī)制和流程，比如建立小快靈的團(tuán)隊(duì)來(lái)適應(yīng)大數(shù)據(jù)的創(chuàng)新，新的平臺(tái)工具需要新的培訓(xùn)，比如hive腳本跑不動(dòng)得自己有能力去解析yarn的日志，看看是否有數(shù)據(jù)傾斜的問(wèn)題……。

無(wú)論如何，我們都將與BI時(shí)代的穩(wěn)定再見(jiàn)，面對(duì)的將是一個(gè)全新的環(huán)境，這是當(dāng)前任何一支大數(shù)據(jù)團(tuán)隊(duì)都會(huì)面臨的問(wèn)題，在如此不確定的環(huán)境中，一支大數(shù)據(jù)團(tuán)隊(duì)如何才能變得更高效是擺在每個(gè)大數(shù)據(jù)管理者面前的課題。

這個(gè)時(shí)候，我們首先要擁有對(duì)新事物勇敢提出問(wèn)題的能力，而能否創(chuàng)造開(kāi)放透明的環(huán)境是最重要的一個(gè)，這也是筆者最近的感悟，因此特別來(lái)說(shuō)一說(shuō)。

這里先舉三個(gè)案例。

團(tuán)隊(duì)組織了一次工作研討會(huì)，特意邀請(qǐng)了剛?cè)肼毜男聠T工談?wù)劰ぷ髦械膯?wèn)題和建議，哪知道原來(lái)引以為豪的數(shù)據(jù)開(kāi)發(fā)管理平臺(tái)被一頓臭罵，從資源占用模式，開(kāi)發(fā)界面，調(diào)試方式……但為什么老員工就能泰然自若，不愿意升級(jí)問(wèn)題呢？也許是習(xí)慣了吧。

不少新人在日?qǐng)?bào)中抱怨，一個(gè)腳本HIVE跑了很多個(gè)小時(shí)沒(méi)跑出來(lái)，因此只能凌晨起來(lái)乘著人少跑，運(yùn)維說(shuō)一些不規(guī)范的腳本也幫助查殺了，性能也就這樣了。

接到客戶(hù)投訴，說(shuō)一個(gè)標(biāo)簽質(zhì)量有問(wèn)題，核查發(fā)現(xiàn)原來(lái)標(biāo)簽開(kāi)發(fā)人員為了萬(wàn)無(wú)一失，將正確的標(biāo)簽命名為sex_new，老的標(biāo)簽sex還留著，說(shuō)是擔(dān)心梳理不出對(duì)老應(yīng)用的影響，就想了這個(gè)兩全其美的方法。

這些看似不經(jīng)意的問(wèn)題，其實(shí)對(duì)于大數(shù)據(jù)的效率影響很大，一旦習(xí)慣了就會(huì)積重難返，大家都懂的，但關(guān)鍵是這些其實(shí)并不是團(tuán)隊(duì)不能解決的問(wèn)題，但為什么會(huì)習(xí)慣于遷就呢？

筆者分析下來(lái)，大致有以下的原因;

1、認(rèn)知格局問(wèn)題：?jiǎn)T工之間，員工與管理者之間信息非常不對(duì)稱(chēng)，擁有的視野和資源不同，對(duì)于事物的輕重緩急認(rèn)知不同，比如管理者認(rèn)為租戶(hù)性能是全局問(wèn)題，不及時(shí)解決后果很?chē)?yán)重，而員工認(rèn)為自己忍忍就算了，員工經(jīng)常聽(tīng)到領(lǐng)導(dǎo)的教誨說(shuō)要站得高一點(diǎn)就是這個(gè)理，對(duì)沖基金公司橋水將所有公司的資料開(kāi)放給員工是提升員工格局的一種手段。有時(shí)候，不知道這個(gè)問(wèn)題是大問(wèn)題是最大的問(wèn)題。

2、趨利避害問(wèn)題：?jiǎn)T工的工作邊界有限，對(duì)于可提可不提的問(wèn)題，從降低風(fēng)險(xiǎn)的角度講一般會(huì)選擇回避，畢竟提出問(wèn)題是需要付出代價(jià)的，你得分析清楚原因吧，得找到利益相關(guān)方討論清楚吧，一般還得求助上級(jí)協(xié)調(diào)解決，每一樣工作都讓你脫離原有的工作舒適區(qū)，這個(gè)違背人性，多一事不如少一事。

從更自私的角度來(lái)講，比如碰到的是工具不好用的全局問(wèn)題，我慢你也慢，那就不會(huì)由于這個(gè)問(wèn)題導(dǎo)致自己的成果比別人差，那就無(wú)所謂了，其實(shí)很多KPI做到了極端就這樣了，問(wèn)題能否解決、餅?zāi)懿荒茏龃鬅o(wú)關(guān)緊要，只要你不比我過(guò)得好。

3、溝通環(huán)境問(wèn)題：要打造開(kāi)放透明的溝通環(huán)境非常不易，互聯(lián)網(wǎng)公司相對(duì)比較扁平化，也還在不停的琢磨如何提升企業(yè)的透明程度，比如Google，大多企業(yè)層級(jí)式的匯報(bào)體系的確抑制了問(wèn)題的暴露，從大了講涉及到企業(yè)的文化，從小了講涉及團(tuán)建能力，很多問(wèn)題其實(shí)早就有人提了，要么沒(méi)人理，要么草草應(yīng)付。

4、小白兔問(wèn)題：如果說(shuō)趨利避害還帶有一點(diǎn)選擇性作為的話(huà)，小白兔就是不作為了，不作為不是不做事，如果你的工作都是領(lǐng)導(dǎo)安排的，比如說(shuō)一下動(dòng)一下，就要考慮自己是不是已經(jīng)成為小白兔了。

有人說(shuō)我的工作性質(zhì)就是穩(wěn)定啊，只需要執(zhí)行就成，沒(méi)有需要主動(dòng)推進(jìn)的事情，姑且不說(shuō)這種被動(dòng)心態(tài)，其實(shí)任何事情有深有淺之分，沒(méi)有簡(jiǎn)單的事，只有簡(jiǎn)單的人，比如按部就班的處理工單算做事，想著如何提高工單效率也是做事，把處理工單的方法編撰成手冊(cè)是做事，最后實(shí)現(xiàn)了一套自動(dòng)化工單處理系統(tǒng)更是做事，其實(shí)沒(méi)有人為你過(guò)設(shè)定邊界，前者相對(duì)后者就是小白兔，而小白兔對(duì)于大數(shù)據(jù)這種創(chuàng)新團(tuán)隊(duì)影響更大。

大家會(huì)笑國(guó)王的新裝，但自己不小心就會(huì)成為主角，管理者則被過(guò)頂傳球了，這對(duì)于團(tuán)隊(duì)的傷害很大，大數(shù)據(jù)這類(lèi)新事物特別需要問(wèn)題的暴露和反饋，從而推進(jìn)各類(lèi)問(wèn)題的快速解決，刻意練習(xí)提到重復(fù)單調(diào)的10000小時(shí)努力不會(huì)讓你成為專(zhuān)家，這個(gè)道理同樣適用于團(tuán)隊(duì)，卓越的團(tuán)隊(duì)無(wú)法靠無(wú)腦的擴(kuò)張和機(jī)械的重復(fù)打造。

互聯(lián)網(wǎng)公司值得我們學(xué)習(xí)的，不僅僅是技術(shù)，透明化、扁平化絕對(duì)是重要的一條，Google在《重新定義團(tuán)隊(duì)》提了很多了，對(duì)沖基金公司橋水創(chuàng)始人瑞·達(dá)利歐在《原則》一書(shū)中提到了“極度求真和極度透明”，李開(kāi)復(fù)在微軟亞洲研究院提倡的“白板文化”激蕩和迸發(fā)了多少創(chuàng)意，也許只有經(jīng)歷過(guò)才能知道開(kāi)放透明的價(jià)值。

毫無(wú)疑問(wèn)，大數(shù)據(jù)將帶來(lái)平臺(tái)，工具，管理的巨大變革，有太多的問(wèn)題需要解決，而能否勇敢、坦誠(chéng)的提出問(wèn)題是適應(yīng)新變化的前提，同樣起點(diǎn)的團(tuán)隊(duì)，會(huì)由于開(kāi)放透明程度的不同形成巨大差距，大數(shù)據(jù)不能容忍鴕鳥(niǎo)政策，比如前面的三個(gè)問(wèn)題通過(guò)團(tuán)隊(duì)的群策群力，我們給出了以下舉措：

措施1：將開(kāi)發(fā)管理平臺(tái)的體驗(yàn)改善提升到團(tuán)隊(duì)工作的高級(jí)別，落實(shí)相關(guān)開(kāi)發(fā)資源，在年底前逐步解決，同時(shí)反思項(xiàng)目化的建設(shè)模式是否符合新時(shí)期的要求。

措施2：新申請(qǐng)租戶(hù)資源或者調(diào)整各個(gè)租戶(hù)資源配額，削峰填谷；將開(kāi)發(fā)人員按業(yè)務(wù)拆分成多個(gè)團(tuán)隊(duì)租戶(hù)；明確開(kāi)發(fā)規(guī)范，在年底前將開(kāi)發(fā)規(guī)則內(nèi)嵌在開(kāi)發(fā)管理平臺(tái)。

措施3：標(biāo)簽上線增加審核，比如區(qū)分變更還是新增，規(guī)范命名，對(duì)于存量標(biāo)簽相似名稱(chēng)進(jìn)行核查，下線造成歧義的雷同標(biāo)簽。

現(xiàn)在有個(gè)熱詞叫做涌現(xiàn)，凱文.凱利在他的《失控》這本書(shū)中專(zhuān)門(mén)講過(guò)蟻群，一只螞蟻可能什么都做不了，但是一群螞蟻通過(guò)一種協(xié)同的機(jī)制，可以做出很多精巧的事情。人的大腦是由神經(jīng)元構(gòu)成的，但是單個(gè)的神經(jīng)元獨(dú)立的看只是一個(gè)部件，但是通過(guò)不斷的刺激，讓神經(jīng)元之間產(chǎn)生聯(lián)系之后，我們就可以創(chuàng)造人類(lèi)文明。這些就是涌現(xiàn)。我們熟悉的市場(chǎng)是涌現(xiàn)，區(qū)塊鏈技術(shù)也是涌現(xiàn)。

這個(gè)道理似乎也能應(yīng)用于團(tuán)隊(duì)，如果每個(gè)成員都能做到知無(wú)不言，團(tuán)隊(duì)將涌現(xiàn)出一種高效解決問(wèn)題的能力，這也是我們夢(mèng)寐以求的吧。

當(dāng)然，筆者這里只是提出了問(wèn)題，但卻無(wú)法告訴解決問(wèn)題的辦法，比如打造開(kāi)放、透明的團(tuán)隊(duì)環(huán)境的具體方法，因?yàn)樽约阂膊恢?，只知道照搬別人是很難的，因?yàn)槊總€(gè)企業(yè)有自己獨(dú)特的環(huán)境，頭腦風(fēng)暴在一些企業(yè)很好使，但在很多地方完全不行，為了加大溝通讓新人寫(xiě)日?qǐng)?bào)能成，但對(duì)于其他人就不一定適用，因?yàn)椴灰欢軐?duì)這個(gè)事達(dá)成共識(shí)，強(qiáng)扭的瓜也不會(huì)甜，“白板文化”說(shuō)說(shuō)容易，但真功夫不是看看李開(kāi)復(fù)的書(shū)就能學(xué)會(huì)的，還是要自己實(shí)踐和體會(huì)。

但在這個(gè)特殊的時(shí)期，理解“開(kāi)放、透明的環(huán)境對(duì)于大數(shù)據(jù)團(tuán)隊(duì)是如此重要”這句話(huà)是非常有益的，因?yàn)檎J(rèn)識(shí)到這個(gè)問(wèn)題的重要性才有行動(dòng)的可能。

你看赫拉利又出了本新書(shū)《今日簡(jiǎn)史》，他只是提出了21個(gè)問(wèn)題，啥回答都沒(méi)有，但也引發(fā)了大家的思考，最近正好讀托馬斯.弗里德曼的《世界是平的》一書(shū)，也發(fā)現(xiàn)了類(lèi)似的話(huà)，分享于你。

一位朋友曾向諾貝爾物理學(xué)獎(jiǎng)獲得者伊西多.拉比詢(xún)問(wèn)他的成才之道。拉比回答說(shuō)，小時(shí)候每天放學(xué)后母親都會(huì)問(wèn)他當(dāng)天的學(xué)習(xí)情況。她對(duì)兒子一天所學(xué)的內(nèi)容并不感興趣，但她總是會(huì)問(wèn)：“今天你是否提出了一個(gè)好問(wèn)題？”,拉比說(shuō)：“提出好問(wèn)題讓我成為了科學(xué)家?！?

自 2016 年以來(lái)，Uber 已在平臺(tái)上增加了幾項(xiàng)新業(yè)務(wù)，包括 Uber Eats、Uber Freight 和 Jump Bikes?，F(xiàn)在，Uber 平臺(tái)每天發(fā)生 1500 萬(wàn)次交易，每月有超過(guò) 7500 萬(wàn)活躍用戶(hù)。在過(guò)去的八年中，Uber 已經(jīng)從一家小型創(chuàng)業(yè)公司發(fā)展成為一個(gè)在全球擁有 18,000 名員工的巨頭公司。

隨著業(yè)務(wù)的增長(zhǎng)，數(shù)據(jù)系統(tǒng)和工程架構(gòu)的復(fù)雜性也日益增加。我們的分析引擎中存在數(shù)萬(wàn)個(gè)表，包括 Hive、Presto 和 Vertica。因?yàn)閿?shù)據(jù)太過(guò)分散，我們必須對(duì)可用的信息有全面的了解，特別是當(dāng)我們繼續(xù)添加新業(yè)務(wù)數(shù)據(jù)和員工時(shí)。2015 年，Uber 開(kāi)始使用一些手動(dòng)維護(hù)的靜態(tài) HTML 文件對(duì)這些數(shù)據(jù)表進(jìn)行編目。

隨著公司的發(fā)展，我們需要更新的表的數(shù)量和相關(guān)元數(shù)據(jù)的數(shù)量也在增長(zhǎng)。為了確保我們的數(shù)據(jù)分析能夠跟上公司發(fā)展的步伐，我們需要一種更簡(jiǎn)單、更快捷的方式來(lái)更新這些信息。在這種規(guī)模和增長(zhǎng)速度的背景下，擁有一個(gè)可用于發(fā)現(xiàn)數(shù)據(jù)集及其相關(guān)元數(shù)據(jù)的強(qiáng)大系統(tǒng)已經(jīng)到了刻不容緩的地步。

圖1

為了可以更容易發(fā)現(xiàn)和探索數(shù)據(jù)集，我們開(kāi)發(fā)了 Databook。Databook 可用于管理和展示 Uber 數(shù)據(jù)集的元數(shù)據(jù)，讓 Uber 的員工能夠在 Uber 探索、發(fā)現(xiàn)和有效利用這些數(shù)據(jù)。Databook 可以保證數(shù)據(jù)的上下文（數(shù)據(jù)的意義、質(zhì)量等）對(duì)于成千上萬(wàn)試圖分析它們的人來(lái)說(shuō)是有意義的。簡(jiǎn)單地說(shuō)，Databook 元數(shù)據(jù)讓 Uber 的工程師、數(shù)據(jù)科學(xué)家和運(yùn)營(yíng)團(tuán)隊(duì)從原先的查看原始數(shù)據(jù)轉(zhuǎn)變?yōu)楝F(xiàn)在的掌握可操作信息。

有了 Databook，我們從手動(dòng)更新轉(zhuǎn)變?yōu)槔酶呒?jí)自動(dòng)化元數(shù)據(jù)存儲(chǔ)來(lái)收集各種經(jīng)常刷新的元數(shù)據(jù)。Databook 具備以下幾項(xiàng)特性：

可擴(kuò)展性：易于添加新的元數(shù)據(jù)、存儲(chǔ)和實(shí)體。

可訪問(wèn)性：服務(wù)可以以編程的方式訪問(wèn)所有元數(shù)據(jù)。

可伸縮性：支持高吞吐量讀取。

其他：跨數(shù)據(jù)中心讀寫(xiě)。

Databook 提供了各種源自 Hive、Vertica、MySQL、Postgres、Cassandra 和其他幾種內(nèi)部存儲(chǔ)系統(tǒng)的元數(shù)據(jù)，包括：表的模式、表 / 列說(shuō)明、樣本數(shù)據(jù)、統(tǒng)計(jì)信息、Lineage、表的新鮮度、SLA 和所有者、個(gè)人數(shù)據(jù)分類(lèi)。

所有的元數(shù)據(jù)都可以通過(guò)一個(gè)集中式 UI 和 RESTful API 來(lái)訪問(wèn)。Databook UI 為用戶(hù)訪問(wèn)元數(shù)據(jù)提供了一種便利的方式，而 Restful API 則為 Uber 的其他服務(wù)和用例提供支持。

雖然現(xiàn)在已經(jīng)有像 LinkedIn WhereHows 這樣的開(kāi)源解決方案，但在開(kāi)發(fā) Databook 的過(guò)程中，Uber 不支持 Play Framework 和 Gradle。WhereHows 缺乏對(duì)跨數(shù)據(jù)中心讀寫(xiě)的支持，而這對(duì)于我們來(lái)說(shuō)卻至關(guān)重要。因此，我們開(kāi)始構(gòu)建自己的內(nèi)部解決方案，并使用 Java 開(kāi)發(fā)，充分利用 Java 的內(nèi)置功能和成熟的生態(tài)系統(tǒng)。

接下來(lái)，我們將分享我們是如何創(chuàng)建 Databook 的，以及在這一過(guò)程中遇到了哪些挑戰(zhàn)。

Databook 架構(gòu)

Databook 的架構(gòu)可以分為三個(gè)部分：如何收集元數(shù)據(jù)、如何存儲(chǔ)元數(shù)據(jù)以及如何顯示元數(shù)據(jù)。下圖描繪了 Databook 的整體架構(gòu)：

圖2

Databook 將多個(gè)源作為輸入，存儲(chǔ)相關(guān)元數(shù)據(jù)，并通過(guò) RESTful API 輸出這些信息。其中 Databook UI 也使用了這些 API。

在設(shè)計(jì) Databook 之初，我們必須做出一個(gè)重大的決定：存儲(chǔ)收集到的元數(shù)據(jù)還是按需獲??？我們的服務(wù)需要支持高吞吐量和低延遲讀取，如果我們將操作委托給元數(shù)據(jù)源，所有源都要支持高吞吐量和低延遲讀取，這將帶來(lái)更大的復(fù)雜性和更高的風(fēng)險(xiǎn)。例如，用于獲取表模式的 Vertica 查詢(xún)通常需要幾秒鐘，所以不適合用于可視化。同樣，我們的 Hive Metastore 管理著所有的 Hive 元數(shù)據(jù)，要讓它支持高吞吐量讀取是有風(fēng)險(xiǎn)的。Databook 可以支持多種不同的元數(shù)據(jù)源，因此我們決定將元數(shù)據(jù)保存在 Databook 中。此外，雖然大多數(shù)用例需要新的元數(shù)據(jù)，但它們不需要實(shí)時(shí)查看元數(shù)據(jù)變更，所以我們可以進(jìn)行定時(shí)爬取。

我們還將請(qǐng)求服務(wù)層與數(shù)據(jù)收集層分開(kāi)，每個(gè)層都運(yùn)行在一個(gè)單獨(dú)的進(jìn)程中，如下圖所示：

圖3

這種方式將兩個(gè)層隔離開(kāi)，從而減少了附帶影響。例如，數(shù)據(jù)收集爬蟲(chóng)作業(yè)可能會(huì)使用較多的系統(tǒng)資源，從而影響請(qǐng)求服務(wù)層 API 的 SLA。此外，與 Databook 的請(qǐng)求服務(wù)層相比，數(shù)據(jù)收集層對(duì)中斷不太敏感，如果數(shù)據(jù)收集層關(guān)閉，仍然可以提供過(guò)時(shí)的元數(shù)據(jù)，從而最大限度地減少對(duì)用戶(hù)的影響。

基于事件的收集與調(diào)度收集

我們的下一個(gè)挑戰(zhàn)是決定改如何最有效地從幾個(gè)不同的數(shù)據(jù)源收集元數(shù)據(jù)。我們考慮了多種方案，包括：創(chuàng)建分布式的容錯(cuò)框架，并利用事件流來(lái)近乎實(shí)時(shí)地檢測(cè)和調(diào)試問(wèn)題。

我們先是創(chuàng)建了爬蟲(chóng)，定時(shí)收集來(lái)自各種數(shù)據(jù)源和微服務(wù)的信息，這些數(shù)據(jù)源和微服務(wù)會(huì)生成數(shù)據(jù)集的元數(shù)據(jù)信息，例如由開(kāi)源工具 Queryparser 生成的數(shù)據(jù)表的使用統(tǒng)計(jì)信息。（有趣的是，Queryparser 是由 Uber 的數(shù)據(jù)知識(shí)平臺(tái)團(tuán)隊(duì)開(kāi)發(fā)的）。

我們需要以可伸縮的方式頻繁收集元數(shù)據(jù)信息，同時(shí)不能阻塞其他爬蟲(chóng)任務(wù)。為此，我們將爬蟲(chóng)部署在不同的計(jì)算機(jī)上，并且需要協(xié)調(diào)這些分布式的爬蟲(chóng)。我們使用了 Quartz 的分布式模式（由 MySQL 支持）。然而，有兩個(gè)問(wèn)題阻礙了這個(gè)方案的實(shí)現(xiàn)：首先，在多臺(tái)機(jī)器上以集群模式運(yùn)行 Quartz 需要定期同步 Quartz 時(shí)鐘，從而增加了外部依賴(lài)。其次，在調(diào)度程序啟動(dòng)后，持續(xù)出現(xiàn) MySQL 連接不穩(wěn)定的情況。最后，我們決定不使用 Quartz 的集群模式。

不過(guò)，我們?nèi)匀焕^續(xù)使用 Quartz 來(lái)實(shí)現(xiàn)內(nèi)存調(diào)度，以便更輕松、更高效地將任務(wù)發(fā)布到任務(wù)隊(duì)列中。我們使用了 Uber 開(kāi)源的任務(wù)執(zhí)行框架 Cherami 來(lái)處理任務(wù)隊(duì)列。這個(gè)開(kāi)源工具可以用來(lái)解耦分布式系統(tǒng)中的消費(fèi)者應(yīng)用程序，讓它們能夠以異步方式跨多個(gè)消費(fèi)者群組進(jìn)行通信。有了 Cherami，我們就可以爬蟲(chóng)打包成 Docker 容器，并部署到不同的主機(jī)和多個(gè)數(shù)據(jù)中心中。借助 Cherami，我們可以從多個(gè)不同來(lái)源收集各種元數(shù)據(jù)，而不會(huì)阻塞任何任務(wù)，同時(shí)將 CPU 和內(nèi)存消耗保持在理想水平。

雖然我們的爬蟲(chóng)可以爬取大多數(shù)元數(shù)據(jù)類(lèi)型，但是有時(shí)候需要近乎實(shí)時(shí)地捕獲一些元數(shù)據(jù)，于是我們決定過(guò)渡到使用基于事件的架構(gòu)（Kafka）。有了這個(gè)，我們就能夠立即檢測(cè)并調(diào)試數(shù)據(jù)中斷。我們的系統(tǒng)還可以捕獲到關(guān)鍵的元數(shù)據(jù)變更，例如數(shù)據(jù)集 lineage 和新鮮度，如下圖所示：

圖4

這種架構(gòu)讓我們的系統(tǒng)能夠以編程方式觸發(fā)其他微服務(wù)，并近乎實(shí)時(shí)地向數(shù)據(jù)用戶(hù)發(fā)起通信。我們?nèi)匀皇褂门老x(chóng)執(zhí)行其他一些任務(wù)，比如收集（或刷新）樣本數(shù)據(jù)、限制目標(biāo)資源請(qǐng)求，以及一些沒(méi)有必要收集的元數(shù)據(jù)（有些事件發(fā)生時(shí)會(huì)自動(dòng)觸發(fā)其他系統(tǒng)，如數(shù)據(jù)集使用統(tǒng)計(jì)）。

除了近乎實(shí)時(shí)地輪詢(xún)和收集元數(shù)據(jù)之外，Databook UI 還收集來(lái)自數(shù)據(jù)集消費(fèi)者和生產(chǎn)者的語(yǔ)義信息，例如對(duì)表和列的描述。

我們是如何存儲(chǔ)元數(shù)據(jù)的

在 Uber，為了能夠進(jìn)行失效備援，我們的大多數(shù)管道都運(yùn)行在多個(gè)集群上。因此，同一張表的某些類(lèi)型元數(shù)據(jù)的值（例如延遲和使用統(tǒng)計(jì)）可能因集群的不同而不同，它們是特定于集群的。相反，來(lái)自用戶(hù)的元數(shù)據(jù)則與群集無(wú)關(guān)：同一張表的描述和所有權(quán)信息對(duì)于所有群集來(lái)說(shuō)都是一樣的。為了正確鏈接這兩種類(lèi)型的元數(shù)據(jù)，例如將列描述與所有集群數(shù)據(jù)表的列關(guān)聯(lián)起來(lái)，可以采用兩種方法：寫(xiě)入期間鏈接或讀取期間鏈接。

寫(xiě)入期間鏈接

在關(guān)聯(lián)特定于群集的元數(shù)據(jù)和群集無(wú)關(guān)的元數(shù)據(jù)時(shí)，最直接的策略是在寫(xiě)入期間將元數(shù)據(jù)鏈接在一起。例如，當(dāng)用戶(hù)將列描述添加到給定的表列時(shí)，我們將信息保存到所有集群的表中，如下圖所示：

圖5

這個(gè)方法可確保持久數(shù)據(jù)處于干凈狀態(tài)。例如，在上圖中，如果“列 1”不存在，它將會(huì)拒絕請(qǐng)求。不過(guò)這樣就存在一個(gè)問(wèn)題：在寫(xiě)入期間將與群集無(wú)關(guān)的元數(shù)據(jù)鏈接到特定于群集的元數(shù)據(jù)，所有特定于群集的元數(shù)據(jù)必須存在，并且只有一次機(jī)會(huì)。例如，當(dāng)圖 4 中的描述被觸發(fā)時(shí)，只有集群 1 有“列 1”，因此對(duì)集群 2 的寫(xiě)入會(huì)失敗。稍后，群集 2 中同一個(gè)表的模式會(huì)被更新，但已經(jīng)沒(méi)有鏈接元數(shù)據(jù)的機(jī)會(huì)了，除非我們進(jìn)行定時(shí)重試，否則這個(gè)描述將永遠(yuǎn)不可用，從而讓系統(tǒng)變得更復(fù)雜。下圖描述了這種場(chǎng)景：

圖6

讀取期間鏈接

另一種方法是在讀取期間鏈接群集無(wú)關(guān)和特定于群集的元數(shù)據(jù)。這個(gè)方法解決了寫(xiě)入期間鏈接會(huì)丟失元數(shù)據(jù)的問(wèn)題，因?yàn)橹灰囟ㄓ谌杭脑獢?shù)據(jù)存在，這兩種類(lèi)型的元數(shù)據(jù)就可以在讀取期間進(jìn)行鏈接。模式更新后，“列 1”就會(huì)出現(xiàn)，并在用戶(hù)讀取時(shí)被合并，如下圖所示：

圖 7

存儲(chǔ)選擇

MySQL 最初用于為 Databook 的后端提供支持，因?yàn)橛盟_(kāi)發(fā)速度快，還可以通過(guò) Uber 的基礎(chǔ)設(shè)施門(mén)戶(hù)進(jìn)行自動(dòng)配置。不過(guò)，當(dāng)涉及多數(shù)據(jù)中心時(shí)，共享 MySQL 集群的效果并不理想，原因有三：

單個(gè)主節(jié)點(diǎn)：首先，Uber 只支持單個(gè)主節(jié)點(diǎn)，導(dǎo)致其他數(shù)據(jù)中心的寫(xiě)入較慢（每次寫(xiě)入增加了約 70 毫秒）。

手動(dòng)切換主節(jié)點(diǎn)：其次，當(dāng)時(shí)還不支持自動(dòng)切換主節(jié)點(diǎn)。因此，如果主節(jié)點(diǎn)宕機(jī)，需要幾小時(shí)才能切換到新的主節(jié)點(diǎn)。

數(shù)據(jù)量：我們棄用 MySQL 的另一個(gè)原因是 Uber 的大量數(shù)據(jù)。我們打算保留所有的歷史變更記錄，并希望我們的系統(tǒng)能夠支持未來(lái)的擴(kuò)展，而無(wú)需在集群維護(hù)上花費(fèi)太多時(shí)間。

鑒于這些原因，我們使用 Cassandra 取代了 MySQL，因?yàn)樗峁┝藦?qiáng)大的 XDC 復(fù)制支持，可以在幾乎不增加延遲的情況下從多個(gè)數(shù)據(jù)中心寫(xiě)入數(shù)據(jù)。而且 Cassandra 是線性可擴(kuò)展的，可以適應(yīng) Uber 不斷增長(zhǎng)的數(shù)據(jù)量。

我們是如何提供數(shù)據(jù)的

Databook 提供了兩種訪問(wèn)元數(shù)據(jù)的方法：RESTful API 和 UI 控制臺(tái)。Databook 的 RESTful API 由 Dropwizard 提供支持，Dropwizard 是一個(gè)用于開(kāi)發(fā)高性能 RESTful Web 服務(wù)的 Java 框架，可部署在多臺(tái)計(jì)算機(jī)上，并通過(guò) Uber 的內(nèi)部請(qǐng)求轉(zhuǎn)發(fā)服務(wù)進(jìn)行負(fù)載均衡。

在 Uber，大部分服務(wù)通過(guò)編程的方式訪問(wèn) Databook 的數(shù)據(jù)。例如，我們的查詢(xún)解析 / 重寫(xiě)服務(wù)就依賴(lài)于 Databook 的表模式信息。API 可以支持高吞吐量讀取，并且支持水平擴(kuò)展，每秒的峰值查詢(xún)大約為 1,500。UI 控制臺(tái)使用 React.js、Redux 以及 D3.js 開(kāi)發(fā)，整個(gè)公司的工程師、數(shù)據(jù)科學(xué)家、數(shù)據(jù)分析師和運(yùn)營(yíng)團(tuán)隊(duì)都在用它診斷數(shù)據(jù)質(zhì)量問(wèn)題以及識(shí)別和探索相關(guān)數(shù)據(jù)集。

搜索

搜索是 Databook UI 的一項(xiàng)重要功能，用戶(hù)因此能夠輕松訪問(wèn)和瀏覽表的元數(shù)據(jù)。我們使用 Elasticsearch 作為全索引搜索引擎，Elasticsearch 會(huì)從 Cassandra 同步數(shù)據(jù)。用戶(hù)可以使用 Databook 進(jìn)行跨維度搜索，例如名稱(chēng)、所有者、列和嵌套列，如下圖所示，從而實(shí)現(xiàn)更及時(shí)、更準(zhǔn)確的數(shù)據(jù)分析：