【DataSpider】開発コスト・運用コストを抑えたスクリプトの構築方法

最初に

DataSpiderやASTERIA Warp、Talendなどプログラムを書かなくてもデータ連携ができるETLツール。自由度が高い分、構築手法が属人的になりがちで、しっかりとルールを決めずに作ると引き継ぎが大変になってしまうことがございます。

そこで各ツールでの構築経験もあり、ETLツールでの開発キャリアが10年以上ある私から、チームでの開発コスト、運用コストが低い構築方法について紹介します。

ベストプラクティスな構築方法

今回オススメするベストプラクティスな構築方法は以下の状況の時にオススメです。

• チームでETLの構築をするとき
• 構築後に誰かに引き継ぐ可能性があるとき
• 日々の運用をとにかく楽したいとき

最初にこれらの用意をするのは少し工数がかかりますが、例えばスクリプトを10本以上作ることが確定しているのであればぜひ採用していただければと思います。

それではここからは具体的に構築方法について記載して参ります。

今回紹介する構築方法は以下の４つになります。

• ３世代スクリプトを構築する
• 共通ライブラリをつくる
• ログのデータベース書き込みによるデータ連携イベントの可視化する
• データは多めに消して多めに入れる

早速みていきましょう。

３世代スクリプトを構築する

ETLツールはスクリプト単位でデータ連携処理を構成することができますが、スクリプトの中にたくさんの数のコンポーネントを配置することができます。
しかしこの量を多くし過ぎると処理が重くなったり、このスクリプトが何をやっているのかわからなくなったりします。
そのため、図のようにそれぞれの役割に分けたスクリプト設けることが重要となります。

共通ライブラリをつくる

いろいろなスクリプトに同じ処理を作る場合は必ず共通化しましょう。
最初から汎用性を意識しながらライブラリをつくるのは難しいのですが、「あ、この処理って別のスクリプトでつくったな」と思ったら、すぐに共通化することを考えましょう。

運用を続けていくと、ライブラリの恩恵を感じることがたくさんあります。
やや大きな変更を加える必要のあるときに、全スクリプトを調べ直す必要もなく、一箇所修正するだけでOKという状況を作っておかないと、管理するのが嫌になっちゃいますからね。

別記事に参考になるライブラリを用意しましたので、ぜひ参考にしてください。
【DataSpider】使い勝手の良いライブラリたちを公開します

主要なライブラリを抜粋したものがこちらです。

ライブラリ名	説明	参照記事URL
処理開始DBログ	スクリプト開始時点でDBに時刻を書き込む	【DataSpider】処理開始DBログライブラリ
異常終了DBログ	スクリプト異常終了時点でDBに時刻を書き込む	【DataSpider】異常終了DBログライブラリ
メール送信	正常・異常を判定し、終了の内容をメール送信する	【DataSpider】メール送信ライブラリ
正常終了DBログ	スクリプト正常終了時点でDBに時刻を書き込む	【DataSpider】正常終了DBログライブラリ
DBバックアップ	（データベースがDr.Sumならば）定期的にデータベースをバックアップする	【DataSpider】DB_BackUpライブラリ
DB再構築	（データベースがDr.Sumならば）定期的にデータベースを再構築する	【DataSpider】DB_Rebuildライブラリ

スクリプトテンプレートをつくる

スクリプトをつくるときには、あらかじめ用意しておいたスクリプトテンプレートをコピーしてつくるようにしましょう。
共通処理はすべて搭載しておきます。
ここで大事なのはスクリプトテンプレートはコピーだけしてすぐにつくれるようにすることです。

こちらの場合、コピーしてから手を加える箇所は、スクリプト変数の初期値を変更するだけです。

• スクリプトID
• スクリプト名

なぜ、スクリプトIDとスクリプト名が必要なのか、これは次の章のログの書き込みでわかります。

スクリプトテンプレートをつくって、共通処理の場所には触れないようにすれば、チームで開発しても基本的な形式を保つことができます。

ログのデータベース書き込みによるデータ連携イベントの可視化する

いきなりですが、スクリプトの流れがこのような感じで参照できるようになると、全体がどのように流れてどれくらいの時間がかかっているか、すごくわかりやすくないですか？

