資料是創立asana的核心部分，并且每一個團隊都依賴他們自己的方式。我們的負責增長的團隊依靠事件資料來分析試驗結果（對比試驗）。 我們做很多快速的實驗--通常會有很多實驗一起跑-- 讓這些互相影響的作用和其他關鍵度量引導我們需要放棄什麼和投入什麼 項目經理，設計師和産品工程師通過分析使用資料來發現不可避免的妥協，比如簡潔性對強大性。
通過這種方法，我們可以知道什麼樣的新産品方向能夠釋放出最多的潛力。市場部門需要明确在他們的競争力中的哪個部分能夠驅使新使用者到asana。财會部門需要非常可靠的關于總體增長模式的統計資料來幫助asana确認能持續發展到2064年。你是怎樣建造一個支援所有這些多樣需求的系統呢 ？
（asana 資料基礎架構）
從小開始，逐漸增長
上圖并不是我們一開始就建立的系統。我們從一個十分簡單的系統開始，也就是一些python腳本和mysql資料庫，它們全都運作在一個機器上。剛開始的時候，一個簡潔的系統能夠減少系統維護，并且如果還沒有任何使用者，或許你就可以從這裡開始。但是，從2011開始，asana的增長就一直穩定（看下面的圖）。然後我們就開始碰到一些限制。最近，針對資料基礎架構，我們做了一系列的變化。所有的一切都證明是很有價值的。
往監控，測試和自動化上投資來減少救火的次數 從mysql遷移到redshift，得到一個可擴充的資料倉庫 從本地的日志處理遷移到基于hadoop的可擴充的日志處理 引進商業智庫工具來允許非專家來回答他們自己的資料問題 asana随着時間變化時的“時間”數量圖。按照原始資料量做機關
結束無休止的問題
一年前，我們遇到了一些關于資料處理健壯性的問題。當圖表中有個重要的變化，人們立馬會質疑資料的整體性。把問題和有趣的想法區分開來是很難的。資料科學已經是一門藝術，是以你需要基礎架構來給你提出的問題一個信得過的答案。然而，99%的準确性還是不夠好。在資料基礎架構小組那裡，我們花費了太多時間鼓搗非常緊急的問題，而且這點使得我們沒法取得更長期的發展。這太痛苦了。
受到啟發
當壞的事情發生後，我們會采取“5個為什麼”的方法來發現問題的原因和解決這個問題。比如，我們曾經讓一個資料處理腳本錯誤地生成了一個超級大的日志檔案，它太大了，以至于我們無法用電子郵件發送。作為解決方案，我們在發生日志檔案前就開始把日志檔案分割成小段，并且在發送郵件錯誤的時候發送警告資訊和在腳本輸出結果上增加監控。在其他的一些我們還沒有辦法洞悉原因的例子裡，我們就增加日志，檢測和預警。例如，我們的實驗總是經常性的落後，是以我們在不同的處理階段增加更廣泛的日志記錄來看看哪裡花費了最多的時間，并且用來訓示什麼部分需要優化。
當我們的監控和日志記錄不夠的時候，最壞的事情持續了好幾個月。一個比較極端的例子就是，我們的一個工具花費了比其應花費時間多很多的時間。一段時間後，我們發現了一些查詢被傳遞進了一個不知道為什麼我們也沒搞懂的、含有有特殊時區資訊的時間類。這些查詢顯著地增加了查詢時間。由于這個任務花費了一天多的時間來完成，是以第二天的任務才能接着開始，然而這導緻了mysql鎖過期。當生成圖像的時候，這些任務就沒法取得所有需要的資料。我們隐藏了零數值，并且必須要每次人工地做很多工作去清理。錯誤總是導緻更多的錯誤，是以打更新檔也沒有用。最終，這個事件使得我們真正要去把測試的優先級提到最高。
一年前，我們的資料基礎架構的代碼上面幾乎就沒有任何測試。然而我們還不能滿足我們目前的測試覆寫率，但是我們已經做了很多改進。當你得到一個失敗的測試結果并且你意識到這個本可能出問題的部分使得你改變了産品的一些代碼。這樣的感覺好極了。雖然我們一直在探索節點增加的特性，我們還是使用python内置的單元測試子產品。我們把努力的方向放在為數不多的，特别是在那些我們能夠建立自己的架構代碼的領域，進而使得我們的資料科學家和其他的資料使用者能夠寫出他們自己的測試。
自動化測試
原來我們用cron來運作所有的事情。任務會在不同的時間段運作，我們期望某些任務在另外一些依賴它們的任務開始前完成。但是事情不總是這樣。比如，一個任務運作失敗，那就需要很多人為的清理。接着，我們開始使用luigi 來建立一個管道。這個管道懂得依賴性，就像你看到的下圖中我們的管道的一小部分示例。通過luigi，當一個任務運作失敗，我們會得到告警，而且所有依靠它的任務都不會運作，直到我們修複那個運作失敗的問題。隻需要恢複管道并且讓未完成的任務繼續，這樣就簡單多了。這個也是我們并行化這些任務的第一步。
我們的過去的預警方式很粗糙簡陋。我們有顯而易見的比如關于可用的硬碟空間的預警，但是這個花費很多思考和努力來克服困難進而得到我們今天擁有的一切。現在，我們覆寫了所有的系統警告，從記憶體和cpu使用率到redshift叢集上長時間的高負載。我們監控我們資料管道的變化，當時間花費超出預期或者一些任務沒有能夠在我們期望的時間内完成時就發出預警。我們監控資料本身，保證重要的變量都是非零的，并且用回歸分析來提示一個事件出現多于或者少于在過去的幾個星期中我們看到的次數。
（用luigi畫的我們資料的etl 管道）
我們改進關于優先處理郵件警示的過程。我們十分重度地依賴asana，它工作十分良好，特别是在分擔責任和當資料會出現預知的錯誤時通知使用者。
（原文此處的will應該為with）有了這些努力，問題逐漸變得少了。一旦不再花費時間讓已有的資料基礎架構發生癱瘓，我們就有時間來建造未來。
我們的資料基礎架構的最新發展如下：
擴充的資料倉庫 (redshift)
最初，我們使用mysql資料庫作為資料倉庫，因為我們的工程師擅長優化這個資料庫。但是，因為mysql是基于行記錄的，是以它不适合在非常大的資料集合上運作包含複雜連結操作的聚集查詢。當我們遇到了性能問題，我們修改索引。當我們還遇到更多的性能問題，我們在mysql之上建立一個定制的、面向直方圖的查詢緩沖層。
依舊，每一處優化隻能幫助我們走得這麼遠，并且我們并不想把我們的寶貴的工程師資源花在建立分析資料庫上。很多公司都宣稱redshift幫助他們很好的提速。是以我們也打算試一試。結果太好了。在最極端的情況下，一個日常的查詢在mysql上需要6個小時，但是在redshift上，隻需要幾秒鐘，而且不需要任何修改。
一個在mysql上需要花費數分鐘的查詢，但在redshift隻需要1秒鐘。
遷移的過程
遷移到redshfit可不是一個小事情。我們已存在的資料管道是适合于mysql的計劃而建造的。并且每一個人都很熟悉這個特點。我們努力抽象出redshift的特性。比如，通過亞馬遜的s3加載資料和依據主鍵合成資料到一個已有的表格。缺少對于主鍵的支援是意料之外的最大缺點。然後遷移我們已存在的資料管道的樂趣就開始了。複雜的依賴性意味着我們必須小心地按照正确的順序遷移寫入。有時，當我們遷移從mysql的一個表格到redshift的所有查詢時，我們必須同時寫入到mysql和redshift。最困難的部分是協調部門之間的努力去遷移數量巨大的、互相依賴的mysql查詢語句。而且其中的一些隻被很少的一部分人了解和使用。我們從資料科學家和商業團隊中得到了關于他們最棘手的部分的有價值的回報。繼而，我們使得他們的工作變得更愉快。
解鎖新的分析
然而我們選擇redshift時的主要目的是解決性能和可擴充性的問題，不過它順便也改進了可通路性。這點來得有點間接和意外。在遷移到redshift的同時，我們也在探尋商業智能工具。我們評估了一些工具，本來最喜歡looker，而且決定嘗試一下。不幸的是，當我們把它和mysql連在一起時的分析結果太慢了，以至于我們沒法推薦給我們的商業團隊。把looker和redshift連結後，性能從需要數分鐘變得足以實時地在絕大多數查詢上循環。這個組合太強大了，以至于我們的商業團隊自己就決定用它了。
我們絕大多數的商業團隊就憑他們自己，其中有些成員甚至連sql查詢不熟悉，也能夠玩資料。更好的是，他們能夠在不需要資料基礎架構小組的支援下做到這點。他們的團隊負責人說：“這個就仿佛我把1995年自動擋的吉普牧馬人換成了法拉利一樣爽… 有快又有樂趣！”
進一步地擴充
redshift還提供了工具用來限制給單獨的程序和程式的資源。我們非常依靠這些功能來防止某些個人把資料庫獨占，進而别人無法使用。通過增加機器的數量，然後按一些按鈕我們就能在半個小時内加速和增加存儲量。在将來，我們還可能自動化這個過程。
可擴充的日志處理 (彈性 mapreduce)
我們日常的資料處理延遲變得很長，但是我們努力保持處理時間在24小時内。雖然redshift起了很大的幫助，但是我們也需要擴充日志處理部分。我們決定采用這個行業的長期标準 hadoop mapreduce。除了容易變得可擴充的，這也是一個更容易的資料處理方式。和建造易使用架構的努力一起，這個使得更多的每天工作不是寫代碼的同僚也能夠把日志處理成有用的模式。是以，這個既是一個大的擴充性項目也是一個易用性的項目。
我們在yelp的映射歸納任務架構(mrjob)的基礎上建立我們的系統。因為我們都知道python很好，而且在靈活的mapreduce上開始跑任務也比較容易。我們知道這個明顯地比java和流慢一些，但是那個層次的性能還不重要到讓我們降低易用性。我們在設計基礎架構的時候就好像知道在将來我們會把mrjob換到到其他的一些東西。
當我們開始用mapreduce的時候，我們仍舊同時寫入mysql和redshift中。起初，這個讓我們同時從hadoop叢集上加載資料到兩個資料庫中。但是這個并不好使，因為大多數的叢集會空閑很長的時間，而有時我們就很容易地碰到過期。是以我們提倡放棄mysql，而在叢集之外，移動資料到redshift。亞馬遜的彈性mapreduce可以存儲輸出到s3。我們利用這個來存儲資料，并且加載它到redshift上來作為一個來自單獨的伺服器的任務。
目前，我們用一個八個節點的叢集，這個給我們4到6倍的性能提升。當我們負責增長的團隊要增加三倍的運作任務的時候，我們隻需要增加hadoop叢集的大小或者增加更多的叢集。我們運作在亞馬遜彈性mapreduce上，就使得這樣做變得更容易。可擴充性還間接地幫助了易用性。因為不用擔心他們的代碼變得很慢和對資料管道有負面的影響，我們的商業團隊在增加更多的資料處理上變得舒服很多。
商業智能工具 (interana and looker)
當調研商業智庫工具的時候，有人介紹interana。一個基于互動事件的、處理原生日志檔案的分析解決方案。然而，這個并不是我們一開始需求的東西。我們集合我們的資料後發現它可以滿足一個之前并沒有預料到的需求：超快循環分析原生日志。我們就成為他們的最初的幾個使用者之一。在早期的産品設計裡，我們和他們反複交流，使得他們實作了很多我們的性能需求。這逐漸地成為我們産品團隊資料分析中的一個內建部分。同時，looker繼續成為我們商業團隊的一個重要的補充。我們的團隊需要及時分析某幾個時間點上資料的狀态。
我們能夠在幾秒鐘内處理十億數量級的資料點。進而展現出很多我們的資料中深層次的資料分析，這在以前不可能的。任何查詢資料模式的人都能夠很快地切割資料來發現根本原因并且擁有我們全部的資料集的通路權來快速地在區塊中篩查。這允許他們探索我們的使用者怎樣使用這個産品，從通過群組來做簡單的事件計數到複雜的對話和漏鬥分析。現在，我們很少寫專門的腳本來扒下建立特殊聚集的日志。我們開始用interana來分析性能日志。團隊成員說：“一旦當interana加入到我們的資料處理管道中，查找和解決回歸分析的效率就提高了一個數量級。”
一些looker擅長的例子： 查詢金融和收入資料；多種方式分切收入來了解增長的趨勢 視覺化随着時間流逝的群效應（見截圖右側部分） 資料堆砌；所有滿足一個标準的客戶，等等。
（looker幫助我們檢視大次元模組化在時間軸上的群效應）
一些interana 擅長的事情： 互動的漏鬥分析 視覺化使用者行為，導緻新能問題（截圖中的右邊部分） 了解長期使用這個應用的使用者會做什麼操作 interana使我們能夠找出在asana中最慢的一些共同的行為
接下來
除了這些大項目，我們加強了一切，進而使得同僚不會輕易的不小心弄癱瘓裝置。justin krause，我們的商業智庫負責人說：“我們的工作生活變得非常好了，我幾乎不會弄壞任何東西了。” 大多數星期裡，我們隻用半個小時的時間來維護基礎裝置。我們喜歡我們現在的狀态，但是這個僅僅是漫長旅行中的一點。伴随增長，新的功能，新的生意需求，我們管道中的很多部分在将來的歲月中都會變得過時。我們知道事物總是會出現新的、有趣的錯誤，是以我們也增加測試和監控，以謀求在發生前發現大部分情況。我們還留意在資料分析領域中，哪個新系統變得流行，我們就會做出相應的對策。
我們認為會在下面幾點探索一下： 加入hive，在redshift之上增加一些東西，或者在interana的能力範圍之外用另外一個系統來做原始的日志查詢。 流資料分析的系統 比mrjob更快的hadoop，或者可能用像spark一樣的東西來做記憶體中的mapreduce 更好的異常探測和趨勢預警 限制單點缺陷
如果你對在快速變化的環境下建立資料基礎架構有很好的想法，請加入我們下一階段的旅行吧。如果你想分析大資料和學習各個組之間怎樣工作，就以一個資料科學家的身份來用這個基礎架構！clark bernier，我們的一個資料科學家說：“和一群有天賦，有擔當的資料基礎架構團隊一起工作是在asana中作為資料科學家時最美好的一部分。我能夠專心于數字和他們的含義中，我相信我的分析能夠如閃電般一樣飛速。”
來源：董老師在矽谷 知乎專欄
原作者：marco gallotta
譯者： liang yu
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-04-04</b>