Databricks Certified Data Engineer Professional 問題集

正解: C

正解の理由
billing.usage は修正に対応していて、使用レコードのどこかが誤っていたとき、Databricks は元の行を書き換えずに2行を足す。RETRACTION の行は元の行と同じ内容で usage_quantity だけが負の値になり、元の誤った使用を打ち消す。RESTATEMENT の行は正しい項目と使用量を持つ。record_type で絞らずに SUM すれば、ORIGINAL と RETRACTION が相殺し、RESTATEMENT の値だけが残る。公式の例も、HAVING usage_quantity != 0 を付けてこの形で集計している。

違う選択肢
「訂正のある時間帯は RESTATEMENT の行を使い、それ以外は ORIGINAL の行を使うように、record_type で場合分けして集計する」… 多くの修正には合うが、元の使用レコードが書かれるべきでなかった場合の修正は、RETRACTION の行だけが足され、RESTATEMENT の行は無い。場合分けではこの時間帯の ORIGINAL が残り、無かったはずの使用が数えられ続ける。
「ORIGINAL のままでよい。修正があると Databricks は元の ORIGINAL の行の usage_quantity を書き換えるので、時間がたてば請求の額と合う」… 修正は元の行を書き換えるのではなく、新しい行を足す形で行われる。ORIGINAL だけを見ていると、誤った元の値がいつまでも残り、請求の額との差は消えない。
「RETRACTION の行を除いたうえで合計する。RETRACTION は取り消された値の控えで、元の行と同じ正の値を持つ」… RETRACTION の usage_quantity は元の値の符号を反転した負の値で、元の行を打ち消すために入っている。除いてしまうと ORIGINAL と RESTATEMENT の両方が数えられ、修正のあった時間帯が二重に計上される。

押さえどころ
レコードは通常12時間以内に入るが、この目安は ORIGINAL の行の話で、RETRACTION と RESTATEMENT の行には当てはまらない。修正は後から届くので、過去の期間の集計も定期的に作り直す前提で組む。日付で集計するなら usage_date を使うと速い。