ETL/EAIツールでデータ連携処理を構築するベストプラクティスとは?(第3回)

こんにちは!アシストでデータ連携製品(DataSpider/DMExpress)を担当している市毛です。
私はETL/EAIツールのフィールド技術担当として、お客様が製品を最大限に活用できるようにツール購入後の初期支援(製品トレーニング、スキルトランスファー支援、標準化支援等)を日々行っております。
そんな日々のお客様支援を通じて得られた「データ連携処理構築におけるベストプラクティス」を私なりにまとめたものを連載でお届けしたいと思います。
データ連携処理開発プロセスのベストプラクティス(←今回はココ)
データ連携処理開発プロセスのベストプラクティスとは
今回は、本連載の肝となる「データ連携処理開発プロセスのベストプラクティス」について考えていきたいと思います。
前回の記事では、データ連携処理開発の躓きやすいポイント についてデータ連携ツール適用における問題と解決策の概要をご紹介しました。
【データ連携ツール適用時の問題に対する解決策5つ】
クリティカルな要件に対し可能な限り実環境で評価版検証する
データ連携の標準的なパターン/適用範囲を明確化する
ツールの特性を踏まえた標準化ルールを策定する
ツールでのロジック共通化の適用範囲/制限事項を押さえる
ツールを利用した構築Tips集を用意する
この解決策の具体的な方法を一つ一つひも解いていきたいと思います。
1.クリティカルな要件に対し可能な限り実環境で評価版検証する

1つ目は「クリティカルな要件に対し、可能な限り実環境で評価版検証する」です。
クリティカルな要件は、大きく3つに分類することができます。
要件その1ー重要な接続先との接続(例:SAP、Salesforceなど)
データ連携元/データ連携先の中核を担うのが接続先です。各種のマスタ/トランザクション情報を保持し、周辺システムに対するマスタ連携/トランザクション連携を行う必要がある「基幹システム」が主に該当します。ERPパッケージのSAP、顧客管理/SFAのクラウドサービスであるSalesforceなどが例として挙げられます。
要件その2ー汎用アダプタを利用した接続
(例:JDBC、ODBC、REST、Webサービス、FTP)
次に押さえておくべきは、汎用アダプタを利用した接続です。データ連携ツールは各種データソースに対する専用のアダプタを持っていますが、専用アダプタがない場合でも汎用的なプロトコルを使って接続することができます。
データベース系・・JDBC/ODBC
WebAPI・・REST/Webサービス
ファイル転送・・FTP など
なぜ、汎用アダプタについて実環境で検証したほうがよいかというと「汎用」という名のとおり、標準的なプロトコルでの接続方式を取っているため接続先によっては、問題が発生する可能性があるからです。
また、汎用アダプタは、専用アダプタと比べて個別データソースの接続に関する問題に対する修正対応が難しいことが多く、早い段階で要件を満たせるかどうかの検証を行っておくべきなのです。
要件その3ー処理性能(例:大量データ、同時実行)
データ連携ツールが持っている機能にもよりますが、コーディングと比較するとパフォーマンスチューニングの選択肢が限られる場合があります。そのため
大量データの処理時間が要件を満たせるかどうか
同時実行数の要件に対して問題なく処理できるかどうか
という点を、可能であれば実際のデータフォーマット/データサイズを用いて実検証しておくことがリスク回避につながります。
上記の実検証の観点に加えて、データ連携ツールでは実現できない場合の代替策も併せて押さえておくことも大切です。
代表的な代替策を挙げてみます。
・外部プログラムの実行
実現不可の部分を外部プログラム化し、データ連携ツールから外部プログラムを実行する
・独自関数の作成
主にデータ加工に関する実現不可の部分を独自関数として実装し、データ連携ツールに組み込む
・独自アダプタを作成
主に接続先データソースに関する実現不可の部分を独自アダプタとして実装し、データ連携ツールに組み込む
採用するデータ連携ツールでこれらの代替策が利用できるかどうかを事前に確認しておくことで実現可能な選択肢が明確になります。
アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」を例に各代替策が取れるかどうかをまとめてみたので、こちらも参考にしていただければと思います。

2.データ連携の標準的なパターン/適用範囲を明確化する

データ連携処理で必要となる主要な要素を分解すると次のようになります。
・データ抽出/データ出力
・データ変換
・集計/結合/ソート
・ファイル操作(ファイル移動/コピー/削除、フォルダ作成等)
これに対して、データ連携ツールの特性を踏まえて、
・全面的に利用する要素
・条件を満たす場合に利用する要素
・データ連携ツールの特性に合わないため利用しない要素
というように利用する範囲を明確化しておくことで、ツールの特性に合わない利用方法を抑止することが期待できます。
アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」をもとに各ツールの適用範囲例をまとめてみました。
データ連携要件やプロジェクト特性によって適用範囲は変わってくるのであくまでの一つの例として参考にしていただければと思います。

もう一つは、データ連携の標準的な処理パターンを明確化することです。
処理パターンの要素は下記のとおりです。
・処理の起動方法
ツールの自動起動機能を利用 or ジョブ管理ツールからキック
・連携元からのデータ抽出方式
ファイル or DBテーブル or DBワークテーブル
・連携先へのデータ出力方式
ファイル or DBテーブル or DBワークテーブル
アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」をもとに、各ツールの処理パターン例をまとめてみました。こちらも、データ連携要件やプロジェクト特性によって処理パターンは変わってくるので、あくまでの一つの例として参考にしていただければと思います。

3.ツールの特性を踏まえた標準化ルールを策定する

