目的
ETL を使用して Data Lake と Star Schema を構築しているとします。ストレージ形式は Delta Lake です。ETL の責務の 1 つは、緩やかに変化するディメンション (SCD) テーブル (累積状態) を構築することです。これは、すべての SCD テーブルについて、ETL が毎日完全なテーブルの状態を読み取り、更新を適用してそれらを保存する (完全上書き) ことを意味します。
質問
私のチーム内で議論した質問の 1 つ: SCD (完全上書き) テーブルに時間パーティションを追加する必要がありますか? つまり、最新の (完全な) テーブルの状態を に保存する必要がありますSOME_DIMENSION/かSOME_DIMENSION/YEAR=2020/MONTH=12/DAY=04/?
考慮事項
一方では、Delta Lake には必要なすべての機能 (タイムトラベルと ACID) が備わっています。テーブル全体を上書きすると、論理的な削除が発生し、古いバージョンを照会してそれらにロールバックすることができます。したがって、Delta Lake はほぼ時間パーティションを管理しているため、コードはより単純になります。
一方、私が「ほぼ」と言ったのは、IMHO タイムトラベルと ACID が 100% のユース ケースをカバーしていないためです。到着時間の概念はありません。例えば：
例（時分割が必要な場合）
BA チームは、SOME_FACT/YEAR=2019/MONTH=07/DAY=15データが壊れていることを報告しました (データは到着時間によって処理されるため、事実はどのような場合でもタイム パーティションと共に保存する必要があります)。DEV/TEST 環境で問題を再現するには、1 つのファクト テーブルの raw 入力と 10 の SCD テーブルが必要です。
Data Lake には未加工の入力があるため、事実があればすべてが簡単です。しかし、増分状態 (SCD テーブル) の場合は複雑になります。処理された時点の 10 個の SCD テーブルの状態を取得するにはどうすればよいでしょうか? SOME_FACT/YEAR=2019/MONTH=07/DAY=15これを自動的に行う方法は？
事態をさらに複雑にするために、環境は多数のバグ修正と履歴の再処理を経る場合があります。つまり、2019 年 7 月のデータは 2020 年のどこかで再処理される可能性があります。また、Delta Lake では、処理またはバージョン番号に基づいてのみロールバックできます。したがって、実際にはどのバージョンを使用すべきかわかりません。
一方、日付のパーティショニングでは、SOME_FACT/YEAR=2019/MONTH=07/DAY=15が で計算されたことを常に確信できますSOME_DIMENSION/YEAR=2019/MONTH=07/DAY=15。