【要約】Data Catalog 第2回：Object Storage上のOracle Databaseマニュアルと文書インベントリParquetをカタログ化してみてみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
データエンジニアは、Object Storageに配置した大量のPDFマニュアルの管理において、情報の欠落という課題に直面している。ファイル名やパスだけでは、検索や分析に必要な業務的な文脈を十分に保持できないためである。具体的には、以下の問題が発生する。
- ・製品名や製品バージョンといった識別情報の不足。
- ・公式URLや文書番号などの業務メタデータの欠落。
- ・RAG（検索拡張生成）における利用可否の判別不能。
- ・将来的なデータベース結合（JOIN）に必要な一意識別子の不在。
// Approach
筆者は、文書の実体（PDF）と管理情報（Parquet）を分離して管理するアーキテクチャを採用した。Pythonを用いてCSVから厳格な型を持つParquetを生成し、OCI Data Catalogで両者を統合するアプローチである。
- ・PDFは製品・バージョン・系列ごとに階層化したパスで配置。
- ・PythonスクリプトでCSVの必須項目、型、重複、URL形式を厳格に検証。
- ・検証済みのデータをParquet形式で生成し、Object Storageへ配置。
- ・OCI Data CatalogのCustom Propertiesを用い、PDFに業務メタデータを付与。
- ・Include Unrecognized Files設定により、非構造化ファイルであるPDFをカタログ化。
// Result
検証の結果、10個のPDFと1つのParquetファイルに対し、正確なカタログ化が確認された。これにより、業務要件に基づいた高度な検索と、次ステップのAI活用への準備が整った。
- ・PDFに対し、製品バージョンや公式URLなど7項目のCustom Propertiesを付与。
- ・Parquetから20個の属性（Attribute）を正確に抽出。
- ・製品バージョンやデータ所有者による絞り込み検索を実現。
- ・次回のRAG構築や、外部表としてのJOIN操作に耐えうるデータ基盤を確立。
Senior Engineer Insight
> メタデータをParquetとして構造化し、PDFのCustom Propertiesと紐付ける設計は、RAG基盤として極めて合理的だ。単なるファイル管理に留まらず、将来的なSQLによるJOINを見据えたID設計がなされている点も評価できる。ただし、メタデータのマスターとなるCSVのメンテナンスが手動である点は、運用フェーズでのスケーラビリティに懸念が残る。実戦投入時には、このCSV生成プロセスをデータパイプラインへ組み込み、完全自動化することが必須条件となるだろう。