ETLは内製と製品のどちらか｜データを運ぶ土台の選び方

大手クラウド事業者の設計指針は、データを運ぶ二つのやり方の違いを一行で書いています。違うのは変換がどこで行われるかだけだ、と。取り出して、形をそろえて、書き出す。3つの工程のうち真ん中をどこでやるかが、呼び名を分けているにすぎません。それでも社内の議論が長引くのは、決めているのが工程ではなく、止まった日に誰が直すかだからです。効いてくるのは、動くかどうかではなく、壊れたときにやり直せるかどうかです。この記事では、3工程の中身から、先に整えるか後で整えるかの分かれ目、止まる典型4つ、やり直しができる作りの決めごと、遅れて届く記録の扱い、動かす頻度の決め方、費用が増える3か所、そしてAIに任せてよい工程と、自分たちで組むか製品を使うかの分かれ目までを整理します。

運ぶ仕組みは3工程。呼び名を分けるのは、真ん中をどこでやるかだけ

取り出す、形をそろえる、書き出す。この3つのうち、真ん中を書き出す前にやるやり方と、先に書き出してから置き場の中でやるやり方があります。大手クラウド事業者の設計指針は、後者について前者と違うのは変換がどこで行われるかだけだと書き、専用の変換の仕組みを別に持たず、書き出し先の処理能力で整える形だと説明しています。

同じ指針は、この形は書き出し先が十分に強いときにしかうまく働かない、とも付け加えています。つまり選択は好みではなく、書き出し先の性格で決まる部分が大きいということです。また3つの工程は順番に走るとは限りません。時間を節約するために並行して走らせるのがふつうで、並行の切れ目は日付や取引先といったデータの区切りに沿って設計する、と書かれています。

その理由が2つ挙げられていて、ここが本題につながります。1つは、同じ場所への書き込みがぶつからないようにするため。もう1つは、やり直しを何度実行しても結果が変わらないようにするためです。速さのために区切っているのではなく、やり直せるように区切っている。運ぶ仕組みの設計は、最初からここを向いています。

3工程のうち、どこを自分たちで持つかも先に見えてきます。取り出す工程は、相手の仕組みの都合で決まるので、こちらで工夫できる余地が小さい。書き出す工程は、置き場を決めた時点でほぼ決まります。選択の幅が残っているのは、真ん中の形をそろえる工程だけです。作るか買うかの議論も、この真ん中を誰が書き、誰が直し続けるかの議論に落として考えると、話が具体的になります。

先に整えるか、入れてから整えるか——分かれ目は3つ

どちらを選ぶかは、同じ設計指針が条件を並べています。製品の優劣ではなく、書き出し先の力と、業務のルールと、社内の規程で決まる、という整理です。3つの条件を並べます。

見るところ	先に整えてから書き出す	書き出してから中で整える
書き出し先の力	整える処理を任せると重い相手のとき、手前で済ませて負担を逃がす	計算資源が伸び縮みする置き場なら、そこの機能で整えたほうが速い
業務のルール	複雑な業務ルールがあり、専用の変換の仕組みが要るとき	整える処理が置き場の標準の機能で書けるとき
記録の要求	規程や監査で、取り込む前に整えた控えを残すことを求められるとき	生のまま残しておき、後から解釈を変えられるようにしたいとき

実務では、この2つはきれいに分かれません。1つの会社の中で両方が混ざるのがふつうです。大事なのは全部を一方に寄せることではなく、どの流れがどちらなのかを一覧にしておくことです。混ざっていること自体は問題になりませんが、どちらか分からない流れがあると、直すときに手が止まります。

3行目は業種によって重みが変わります。取り込む前の姿を求められる業種では、後で整える形に寄せづらく、手前に控えを残す工程が消せません。この一行は技術の議論ではなく、監査で何を見せるかの議論なので、情報システム部門だけで決めずに、内部監査の担当と一緒に確認しておくと後戻りが減ります。

止まる典型は、だいたい4つに集まる

運ぶ仕組みが止まる形は、驚くほど限られています。どれも作りの善し悪しではなく、外から来ます。だから防ごうとするより、起きる前提でやり直せるようにしておくほうが早く落ち着きます。

