ファイル ストレージについて調べる
ファイルにデータを格納する機能は、すべてのコンピューティング システムの中核となる要素です。 ファイルは、パーソナル コンピューターのハード ディスク上のローカル ファイル システム、および USB ドライブなどのリムーバブル メディアに格納できます。しかし、ほとんどの組織では、重要なデータ ファイルは、何らかの種類の共有ファイル ストレージ システムに一元的に格納されます。 さらに、その中央のストレージの場所はクラウドでホストされるため、大量のデータに対してコスト効率に優れ、安全で信頼性の高いストレージを実現できます。
データの格納に使用される特定のファイル形式は、次のような多くの要因によって異なります。
- 格納されるデータの種類 (構造化、半構造化、または非構造化)。
- データの読み取り、書き込み、処理が必要なアプリケーションとサービス。
- データ ファイルを人間が判読できるようにするか、効率的なストレージと処理のために最適化する必要性。
いくつかの一般的なファイル形式については、以下で説明します。
区切りテキスト ファイル
多くの場合、データは、特定のフィールド区切り記号と行ターミネータを使用してプレーン テキスト形式で格納されます。 区切りデータの最も一般的な形式は、コンマ区切り値 (CSV) です。この場合、フィールドはコンマで区切られ、行は復帰や改行で終了します。 必要に応じて、最初の行にフィールド名を含めることができます。 その他の一般的な形式としては、タブ区切り値 (TSV) とスペース区切り (タブやスペースを使用してフィールドを区切る)、および固定幅データ (各フィールドに固定数の文字が割り当てられる) などがあります。 区切りテキストは、人間が判読できる形式で幅広いアプリケーションやサービスからアクセスする必要がある構造化データに適しています。
次の例では、コンマ区切り形式の顧客データを示しています。
FirstName,LastName,Email
Joe,Jones,joe@litware.com
Samir,Nadoy,samir@northwind.com
JavaScript Object Notation (JSON)
JSON は、複数の属性を持つデータ エンティティ (オブジェクト) を定義するために階層ドキュメント スキーマが使用される、ユビキタス形式です。 各属性はオブジェクト (またはオブジェクトのコレクション) である場合があり、JSON を構造化と半構造化の両方のデータに適した柔軟な形式にします。
次の例は、顧客のコレクションを含む JSON ドキュメントを示しています。 各顧客には 3 つの属性 (firstName、 lastName、 contact) があり、 連絡先 属性には、1 つ以上の連絡先メソッド (電子メールまたは電話) を表すオブジェクトのコレクションが含まれています。 オブジェクトは中かっこ ({..}) で囲み、コレクションは角かっこ ([..]) で囲まれます。 属性は name:value ペアで表され、コンマ (,) で区切られます。
{
"customers":
[
{
"firstName": "Joe",
"lastName": "Jones",
"contact":
[
{
"type": "home",
"number": "555 123-1234"
},
{
"type": "email",
"address": "joe@litware.com"
}
]
},
{
"firstName": "Samir",
"lastName": "Nadoy",
"contact":
[
{
"type": "email",
"address": "samir@northwind.com"
}
]
}
]
}
XML (Extensible Markup Language)
XML は、1990 年代と 2000 年代に人気があった人間が判読できるデータ形式です。 大部分は冗長性が低い JSON 形式で置き換えられていますが、まだ XML を使用してデータを表すシステムもあります。 XML では、角かっこ () で囲まれた < を使用して、次の例に示すように、>と属性 を定義します。
<Customers>
<Customer name="Joe" lastName="Jones">
<ContactDetails>
<Contact type="home" number="555 123-1234"/>
<Contact type="email" address="joe@litware.com"/>
</ContactDetails>
</Customer>
<Customer name="Samir" lastName="Nadoy">
<ContactDetails>
<Contact type="email" address="samir@northwind.com"/>
</ContactDetails>
</Customer>
</Customers>
バイナリ ラージ オブジェクト (BLOB)
最終的には、すべてのファイルがバイナリ データ (1 と 0) として格納されますが、上述のように人間が判読できる形式であり、バイナリ データのバイトは印刷可能な文字にマップされます (通常、ASCII や Unicode などの文字エンコード方式を使用)。 しかし、一部のファイル形式では、特に非構造化データの場合、アプリケーションによって解釈され、レンダリングする必要がある未加工のバイナリとしてデータが格納されます。 バイナリとして格納される一般的なデータの種類には、画像、ビデオ、オーディオ、およびアプリケーション固有のドキュメントなどがあります。
このようなデータを扱う場合、データの専門家は、データ ファイルを BLOB (バイナリ ラージ オブジェクト) と見なすことがよくあります。
最適化されたファイル形式
構造化および半構造化データの人間が判読できる形式が便利な場合はありますが、通常は記憶領域や処理には最適化されていません。 圧縮、インデックス作成、および効率的なストレージと処理を可能にする一部の特殊なファイル形式は徐々に開発されてきました。
一般的に最適化されたファイル形式には、 Parquet と Avro が含まれます。
- Parquet は列形式のデータ形式であり、最新のデータ レイクハウスの事実上の標準です。 これは Apache プロジェクトです。 Parquet ファイルには、行グループが含まれています。 各列のデータは、同じ行グループにまとめて格納されます。 各行グループには、1 つ以上のデータ チャンクが含まれます。 Parquet ファイルには、各チャンクに格納されている行のセットを記述するメタデータが含まれています。 アプリケーションでは、このメタデータを使用して、特定の行セットに対する適切なチャンクをすばやく検索し、これらの行に対して指定された列のデータを取得することができます。 Parquet は、入れ子になったデータ型を効率的に格納および処理することを専門とし、効率的な圧縮とエンコード スキームをサポートします。
- Avro は行ベースの形式です。 これは Apache によって作成されたものです。 各ファイルには、ファイル内のデータの構造を記述するヘッダーが含まれています。 このヘッダーは JSON として格納されます。 データは、1 つ以上のレコード ブロックにバイナリ情報として格納されます。 アプリケーションでは、ヘッダー内の情報を使用してバイナリ データを解析し、格納されているフィールドを抽出します。 Avro は、データを圧縮し、必要なストレージとネットワーク帯域幅を最小限に抑えるのに優れた形式です。
- Delta Lake は、トランザクション ログを追加して Parquet 上に構築されるオープンソースストレージ形式です。これにより、データ レイクに格納されているファイルの上に ACID トランザクション、データのバージョン管理、および信頼性の高い更新が可能になります。