大數據是計算領域的新高地，它有望提供一種方法來應對二十一世紀不斷增長的數據生成。越來越多的大數據愛好者正在湧現，越來越多的公司正在採用各種大數據平臺，並希望提出以客戶為中心的解決方案，幫助他們在競爭激烈的市場中取得領先地位。雖然最常見的是使用大數據解決方案來推導針對業務收入的分析，但作為IT公司的開發人員，我的方法卻略有不同。

以下是Hadoop生態系統用於監控，分析和改進IT公司軟件組件的用例。

軟件基礎設施和組織

IBTech是QNB Finansbank的IT子公司，QNB Finansbank是土耳其最大的銀行之一。銀行交易在邏輯上劃分為業務模塊，如客戶，存款，現金管理，財務，貸款等。一般又分為手機、網絡、網銀、呼叫中心、ATM、分行等進入渠道。

因此，我們內部開發的CoreBanking生態系統包含一個主要的後端群集，其中所有交易都在其中進行，並且幾個前端應用程序在不同平臺上工作並使用各種框架編寫。我們的系統具有面向服務的體系結構，這意味著來自客戶端的所有請求以及後端模塊之間的所有交互都以服務的形式進行處理。

每個請求都作為服務調用進入到服務器，並在響應之前執行幾個內部服務的調用。所有服務都由內存服務總線動態調用和路由。

我們的動機

在採用Hadoop之前，我們現有的監控工具無法捕獲有關係統運行時的自定義詳細信息。我們一直在使用HP-BSM，它可以監控我們的服務入口點和各種外部層。這是一個很好的起點，但在高級分析需要更詳細或自定義的信息時會失敗。

使用傳統方法（如將數據存儲在關係數據庫或文件系統中）以及按順序讀取和分析數據的自定義實施監控和分析工具也證明是非常不可行的，尤其是當所涉及的系統每天處理超過2億筆交易時，每個交易都會觸發大約20個內部服務調用和15個SQL語句。

除了監控問題之外，由於服務調用的動態特性，我們無法正確和完全地識別從不同端點或靜態模塊依賴性發出的服務調用的可能路由和分支。相關分析將通過檢查我們現有工具生成的靜態代碼分析來完成，該工具需要大量人力資源，結果還是不完整，使任務幾乎不可能完成。

由於IT團隊包含各種角色，這些角色使用不同的技術和不同的業務領域，並且彼此互不關心，因此，對於財務部後端開發人員來說，要了解他們在移動銀行應用程序中對特定屏幕的特定服務更改的影響並不容易。當呼叫中心前端開發人員按下某個頁面上的按鈕調用某個服務時，他們也不清楚是什麼導致了性能下降。

所有這些問題促使我們使用Hadoop及其各組件監控，分析和改進軟件組件IT公司軟件組件。

實施細節

我們編寫了一個名為Milena的模塊，它收集通過我們的核心銀行服務器的所有運行時數據，並將數據發送到Kafka。我們配置了從Kafka讀取這些流的Flume代理，並將它們保存到HDFS。前一天的數據在一天結束時通過Spark批次進行分析，結果在ElasticSearch上編制索引並在我們的Kibana儀表板中可視化。我們稱這整個系統為Insights。

圖1：整個系統的概述

我們的運行時數據包括有關事務的標識信息、有關客戶機和用戶的信息、已執行的服務、已執行的SQL語句和受影響的表、返回代碼以及與每個可執行單元對應的開始和完成時間戳。

我們的OLTP服務器處理大約2億個事務，每天產生3.3 TB的數據。存儲的原始數據的一個示例是：