3つ目は「ツールの特性を踏まえた標準化ルールを策定する」です。
「開発標準化ルール」の主なものを挙げてみます。
・命名規約
・フォルダ構成
・エラーハンドリング
・ログ管理
・トランザクション管理
データ連携ツールを用いる場合でも、上記のような基本的な開発標準化ルールは定めておくべきですがこれに加えてツールの特性を踏まえた標準化ルールを用意しておく必要があります。
それは、「処理フロー作成」や「データマッピング」といったGUIを使用した処理フロー/マッピングの開発スタイルに沿ったルールです。
たとえば、処理フロー作成では、
・アイコンの配置方法
・配置するアイコン数
・アイコンの表示方法
・コメントの付与
といった点が挙げられます。
アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」の例をまとめてみたので、こちらも参考にしていただければと思います。

また、フロー作成ルールには、処理性能/リソースを考慮した設定を含めておくことも重要です。
この観点が抜け落ちていると
後工程での性能テスト/負荷テストで処理性能が出ない
リソースを使いすぎてメモリエラーが頻発する
ということが発覚する可能性があります。
そうなってしまうと、パフォーマンスチューニング等の余計な開発工数が発生するかもしれません。
処理性能/リソースを考慮した設定については、各データ連携ツールの機能に大きく依存するので、それらの機能は必須で押さえておくべきポイントだと思います。
アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」の例をまとめてみたので、こちらも参考にしていただければと思います。

4.ツールでのロジック共通化の適用範囲/制限事項を押さえる

4つ目は「ツールでのロジック共通化の適用範囲/制限事項を押さえる」です。
「共通化」は、同じものを作らなくて済むことでの開発工数削減や、修正箇所を1か所にすることができる保守性の向上につながるので、システム開発を行う上では当然のように検討する内容です。
そして、データ連携ツールを用いてデータ連携処理開発を行う際にも「共通化」は必要な検討課題となります。
ここでは、まず、データ連携処理開発の共通化要素を考えてみたいと思います。
データ連携処理の基本パターンは
入力 → 加工/変換 → 出力
となります。
この中での共通化要素は下記のとおりです。
・入力/出力のファイル/DBテーブル等のレコードレイアウト(列一覧の定義)
・入力/出力のデータソース接続定義
(DBであればホスト/ポート/データベース/ユーザ/パスワード)
・加工/変換の処理ロジック (加工/変換関数)
・入力→加工/変換→出力の処理フローそのもの
イメージでまとめると下記のようになります。

これらの共通化要素に対して、
データ連携ツールの機能が対応しているのか
対応しているのであれば、どのように実現できるのか
という点を押さえておきます。
アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」の例をまとめてみたので、こちらも参考にしていただければと思います。

5.ツールを利用した構築TIPS集を用意する

5つ目は「ツールを利用した構築TIPS集を用意する」です。
データ連携処理開発を可能な限り効率化して生産性高く行っていくためには、データ連携ツールの通常の機能「+アルファ」の便利な機能を理解してその部分を開発メンバーに共有化することが大事です。
ここでは、アシストで取り扱っているETL/EAIツール「DMExpress」「DataSpider」の機能を交えて、TIPSとして共通利用できそうなものをピックアップしてご紹介いたします。
■ファイルレイアウトインポート
データ連携ツールで入出力ファイルを定義する際にはファイルの入出力レイアウト(列の一覧と各列のデータ形式)を手動で設定します。ただし、入出力ファイルの列数が多い場合には手動で設定するのは大変なためレイアウト定義ファイルを用意して、レイアウトをインポートする機能が付いているかと思います。
このレイアウトインポート機能をベースに一歩進めて考えると、Excel等で作成するファイルレイアウト定義書から、インポートするためのレイアウト定義ファイルを自動生成するようなExcelマクロやデータ連携ツールでのスクリプトをあらかじめ用意しておくことで、レイアウト定義ファイル作成の作業工数をゼロにすることが可能です。

■テストの効率化
データ連携処理開発に限らないことですが、システム構築において大きな工数を占める一つがテスト工程です。このテスト工程をデータ連携ツールの機能を用いることで省力化/効率化できる可能性があります。
たとえば、高速ETLツール「DMExpress」は大量データの集計/結合処理に力を発揮するので、システムマイグレーション時の重要なテスト観点である現新比較テスト(現行システムと新システムの処理結果が同じであることを比較するテスト)の結果確認用に、DMExpressで「現」処理結果データと「新」処理結果データを結合する処理を作成して、大量データの比較でも短時間でテスト結果を得ることが可能です。
また、DataSpiderの例としては、DataSpiderにはテスト自動化を支援する機能が付いているため
テストデータ読み取り→テスト対象スクリプト実行→結果比較→テスト結果出力という流れのテスト用のスクリプトを用意して定期的にトリガーで実行できるようにしておくことで、仕様変更等による再テスト/リグレッションテストを自動化することが可能です。

連載の総まとめ
今回の連載の内容をまとめると、
・データ連携ツールを利用することで工数削減は見込める
・データ連携ツールを利用する際には3つの躓きやすいポイントに注意する必要がある。
1.ツールの検証が不十分
2.ツールの適用範囲があいまい
3.ツールの標準化が浸透していない
・躓きやすいポイントにはまらずに工数削減の効果を得るためには
5つのベストプラクティスを組み込む
①事前検証
②適用範囲の明確化
③標準化
④共通化
⑤TIPS
3回の連載を1つにまとめた資料を近日中に公開予定です!
本ブログ記事にて公開する予定ですので、少しだけお待ちください。
「いますぐにほしい!」という方がいらっしゃいましたら、
お問い合わせフォームからご連絡いただけましたら幸いです。

ページトップへ戻る
この記事を書いたスタッフ
市毛 正浩
市毛 正浩
関連記事
この記事のハッシュタグ #DataSpider #Precisely Connect #EAI #ETL #比較 #ファイル から関連する記事を表示しています。