DataSpider（Dr.Sum Connect）をつかったETLのスクリプトのつくり方

ETLツールでデータ連携をお手軽に

ETLツールがあるとデータの連携作業がとてもお手軽になります。プログラムを書く必要がほぼなくなりますからね。
しかしいくら簡単に処理ができると言っても、ひとつの画面（スクリプト）にたくさんコンポーネントを置いてしまうと、訳が分からなくなり、属人化して他の人に引き継ぎがしにくくなってしまうという弊害が出てきます。

ぜひともスクリプトの正しいを覚えてみましょう。

スクリプトのつくり方

親子関係を意識する

プログラム開発をする方なら意識されると思うのですが、スクリプトが冗長化させない秘訣は、スクリプトを分割することです。
その内の最適な分割方法というのは
・ログ出力、メール送信などの決まった処理はスクリプト化
・１つのテーブルの抽出→加工→取り込みまでを１スクリプトにする
という点です。

最初に作り込むときから、スクリプトをどう分割するかを頭の中に入れておくと、可読性の高いスクリプトがつくれます。
規模が大きくなってくると親・子・孫・ひ孫・玄孫（やしゃご）くらいまでは登場しますwww

各スクリプトの親子関係はこのようになります。

なぜ親子関係にするかをもう少し解説

先ほどもちょっと記載しましたが、大きなメリットは２つあるかなと思います。

可読性の向上による属人化の解消

ぱっと見、わかりやすいんですね。
このジョブはなんのために動いている、次は何をする処理だなど、見てすぐにわかります。
そして例えば「売上テーブルの加工ってどうやってたっけ？」となると、すぐに販売管理の売上スクリプトを覗きに行くことができます。

この可読性の高さは、担当が突然いなくなったり（考えたくないですが）しても、引き継ぐことができます。

ちなみに大半のETLツールは仕様書の出力機能もついていて、HTMLに記載されるので、細かな処理は仕様書から追うこともできます。

エラーハンドリングが容易

これもポイント高いです。
ETL関連の大事なポイントは障害発生時にいかに脳を殺して、短時間で復旧できるかにかかっています。
障害が発生すると、基本的にバタバタします。平常心ではいられません。
そのときに可読性が悪いロジックだったり、復旧手順が複雑だと、二次被害を巻き起こしてしまうことがあるのです。

理想の形はエラーになった箇所をログから特定し、もう一度そこから流してあげると処理がうまく行くように作り込むことです。
あれやこれやと処理を組み替えていると、人間いつかはミスをします。
特に夜中に異常終了となり、朝までに復旧しないとならない状況とかだと、ホントミスします。
なのでエラー時のハンドリングを常に意識して作り込みましょう。

Insertオンリーはオススメできない。

次のスクリプトのつくり方のコツですが、なるべくならデータベースへの単純Insertはやめましょう。
これも理由はエラーハンドリングです。

データ元が変わらない限り、何度処理を流しても、取り込んだデータは増減しないようにつくることが理想です。

Insertオンリーですと、処理を流すたびにデータが増えていきます。
ユニークキーが設定されていたら、エラーとなりますが、そのジョブは毎回エラーとなり、障害発生時には邪魔な存在となります。

こうしたことを防ぐために、
✅ 可能であれば、移行先のテーブルは全件削除→挿入
✅ 差分取り込みならば、移行先のテーブルの対象の期間のデータを削除→対象の期間のデータだけ挿入

という形になるようにしましょう。

実際のスクリプトで解説

それでは上記を意識した、スクリプトを紹介します。

DailyBatch

親スクリプトであるDailyBatchです。

このスクリプトをトリガーに仕込んで、毎日決まった時間にデータが流れます。
コンポーネントのほとんどは、子スクリプトを呼び出しているものです。

臨時バッチ

なお、ほぼ同じ形の臨時バッチというものもつくっています。

こちらはエラー復旧用で、エラーになった箇所から再実行するためのものです。

子スクリプトのひとつ

実行のメインとなる子スクリプトのひとつです。

連続してデータを取り込もうとしています。
さらにここから孫スクリプトを呼び出しています。
孫スクリプトのひとつひとつが実際に、テーブルを抽出・加工・取り込み処理をしているところです。

孫スクリプトのひとつ

ここではSalesforceのひとつのオブジェクトからデータを抜き、マッピングをしてDr.Sumに取り込んでいます。

キーポイントはtruncate_table_dataのところですね。
Dr.Sumのテーブルを全件削除しているのです。
ここの削除条件が複雑だったり、Insertするデータが差分であると、ロジックが複雑化し、エラーハンドリングの難易度が高まります。

実行ログスクリプト

これから何かをするときに、必ず呼び出されます。

単純明快ですね。
でもわざとスクリプト化しています。
もし文言を変えたくなったときに、ひとつ一括で変更されますので、メンテナンス性が向上します。
同様にエラーログスクリプトも存在します。

管理者メールスクリプト

異常終了の時は、キチンと管理者にメールを飛ばしましょう。

どの部分でコケたかを教えてあげると、障害対応者の心的ストレスの軽減につながります。

これらの基本的なスクリプト構成を意識していると、どのETLツールにも対応できるようになります。
実際に、ぼくも4つくらいETLツールを扱えますが、基本構成はどこも似たようなものです。

おわりに

最初は少々めんどうでも、一度この構成でつくってしまえば、今後の運用のハードルはとっても下がります。
開発する時間は瞬間的ですが、運用は永続です。

ストレスのない運用を意識したスクリプト管理をしてみませんか？