應用性能管理（APM，全稱Application Performance Management）并不是一門新興學科，但它是大數據的一個新的最佳實踐。采用先進應用程序的方法來最大限度地利用集群資源，同時最大限度地降低基礎架構的TCO。對于架構師而言，這意味着需要設計大數據架構以滿足速度，可靠性和成本效益方面的新業務需求，并且需要與架構标準的性能，可伸縮性和可用性保持一緻。

大數據正在從實驗項目趨向成為提供一系列大型數據應用的關鍵任務數據平台。企業期待這些大數據應用（如ETL加載，商業智能BI，分析，機器學習，物聯網等）推動戰略業務價值。

随着大數據應用轉向生産，性能預期也需要到生産級别。業務需要幾秒鐘而不是幾小時的答案，硬件和資源需要不斷優化成本，并且需要保證期限/SLAs。這意味着APM需要成為大型數據架構的戰略組件，以消除與低性能，可用性和可擴展性相關的風險和成本。

根本問題在于，大型數據堆棧由于其分布式特性而變得複雜，其中基礎架構，存儲和計算分布在許多層，組件和異構技術中。無論具體體系結構如何（即傳統流式分析，Lambda，Kappa或Unified）都存在此問題。從生産大數據平台和運行它的應用的角度來看，每件事都必須像發條一樣運行：ETL作業必須以固定的時間間隔進行；用戶期望儀表闆實時更新；面向用戶的數據産品必須不斷演進。但是從底層平台的角度來看，這個應用并不是一項孤立的工作，而是一系列通過大數據棧進行處理的步驟。例如，欺詐檢測應用程序（即數據使用者）将由來自Spark SQL，Spark Streaming，HDFS，MapReduce和Kafka的許多系統鍊以及每個系統中的許多處理步驟組成。因此，跨所有這些層管理性能和利用率的整個過程呈指數級複雜。

因此，跨應用程序，系統和基礎架構規劃，實施和擴展性能和利用率的過程不是生産就緒的。這一挑戰在Gartner 2017年3月針對Hadoop的市場指南中提出。該報告指出，“将Hadoop從小規模的試點項目擴展到大規模生産集群，涉及許多企業尚未準備好的操作知識方面的加速學習曲線。”

生産準備缺乏跨越業務部門，開發人員和運營部門的多個領域。它的核心是它不可能實現一個多租戶集群模型，在這個模型中，一個小的Ops團隊需要支持大量的應用程序，業務單元和混合工作負載以及SLA綁定作業的組合。數據發現。最終會影響大數據和業務價值實現的采用。

架構師應該發揮關鍵作用，确保大數據平台的設計用于生産。架構師可以确保大數據平台能夠在時間和預算限制内滿足業務需求，并确保架構随着時間的推移而适應新的業務需求。以下架構師的清單可用于規劃，操作和擴展大型數據平台，以管理性能，利用率和成本：

• 試圖構建和部署的應用程序的類型是什麼？

• 應用程序是SLA綁定的還是臨時的？如何優化成本效益的工作量？

• 哪些系統最适合應用程序（例如Spark，Hadoop，Kafka等）？

• 哪種架構方法最适合（例如，Lambda等）？集群是内部部署，雲中還是混合部署？

• 有多少并發用戶需要在同一集群上運行而不會耗盡資源？24小時内需要在同一群集上運行多少個應用程序？吞吐量将如何優化？

• 存儲應該如何分層？

• 集群需要多少個節點？需要哪些基礎架構來确保可擴展性，低延遲和性能，包括計算存儲和網絡功能？

• 需要制定哪些數據治理政策？

• 開發，QA和生産将如何開展？

• 集群需要多少成本才能運行？該業務将如何收回？

運營階段可以分為4個階段。分階段的方法有助于逐步形成和擴展大數據應用的成功實施和投資回報。

對于每個階段，應用以下一組關鍵問題：

• 什麼是應用的SLA？他們如何得到保證？

• 什麼是應用的延遲目标？他們将如何得到滿足？

• Ops如何能夠支持多租戶群中的業務部門和用戶？它将如何以自助服務的方式監控應用程序？Ops如何解決問題？

• 用戶通常何時登錄和注銷？多久？

• 不同的用戶群體的行為有所不同嗎？用戶活動情況如何随時間變化？

• 如何跟蹤多租戶群集中的成本？我如何将它們分配給項目，業務單位，用戶，應用程序等？

• 數據治理策略将如何實施？

大數據很難。有了這麼多新技術和新興層面，大數據棧非常複雜。處理這種複雜性的唯一方法是采用以應用為中心的方法。但單靠這種方法還不夠，因為很難對應用的性能進行清晰而一緻的了解。那麼，APM就是答案了。

要正确推出APM，需要進行徹底規劃。一旦你完成了上述清單，你将準備好執行APM以獲得更大的投資回報。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!