原文 Stable Accessible Data Infrastructure in Startup 作者：Marco Gallotta 譯者：Liang Yu
數(shù)據(jù)是創(chuàng)立Asana的核心部分，并且每一個(gè)團(tuán)隊(duì)都依賴他們自己的方式。我們的負(fù)責(zé)增長(zhǎng)的團(tuán)隊(duì)依靠事件數(shù)據(jù)來(lái)分析試驗(yàn)結(jié)果（對(duì)比試驗(yàn)）。 我們做很多快速的實(shí)驗(yàn)--通常會(huì)有很多實(shí)驗(yàn)一起跑-- 讓這些互相影響的作用和其他關(guān)鍵度量引導(dǎo)我們需要放棄什么和投入什么。 項(xiàng)目經(jīng)理，設(shè)計(jì)師和產(chǎn)品工程師通過(guò)分析使用數(shù)據(jù)來(lái)發(fā)現(xiàn)不可避免的妥協(xié)，比如簡(jiǎn)潔性對(duì)強(qiáng)大性。通過(guò)這種方法，我們可以知道什么樣的新產(chǎn)品方向能夠釋放出最多的潛力。市場(chǎng)部門需要明確在他們的競(jìng)爭(zhēng)力中的哪個(gè)部分能夠驅(qū)使新用戶到Asana。財(cái)會(huì)部門需要非?？煽康年P(guān)于總體增長(zhǎng)模式的統(tǒng)計(jì)數(shù)據(jù)來(lái)幫助Asana確認(rèn)能持續(xù)發(fā)展到2064年。你是怎樣建造一個(gè)支持所有這些多樣需求的系統(tǒng)呢 ？
Asana 數(shù)據(jù)基礎(chǔ)架構(gòu)
從小開始，逐漸增長(zhǎng)
上圖并不是我們一開始就建立的系統(tǒng)。我們從一個(gè)十分簡(jiǎn)單的系統(tǒng)開始，也就是一些python腳本和MySQL數(shù)據(jù)庫(kù)，它們?nèi)歼\(yùn)行在一個(gè)機(jī)器上。剛開始的時(shí)候，一個(gè)簡(jiǎn)潔的系統(tǒng)能夠減少系統(tǒng)維護(hù)，并且如果還沒(méi)有任何用戶，或許你就可以從這里開始。但是，從2011開始，Asana的增長(zhǎng)就一直穩(wěn)定（看下面的圖）。然后我們就開始碰到一些限制。最近，針對(duì)數(shù)據(jù)基礎(chǔ)架構(gòu)，我們做了一系列的變化。所有的一切都證明是很有價(jià)值的。
往監(jiān)控，測(cè)試和自動(dòng)化上投資來(lái)減少救火的次數(shù)
從MySQL遷移到Redshift，得到一個(gè)可擴(kuò)展的數(shù)據(jù)倉(cāng)庫(kù)
從本地的日志處理遷移到基于Hadoop的可擴(kuò)展的日志處理
引進(jìn)商業(yè)智庫(kù)工具來(lái)允許非專家來(lái)回答他們自己的數(shù)據(jù)問(wèn)題
Asana隨著時(shí)間變化時(shí)的“時(shí)間”數(shù)量圖。按照原始數(shù)據(jù)量做單位
結(jié)束無(wú)休止的問(wèn)題
一年前，我們遇到了一些關(guān)于數(shù)據(jù)處理健壯性的問(wèn)題。當(dāng)圖表中有個(gè)重要的變化，人們立馬會(huì)質(zhì)疑數(shù)據(jù)的整體性。把問(wèn)題和有趣的想法區(qū)分開來(lái)是很難的。數(shù)據(jù)科學(xué)已經(jīng)是一門藝術(shù)，所以你需要基礎(chǔ)架構(gòu)來(lái)給你提出的問(wèn)題一個(gè)信得過(guò)的答案。然而，99%的準(zhǔn)確性還是不夠好。在數(shù)據(jù)基礎(chǔ)架構(gòu)小組那里，我們花費(fèi)了太多時(shí)間鼓搗非常緊急的問(wèn)題，而且這點(diǎn)使得我們沒(méi)法取得更長(zhǎng)期的發(fā)展。這太痛苦了。
受到啟發(fā)
當(dāng)壞的事情發(fā)生后，我們會(huì)采取“5個(gè)為什么”的方法來(lái)發(fā)現(xiàn)問(wèn)題的原因和解決這個(gè)問(wèn)題。比如，我們?cè)?jīng)讓一個(gè)數(shù)據(jù)處理腳本錯(cuò)誤地生成了一個(gè)超級(jí)大的日志文件，它太大了，以至于我們無(wú)法用電子郵件發(fā)送。作為解決方案，我們?cè)诎l(fā)生日志文件前就開始把日志文件分割成小段，并且在發(fā)送郵件錯(cuò)誤的時(shí)候發(fā)送警告信息和在腳本輸出結(jié)果上增加監(jiān)控。在其他的一些我們還沒(méi)有辦法洞悉原因的例子里，我們就增加日志，檢測(cè)和預(yù)警。例如，我們的實(shí)驗(yàn)總是經(jīng)常性的落后，所以我們?cè)诓煌奶幚黼A段增加更廣泛的日志記錄來(lái)看看哪里花費(fèi)了最多的時(shí)間，并且用來(lái)指示什么部分需要優(yōu)化。
當(dāng)我們的監(jiān)控和日志記錄不夠的時(shí)候，最壞的事情持續(xù)了好幾個(gè)月。一個(gè)比較極端的例子就是，我們的一個(gè)工具花費(fèi)了比其應(yīng)花費(fèi)時(shí)間多很多的時(shí)間。一段時(shí)間后，我們發(fā)現(xiàn)了一些查詢被傳遞進(jìn)了一個(gè)不知道為什么我們也沒(méi)搞懂的、含有有特殊時(shí)區(qū)信息的時(shí)間類。這些查詢顯著地增加了查詢時(shí)間。由于這個(gè)任務(wù)花費(fèi)了一天多的時(shí)間來(lái)完成，所以第二天的任務(wù)才能接著開始，然而這導(dǎo)致了MySQL鎖過(guò)期。當(dāng)生成圖像的時(shí)候，這些任務(wù)就沒(méi)法取得所有需要的數(shù)據(jù)。
我們隱藏了零數(shù)值，并且必須要每次人工地做很多工作去清理。錯(cuò)誤總是導(dǎo)致更多的錯(cuò)誤，所以打補(bǔ)丁也沒(méi)有用。最終，這個(gè)事件使得我們真正要去把測(cè)試的優(yōu)先級(jí)提到最高。
一年前，我們的數(shù)據(jù)基礎(chǔ)架構(gòu)的代碼上面幾乎就沒(méi)有任何測(cè)試。然而我們還不能滿足我們當(dāng)前的測(cè)試覆蓋率，但是我們已經(jīng)做了很多改進(jìn)。當(dāng)你得到一個(gè)失敗的測(cè)試結(jié)果并且你意識(shí)到這個(gè)本可能出問(wèn)題的部分使得你改變了產(chǎn)品的一些代碼。這樣的感覺(jué)好極了。雖然我們一直在探索節(jié)點(diǎn)增加的特性，我們還是使用python內(nèi)置的單元測(cè)試模塊。我們把努力的方向放在為數(shù)不多的，特別是在那些我們能夠建立自己的架構(gòu)代碼的領(lǐng)域，從而使得我們的數(shù)據(jù)科學(xué)家和其他的數(shù)據(jù)用戶能夠?qū)懗鏊麄冏约旱臏y(cè)試。
自動(dòng)化測(cè)試
原來(lái)我們用cron來(lái)運(yùn)行所有的事情。任務(wù)會(huì)在不同的時(shí)間段運(yùn)行，我們期望某些任務(wù)在另外一些依賴它們的任務(wù)開始前完成。但是事情不總是這樣。比如，一個(gè)任務(wù)運(yùn)行失敗，那就需要很多人為的清理。接著，我們開始使用Luigi 來(lái)建立一個(gè)管道。這個(gè)管道懂得依賴性，就像你看到的下圖中我們的管道的一小部分示例。通過(guò)Luigi，當(dāng)一個(gè)任務(wù)運(yùn)行失敗，我們會(huì)得到告警，而且所有依靠它的任務(wù)都不會(huì)運(yùn)行，直到我們修復(fù)那個(gè)運(yùn)行失敗的問(wèn)題。只需要恢復(fù)管道并且讓未完成的任務(wù)繼續(xù)，這樣就簡(jiǎn)單多了。這個(gè)也是我們并行化這些任務(wù)的第一步。
我們的過(guò)去的預(yù)警方式很粗糙簡(jiǎn)陋。我們有顯而易見(jiàn)的比如關(guān)于可用的硬盤空間的預(yù)警，但是這個(gè)花費(fèi)很多思考和努力來(lái)克服困難從而得到我們今天擁有的一切?，F(xiàn)在，我們覆蓋了所有的系統(tǒng)警告，從內(nèi)存和CPU使用率到Redshift集群上長(zhǎng)時(shí)間的高負(fù)載。我們監(jiān)控我們數(shù)據(jù)管道的變化，當(dāng)時(shí)間花費(fèi)超出預(yù)期或者一些任務(wù)沒(méi)有能夠在我們期望的時(shí)間內(nèi)完成時(shí)就發(fā)出預(yù)警。我們監(jiān)控?cái)?shù)據(jù)本身，保證重要的變量都是非零的，并且用回歸分析來(lái)提示一個(gè)事件出現(xiàn)多于或者少于在過(guò)去的幾個(gè)星期中我們看到的次數(shù)。
用Luigi畫的我們數(shù)據(jù)的ETL 管道
我們改進(jìn)關(guān)于優(yōu)先處理郵件警示的過(guò)程。我們十分重度地依賴Asana，它工作十分良好，特別是在分擔(dān)責(zé)任和當(dāng)數(shù)據(jù)會(huì)出現(xiàn)預(yù)知的錯(cuò)誤時(shí)通知用戶。
（原文此處的will應(yīng)該為with）有了這些努力，問(wèn)題逐漸變得少了。一旦不再花費(fèi)時(shí)間讓已有的數(shù)據(jù)基礎(chǔ)架構(gòu)發(fā)生癱瘓，我們就有時(shí)間來(lái)建造未來(lái)。
我們的數(shù)據(jù)基礎(chǔ)架構(gòu)的最新發(fā)展
可擴(kuò)展的數(shù)據(jù)倉(cāng)庫(kù) (Redshift)
最初，我們使用MySQL數(shù)據(jù)庫(kù)作為數(shù)據(jù)倉(cāng)庫(kù)，因?yàn)槲覀兊墓こ處熒瞄L(zhǎng)優(yōu)化這個(gè)數(shù)據(jù)庫(kù)。但是，因?yàn)镸ySQL是基于行記錄的，所以它不適合在非常大的數(shù)據(jù)集合上運(yùn)行包含復(fù)雜鏈接操作的聚集查詢。當(dāng)我們遇到了性能問(wèn)題，我們修改索引。當(dāng)我們還遇到更多的性能問(wèn)題，我們?cè)贛ySQL之上建立一個(gè)定制的、面向直方圖的查詢緩沖層。
依舊，每一處優(yōu)化只能幫助我們走得這么遠(yuǎn)，并且我們并不想把我們的寶貴的工程師資源花在建立分析數(shù)據(jù)庫(kù)上。很多公司都宣稱Redshift幫助他們很好的提速。所以我們也打算試一試。結(jié)果太好了。在最極端的情況下，一個(gè)日常的查詢?cè)贛ySQL上需要6個(gè)小時(shí)，但是在Redshift上，只需要幾秒鐘，而且不需要任何修改。
一個(gè)在MySQL上需要花費(fèi)數(shù)分鐘的查詢，但在Redshift只需要1秒鐘
遷移的過(guò)程
遷移到Redshfit可不是一個(gè)小事情。我們已存在的數(shù)據(jù)管道是適合于MySQL的計(jì)劃而建造的。并且每一個(gè)人都很熟悉這個(gè)特點(diǎn)。我們努力抽象出Redshift的特
性。比如，通過(guò)亞馬遜的S3加載數(shù)據(jù)和依據(jù)主鍵合成數(shù)據(jù)到一個(gè)已有的表格。
缺少對(duì)于主鍵的支持是意料之外的最大缺點(diǎn)。然后遷移我們已存在的數(shù)據(jù)管道的樂(lè)趣就開始了。復(fù)雜的依賴性意味著我們必須小心地按照正確的順序遷移寫入。有時(shí)，當(dāng)我們遷移從MySQL的一個(gè)表格到Redshift的所有查詢時(shí)，我們必須同時(shí)寫入到MySQL和Redshift。最困難的部分是協(xié)調(diào)部門之間的努力去遷移數(shù)量巨大的、相互依賴的MySQL查詢語(yǔ)句。而且其中的一些只被很少的一部分人理解和使用。我們從數(shù)據(jù)科學(xué)家和商業(yè)團(tuán)隊(duì)中得到了關(guān)于他們最棘手的部分的有價(jià)值的反饋。繼而，我們使得他們的工作變得更愉快。
解鎖新的分析
然而我們選擇Redshift時(shí)的主要目的是解決性能和可擴(kuò)展性的問(wèn)題，不過(guò)它順便也改進(jìn)了可訪問(wèn)性。這點(diǎn)來(lái)得有點(diǎn)間接和意外。在遷移到Redshift的同時(shí)，我們也在探尋商業(yè)智能工具。我們?cè)u(píng)估了一些工具，本來(lái)最喜歡Looker，而且決定嘗試一下。不幸的是，當(dāng)我們把它和MySQL連在一起時(shí)的分析結(jié)果太慢了，以至于我們沒(méi)法推薦給我們的商業(yè)團(tuán)隊(duì)。把Looker和Redshift鏈接后，性能從需要數(shù)分鐘變得足以實(shí)時(shí)地在絕大多數(shù)查詢上循環(huán)。這個(gè)組合太強(qiáng)大了，以至于我們的商業(yè)團(tuán)隊(duì)自己就決定用它了。我們絕大多數(shù)的商業(yè)團(tuán)隊(duì)就憑他們自己，其中有些成員甚至連SQL查詢不熟悉，也能夠玩數(shù)據(jù)。更好的是，他們能夠在不需要數(shù)據(jù)基礎(chǔ)架構(gòu)小組的支持下做到這點(diǎn)。他們的團(tuán)隊(duì)負(fù)責(zé)人說(shuō)：“這個(gè)就仿佛我把1995年自動(dòng)擋的吉普牧馬人換成了法拉利一樣爽… 有快又有樂(lè)趣！”
進(jìn)一步地?cái)U(kuò)展
Redshift還提供了工具用來(lái)限制給單獨(dú)的進(jìn)程和程序的資源。我們非常依靠這些功能來(lái)防止某些個(gè)人把數(shù)據(jù)庫(kù)獨(dú)占，從而別人無(wú)法使用。通過(guò)增加機(jī)器的數(shù)量，然后按一些按鈕我們就能在半個(gè)小時(shí)內(nèi)加速和增加存儲(chǔ)量。在將來(lái)，我們還可能自動(dòng)化這個(gè)過(guò)程。
可擴(kuò)展的日志處理 (彈性 MapReduce)
我們?nèi)粘５臄?shù)據(jù)處理延遲變得很長(zhǎng)，但是我們努力保持處理時(shí)間在24小時(shí)內(nèi)。雖然Redshift起了很大的幫助，但是我們也需要擴(kuò)展日志處理部分。我們決定采用這個(gè)行業(yè)的長(zhǎng)期標(biāo)準(zhǔn) Hadoop MapReduce。除了容易變得可擴(kuò)展的，這也是一個(gè)更容易的數(shù)據(jù)處理方式。和建造易使用框架的努力一起，這個(gè)使得更多的每天工作不是寫代碼的同事也能夠把日志處理成有用的模式。因此，這個(gè)既是一個(gè)大的擴(kuò)展性項(xiàng)目也是一個(gè)易用性的項(xiàng)目。
我們?cè)赮elp的映射歸納任務(wù)框架(mrjob)的基礎(chǔ)上建立我們的系統(tǒng)。因?yàn)槲覀兌贾繮ython很好，而且在靈活的MapReduce上開始跑任務(wù)也比較容易。我們知道這個(gè)明顯地比Java和流慢一些，但是那個(gè)層次的性能還不重要到讓我們降低易用性。我們?cè)谠O(shè)計(jì)基礎(chǔ)架構(gòu)的時(shí)候就好像知道在將來(lái)我們會(huì)把mrjob換到到其他的一些東西。
當(dāng)我們開始用MapReduce的時(shí)候，我們?nèi)耘f同時(shí)寫入MySQL和Redshift中。起初，這個(gè)讓我們同時(shí)從Hadoop集群上加載數(shù)據(jù)到兩個(gè)數(shù)據(jù)庫(kù)中。但是這個(gè)并不好使，因?yàn)榇蠖鄶?shù)的集群會(huì)空閑很長(zhǎng)的時(shí)間，而有時(shí)我們就很容易地碰到過(guò)期。所以我們提倡放棄MySQL，而在集群之外，移動(dòng)數(shù)據(jù)到Redshift。亞馬遜的彈性MapReduce可以存儲(chǔ)輸出到S3。我們利用這個(gè)來(lái)存儲(chǔ)數(shù)據(jù)，并且加載它到Redshift上來(lái)作為一個(gè)來(lái)自單獨(dú)的服務(wù)器的任務(wù)。
當(dāng)前，我們用一個(gè)八個(gè)節(jié)點(diǎn)的集群，這個(gè)給我們4到6倍的性能提升。當(dāng)我們負(fù)責(zé)增長(zhǎng)的團(tuán)隊(duì)要增加三倍的運(yùn)行任務(wù)的時(shí)候，我們只需要增加Hadoop集群的大小或者增加更多的集群。我們運(yùn)行在亞馬遜彈性MapReduce上，就使得這樣做變得更容易?？蓴U(kuò)展性還間接地幫助了易用性。因?yàn)椴挥脫?dān)心他們的代碼變得很慢和對(duì)數(shù)據(jù)管道有負(fù)面的影響，我們的商業(yè)團(tuán)隊(duì)在增加更多的數(shù)據(jù)處理上變得舒服很多。
商業(yè)智能工具 (Interana and Looker)
當(dāng)調(diào)研商業(yè)智庫(kù)工具的時(shí)候，有人介紹Interana。一個(gè)基于交互事件的、處理原生日志文件的分析解決方案。然而，這個(gè)并不是我們一開始需求的東西。我們集合我們的數(shù)據(jù)后發(fā)現(xiàn)它可以滿足一個(gè)之前并沒(méi)有預(yù)料到的需求：超快循環(huán)分析原生日志。我們就成為他們的最初的幾個(gè)用戶之一。在早期的產(chǎn)品設(shè)計(jì)里，我們和他們反復(fù)交流，使得他們實(shí)現(xiàn)了很多我們的性能需求。這逐漸地成為我們產(chǎn)品團(tuán)隊(duì)數(shù)據(jù)分析中的一個(gè)集成部分。同時(shí)，Looker繼續(xù)成為我們商業(yè)團(tuán)隊(duì)的一個(gè)重要的補(bǔ)充。我們的團(tuán)隊(duì)需要及時(shí)分析某幾個(gè)時(shí)間點(diǎn)上數(shù)據(jù)的狀態(tài)。
我們能夠在幾秒鐘內(nèi)處理十億數(shù)量級(jí)的數(shù)據(jù)點(diǎn)。從而展現(xiàn)出很多我們的數(shù)據(jù)中深層次的數(shù)據(jù)分析，這在以前不可能的。任何查詢數(shù)據(jù)模式的人都能夠很快地切割數(shù)據(jù)來(lái)發(fā)現(xiàn)根本原因并且擁有我們?nèi)康臄?shù)據(jù)集的訪問(wèn)權(quán)來(lái)快速地在區(qū)塊中篩查。這允許他們探索我們的用戶怎樣使用這個(gè)產(chǎn)品，從通過(guò)群組來(lái)做簡(jiǎn)單的事件計(jì)數(shù)到復(fù)雜的對(duì)話和漏斗分析?，F(xiàn)在，我們很少寫專門的腳本來(lái)扒下創(chuàng)建特殊聚集的日志。我們開始用Interana來(lái)分析性能日志。團(tuán)隊(duì)成員說(shuō)：“一旦當(dāng)Interana加入到我們的數(shù)據(jù)處理管道中，查找和解決回歸分析的效率就提高了一個(gè)數(shù)量級(jí)?！?/p>
一些Looker擅長(zhǎng)的例子：
查詢金融和收入數(shù)據(jù)；多種方式分切收入來(lái)理解增長(zhǎng)的趨勢(shì)
視覺(jué)化隨著時(shí)間流逝的群效應(yīng)（見(jiàn)截圖右側(cè)部分）
數(shù)據(jù)堆砌；所有滿足一個(gè)標(biāo)準(zhǔn)的客戶，等等。
Looker幫助我們查看大維度建模在時(shí)間軸上的群效應(yīng)
一些Interana 擅長(zhǎng)的事情：
交互的漏斗分析
視覺(jué)化用戶行為，導(dǎo)致新能問(wèn)題（截圖中的右邊部分）
理解長(zhǎng)期使用這個(gè)應(yīng)用的用戶會(huì)做什么操作
Interana使我們能夠找出在Asana中最慢的一些共同的行為
接下來(lái)
除了這些大項(xiàng)目，我們加固了一切，從而使得同事不會(huì)輕易的不小心弄癱瘓?jiān)O(shè)備。Justin Krause，我們的商業(yè)智庫(kù)負(fù)責(zé)人說(shuō)：“我們的工作生活變得非常好了，我?guī)缀醪粫?huì)弄壞任何東西了?！?大多數(shù)星期里，我們只用半個(gè)小時(shí)的時(shí)間來(lái)維護(hù)基礎(chǔ)設(shè)備。我們喜歡我們現(xiàn)在的狀態(tài)，但是這個(gè)僅僅是漫長(zhǎng)旅行中的一點(diǎn)。伴隨增長(zhǎng)，新的功能，新的生意需求，我們管道中的很多部分在將來(lái)的歲月中都會(huì)變得過(guò)時(shí)。我們知道事物總是會(huì)出現(xiàn)新的、有趣的錯(cuò)誤，所以我們也增加測(cè)試和監(jiān)控，以謀求在發(fā)生前發(fā)現(xiàn)大部分情況。我們還留意在數(shù)據(jù)分析領(lǐng)域中，哪個(gè)新系統(tǒng)變得流行，我們就會(huì)做出相應(yīng)的對(duì)策。
我們認(rèn)為會(huì)在下面幾點(diǎn)探索一下：
加入Hive，在Redshift之上增加一些東西，或者在Interana的能力范圍之外用另外一個(gè)系統(tǒng)來(lái)做原始的日志查詢。
流數(shù)據(jù)分析的系統(tǒng)
比mrjob更快的Hadoop，或者可能用像Spark一樣的東西來(lái)做內(nèi)存中的MapReduce
更好的異常探測(cè)和趨勢(shì)預(yù)警
限制單點(diǎn)缺陷
如果你對(duì)在快速變化的環(huán)境下建立數(shù)據(jù)基礎(chǔ)架構(gòu)有很好的想法，請(qǐng)加入我們下一階段的旅行吧。如果你想分析大數(shù)據(jù)和學(xué)習(xí)各個(gè)組之間怎樣工作，就以一個(gè)數(shù)據(jù)科學(xué)家的身份來(lái)用這個(gè)基礎(chǔ)架構(gòu)！Clark Bernier，我們的一個(gè)數(shù)據(jù)科學(xué)家說(shuō)：“和一群有天賦，有擔(dān)當(dāng)?shù)臄?shù)據(jù)基礎(chǔ)架構(gòu)團(tuán)隊(duì)一起工作是在Asana中作為數(shù)據(jù)科學(xué)家時(shí)最美好的一部分。我能夠?qū)Ｐ挠跀?shù)字和他們的含義中，我相信我的分析能夠如閃電般一樣飛速?！?/p>
聯(lián)系客服
