この記事では、 Tinkoff BankでのDWHの開発における別の段階についてお話したいと思います。



現代のビジネス情報システムにおけるディザスタリカバリ（以下、DR）の可用性の要件が「必須」として分類されていることは周知の事実です。 そのため、1年ほど前、銀行のDWHの開発に携わるチームは、DWHのDRの実装を任されました。DWHには、オフラインとオンラインの両方の銀行プロセスが構築されています。

問題の声明

それで、与えられたもの：

• データソース側で変更をキャプチャし、それらをレイヤーオンライン操作データ（以降OOD）に適用するためのシステム-Attunity Replicate 。
  
  
• ダウンロード、データ変換、IN / OUTデータ統合、ウィンドウドレッシング、およびETL / ELT全体-SAS Data Integration Studio 、 〜1700 ETLタスク 。
  
  
• 銀行でDWHが構築される主なDBMSは、MPP DBMS Pivotal Greenplum、 データボリューム〜30TBです。
  
  
• レポート、ビジネスインテリジェンス、アドホック-SAP BusinessObjects + SASエンタープライズガイド。
  
  
• モスクワの異なる端に地理的に分散している2つのデータセンターの間にネットワークチャネルがあります。
  
  

目的：故障後1時間以内に、メインサイトでのGreenplumの動作不能につながる、Greenplumのバックアップ回路上のすべてのDWHプロセスの動作可能性を確保する。 基本的に、このタスクはGreenplumのホットスタンバイを構築することです。

リサーチ

概念の研究開発のために約1か月が割り当てられました。



もちろん、私たちに最初に起こったのは、ベンダーの方向に掘ることでした-Pivotal、つまり EMC 調査の結果、Greenplumにはホットスタンバイを構築するための標準ツールがなく、GreenplumのDRソリューションはEMC Data Domainを使用して構築できる可能性があることがわかりました。 しかし、Data Domainの詳細な調査により、このテクノロジーは多数のバックアップを作成することを目的としており、これを考慮すると非常に高価であることがわかりました。 また、「すぐに使える」Data Domainには、2番目の回路を最新の状態に保つ機能がありません。 EMC Data Domainの検討を拒否しました。



私たちが取り組んできた2番目のオプションは、サードパーティのレプリケーションツールGreenplumToGreenplumを使用することです。 オプションはすぐに廃止されました。 当時は、Greenplumをソースとしてサポートする複製ツールはありませんでした。



取り上げた3番目のオプションは、デュアルアプライクラスソリューションです。 TeradataとInformaticaが、Teradataデュアルアクティブソリューション（ Teradata Magazine ）向けのInformaticaデュアルロードと呼ばれるソリューションを見た後、Greenplum向けの同様のソリューションを構築するためのテクノロジー市場の調査を開始しました。 しかし、彼らは何も準備ができていませんでした。



調査後、私たちは独自の開発が最良の選択肢であると判断しました。 そこで、独自のシステムの作成を開始し、デュアルETLと呼びました（開発者のサークルでは、プロジェクトは「デュエット」と呼ばれていました）。

Duetとその構築方法

概念的なアーキテクチャ

システム構築のコンセプトは、原則に基づいていました。GreenplumのメインサーキットでETLがテーブルを再構築するとすぐに、システムはこのイベントをキャッチし、このテーブルのデータをGreenplumのバックアップサーキットに転送します。 したがって、この原則を遵守して、地理的に離れた2つのデータセンターの2つの回線に同期して、一定の時間遅延でDWHを構築します。









図1概念アーキテクチャ



アーキテクチャの開発中、システムは6つのコンポーネントに分割されました。

• メインコンポーネントで動作し、データの受信を担当するバックアップコンポーネント。
  
  
• メインサイトとリザーブサイト間のデータ転送を担当するトランスポートコンポーネント。
  
  
• 復元コンポーネント。バックアップサイトで動作し、データの適用を担当する必要があります。
  
  
• ストレージに転送し、毎日のバックアップを収集するコンポーネント。
  
  
• システムのすべてのプロセスを操作する制御コンポーネント。
  
  
• また、システムで何が起こっているのか、メインサイトの背後にある予備サイトがどれだけあるのかを理解するための監視コンポーネント。
  
  

既存のETLの改良

テーブルの準備状況についてシステムに通知するために、キューが実装され、ETLにオブジェクト（テーブル）の作成が完了したらすぐに追加するように指示しました。 したがって、イベントをシステムに送信する機能が実装された後、システムはGreenplumバックアップ回路でこのテーブルを再構築する必要がありました。

制御コンポーネントの実装

ETLタスクスケジューラはSASで記述されており、DWHチームはSASマクロ言語での作業に豊富な専門知識を持っているため、SASで制御メカニズムを記述することが決定されました。



実装されたメカニズムは、キューから新しいテーブルを取得し、バックアップコンポーネントを起動し、ダンプテーブルをバックアップサイトに送信し、復元コンポーネントを起動するなどの単純なアクションを実行します。 これに加えて、タスクの種類（バックアップ、トランスポート、復元、バックアップのストレージへの転送）ごとにフロー数を調整できるという事実、そしてもちろん、ジャーナリングや電子メール通知などの必要な機能にもかかわらず、マルチスレッドが実装されます。

バックアップコンポーネントの実装

転送されたテーブルのバックアップコンポーネントは、gp_dumpユーティリティを呼び出します。 メインサイトのGreenplumセグメントサーバーに分散したダンプテーブルを取得します。 gp_dumpユーティリティを呼び出す例：

