Data Engineering Study #4「データ分析基盤の障害対応事例LT祭り」 での登壇資料です

1. 正確な意思決定を阻む
問題・障害との向き合い方
id:syou6162
2020/11/04
Data Engineering Study #4「データ分析基盤の障害対応事例 LT祭り」 登壇資料

2. 自己紹介
● 吉田 康久
○ Twitterやはてなidは@syou6162 / id:syou6162
● 前職: NTTコミュニケーション科学基礎研究所
○ 自然言語処理や機械学習の研究に従事
● 株式会社はてな
○ アプリケーションエンジニアとして入社
○ はてなブックマーク
○ サーバー管理/監視システムMackerel
■ 教師なし学習による異常検知機能開発
● 2020年2月よりMackerelチームのCRE (Customer Reliability Engineer)
○ 主にデータ基盤整備 / データ分析
2

3. この発表での話題
● 1: RDBMSでは担保できていた制約がデータ基盤に入れられなかったために集計の
差異が発生した例
● 2: データマートで利用されていないリソースが氾濫、目的に不適合なデータを元に
意思決定されてしまった例
3
地味だけど、あるあるっぽい話題とそ
の対応方法について話します !

4. RDBMSでの制約
● PRIMARY KEY制約やUNIQUE制約などで一意性の担保
○ 例: このカラムに同じメールアドレスが二個以上含まれることはない
● チェック制約による値の条件の制約
○ 例: この機能のフラグがonにできるのは、有料プランのユーザーだけ
● アプリケーションのロジックでも担保されるが、RDBMSはデータを守る最後の砦
4

5. 制約が付けられないデータストア
● データに制約を付けられないデータストアもたくさんある
○ 例: Salesforceやスプレッドシート
● 制約がないと困る例
○ 同じ会社名が複数存在しまくると困る
■ 同名企業は存在し得る。とはいえ...
■ あまりに多いと入力時の確認ミスの可能性
○ 商談が次のフェイズに移ったのに完了日が未記入
■ リードタイムの計算ができない
■ 本来は入力必須の項目になっていて欲しい
○ ある月のある企業の売上が複数行に存在
■ スプレッドシート上の手動オペレーション(コピペ)時のミス
● RDBMSが恋しくなるときもあるが、それぞれのデータストアのよさはある 5

6. 制約が付けられないと、問題・障害が時々起こる...
● 制約が付けられないデータストアをデータ基盤に転送していると、たまに問題が発生
する
○ 例「このダッシュボードで出てる売上、あっちの値より大きいの何で?」
■ 意図せぬスプレッドシートの行の重複があった
○ 例「株式会社XXXさん、ダッシュボードに出てこないの何で?」
■ Salesforceのとあるカラムのステータスの変更漏れがあった
● 仕組み的にどうしようもない場合もあるが、少なくとも問題が起こったら早期に気付
きたい
○ 問題が発生してから発覚したのは1ヶ月後、だと調査も大変
6

7. 対策: 満たして欲しい制約と期待する結果をvalidation
7
定期的にCloud Schedulerで実行。
制約を満たしていなかったら、 Slackに通知。会社
ブログに詳しく書いてます
私「データの重複がありますね ...」
事務の方「データ直しておきます」
私「あれ、このカラムって必須のものではな
い...?NULLが入ってきた」
事務の方「そういうユースケースがあるなら
Salesforceで入力必須にしておきますね」

8. データの民主化とデータマート
● データ基盤が使われだすようになると、データマートにテーブルやビューがたくさん
作られる
○ 基本的にはよいこと!
● とはいえ、お試しで作ったものや一時的な調査のためのものも多数存在
8
データマート
テーブルA
最終利用日: 2020/09
テーブルB
最終利用日: 2018/04
ビューC
最終利用日: 2020/07
テーブルD
最終利用日: 2019/01
テーブルE
最終利用日: 2020/10
ビューF
最終利用日: 2019/06

9. 使われていないリソースが氾濫すると...
● データ分析者
○ よーし、この分析をしよう!
○ ゼロからSQL書くの面倒だな...
○ データマートに何かあった気がするぞ
○ それっぽい名前のものがあったからこれでダッシュボードにしてみよう
● データマートにあったのは実は調査用に作られたテーブル。集約の条件が目的と異
なるものであった...
○ 意思決定の目的に似わないデータによって、誤った意思決定がされてしまう
○ ある種の障害
9

10. 対策: データマートの定期的な掃除
● 四半期に一度、利用頻度の低いテーブルやビューを削除する
● 以下の情報を元に削除対象を決定
○ クエリが最後に発行されたのはいつか
○ クエリが最後に発行したのは誰か
○ クエリが何回発行されたか
● いきなり消えると困る場合もあるので、2週間後にexpireするように設定
○ 必要な場合はexpireを自分で外してもらう
○ expire後に泣きつかれた場合(?)用に、viewならSQLを手元にバックアップ
10
GCP(BigQuery)ならAudit Logや
INFORMATION_SCHEMAでメタ情報が取
れる!

11. 困り事: これ、本当に削除して大丈夫...?
● クエリ統計量だけ出されても、消して大丈夫か自信が持てない場合は多い
○ 参照しているダッシュボードやviewは存在しない? あったら壊れそう...
● 安心して消せるように補助情報を出してあげる
データリネージを元にどこで
使われているかさっと分かる。
ビューの目的がメタデータで分か
る
11
このデータ(左側)がここで使われている (右側)とい
う情報をデータリネージとして整備
依存元がなくなってビューが壊れたら slackに通知
してすぐに気付けるように
詳細はブログをご参照ください

12. この発表のまとめ
● 1: RDBMSでは担保できていた制約がデータ基盤に入れられなかったために集計の
差異が発生した例
● 2: データマートで利用されていないリソースが氾濫、目的に不適合なデータを元に
意思決定されてしまった例
12
地味ではあるけど、あるあるな事例だと思うので
参考になればうれしいです !