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