注：本文英文原文在google開發者工具組的博客上[需要FQ],以下是我的翻譯，歡迎轉載，但請尊重作者版權，注名原文地址。
之前的文章，介紹了Google在分布式構建軟件過程中，如何把構建過程分發到許多台機器上並復用之前構建的結果來大幅度提高構建的速度。這種分發和復用會凸顯出性能瓶頸。尤其是一個大工程的一次完整構建會產出幾個G的輸出文件，所有的這些文件都需要從雲端傳回到開發者的機器上。這加重了網絡和開發者本地硬盤的負擔，延遲和有限的帶寬會拖慢構建的速度。
而且，開發者通常不需要訪問一次構建的所有的輸出。她可能只關心構建結果中最后的可執行文件，而一點也不關心中間的對象文件。另外一個例子是當開發者使用分布式構建系統來在雲上構建並執行測試。這種情況下，她不需要訪問構建的結果，只需要簡單的知道測試是通過了還是失敗了就足夠了。所以每次都把構建結果從雲端拉回到開發者本地機器是沒必要而且也是非常浪費的。相反，僅僅把開發者需要使用的構建結果拉回本地即可。
為了解決這個性能瓶頸，我們的分布式構建系統把所有的構建輸出結果都寫入到一個持久化，分布式的存儲系統里。這個存儲系統處理持續的讀寫請求的速度，相比本地磁盤而言要快好幾倍。分布式構建系統與這個存儲系統之間的網絡連接比跟本地磁盤相比，帶寬更大，延遲更小。構建結果通過內容指紋, 來提供簡單的機制去索引和檢索文件的。（這個雲端的存儲系統也在分布式構建系統中扮演第二級緩存的角色，當構建結果沒有命中第一級緩存時，這個雲端的存儲系統可以提升性能）。在雲上使用這個分布式存儲系統，我們可以讓構建的速度比構建系統直接在開發者本地磁盤上存儲構建結果要快至少2倍。
使用基於雲的存儲來存儲構建結果可以顯著的提高構建速度，剩下的挑戰是仍然能夠讓開發者的本地機器在構建完成后，可以按需訪問這些輸出結果。我們通過編寫的一個定制的文件系統來提供構建結果的視圖。像我們第一篇文章所描述的那樣，用戶空間文件系統(FUSE)內核模塊提供了方便的方法來使用一個用戶空間的守護進程來實現這樣一個文件系統。隨着各個構建步驟的完成，分布式構建系統通知守護進程新的構建結果產出了，同時提供文件的相對路徑和內容的指紋。這樣，當開發人員訪問這些路徑下的某個文件，守護進程會從雲上把文件下載下來，使用內容指紋作為鍵，然后通過用戶空間文件系統(FUSE)來提供給開發人員(通過在開發人員的機器上緩存下載下來的文件來加快后續訪問的速度)。內容指紋本身是作為用戶空間文件系統(FUSE)的一個擴展屬性來存儲的，這樣構建系統就能夠輕松獲得內容指紋了，正如我們在第二篇文章里所介紹的那樣，這是構建系統執行增量構建的必要條件。
本地守護進程除了通過雲存儲來獲得構建結果，從本地構建輸出的元數據，還執行了很多額外的重要工作來保證系統正常工作。例如，輸出結果只要有一台開發者的本地機器引用了，就會一直保存在雲上。守護進程周期性地為開發者機器上的所有構建的構建結果進行續約。另外一個例子，如果順序地獲取開發者想訪問的巨大的構建結果，虛擬文件系統的性能會很差。相反，守護進程會並發地從雲上的多個存儲服務那里下載文件塊。守護進程也需要負責本地數據的完整性校驗，本地磁盤管理和緩存更新以及其他維護性任務。
下面的這張圖總結了Google的構建系統[譯者注：就是Blaze系統]整體是如何工作的，包含了本系列四篇博客中的內容。
開發人員在自己的工作站上調用構建系統的客戶端，指定一個或多個要構建的目標。客戶端協調並分發獨立的構建行為到雲端去執行，通過用戶空間文件系統(FUSE)的守護進程來讀取所需的源代碼的元數據，作為雲端執行系統的輸入。這些行為的構建結果（例如可執行文件）會存儲到雲端存儲系統，用戶通過用戶空間文件系統(FUSE)來按需下載。所有這些構成了一個能夠把構建結果在數秒之后而不是幾個小時之后就呈現給開發的構建系統。