半構造化データは、ある程度の組織構造は持っているものの、表形式にきれいに収まるものではありません。JSON、XML、YAML、メールヘッダーなどはすべてこのカテゴリに属します。データには構造を記述するタグやキーがありますが、その構造はレコードごとに異なる場合があります。あるJSONオブジェクトにはあるフィールドが、別のJSONオブジェクトには存在しないこともあります。あるXMLドキュメントは、別のXMLドキュメントとは異なる要素のネスト構造を持つ可能性があります。スキーマは柔軟で、スキーマオンリードと呼ばれることもあります。構造は、データを保存する時ではなく、データをクエリする時に適用されます。
半構造化データは、現代のアプリケーションでよく見られます。APIはJSONを返し、ログファイルはキーと値のペアを使用し、設定ファイルはYAMLを使用します。NoSQLドキュメントデータベースはJSONをネイティブに格納します。この柔軟性は、データモデルが進化したり変化したりする場合に役立ちますが、分析においては課題となります。半構造化データのクエリには、テーブルのクエリとは異なるツールとテクニックが必要です。ネストされた構造をナビゲートし、欠落したフィールドを処理し、配列をフラット化する必要があります。SQLエンジンはこれに対応しており、PostgreSQL、MySQL、SnowflakeはすべてJSON関数をサポートしています。JSONドキュメントを最初に抽出することなく、内部をクエリできます。このように構造化データと半構造化データの境界が曖昧になっているため、両者の区別は重要性を失っています。重要なのは、データが半構造化されているかどうかではなく、効果的にクエリを実行できるかどうかです。
半構造化フォーマット
- JSON — キーと値のペア、配列、ネストされたオブジェクト
- XML — タグ付き要素、階層構造
- YAML — 人間が読める設定ファイル
- CSV — 区切り文字はあるが、型情報は含まれていない
- ログファイル — 可変フィールドを持つタイムスタンプ付きイベント
半構造化データは、その中間的な位置づけにある。有用な構造を持ちながらも、ある程度の柔軟性も備えているため、多少乱雑な部分があっても問題ない。
Comments (2)
Leave a comment