gp_dump --username=gpadmin --gp-d=$DIRECTORY --gp-r=$REPORT_DIR $COMPRESS -t $TABLE db_$DWH_DP_MODE &> /tmp/gp_dump_$NOW
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

トランスポートコンポーネントの実装

トランスポートコンポーネントの主なタスクは、メインサイトのGreenplumセグメントサーバーからバックアップサイトの対応するGreenplumサーバーセグメントにダンプファイルを迅速に転送することです。 ここでは、ネットワークの制限に直面しています。つまり、メイン回線のセグメントには、ネットワーク上のバックアップ回線のセグメントが表示されません。 DWH管理者の知識のおかげで、SSHトンネルを使用してこれを回避する方法を思いつきました。 SSHトンネルは、各回線のGreenplumセカンダリマスターサーバーで発生しました。 したがって、テーブルダンプの各部分は、メインサイトのセグメントサーバーからバックアップサイトのサーバーセグメントに転送されました。

復元コンポーネントの実装

トランスポートコンポーネントをシャットダウンした後、バックアップサイトのGreenplumセグメントサーバーにダンプテーブルが広がっています。 このテーブルでは、復元コンポーネントがgp_restoreユーティリティを実行します。 その結果、予約サイトで更新されたテーブルを取得します。 以下は、gp_restoreユーティリティを呼び出す例です。

 gp_restore $COMPRESS --gp-d=$SOURCE --gp-r=$REPORT_DIR --gp-k=$KEY -s --status=$SOURCE -d db_$DWH_DP_MODE > /tmp/gp_restore_$(echo $KEY)_$RAND 2>>/tmp/gp_restore_$(echo $KEY)_$RAND
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

監視の実装

主なコンポーネントの開発と最初の起動が完了した後、一般的に機能するシステムができました。 バックアップサイトにテーブルがセットアップされ、ジャーナリングが機能し、郵便局に手紙が届き、システムが機能しているように見えましたが、特定の瞬間に何が起こっているのかを明確に理解することはできませんでした。 私たちは、システムを監視するためのメトリックの割り当てと実装の監視の技術的要素の2つのステップに分かれた監視の問題について懸念していました。



メトリックは非常に迅速に特定されたため、特定の時点でシステムで何が起こっているのかを明確に明確にしたはずです。

• ステータスのオブジェクトの数。
  
  
• ステータスのエラーの数。
  
  
• 待ち行列に入った瞬間からの遅れ。
  
  
• ステージの開始時の遅延。
  
  
• ステージの平均期間（最後の10個のオブジェクト）。
  
  
• また、各段階で作業スレッドの数を監視します。
  
  

また、Graphite + Graphanaという技術的な実装も非常に迅速に決定しました。 別の仮想マシンにGraphiteを展開し、発明されたメトリックをプログラミングするのは簡単でした。 また、Graphanaを使用すると、作業中のGraphiteで美しいダッシュボードが開発されました。



上記のすべての指標は、視覚化と、特に重要なオンライン性を発見しました。









図2ステータスのオブジェクトの数









図3ステータスのエラー数









図4キューに入る瞬間の遅れ









図5ステージ開始時の遅延









図6ステージの平均期間（最後の10個のオブジェクト）









図7各段階での作業スレッドの数

後処理

復元プロセスが完了すると、ダンプファイルはバックアップサイトのストレージに転送されます。 バックアップサイトのストレージとメインサイトのストレージの間でレプリケーションが構成されます。このレプリケーションはNetApp SnapMirrorテクノロジーに基づいています。 したがって、データ復旧を必要とするメインサイトで障害が発生した場合、これらの作業用のストレージのバックアップがすでに用意されています。

まとめ

私たちが得たもの

システムが開発され、すべてがそれほど悪くないことが判明しました。 システムが解決することを意図したタスクは完全に閉じられています。 開発が完了した後、DWHサポートプロセスの一部としてバックアップサイトへの移行を許可する多くの規制が開​​発されました。

私たちが得た主なものは、もちろん、メインサイトで障害が発生した場合に30分以内にバックアップサイトに移動する機会です。これにより、情報システムとしての単純なDWHが大幅に最小化され、その結果、ビジネスでレポート、分析用データ、一時的であり、多くのオンラインプロセスを停止しません。 また、このシステムにより、デュアルETLシステムが受信したバックアップを優先して、日常のバックアップ手順を中止することができました。

仕事の統計

1日あたり約6,500個のオブジェクト（テーブル）がシステムを通過し、合計ボリュームは約20 TBです。

「キューに入った瞬間から遅れている」というメトリックの例（図8を参照）









図8キューに入る瞬間からの遅れ



メインサイトからリザーブサイトのバックログを確認できます。 夜間スケジューラの作業中、ETLが倉庫をアクティブに構築しているとき、ピーク時の遅延は2〜3時間に達します。 ストレージが完了するまでに、午前10時に、バックログは削減され、5〜10分のレベルにとどまります。 日中は、30分以内にオンラインスケジューラの作業中にラグバーストが発生する場合があります。



また、比較的最近、私たちのシステムには小さな記念日があり、 1,000,000（百万）個のオブジェクトが通過しました！

エピローグ

Tinkoff BankのDWHチームは、Hadoopに向けて戦略的なコースを取ります。 今後の記事では、「HadoopでのETL / ELT」および「Hadoopでのアドホックレポート」のトピックをカバーする予定です。