• 元の形が変わる：送り元の項目が増える、消える、型が変わる
• 量が跳ねる：ふだんの10倍の行が来て、決めた時間内に終わらない
• 時刻がずれる：送り元と受け側で時刻の基準が違い、締めをまたいだ記録が二重になる
• 途中で落ちる：半分だけ書き込まれた状態で止まり、もう一度動かすと重複する

この4つのうち、1番目と4番目は公表された技術文書に明確な名前と対処法があります。以下ではその2つを先に見て、そのあと3番目の時刻、2番目の量の順に進みます。順番には理由があって、1番目と4番目に手を打っていないと、残りの2つに対処しても数字は合わないからです。

元の形が変わる——列の名前で拾うと壊れる

送り元がデータの形を頻繁に変える状態には、決まった呼び名があります。提供元の技術文書は、項目・列・型が、その場で追加されたり削除されたり変更されたりする状態と定義しています。そして、そのままでは何が起きるかも書いています。「典型的な運び方は、入ってくる列や項目が変わると壊れる。送り元の名前に結びついているからだ」という指摘です。

同じ文書が挙げる備え方は3つです。1つめは、項目名・型・値・長さが変わりうる前提で送り元を定義すること。2つめは、固定の項目名を直に書かず、データの形の規則で動く引数として変換を書くこと。3つめは、名前で指すのではなく、入ってくる項目を規則で照合する式を書くことです。受け方としては、想定になかった列は既定で文字列として受け取り、必要なときだけ型を推測させる、という段取りが紹介されています。

ここには代償があります。同じ文書が明記しているとおり、変わることを受け入れると、途中の画面で列の名前と型が先に分からなくなります。設計の時点で決まる情報が減るので、作るときの見通しは悪くなります。だから全部を緩くはしません。壊れて困る列だけを厳しく決めて、それ以外は緩く受ける、という線を先に引いておきます。

途中で落ちる——同じ記録が2回届くのは、事故ではなく前提

運ぶ仕組みの設計文書は、主要な受け渡しの仕組みが「少なくとも1回は届ける」保証をしている、と書いています。届くことは保証するが、同じものが2回以上届くこともある、という意味です。重複が生まれる形も3つ挙げられています。送る側の再送、受け取り確認が届かなかったための再配信、そして処理の途中での落ちです。

ここで大事なのは、同じ文書がはっきり書いている次の一文です。分散した仕組み全体で「ちょうど1回」の配送を保証するのは現実的ではない。だから持続する解決は、重複配送をなくすことではなく、受け取る側が重複に耐えられるようにすることだ、と。そしてこの考え方は、運び直したデータをもう一度処理する場面にも同じように当てはまる、と明記されています。

これはマーケティングの数字に直結します。同じ問い合わせが2件になり、同じ購入が2回計上され、同じ人が2人として数えられる。しかも気づくのはずっと後です。画面の数字は不自然に見えないので、誰かが元の記録と突き合わせるまで、水増しされた数字のまま報告が続きます。

同じ文書には、この考え方が受け渡しの仕組みに限らないことも書かれています。運び直したデータをもう一度処理する場面、途中の記録から再開する処理、予定が重なって二重に動いた定期処理。どれも同じで、1件を見分ける鍵を決め、処理したことを記録し、重なりを吸収する、という3つの手順に落ちます。受け渡しの仕組みを使っていなくても、この3つは同じように要るということです。

やり直しができる作りにするための5つの決めごと

重複が前提なら、決めることは1つに絞られます。2回動いても結果が変わらない形にすることです。公表されている設計パターンから、実務で決めておくべき点を5つに整理します。

1. 何を1件と見なすかの鍵を決める。再送されても変わらない鍵を使う。送り元が付けた記録の番号か、業務上の識別子が向く。関連する記録をまとめるための番号は、複数の記録が同じ値を持つので使えない。受け取った時刻のように、そのつど変わる値から作るのも避ける
2. 処理と「処理した印」を1回で書く。別々に書くと、処理は済んだのに印だけ残らない瞬間ができ、次に届いた同じ記録がもう一度処理される
3. 重なりはデータベースの側で弾く。同じ鍵は1行しか入らない制約を置けば、同時に来た2件のうち片方だけが通り、もう片方は自動で落ちる。あるか確認してから書く、という手順だけでは同時の2件が両方通る
4. 印の保存期間を決める。再配信されうる期間より長く残す。止めた記録の置き場から人が手で入れ直す場合、ずっと後になることがあるので、そこも見込んで期間を決める
5. 上書きで済む形にできないかを先に考える。足し引きではなく、届いた値をそのまま置く形にできるなら、そもそも重複の管理が要らない

