日常の事故から安定性まで: 管理者の目から見た Informatica 10

データ ウェアハウスの ETL コンポーネントはウェアハウス自体の影に隠れがちで、メインのデータベースやフロントエンド コンポーネント、BI、レポートほど注目されていません。同時に、ウェアハウスにデータを充填するメカニズムの観点からは、ETL は重要な役割を果たしており、管理者は他のコンポーネントと同様に注意を払う必要があります。私の名前はアレクサンダーです。現在、ロステレコムで ETL を管理しています。この記事では、ロステレコムの大規模なデータ ウェアハウスにある最も有名な ETL システムの 1 つの管理者が対処しなければならないことについて少し共有したいと思います。

読者の皆様が、当社のデータ ウェアハウス プロジェクトと Informatica PowerCenter 製品についてすでによくご存じであれば、すぐに次のセクションに進んでいただいて構いません。

数年前、単一の企業データ ウェアハウスのアイデアが成熟し、Rostelecom で実装され始めました。個別の問題を解決するリポジトリはすでに多数作成されていましたが、シナリオの数が増加し、サポートコストも増加し、将来は集中化にあることが明らかになりました。アーキテクチャ的には、これはストレージ自体であり、Hadoop と GreenPlum、補助データベース、ETL メカニズム、および BI に実装されたいくつかのレイヤーで構成されます。

同時に、地理的に分散した異種データ ソースが多数存在するため、特別なデータ アップロード メカニズムが作成され、その操作は Informatica によって制御されました。その結果、データ パッケージは最終的に Hadoop インターフェイス領域に置かれ、その後、ストレージ レイヤー、Hadoop および GreenPlum を介してデータをロードするプロセスが開始され、それらは Informatica に実装されたいわゆる ETL 制御メカニズムによって管理されます。したがって、Informatica システムは、倉庫の運用を保証する重要な要素の 1 つです。

私たちのストレージについては、次のいずれかの投稿で詳しく説明します。

Informatica PowerCenter/Big Data Management は現在、データ統合ツールの分野で主要なソフトウェアとみなされています。これは、ETL (Extract Transform Load)、データ品質管理、MDM (Master Data Management)、ILM (Information Lifecycle Management) などの分野で最強のプレーヤーの 1 つである米国の Informatica 社の製品です。

私たちが使用する PowerCenter は、Informatica アプリケーション自体が実行され、そのサービスを実装する統合 Tomcat アプリケーション サーバーです。

ドメイン実際、これは他のすべての基礎であり、サービス、ユーザー、および GRID コンポーネントはドメイン内で動作します。

管理者コンソール、製品と対話するための主要なツールである Informatica Developer クライアントに加えて、Web ベースの管理および監視ツール

MRS、モデルリポジトリサービスメタデータ リポジトリは、メタデータが物理的に保存されているデータベースと、開発が行われている Informatica Developer クライアントの間の層です。リポジトリには、他の多くの Infromatica サービスに関するデータの説明やその他の情報 (タスク (スケジュール) の実行スケジュールやデータの監視など)、およびアプリケーション パラメータが保存されます。これにより、特に、同じアプリケーションを操作に使用できるようになります。さまざまなデータソースと受信機。

DIS、データ統合サービスこれは、主要な機能プロセスが実行され、その中でアプリケーションが実行され、ワー​​クフロー (一連のマッピングとその相互作用の記述) とマッピング (変換、変換自体が発生するブロック、データ処理) が実際に起動されるサービスです。 ） 行われる。

グリッド構成 – 本質的には、DIS によって開始される負荷がノード (つまり、ドメインの一部であるサーバー) 間で分散される場合に、複数のサーバーを使用して複合体を構築するためのオプションです。このオプションの場合、特定の単一ノードで動作するのではなく、DIS が実行される複数のノードを統合する追加の GRID 抽象化レイヤーを通じて DIS の負荷を分散することに加えて、追加のバックアップ MRS インスタンスも作成できます。メインノードに障害が発生した場合にバックアップノード経由で外部呼び出しを行うことができる高可用性を実装することもできます。現在のところ、この構築オプションは放棄しています。

Informatica PowerCenter、概略図

データ サプライ チェーンの一部としての取り組みの初期段階では、定期的に問題が発生しました。その一部は、当時の Informatica の動作が不安定だったことに起因していました。今回は、Informatica 10 をマスターするというこの物語の思い出に残る瞬間のいくつかを共有したいと思います。

以前の Informatica のロゴ

私たちの責任範囲には他の Informatica 環境も含まれており、負荷が異なるため独自の仕様がありますが、今のところは、Informatica がデータ ウェアハウス自体の ETL コンポーネントとしてどのように開発されたかを正確に覚えておきます。

どうやってそうなった

2016 年に私たちが Informatica の仕事の責任者になったとき、Informatica はすでにバージョン 10.0 に達していました。本格的なソリューションでマイナー バージョン .0 の製品を使用することを決定していた楽観的な同僚にとっては、すべてが明らかであるように思えました。新しいバージョン！ハードウェア リソースの観点からは、当時はすべて問題ありませんでした。

