データエンジニアは、データランドスケープの貴重でありながら苦痛な部分であるJSONカラムを持つテーブルに必ず遭遇します。これらのカラムは生の真実を保持しますが、文字列解析のためにクエリパフォーマンスに大きなコストがかかります。Apache Iceberg v3は、この問題に対処するためにVariant型を導入し、型付きカラムに近いパフォーマンスでJSONのような柔軟性を提供します。これは、シュレッディングと呼ばれる手法によって実現されます。Variantが登場する前は、2つの悪い選択肢がありました。JSONを文字列として保存することは、取り込みは簡単でしたが、読み込みは遅く、すべてのクエリで文字列全体を解析する必要があり、ストレージも冗長でした。もう1つの選択肢は、JSONを型付きカラムにフラット化することでしたが、スキーマの不安定さと頻繁なマイグレーションにより、クエリは高速になりましたが、運用上の苦痛が生じました。多くのチームは両方を維持することに頼り、新しい情報なしに複雑さを増していました。Variantは、これらのオプションを1つの柔軟で高速なカラムに統合します。これは、行ごとに構造が異なる値のためのデータ型であり、オブジェクト、配列、および日付や小数などのプリミティブ型をサポートします。重要なのは、Variant値はテキストではなくバイナリエンコーディングで保存され、Apache Parquet標準を活用していることです。このエンコーディングは、値をメタデータセクション（フィールド名の辞書）と値セクションに分割し、プリミティブを効率的に保存し、特定のフィールドへの直接ジャンプを可能にします。バイナリエンコーディングは文字列ストレージを改善しますが、ParquetがVariant値を不透明なブロブとして扱うため、完全なカラムパフォーマンスを達成できません。この不可視性により、カラム読み込み、圧縮、プルーニングなどの重要な最適化ができなくなります。シュレッディングは、ファイル形式に内部構造を可視化させることで、これを解決します。シュレッディングは、書き込み時にエンジンがVariant値内で一貫して出現するフィールドを特定し、それらを個別の型付きParquetカラムとして保存することによって機能します。たとえば、user_idやevent_typeのような一般的なフィールドは独自のカラムに引き出され、あまり一般的でない、または変化するフィールドは残りのバイナリカラムに残ります。これは、メールルームの担当者が一般的なドキュメント（請求書、ラベル）を別々にファイリングし、他のアイテムを元の封筒に入れておくのと似ています。メカニズム的には、シュレッディングは各一般的なフィールドに対して、typed_valueとvalueのペアのカラムを作成します。typed_valueカラムは、期待される型に一致する場合にフィールドを保持し、すべてのカラム最適化の恩恵を受けます。valueカラムはフォールバックとして機能し、期待される型に一致しない場合は、フィールドをバイナリVariant形式で保存します。これにより、データの整合性が確保され、一般的なフィールドのクエリが劇的に高速化されます。