5番目がいちばん効きます。増減で書くと、2回動いたぶんだけ数がずれます。届いた時点の状態をそのまま置く形にすれば、何回動かしても同じ結果になります。重複の管理を足す前に、管理が要らない形にできないかを見る。この順番だけで、作る量も見張る量も減ります。

遅れて届く記録は、どの時刻を正とするか

締めをまたいで届く記録は必ず出ます。同じ設計指針も、遅れて届く出来事と順番が入れ替わる処理に備える仕掛けを入れること、そして処理できなかった記録は専用の置き場に寄せることを挙げています。ここで先に決めるのは、時刻を3つに分けることです。出来事が起きた時刻、こちらに届いた時刻、そして書き込んだ時刻。この3つは必ずずれます。

決めるのは3点です。締めのあと何日まで受け付けるか。受け付けた記録は起きた月に足すのか、届いた月に置くのか。そして、過去の月を直したときに、前に出した数字を出し直すのか、注記だけ添えるのか。この3つを先に決めておけば、経営に出した数字が後から動いても説明ができます。

処理できない記録は、捨てずに置き場に寄せます。捨ててしまうと、数が合わない理由が永久に分からなくなります。寄せた記録には、落ちた理由と、いつ落ちたかを一緒に残します。そして週に1度、たまった記録を見る時間を取ります。見ない置き場は、ただのごみ箱になって、同じ理由の失敗が何か月も積み上がります。

時刻の基準そのものも、先に1つに決めておきます。送り元ごとに現地の時刻で記録されていると、同じ1日が送り元によって別の範囲を指します。取り込む時点で1つの基準に直し、元の表記も一緒に残しておくのが実務では扱いやすい形です。直した値だけを残すと、後から基準を変えたくなったときに、元に戻せなくなります。

量が跳ねる——次の回と重なると、同じ記録を2つの処理が触る

量が跳ねる日は、だいたい決まっています。大きな配信をした翌日、展示会の直後、送り元の仕組みを入れ替えた初回、そして相手側が過去分をまとめて送り直したとき。ふだんの何倍もの行が来て、決めた時間内に終わらなくなります。

困るのは遅れることそのものではありません。終わらないうちに次の回が始まると、同じ記録を2つの処理が同時に触ります。片方が書いた値を、もう片方が上書きする。この状態は、失敗としても記録されないので、止まっていないのに数字だけが合わない、という形で現れます。原因を探しても、失敗の記録には何も残っていません。

備え方は3つです。前の回が終わっていなければ次を始めない仕掛けを入れること。1回で扱う量に上限を決めて、超えたぶんは次に回すこと。そして、上限を超えた事実を通知として出すことです。3つめを省くと、毎回あふれている状態が正常として定着し、いつまでも古い記録が追いつかないまま残ります。

動かす頻度は、やり直しにかかる時間から決める

頻度の議論は、たいてい「どのくらい新しい数字が要るか」から始まります。そこは必要な話ですが、実務でもう1つ効く物差しがあります。1回の失敗をやり直すのに、何分かかるかです。この物差しは、鮮度の要求とは別に効きます。

1日1回で6時間かかる作りだと、朝に失敗した時点で、その日のうちに数字は出ません。同じ量を1時間ごとに分けておけば、1回のやり直しは短く済み、失敗しても取り返しが付きます。頻度は鮮度の要求だけでなく、直すのにかけられる時間の上限から決めます。会議が朝9時なら、始業前に直せる長さがそのまま上限になります。

ただし細かく分けすぎると、動かす回数が増え、見張る対象も、失敗の通知も増えます。目安として置きやすいのは、失敗しても始業前に直せるか、という一点です。この問いに答えられる長さまで分けて、そこで止めておくのが、手間と安心のつり合いが取れる場所になります。

費用が増えるのは3か所——動かした回数・運んだ時間・変換の計算資源

従量制の仕組みの請求は、だいたい3種類の計り方に分かれます。大手クラウド事業者の運ぶ仕組みは、動かした処理の回数、複写に使ったデータ統合の単位と実行時間、変換の実行と試験に使った処理の芯の数と実行時間、の3つで課金すると明記しています。使った分だけ払う形なので、設計の選択がそのまま請求書に出ます。