2016 年の春以来、請負業者が Informatica の作業を担当しており、システムの数少ないユーザーによれば、「週に数回は機能していた」そうです。ここで、リポジトリは PoC 段階では事実上のものであったこと、チームに管理者がおらず、さまざまな理由でシステムが常にクラッシュし、その後請負業者のエンジニアが再びリポジトリを拾ったことを明確にする必要があります。

秋には 10 人の管理者がチームに加わり、各自の責任分野を分担し、Informatica を含むプロジェクト内のシステムの運用を組織する通常の作業が始まりました。これとは別に、この製品は広く普及しておらず、あらゆる質問に対する答えを見つけて問題を解決できる大規模なコミュニティがあると言わなければなりません。したがって、ロシアのパートナーである Informatica からの完全な技術サポートが非常に重要であり、その助けにより、私たちのすべてのエラーと当時若い Informatica XNUMX のエラーが修正されました。

私たちのチームの開発者と請負業者が最初にやらなければならなかったのは、Informatica 自体の動作を安定させ、Web 管理コンソール (Informatica Administrator) の機能を確保することでした。

これが私たちが Informatica 開発者とよく会った方法です

原因を究明するプロセスはさておき、クラッシュの主な原因は、ネットワーク環境の観点から見ると、Informatica ソフトウェアと比較的離れたサーバーにあるリポジトリ データベースとの対話パターンでした。これにより遅延が発生し、Informatica ドメインの状態を監視するメカニズムが混乱しました。データベースをチューニングし、Informatica のパラメータを変更してデータベースの遅延に対する耐性を高め、最終的に Informatica バージョンを 10.1 に更新し、データベースを以前のサーバーから Informatica に近いサーバーに転送した後、問題は解消されました。それ以来、私たちが観察していないこの種のクラッシュが発生しています。

Informatica Monitor を動作させるための試みの 1 つ

管理コンソールの状況も危機的でした。比較的生産性の高い環境で積極的な開発が直接行われていたため、同僚はマッピングの作業とワークフローを「外出先」で常に分析する必要がありました。新しい Informatica では、データ統合サービスにはそのような監視のための個別のツールはありませんが、管理 Web コンソール (Informatica Administrator Monitor) に監視セクションが表示され、アプリケーション、ワークフロー、マッピングの動作を監視できます。起動、ログ。定期的に、コンソールが完全に利用できなくなったり、DIS 内の現在のプロセスに関する情報の更新が停止したり、ページの読み込み時にエラーが発生したりすることがありました。

パフォーマンスを安定させるための Java パラメータの選択

問題はさまざまな方法で修正され、パラメータを変更する実験が実行され、ログと Jstack が収集されてサポートに送信され、同時に活発なグーグル検索と単純な観察が行われました。

まず、監視用に別の MRS が作成されました。後で判明したように、これは、マッピングが非常に集中的に起動されるため、環境内のリソースの主な消費者の 1 つです。 Java ヒープおよびその他の多数に関するパラメーターが変更されました。
その結果、次のアップデートである Informatica 10.1.1 までに、コンソールとモニターの動作が安定し、開発者はより効率的に作業できるようになり、定期的なプロセスがますます定常的に行われるようになりました。

開発と運営のやりとりの経験は面白いかもしれません。複雑なシステムを使用する場合、物事がどのように機能するか、何ができて何ができないかを一般的に理解するという問題は常に重要です。したがって、最初に管理チームにソフトウェアの管理方法をトレーニングし、開発チームにコードの記述方法とシステム内でのプロセスの描画方法をトレーニングしてから、最初のチームと 2 番目のチームを結果に取り組むために派遣することをお勧めします。時間が無限のリソースではない場合、これは非常に重要です。多くの問題は、オプションをランダムに検索するだけでも解決できますが、場合によっては先験的な知識が必要な場合もあります。私たちのケースは、この公理を理解することの重要性を裏付けています。

たとえば、MRS でバージョン管理を有効にしようとしたとき (最終的には、別のバージョンの SVN が必要でした)、しばらくしてから、システムの再起動時間が数十分に増加していることに気づき、不安になりました。開始が遅れた原因を特定し、バージョン管理を無効にしたことで、再びうまくいきました。

Informatica に関連する注目すべき障害には、成長する Java スレッドとの壮大な戦いが含まれます。ある時点で、レプリケーション、つまり確立されたプロセスを多数のソース システムに拡張する時期が来ます。 10.1.1 のすべてのプロセスが正常に動作しているわけではないことが判明し、しばらくすると DIS が動作不能になりました。数万のスレッドが検出され、その数はアプリケーションの展開手順中に特に顕著に増加しました。機能を復元するために、XNUMX 日に数回再起動しなければならないこともありました。

ここでサポートに感謝する必要があります。問題は EBF (緊急バグ修正) を使用して比較的早く特定され、修正されました。その後、誰もがこのツールが実際に機能することを実感しました。