{
"header": {
 "aygKodu": " ",
 "transactionState": 9,
 "entranceChannelCode": "999",
 "jvmID": "999",
 "pageInstanceId": "",
 "channelTrxName": "IssueCreditTransaction",
 "processTime": "075957",
 "processState": 9,
 "channelHostProcessCode": "0",
 "processDate": "20170328",
 "correlationId": "3e03bb4f-d175-44bc-904f-072b08116d4e",
 "channelCode": "999",
 "userCode": "XXXXXXXXX",
 "transactionID": 99999999999999999999999999,
 "processType": 0,
 "environment": "XXXX",
 "sessionId": "99999999999999999999999999",
 "clientIp": "999.999.999.999"
 },
 "services": [
 {
 "returnCode": 0,
 "channelId": "999",
 "parent": 0,
 "poms": [],
 "endTime": 1490677197467,
 "platformId": "9",
 "serviceName": "CREDIT_ISSUANCE_SERVICE",
 "startTime": 1490677197466,
 "level": 1,
 "environment": "XXXX",
 "order": 1,
 "additionalInfos": {},
 "queries": [],
 "referenceData": "CREDIT_ISSUANCE_OPERATION_PARAMETERS"
 },
 (...),
 {
 "returnCode": 0,
 "channelId": "999",
 "parent": 5,
 "poms": [],
 "endTime": 1490677197491,
 "platformId": "9",
 "serviceName": "GET_CUSTOMER_INFORMATION",
 "startTime": 1490677197491,
 "level": 6,
 "environment": "XXXX",
 "order": 18,
 "additionalInfos": {},
 "queries": [
 {
 "tables": "CUSTOMER_MAIN,CUSTOMER_EXT",
 "startTime": 1490677197491,
 "order": 1,
 "queryName": "SELECT_CUSTOMER_DATA",
 "isExecuted": true,
 "parent": 18,
 "type": 1,
 "endTime": 1490677197491
 }
 ],
 "referenceData": ""
 },
 {
 "returnCode": 0,
 "channelId": "999",
 "parent": 6,
 "poms": [],
 "endTime": 1490677197467,
 "platformId": "9",
 "serviceName": "GET_PRICING_POLICY",
 "startTime": 1490677197466,
 "level": 7,
 "environment": "XXXX",
 "order": 7,
 "additionalInfos": {},
 "queries": [],
 "referenceData": ""
 },
 {
 "returnCode": 0,
 "channelId": "999",
 "parent": 5,
 "poms": [],
 "endTime": 1490677197468,
 "platformId": "9",
 "serviceName": "CALCULATE_ISSUANCE_COMMISSIONS",
 "startTime": 1490677197466,
 "level": 6,
 "environment": "XXXX",
 "order": 6,
 "additionalInfos": {},
 "queries": [],
 "referenceData": ""
 },
 (...),
 {
 "returnCode": 0,
 "channelId": "999",
 "parent": 18,
 "poms": [],
 "endTime": 1490677197491,
 "platformId": "9",
 "serviceName": "CREDIT_ISSUANCE_DOCUMENT_SERVICE",
 "startTime": 1490677197491,
 "level": 9,
 "environment": "XXXX",
 "order": 19,
 "additionalInfos": {},
 "queries": [
 {
 "tables": "ISSUANCE_MAIN,CUSTOMER_MAIN",
 "startTime": 1490677197491,
 "order": 1,
 "queryName": "SELECT_CUSTOMER_ISSUANCE_INFORMATION",
 "isExecuted": true,
 "parent": 19,
 "type": 1,
 "endTime": 1490677197491
 }
 ],
 "referenceData": ""
 },
 (...)
 ]
}

我們有各種自定義儀表板，旨在提供有關核心銀行業務應用程序的總體性能、模塊間和模塊內依賴性以及使用統計信息的見解。我們可以有效地可視化不同服務之間的關聯。這使我們能夠預見服務中的更改或中斷對其他服務和應用程序的影響。以下是一些儀表板中的一些示例，其中假設場景涉及多個參與方。

假設IT監控專家著手減少核心銀行系統的總體響應時間。他們首先檢查General-TOP信息板，以查看最耗時的交易。他們很快發現移動銀行應用程序的信用發行交易IssueCreditTransaction持續時間過長。

通用TOP儀表板，其中觀察到IssueCreditTransaction佔核心銀行總時服務器間的16

他們通知交易的所有者，移動銀行的前端開發團隊，關於這個發現的情況。團隊中的前端開發人員繼續分析這個特定事務的依賴性。