こちらは MotionBoardというデータ可視化ツールで表現したものです。

まぁ可視化は他のツールでもできます。
ここで大事なのは可視化するためにログ情報をデータベースに貯めることなのです。

さきほど登場したDBログライブラリたちがここで生きてきます。
データベースを用意して、ログ情報はどんどんとデータベースに書き込んでいくようにしましょう。

ライブラリ名	説明	参照記事URL
処理開始DBログ	スクリプト開始時点でDBに時刻を書き込む	【DataSpider】処理開始DBログライブラリ
異常終了DBログ	スクリプト異常終了時点でDBに時刻を書き込む	【DataSpider】異常終了DBログライブラリ
正常終了DBログ	スクリプト正常終了時点でDBに時刻を書き込む	【DataSpider】正常終了DBログライブラリ

ログをデータベースに貯めておくと意外なところで役に立つ場面が出てきます。

• 各スクリプトの平均時間を算出する（たまに特定の曜日だけ処理が遅くなるときがあったりする）
• 頻繁に出るエラーの傾向分析ができる
• たまーに出るエラーの傾向がわかる

自分のあった例では、なぜかたまーにエラーになるスクリプトがあって、しばらく放置していました。
ある日貯まったログから傾向を把握すると、「必ず休日の次の日にエラーになる」ということがわかりました。これらはデータを貯めておかないとなかなかわからないことなので、とても参考になりました。

またこのように可視化をすると、わざわざドキュメントに全体の流れを書く必要がなくなります。
新しい開発・運用メンバーが入ってきた時に、この画面を見せながら全体の流れを説明することができます。

ドキュメントを整備する必要がなく、直感的にわかりやすくなるので、運用コストを大幅に下げることが期待できます。

大事なのはスクリプトIDの管理

テーブルにデータを書き込むにあたり、重要な要素としてスクリプトIDの管理があります。
スクリプトに連番を振り、そのIDでテーブル内の管理をするのですね。

参考に某企業ではこのように管理表を作りました。

親子孫スクリプトそれぞれに番号を振ると、管理がしやすくなるので、ぜひ実施しましょう。

データは多めに消して多めに入れる

たとえば毎日スクリプトを動かして、データ連携をするとします。
とあるシステムから１日分のCSVデータが届いたり、基幹システムから1日分のデータを抽出して取り込むようにするでしょう。

でも、そのやり方は運用コストを考えると損失が大きいです。
例えば1月1日にデータ連携が何かしらの理由でエラーになります。
お正月にエラーの調査はなかなかできません。
1月4日にエラーを調査して、原因がわかったとすると、ここから復旧をすることになります。
1日分のデータ連携をしていると、1月1日から4日までのデータを復旧することになります。
そうするとスクリプトの日付を調整して、1日ずつ入れていくことになりますよね。

それ、超めんどくさいです。
めんどくさいだけならまだしも、お客様環境でしたら失敗は許されないので、手作業が多くなるのは本当にイヤです。

運用コストがめちゃめちゃかかりますよね。

こちらを解消するために、以下の方法をとることができます。

• 普段は1日分だけどエラー復旧時には任意でに変えられるようスクリプト変数をつくる
• 毎日7日分のデータ連携をする

私はね、めんどくさがりなのでこの２つを両方採用しています。
つまり「当日-7日から当日まで」のデータを抽出範囲として、取り込み先のデータベースにも「当日-7日から当日まで」を削除してからINSERTするようにしています。

もし万が一、エラーの復旧に8日以上かかったら、スクリプト変数を変更してデータ抽出範囲を増やすのです。

全体のスクリプトの処理時間や各システムの負荷を一番に考えますが、余裕があればぜひこのやり方をデフォルトとしてもらいたいです。

最後に

冒頭にも書きましたがETLツールはGUIで作りやすいのですが、書き方のお作法が統一されておらず、属人的な作り方になってしまうことが多いです。
ライセンス金額から言っても決してひとりで使うツールではないと思います。

なので開発コストや運用コストを下げたベストプラクティスな構築方法を意識して、メンバーが笑顔になる作り方を心掛けて参りましょう。