まだ機能します！

ターゲット モードで作業を開始するまでに、Informatica は次のようになっていました。 Informatica 10.1.1HF1 のバージョン (HF1 は、EBF の複合体からのベンダー アセンブリである HotFix1) に EBF が追加インストールされており、GRID の一部である 20 台のサーバーのうちの 86 台に、スケーリングやその他の問題が修正されます。64 xXNUMX_XNUMX コアローカル ディスクの巨大な低速アレイ上のストレージ - これは、Hadoop クラスターのサーバー構成です。別の同様のサーバーである Oracle DBMS では、Informatica ドメインと ETL 制御メカニズムの両方が動作します。これらすべては、チーム内で使用される標準監視ツール (Zabbix + Grafana) によって、Informatica 自体とそのサービス、およびそこに入る読み込みプロセスの両方で監視されます。外部要因を考慮せずに、パフォーマンスと安定性の両方が負荷を制限する設定に依存するようになりました。

それとは別に、GRID についても言えます。この環境は 3 つのノード上に構築されており、負荷分散が可能です。しかし、テスト中に、アプリケーションの実行中のインスタンス間の相互作用の問題により、この構成が期待どおりに機能しないことが判明したため、この構築スキームを一時的に放棄し、3 つのノードのうち 2 つをドメインから削除することにしました。同時に、スキーム自体は同じままであり、現在は正確に GRID サービスですが、1 つのノードに縮退しています。

現時点では、モニター回路を定期的にクリーニングするとパフォーマンスが低下するという問題が残っています。CNN での処理とクリーニングの実行が同時に行われると、ETL 制御メカニズムの動作に誤動作が発生する可能性があります。この問題は現在、監視回路を手動でクリアし、以前のデータをすべて失うことで「松葉杖として」解決されています。これは、通常の日常業務では生産性にとってそれほど重要ではありませんが、現時点では通常の解決策の模索が進行中です。

これと同じ状況から別の問題が発生します。制御メカニズムが複数回起動されることがあります。

複数のアプリケーションの起動によりメカニズムの障害が発生する

スケジュールに従って実行している場合、システムに大きな負荷がかかると、機構の故障につながる状況が発生することがあります。この問題は依然として手動で修正されており、恒久的な解決策が模索されています。

一般に、高負荷が発生した場合、それに適切なリソースを提供することが非常に重要であると要約できます。これは、Informatica 自体のハードウェア リソースにも当てはまり、データベース リポジトリにも同じことが当てはまります。また、最適な設定を提供することも重要です。彼らのために。さらに、別のホスト上に置くか、Informatica ソフトウェアが実行されるのと同じホスト上に置くか、どちらのデータベース配置スキームが優れているのかという疑問も残ります。一方で、1 台のサーバーではコストが安くなり、組み合わせることにより、ネットワーク相互作用で発生する可能性のある問題が実質的に排除され、他方で、データベースからホストにかかる負荷が Informatica からの負荷によって補われます。

他の本格的な製品と同様に、Informatica にも面白い瞬間があります。
かつて、ある種の事故を整理していたときに、MRS ログが奇妙なことに出来事の時刻を示していることに気づきました。

MRS ログの時間的二元性は「意図的に」

タイムスタンプは午前/午後、つまり正午前か午後かを指定せずに、12 時間形式で記述されていることがわかりました。この件に関しては申請書も提出され、正式な返答が得られました。これが意図したとおりであり、マークはまさに​​この形式で MRS ログに書き込まれます。つまり、エラーの発生時刻に関して何らかの謎が残る場合があります...

最高を目指して努力する

現在、Informatica はかなり安定したツールであり、管理者とユーザーにとって便利であり、現在の機能と可能性の点で非常に強力です。それは私たちの機能上のニーズを何倍も超えており、事実上、最も典型的かつ典型的ではない方法でプロジェクトで使用されています。この問題の一部はメカニズムの動作方法に関係しています。具体的には、サーバーのハードウェア リソースがほぼ完全に使用される一方で、パラメータを集中的に更新してリポジトリ データベースを操作する多数のスレッドが短期間に起動されることです。 CPUによる。

現在、Informatica 10.2.1 または 10.2.2 への移行が近づいており、内部メカニズムの一部が作り直され、現在抱えているパフォーマンスと機能の問題の一部が解消されるようサポートが約束されています。また、ハードウェアの観点からは、ストレージの成長と発展による近い将来の予備を考慮して、当社にとって最適な構成のサーバーが期待されます。

もちろん、テスト、互換性チェックが行われ、場合によっては HA GRID 部分のアーキテクチャ変更も行われます。短期的にはシステムに代わるものを提供できないため、Informatica 内での開発は継続されます。
そして、将来このシステムの責任者となる人は、顧客が提示する必要な信頼性と性能指標を確実に達成できるでしょう。

この記事はロステレコムのデータ管理チームによって作成されました。

現在の Informatica ロゴ

出所： habr.com