資料倉儲的 ETL 元件通常被倉儲本身所掩蓋，並且比主資料庫或前端元件、BI 和報告受到較少的關注。 同時，從資料填入倉庫的機制來看，ETL起著關鍵作用，需要管理員的注意力並不比其他元件少。 我叫 Alexander，現在在 Rostelecom 管理 ETL，在本文中，我將嘗試分享 Rostelecom 大型資料倉儲中最著名的 ETL 系統之一的管理員必須處理的一些問題。
如果親愛的讀者已經大致熟悉我們的資料倉儲專案和 Informatica PowerCenter 產品，那麼您可以立即進入下一部分。
幾年前，單一企業資料倉儲的想法已經成熟，並開始在 Rostelecom 實施。 許多解決個別問題的儲存庫已經創建，但場景數量增加，支援成本也增加，很明顯，未來在於集中化。 從架構上來說，這就是儲存本身，由幾個層組成，在 Hadoop 和 GreenPlum、輔助資料庫、ETL 機制和 BI 上實作。
同時，由於資料來源數量眾多、分佈廣泛、異質，因此創建了專門的資料上傳機制，其運作由Informatica控制。 結果，資料包最終到達Hadoop介面區域，之後開始透過儲存層、Hadoop和GreenPlum載入資料的過程，並由Informatica中實現的所謂ETL控制機制進行管理。 因此，Informatica系統是保證倉庫運作的關鍵要素之一。
我們的存儲將在以下一篇文章中更詳細地描述。
Informatica PowerCenter/大數據管理目前被認為是資料整合工具領域的領先軟體。 這是美國公司Informatica的產品，該公司是ETL（提取轉換載入）、資料品質管理、MDM（主資料管理）、ILM（資訊生命週期管理）等領域最強的參與者之一。
我們使用的 PowerCenter 是一個整合的 Tomcat 應用程式伺服器，Informatica 應用程式本身在其中運行，實現其服務：
域事實上，這是其他一切的基礎；服務、使用者和 GRID 元件在網域內運作。
管理員控制台，一個基於 Web 的管理和監控工具，除了 Informatica Developer 用戶端之外，也是與產品互動的主要工具
MRS，模型儲存庫服務元資料儲存庫是實體儲存元資料的資料庫與進行開發的 Informatica Developer 用戶端之間的一層。 儲存庫儲存資料描述和其他信息，包括許多其他 Infromatica 服務的信息，例如運行任務的計劃 (Schedules) 或監控數據，以及應用程式參數，特別是允許使用相同的應用程式來處理各種資料來源和接收器。
DIS，資料整合服務，這是一項服務，其中發生主要功能流程、在其中運行應用程式以及實際啟動工作流程（映射序列及其交互的描述）和映射（轉換、轉換本身發生的區塊、資料處理） ） 發生。
網格配置 – 本質上，當 DIS 啟動的負載分佈在節點（即屬於網域的一部分的伺服器）之間時，使用多個伺服器建立綜合體的選項。 在此選項的情況下，除了透過聯合多個節點的附加GRID 抽象層來分配DIS 中的負載（DIS 在其上運行而不是在特定的單一節點上工作）之外，還可以建立附加的備份MRS實例。 您甚至可以實現高可用性，如果主節點發生故障，可以透過備份節點進行外部呼叫。 我們暫時放棄了這種建設選擇。
Informatica PowerCenter，示意圖
作為資料供應鏈的一部分，在工作的早期階段，經常會出現問題，其中一些問題是由於當時Informatica的運作不穩定所造成的。 我將分享這個傳奇故事中的一些難忘時刻 - 掌握 Informatica 10。
前 Informatica 標誌
我們的職責範圍還包括其他 Informatica 環境，它們由於不同的負載而有自己的具體情況，但現在我會準確地記住 Informatica 如何作為資料倉儲本身的 ETL 元件進行開發。
這怎麼發生的
2016 年，當我們開始負責 Informatica 的工作時，它已經達到了 10.0 版本，對於決定在嚴肅的解決方案中使用小版本 .0 的產品的樂觀同事來說，一切似乎都是顯而易見的 - 我們需要使用新版本！ 從硬體資源來看，當時一切都很好。
自2016年春季以來，一名承包商一直負責Informatica的工作，據該系統的少數用戶稱，「它每週工作幾次」。 這裡有必要澄清的是，該儲存庫實際上處於PoC階段，團隊中沒有管理員，系統因各種原因不斷崩潰，之後承包商的工程師又重新拾起它。
秋天，三名管理員加入了團隊，劃分了各自的職責範圍，開始正常工作，組織專案中系統的運行，包括Informatica。 另外，必須說這個產品並不普及，並且有一個很大的社區，您可以在其中找到任何問題的答案並解決任何問題。 因此，來自俄羅斯合作夥伴 Informatica 的全面技術支援非常重要，在它的幫助下，我們糾正了當時年輕的 Informatica 10 的所有錯誤和錯誤。
我們必須為我們團隊的開發人員和承包商做的第一件事是穩定Informatica本身的工作，以確保Web管理控制台（Informatica Administrator）的功能。
這就是我們經常見到 Informatica 開發人員的方式
拋開查找原因的過程不談，從網路環境的角度來看，崩潰的主要原因是Informatica軟體與儲存庫資料庫的交互模式，該資料庫位於相對遠端的伺服器上。 這導致了延遲並破壞了監視 Informatica 域狀態的機制。 經過對資料庫進行一些調優，更改了Informatica的參數，使其對資料庫延遲的容忍度更高，最終將Informatica版本更新到10.1，並將資料庫從先前的伺服器轉移到距離Informatica較近的伺服器上，問題就消失了。相關性，從那時起就出現了我們沒有觀察到的此類崩潰。
讓 Informatica Monitor 正常運作的嘗試之一
管理控制台的情況也很嚴峻。 由於積極的開發是直接在相對高效的環境中進行的，因此同事們不斷需要「隨時隨地」分析映射和工作流程的工作。 在新的Informatica中，資料整合服務沒有單獨的工具來進行此類監控，但管理Web控制台中出現了監控部分（Informatica Administrator Monitor），您可以在其中監控應用程式、工作流程和映射的運作情況，啟動、日誌。 控制台會定期變得完全不可用，或者有關 DIS 中當前進程的資訊停止更新，或者在載入頁面時發生錯誤。
java參數選擇以穩定性能
透過多種方式修正了問題，進行了更改參數的實驗，收集了日誌和jstack並發送給支援人員，同時進行了積極的谷歌搜尋和簡單的觀察。
首先，創建了一個單獨的 MRS 來進行監控；後來發現，這是我們環境中資源的主要消耗者之一，因為映射的啟動非常密集。 有關 java 堆和許多其他參數的參數已更改。
結果，到了下次更新Informatica 10.1.1，控制台和監視器的操作變得穩定，開發人員開始更有效率地工作，常規流程也變得越來越規律。
開發和管理之間的互動體驗可能會很有趣。 在使用複雜系統時，整體了解事物如何運作、可以做什麼和不能做什麼始終很重要。 因此，我們可以安全地建議您先培訓管理團隊如何管理軟體，培訓開發團隊如何在系統中編寫程式碼和繪製流程，然後才派第一和第二人處理結果。 當時間不是無限的資源時，這一點非常重要。 許多問題甚至可以透過隨機搜尋選項來解決，但有時有些問題需要先驗知識 - 我們的案例證實了理解這一公理的重要性。
例如，當我們嘗試在MRS中啟用版本控制時（最終結果需要使用不同版本的SVN），一段時間後我們驚恐地發現系統重啟時間增加到了幾十分鐘。 找到啟動延遲的原因並停用版本控制後，我們再次做得很好。
與 Informatica 相關的顯著障礙包括與不斷增長的 Java 線程的激烈鬥爭。 在某些時候，複製的時機已經到來，即將建立的流程擴展到大量來源系統。 事實證明，並非 10.1.1 中的所有進程都運作良好，一段時間後 DIS 變得無法運作。 檢測到數以萬計的線程，其數量在應用程式部署過程中增長尤其明顯。 有時我必須每天重新啟動幾次才能恢復功能。
在這裡我們要感謝大家的支持；使用EBF（Emergency Bug Fix）相對較快地定位並修復了問題——之後，每個人都感覺到這個工具確實有效。
它仍然有效！
當我們開始在目標模式下工作時，Informatica 看起來像這樣。 Informatica 10.1.1HF1 版本（HF1 是HotFix1，來自EBF 複合體的供應商組件），另外安裝了EBF，它解決了我們在GRID 的三台伺服器中的一台（20 個x86_64 核心）上的擴充問題和其他一些問題和存儲，在一個巨大的慢速本地磁碟陣列上——這是 Hadoop 叢集的伺服器配置。 在另一個類似的伺服器上 - Oracle DBMS，Informatica 網域和 ETL 控制機制都與該伺服器一起工作。 所有這些都由雙方團隊（Zabbix + Grafana）使用的標準監控工具進行監控 - Informatica 本身及其服務以及其中的加載流程。 現在，在不考慮外部因素的情況下，效能和穩定性都取決於限制負載的設定。
另外，我們可以談談GRID。 該環境建構在三個節點上，具有負載平衡的可能性。 然而，在測試過程中發現，由於我們應用程式運行實例之間的交互問題，這種配置並沒有按預期工作，因此他們決定暫時放棄這種構建方案，從域中刪除三個節點中的兩個。 同時，方案本身保持不變，現在它準確地說是一種GRID服務，但退化為一個節點。
目前，困難仍然在於定期清理監控電路時效能下降——在 CNN 中同時進行進程和運行清理的情況下，ETL 控制機制的操作可能會發生故障。 目前，這個問題正在「作為拐杖」解決——透過手動清除監控電路，同時丟失所有先前的數據。 在正常的日常操作期間，這對生產力來說並不是太重要，但目前正在尋找正常的解決方案。
另一個問題源自於同樣的情況 - 有時我們的控制機制會發生多次啟動。
多個應用程式啟動導致機制故障
當按計劃運作時，在系統負載較重時，有時會出現導致機制崩潰的情況。 該問題仍在手動修復，並正在尋求永久解決方案。
總的來說，我們可以總結一下，當負載很重時，提供足夠的資源是非常重要的，這對於Informatica本身的硬體資源也是如此，對於它的資料庫儲存庫也是如此，以及提供最佳化的設定對於他們來說。 此外，關於哪種資料庫放置方案更好 - 在單獨的主機上還是在運行 Informatica 軟體的同一主機上，這個問題仍然存在。 一方面，在一台伺服器上會更便宜，並且組合使用時，實際上可以消除網路互動可能出現的問題；另一方面，資料庫在主機上的負載由來自 Informatica 的負載補充。
與任何嚴肅的產品一樣，Informatica 也有有趣的時刻。
有一次，在處理某種事故時，我注意到 MRS 日誌奇怪地顯示了事件發生的時間。
MRS 日誌中的時間二元性“有意為之”
原來，時間戳記是以12小時格式書寫的，沒有指定AM/PM，即中午之前或中午之後。 甚至就此事提出了申請，並收到了官方答复 - 這就是它的意圖，標記以完全相同的格式寫入 MRS 日誌中。 也就是說，有時對於某些錯誤發生的時間仍然存在一些疑問...
力爭做到最好
如今，Informatica 是一個相當穩定的工具，對於管理員和使用者來說很方便，就其當前的功能和潛力而言非常強大。 它超出了我們的功能需求很多倍，事實上現在正在專案中以一種不是最典型和典型的方式使用。 困難部分與機制的工作方式有關——具體是在短時間內啟動大量線程，集中更新參數並與存儲庫數據庫一起工作，而伺服器硬體資源幾乎被完全利用由CPU。
我們現在即將遷移到 Informatica 10.2.1 或 10.2.2，它們重新設計了一些內部機制和支援承諾，以消除我們目前遇到的一些效能和功能問題。 從硬體的角度來看，考慮到由於儲存的成長和發展而為不久的將來儲備的情況，我們期望伺服器具有最佳配置。
當然，HA GRID 部分還會有測試、相容性檢查以及可能的架構變更。 Informatica 內部的開發將繼續進行，因為短期內我們無法提供任何東西來取代這個系統。
而未來負責這個系統的人一定能夠使其達到客戶提出的所需的可靠性和性能指標。
本文由 Rostelecom 資料管理團隊撰寫
目前的 Informatica 標誌
來源： www.habr.com