原文：
https://issues.apache.org/jira/secure/attachment/12559939/Ambari_Architecture.pdf

此文為陸軒完成第一版翻譯，我負責校正。

設計目標

平臺獨立性

該系統在架構上必須完全支援適合硬體和作業系統，如RHEL，SLES，Ubuntu，Winduws等，該平臺上的元件擁有著良好的可插拔介面，這些元件有yum，rpm等。

可插拔的元件

架構不能假定特定的工具和技術。任何特定的工具和技術必須通過可插拔元件封裝。該架構將聚焦在可插拔特性，重點在Puppet和相關的元件，配置工具的選擇，以及儲存狀態的資料庫。我們的目標不是立即替代Puppet，而是要使該架構在未來能容易的這樣做。

可插拔的目標不包括元件之間的協議，或者介面和元件之間的第三方工作實現規範。

版本管理與升級

Anbari元件在不同節點上的執行必須支援多個版本元件獨立升級的協議，Ambari任何元件的升級都不會影響到叢集的狀態。

可擴充套件性

該設計會支援對新的服務、元件和API的簡單新增。可擴充套件性也意味著可以輕鬆的修改Hadoop生態的任何配置或配置步驟。同時，要考慮對HDP之外的Hdoop生態支援的可能性。

故障恢復

系統必須能夠從任何元件故障恢復到一致狀態。完成恢復後，系統會嘗試的掛起操作。如果某些錯誤是不可恢復的，失敗仍應保持系統處於一致的狀態。

安全

安全：
（1）認證和基於角色的授權（Ambari使用者API和Web UI）; （2）通過Kerberos監測Hadoop堆疊的安裝，管理和監控;
（3）在Ambari元件之間的有線通訊的加密和驗證（例如，Ambari主代理通訊）。

錯誤跟蹤

設計力求簡化跟蹤失敗的過程。故障應傳播給使用者足夠的細節和指標進行分析。

在操作中的實時過程反饋

對於需要花一段時間完成的操作，系統需要能夠及時地提供使用者反饋（關於當前執行的任務、操作完成的百分比、操作日誌的引用等）的中間進度（接近實時）。Ambari在以前的版本中，由於Puppet的主代理體系結構和狀態報告機制而不可用。

未完待續。