他們發現在這次交易中花費的時間有60％發生在CREDIT_ISSUANCE_SERVICE中，後者由CREDIT_ISSUANCE_DOCUMENT_SERVICE主導。因此，他們很容易找到CREDIT_ISSUANCE_DOCUMENT_SERVICE的低性能：

圖3：上述JSON中事務的依賴關係樹

最左邊的圖顯示了此事務中內部服務的調用計數。中間的圖表顯示了內部服務中經過的總時間，最大的部分是此事務響應時間的主要負擔。最右邊的圖顯示了此事務的樹結構，其中顯示了從根到葉的所有可能路徑。

移動前端開發團隊要求CREDIT_ISSUANCE_DOCUMENT_SERVICE的所有者，貸款後端開發團隊調查此問題。後端開發人員通過在Service Performance儀表板中搜索所述服務來開始檢查所述服務。該分析揭示了兩個獨立的問題，代碼中花費了大量時間，而SELECT_CUSTOMER_ISSUANCE_INFORMATION查詢代價很高。

圖4：示例JSON數據中CREDIT_ISSUANCE_DOCUMENT_SERVICE的詳細服務分

在上半部分，您可以看到此特定服務的平均持續時間，包括或排除其調用的內部服務所經過的時間。在右下圖中，顯示了此服務通過時間的層。

對於代碼的性能問題，後端開發人員在將代碼部署到生產環境之前對優化和測試請求進行了一些更改。測試人員，他們考慮到變更的服務，嘗試列出測試用例。他們查看調用樹分析，查看哪些入口點導致調用此服務，通過哪些路徑，然後繼續測試這些方案。

圖5：CREDIT_ISSUANCE_DOCUMENT_SERVICE的調用樹分析

左側的圖表說明了導致此服務的所有可能路徑，包括示例JSON中的路徑。右側的圖表顯示了達到此服務的所有可能的入口點和通道。

對於查詢的性能問題，數據架構師檢查SQL stamement，並得出應在表ISSUANCE_MAIN上創建新索引的結論。他們請求創建索引以供數據庫管理員批准。在收到為ISSUANCE_MAIN表創建新索引的請求後，DBAs意識到索引創建成本很高，並且可能導致表被鎖定一段時間。

它們通知流程管理專家在索引創建期間將受服務阻塞影響的事務，並通過觀察表的調用樹分析來相應地計劃操作。

圖6：ISSUANCE_MAIN表的調用樹分析

結果

該系統的第一階段於2016年10月投入生產，並根據客戶反饋和需求不斷擴展和改進。大約在2017年1月左右，它已經成熟到最終狀態，此後一直在頻繁使用。現在該項目是實時且穩定的，它已經大大影響了項目的生命週期。已經吸引了來自不同背景的各種角色。

開發人員和測試人員正在審查變更中受影響的組件，並確保與必要的開發和測試順利集成。

項目投入使用後，由於影響分析不充分，缺乏影響分析而導致的生產誤差大大減少。流程管理專家可以審核結果，以查看哪些特定交易會受到特定功能計劃內或計劃外中斷的影響，並相應地採取相應措施。

結論

對於一家現代科技公司來說，探索大數據以分析具體業務收入的數據至關重要。然而，不應忽視的是，一旦消除了手工和瑣碎的工作負荷，高能力的IT員工將能夠專注於他們工作中更具創新性的方面。

除此之外，軟件基礎設施是企業整個系統最低層次的核心，是是否允許系統的敏捷性、性能、靈活性和能力的關鍵組件。如果想在軟件基礎架構中正確地進行改進，並達到一定程度效果和產生更大的收入，這可以通過有效的監控和分析來實現。因此使用Hadoop或另一個大數據平臺來達成這一目標，是一個非常值得考慮的方案。

更多大數據學習資料，可以私信小編“資料”免費獲取哦~

最後，希望可以幫小編轉發並關注一下，您的轉發和關注就是對小編最大的支持與鼓勵！！！