この形が分かると、減らし方も見えます。回数で増えているなら、細かく分けた処理をまとめる。時間で増えているなら、毎回全件を運ぶのをやめて差分だけにする。計算資源で増えているなら、変換を書き出し先に寄せる。どこで増えているかを見ずに全体を削ると、たいてい鮮度だけが落ちて費用は変わりません。

見積もりのときに落としやすい点も3つあります。試しに動かした分にも課金されること。読み書きや監視の操作にも費用が付くこと。そして、流れごとの内訳は既定では分かれず、設定して初めて流れ単位で請求が割れることです。内訳が分かれていないと、どの流れが高いのかを議論できないまま、総額だけを見て削ることになります。

変換をAIに任せると、それらしく埋まった列が下流に流れる

ここからがAIの線引きです。送り元の列名と書き出し先の列名の対応づけを作らせると、多くはうまくいきます。問題は残りです。似た名前の別の列に結びつけたり、空だった値を「ありそうな値」で埋める規則を書いたりします。どちらも動くので、試したときには気づきません。

埋まった列は、下流では区別できません。画面に出た時点で、それが元からあった値なのか、途中で作られた値なのかは分かりません。数か月後に数字が合わないと分かっても、どこで壊れたかを誰も追えない状態になります。変換の中に判断が埋め込まれると、そこが見えない箱になるからです。

• 対応づけの根拠が残っていない。送り元のどの列を見てそう決めたか分からない
• 空欄を埋める規則が変換の中に書かれていて、外から見えない
• 変換を書き換えた日と、書き換えた人が記録されていない
• 試した結果を人が見ないまま、そのまま本番の流れに入れた

防ぎ方は、AIが作った対応表に、人が承認する列を1つ足すことです。承認されていない対応は動かさない、と決めておきます。空欄を埋める規則だけは、変換の外に出して一覧にしておく。この2つで、後から追えなくなる事故はほぼ防げます。

もう1つ、書き出す先に列を1本足しておくと後が楽になります。その値が元からあったのか、途中で補われたのかを示す列です。1文字で足ります。補った値と元の値が同じ列に並んでいると、数か月後に区別する手段がなくなります。画面を作る側も、補った値を除いた集計をすぐに出せるようになるので、数字が合わないときの切り分けが一段速くなります。

AIに任せてよい工程と、人が決める工程の線

線を具体的に引きます。任せてよいのは3つです。列の対応づけの案出し。変換ルールの下書き。そして失敗した記録の要約です。3つめは効きます。同じ理由で落ちた記録をまとめ、何件がどの理由かを並べさせるだけで、週に1度の確認が短く終わります。

人が決めるのは3つです。1つめは、どの値を正とするか。同じ会社の名前が2通りで入っているとき、どちらを残すかは業務の判断です。2つめは、落ちた行を捨ててよいか。3つめは、止めるか流すかです。この3つはどれも、正解が業務の側にあってデータの側にありません。

いちばん重いのが3つめです。1割が落ちたときに止めれば、その日の数字は出ません。流せば、欠けた数字が会議に出ます。どちらが痛いかは業務で違うので、その場で判断せず、先に線を決めておきます。何割落ちたら止めるか、止めたときに誰に知らせるか、そして流すと決めた日には画面のどこに断りを出すか。この3つを決めておけば、当日の判断が要りません。

線を決めるときの目安も置いておきます。会議で使う数字なら、欠けたまま出すより止めたほうが害が小さいことが多い。日々の運用で使う数字なら、止めると業務が動かないので、欠けたまま流して断りを出すほうが合います。同じ会社の中でも、数字の使われ方によって答えが逆になります。だから流れごとに1行書いておきます。全社で1つの決まりにすると、どちらかの現場が必ず困ります。

内製が成り立つ条件と、成り立たなくなる条件

ここまで来ると、作るか買うかの問いが具体的になります。内製で作るのは、変換の処理そのものではありません。取り出す先とのつなぎ、動かす順番の管理、失敗の見張り、そしてやり直しの仕掛け。この4つを保ち続けることが、仕事の大半になります。変換の中身を書くのは、最初の1か月だけです。

