さいしょに

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

そこでこの記事ではチームでの開発コスト、運用コストが低い構築方法のひとつを紹介します。

経歴紹介

筆者である私は新卒から8年間、ITベンダーでシステムエンジニアを経験しております。そこでは多様なETLツールを使用していました。今回はDr.Sum Connectですが、それ以外にもETLツールを4種類扱い、お客様に導入しています。また今回紹介するスクリプトの構築方法を4社のお客様に導入しております。

この記事を書いている現在でも開発コスト・運用コストを抑えた構築方法として活用されています。

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

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

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

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

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

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

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

それぞれ見ていきましょう。

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

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

共通ライブラリをつくる

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

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

別記事に参考になるライブラリを用意しましたので、ぜひ参考にしてください。

【Connect】使い勝手の良いライブラリたちを公開します

https://navi.wingarc.com/product/drsum/21332

 さいしょにDr.Sum Connectに限らずETLツールは利便性がとっても高いのですが、初めて使う人には少しハードルが高かったりします。でもそれはライブラリやフレームワークが整っていればもっと使いやすくなると思います。そこで今回、私が使用しているライブラリを公開します。この記事とは別に、ベストプラクティスな構築方法を記事にしていますので、そちらも併せてご確認ください。  ライブラリとは ここで言うライブラリとは親子関係に分かれるスクリプトのことを指します。上図の画像のようにScriptTemplateと...

WingArc TECH BLOG

2025.02.06

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

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

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

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

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

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

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

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

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

こちらは MotionBoardで表現したものです。

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

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

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

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

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

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

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

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

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

私は管理表を作りました。

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

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

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

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

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

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

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

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

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

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

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

さいごに

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

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