• つなぐ先が2か所か3か所で、その仕様が自社の管理下にある
• 同じ作りを理解している人が2人いて、片方が休んでも動く
• 失敗しても翌営業日まで待てる業務で、夜間に起こす必要がない
• 動かす頻度が1日1回程度で、やり直しが日中に収まる

成り立たなくなるのは、この裏返しが起きたときです。つなぐ先が増えて、それぞれが自分の都合で仕様を変え始める。書いた人が1人で、その人が別の仕事に移る。夜間に落ちたときに起きる人を決められない。連携先の認証情報の更新が年に何度も来る。どれか1つでも当たったら、作るか買うかではなく、その部分だけ買う、という三つ目の選び方を先に検討します。

判断を先送りしたときの形も書いておきます。つなぎだけが増え続け、動かす順番は担当者の頭の中にあり、失敗は誰かが気づいたときだけ直る。この状態は、動いているように見えるので稟議が通りません。止まるのは、書いた人が抜けた月か、連携先が仕様を変えた週のどちらかです。

その部分だけ買う、という選び方を具体にしておきます。つなぎの部分だけを製品に任せ、整える処理は自分たちで書く形が現実的な落としどころになりやすい。理由は、つなぎが手間の割に自社の独自性を生まない一方で、整える処理には自社の業務ルールが入っていて、外に出しても誰も代わりに決められないからです。分ける線は、独自かどうかで引くと迷いません。

買うと決めたとき、契約の前に確かめる項目

製品を使うと決めたら、機能の一覧ではなく運用の条件を見ます。使い始めてから変えられない項目を先に確かめておくと、後から作り直す手間が減ります。確かめる項目を並べます。

• 課金の単位は何か。動かした回数か、運んだ行数か、つないだ先の数か。試験用の環境が別料金になるかも聞く
• 失敗したときの通知先を複数にできるか。通知に落ちた理由が入るか
• やり直しを、期間を指定して自分で流し直せるか。問い合わせないと直せない仕組みだと、日々の運用が止まる
• 送り元の項目が増えたときに、止まるのか素通しするのかを選べるか
• 変換の中身を外に持ち出せるか。他へ移るときに全部書き直しになるか
• つなぐ先が増えたときの追加費用と、対応していない相手にどうつなぐかの手段があるか

見落とされやすいのは3番目と5番目です。日々の運用の重さは3番目で決まり、5年後に身動きが取れるかどうかは5番目で決まります。選定の場では、つなげる先の数が話題の中心になりがちですが、その数は後から増やせます。後から変えられないのは、やり直しの手段と、持ち出せるかどうかのほうです。

試用のときに必ず一度やっておきたいのが、わざと壊してみることです。送り元の列を1つ消して動かし、何が起きるかを見る。止まるのか、素通しするのか、通知は誰に届くのか、そのあと自分たちで流し直せるのか。機能の一覧では同じに見える製品でも、ここの振る舞いは大きく違います。動く様子ではなく、壊れた様子を見て決めます。

小さく始める順番

最後に、着手の順番です。全部の流れを一度に作り替える進め方は、止まったときに切り分けができなくなります。いちばん使われている数字を1つ選んで、その1本を最後まで通してから広げます。

まとめ

データを運ぶ仕組みは、取り出す・形をそろえる・書き出すの3工程です。呼び名を分けているのは、真ん中をどこでやるかだけで、選び分けは書き出し先の力と、業務のルールと、監査で求められる控えの3つで決まります。止まる形は4つに集まります。元の形が変わる、量が跳ねる、時刻がずれる、途中で落ちる。どれも外から来るので、防ぐより、やり直せるようにするほうが早い。同じ記録が2回届くのは事故ではなく前提です。

だから決めるのは、変わらない鍵を選ぶこと、処理と印を1回で書くこと、重なりをデータベース側で弾くこと、印の保存期間を決めること、そして上書きで済む形にできないかを先に見ることの5つです。頻度は鮮度だけでなく、やり直しにかけられる時間の上限から決めます。費用は、動かした回数・運んだ時間・変換の計算資源の3か所で増えます。AIには、列の対応づけの案出しと、変換の下書きと、失敗した記録の要約を任せる。どの値を正とするか、落ちた行を捨ててよいか、止めるか流すかは人が決める。それらしく埋まった列が下流に流れると、どこで壊れたかを誰も追えなくなります。作るか買うかは、変換を書けるかではなく、つなぎと見張りとやり直しを持ち続けられるかで決まります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。