ベストオープンデータフォーマット：トップピックの比較

オープン データ形式は、データのエンコードと交換に関する公開されたロイヤリティフリーの仕様であり、準拠ツールであればベンダーの許可なしにそれを読み取ることができます。このランドスケープは、エンタープライズ パイプラインで最も広く導入されている JSON、CSV、Parquet、Avro、ORC、RDF Turtle を含む 4 つのファミリー (テキスト、柱状、グラフ、スキーマ/モデリング) にわたる数十の仕様をカバーしています。

オープンデータ形式の説明

オープン データ形式はファイルとフィードの仕様であり、その定義は公的に文書化されており、自由に実装できます。決定基準は人気ではなく、ライセンスとガバナンスです。つまり、料金を支払ったり契約に署名したりせずに仕様を読み、実装し、拡張できる場合、およびベンダーが一方的にルールを変更できない場合、フォーマットはオープンです。

真にオープンなフォーマットと単なる一般的なフォーマットは 3 つのプロパティによって区別されます。まず、仕様の入手可能性 (文法、バイナリ レイアウト、またはスキーマ言語) が完全に公開されています。第 2 に、実装の自由: 複数の独立したプロジェクト (元のベンダーだけでなく) が、準拠したリーダーとライターを提供します。第三に、ガバナンス: 管理は、単一企業の製品ロードマップではなく、標準化団体、財団、またはオープン コミュニティの責任です。

Wikipedia のオープン ファイル形式のリストは方向性マップとしては便利ですが、実際には大きく異なる動作をするカテゴリが混在しています。 ZIP のようなコンテナ形式、CSV のような表形式、Parquet のような列形式、および RDF Turtle のようなグラフィック シリアル化は、それぞれ異なる問題を解決するものであり、それぞれを代替するものではありません。 「オープン フォーマット」を 1 つの決定として扱うエンタープライズ アーキテクトは、通常、最終的に勝者ではなくスタックに終わります。

オープンデータ形式とは

オープン データ形式は、誰でも実装できる構造化データまたは半構造化データ (構文、型システム、および多くの場合スキーマ進化ルール) を表現するための文書化された規則です。仕様が製品です。ライブラリはそれを実装したものです。

形式は 4 つの実用的なファミリーに分類されます。

関連: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

• テキストおよび交換形式 JSON、CSV、YAML、XML、NDJSON。人間が判読可能で、広くサポートされており、API と構成のデフォルトです。ストレージ効率とスキャン パフォーマンスを犠牲にして、透明性とツールの普遍性を実現します。
• 列およびバイナリ形式。 Apache Parquet、Apache ORC、および Apache Avro。圧縮、エンコード、埋め込みスキーマを備えた大規模分析用に構築されています。寄木細工とORCは柱状です。 Avro は、スキーマフォワード設計による行指向です。
• グラフィックスとセマンティック形式 シリアル化された RDF (Turtle、N-Triples、JSON-LD、RDF/XML)、および GraphML や Cypher ベースのエクスポート規約などのプロパティ グラフ形式。これらには単なる構造ではなく意味が含まれています。
• スキーマおよびモデリング形式 JSON スキーマ、Avro IDL、Protobuf .proto、OpenAPI、およびクラウド情報モデルなどのモデル交換仕様。これらはデータを保存するのではなく記述するため、アプリケーション間の相互運用性が実現します。

シリアル化 形式と モデリング 形式の区別は、ほとんどの比較で認められているよりも重要です。 Parquet は、バイトがどのように配置されるかをリーダーに伝えます。共有モデルは、2 つのシステムに「顧客」が両側で同じものを意味することを伝えます。クラウド データ モデリングのシリアル化形式は 2 番目のカテゴリに分類され、多くの場合、統合プロジェクトでは欠落しているレイヤーになります。

オープンデータ形式の意味

「オープン データ フォーマット」の意味はコンテキストに応じて変化し、意味の混同は実際のアーキテクチャ上のエラーを引き起こします。

オープン データ/シビック テクノロジー の意味では、このフレーズは政府または研究のデータセットを、誰でも再利用できるように、機械可読でオープンにライセンスされた形式 (CSV、JSON、さらには RDF) で公開することを指します。 Open Data Format 仕様と、opendataformats.org および odf.dev を中心となって活動するコミュニティはこの伝統に属しており、移植性と公共再利用を重視しています。

私たちの選択: Workato — ビジネスチームが実際に構築できる自動化主導の iPaaS.

データ エンジニアリングの意味では、この表現はパイプラインで使用されるストレージおよび交換形式 (Parquet、Avro、ORC およびそれらのメタデータ レイヤー) を指します。ここでの「オープン」とは、独自のウェアハウスやファイル形式に自分を閉じ込めることを避けることを意味します。

セマンティック Web およびナレッジ グラフ の意味では、これは RDF シリアル化形式と、それが保持するオントロジーを指し、目的は組織間で意味を共有することです。

エンタープライズ統合という意味では、これは、個別に作成されたアプリケーションがカスタム マッピングなしでデータを交換できるようにするスキーマおよびモデル形式を意味します。クラウド情報モデルは、クラウド システムとオンプレミス システムの両方で後者の目標に対処することを目的とした、オープンでアプリケーションに依存しないモデルの一例です。

通常、単一の組織は、公開データのオープン ライセンス、レイクハウスのオープン ストレージ フォーマット、ナレッジ ワークのオープン グラフ フォーマット、アプリケーションの相互運用性のオープン モデルの 4 つの意味すべてを一度に必要とします。

オープン データ形式の利点

オープン フォーマットには 4 つの具体的な利点があり、時間の経過とともに増大します。

ベンダー独立性。 Parquet、Avro、または RDF で書かれたデータは、多くのサプライヤーのツールで読み取ることができます。データはそれを生成したプラットフォームよりも存続するため、移行コストが削減されます。これは、企業がオープン フォーマットを採用する最大の理由であり、調達サイクルを最も効果的に乗り切る理由でもあります。

関連: Matillion — クラウド データ ウェアハウス用に構築されたプッシュダウン ELT.

システム間の相互運用性 共有フォーマットは共有契約です。 2 つのアプリケーションが両方とも登録済みスキーマを使用して Avro を発行すると、統合作業はカスタム マッピングからスキーマ検証に移行します。オープンソース データ モデリング形式は、これを構文からセマンティクスまで拡張しますが、実際に統合コストがかかるのはここです。

耐久性と監査可能性 CSV や JSON などのテキスト形式は、数十年後もテキスト エディターだけで読み取ることができます。公開された仕様を持つバイナリ形式は再実装できます。独自のフォーマットは、ベンダーが存続し、関心を持ち続けるかどうかに依存します。

エコシステムの活用。 オープン フォーマットはライブラリ、コネクタ、ベンチマークを引き寄せます。 Parquet のパフォーマンス ストーリーは、それを最適化する幅広いエンジンと切り離すことができません。 RDF ツール (トリプル ストア、SPARQL エンジン、バリデータ) は、仕様がオープンで安定しているために存在します。

ショッピングの場合: Boomi AtomSphere — ハイブリッドクラウドとオンプレミスの統合のためのエンタープライズ iPaaS.

オープンデータ形式の長所と短所

フォーマット	ファミリー	強み	トレードオフ	ベストフィット
CSV	テキスト	普遍的、解析が簡単、人間が読める	型なし、スキーマなし、引用の曖昧さ、ネストの貧弱さ	エクスポート、小規模な表形式の交換
JSON / NDJSON	テキスト	ユビキタスな入れ子構造、Web API ネイティブ	冗長、ネイティブ スキーマなし、数値型指定が弱い	API、構成、イベント ストリーム
Apache Parquet	円柱状	優れた圧縮とスキャンのパフォーマンス、埋め込みスキーマ	人間が判読できない、行レベルの更新がぎこちない	分析、レイクハウスストレージ
Apache Avro	行バイナリ	コンパクト、スキーマの進化、強力な Kafka 統合	分析のために行指向のスキャンが遅くなる	ストリーミング、レコード指向のパイプライン
Apache ORC	円柱状	強力な圧縮、述語プッシュダウン、Hive リネージ	Hive/Spark の外側の Parquet よりも小さなエコシステム	Hive および Spark ウェアハウス
RDFタートル	グラフ	人間が読めるトリプル、IRI、標準ベースのセマンティクス	大規模で冗長、急峻な学習曲線	ナレッジ グラフ、リンクされたデータ
JSON-LD	グラフ	リンクされたデータのセマンティクスを使用した JSON 構文	コンテキストの処理が初心者を混乱させる	Web公開リンクデータ
Protobuf	スキーマ/バイナリ	コンパクト、高速、強力な型指定、コード生成	自己記述型ではなく、スキーマの配布が必要	サービス間 RPC
JSON スキーマ	スキーマ	言語に依存しない検証、可読性	検証のみ、シリアル化なし	API コントラクト、データ品質ゲート

上記の長所と短所の表は出発点であり、評決ではありません。正直にまとめると、アクセシビリティではテキスト形式が勝ち、分析コストではカラム形式が勝ち、ストリーミング スループットでは行バイナリ形式が勝ち、データとともに意味を伝えなければならない場合はグラフ形式が勝つ、ということになります。

オープン データ形式には価値がありますか

データがツールを超えて存続する必要がある場合、組織の境界を越える必要がある場合、または制御していない関係者によって読み取られる必要がある場合には、オープン形式が価値があります。単一アプリケーション内の存続期間の短い中間状態では、独自のメモリ内表現のほうが高速かつ単純であるため、これらはあまり説得力がありません。

コストは実際に発生しますが、限界があります。 Parquet または Avro を採用することは、スキーマ管理、カタログ化、およびバージョン管理の規律に投資することを意味します。 RDF を採用するということは、オントロジーの設計とクエリのスキルに投資することを意味します。共有エンタープライズ モデルを採用するには、定義に同意していない可能性のあるチーム間でのガバナンス作業が必要です。これらのコストはいずれもフォーマットの問題ではありません。これらはデータ管理の問題であり、独自の形式では移行当日まで隠蔽されるだけです。

実践的なテスト: 形式仕様が明日なくなったとしても、あなたのチームはまだ昨年のデータを読み取ることができますか?答えが「いいえ」の場合、速度に関係なく、フォーマットは負債となります。

オープンデータ形式の問題

オープンフォーマットには、ベンダーがめったに強調しない、十分に文書化された実際の問題があります。

断片化。 「オープン」は「1 つ」という意味ではありません。 RDF だけでもいくつかのシリアル化があり、その中から選択することは実際の決定であり、rdf シリアル化形式の比較が不可欠になります。 JSON には競合するスキーマ方言があります。 Parquet、ORC、Avro はいずれも分析分野のニッチを主張しています。断片化により、統合作業が消費者に押し付けられます。

仕様のドリフトと部分的な実装。 公開された仕様は、実装が準拠していることを保証するものではありません。リーダーは型のサブセットをサポートしたり、ネストされた構造を誤って処理したり、null やタイムスタンプの精度の処理などの特殊なケースで分岐したりする可能性があります。多くの場合、それを確認する唯一の方法はコンプライアンステストです。

ガバナンスのギャップ。 一部の「オープン」フォーマットは、ロードマップを管理する単一のベンダーによって管理されています。仕様は読みやすいですが、事実上の標準はそのベンダーが出荷するものです。これはライセンス上は公開されていますが、実際には公開されていません。

スキーマと意味論的負債。 オープン フォーマットは意味ではなく構文を解決します。 2 つのチームが両方とも有効な Avro を発行しても、フィールドが表す内容について意見が一致しない場合があります。これはまさに、オープン データ モデリング形式と、クラウド情報モデルなどの共有エンタープライズ モデルが埋めるために設計されたギャップです。

運用オーバーヘッド。 スキーマ レジストリ、バージョン管理ポリシー、および互換性ルールの追加プロセス。この規律を持たないチームは、独自のフォーマットでは先送りされていた問題がオープン フォーマットによって表面化することがよくあります。

ビッグ データのオープン データ形式または etl の rdf シリアル化形式を検討する場合、オープン ソースの rdf シリアル化形式を調べ、rdf シリアル化形式のベンチマークを実行して、特定のワークロードに最適なものを判断すると役立ちます。

RDF シリアル化形式の選択

RDF は、エンタープライズ ナレッジ ワークとして最も頻繁に評価されるファミリーであり、そのシリアル化が頻繁に相互に比較されるため、別個に扱う必要があります。 rdf シリアル化形式の比較を実行する場合、さまざまなニーズによって選択が決まります。

Turtle は人間が最も読みやすい RDF シリアル化であり、オーサリングとレビューに通常選択されます。 N-Triples は厳密に行ベースのサブセットであり、各行が独立しているため、ストリーミングと比較に最適です。 JSON-LD は、リンクされたデータを JSON に埋め込み、Web API と JavaScript ツールの実用的なブリッジとします。 RDF/XML は最も古く、最も冗長であり、主に従来の相互運用性のために保持されています。 TriG と N-Quads は、それぞれ Turtle と N-Triples を名前付きグラフに拡張します。

RDF シリアル化形式のベンチマーク では、一貫して同じパターンの結果が示されています。バイナリ形式と圧縮形式は最も速く解析され、占有するスペースが最も小さく、N-Triples と Turtle はその中間に位置し、RDF/XML は一般に最も遅く最大です。 ETL 用の rdf シリアル化形式の実際的な意味は、解析速度がボトルネックになることはほとんどないということです (通常、トリプル ストアの取り込みとクエリ プランニングが支配的です)。したがって、チームは解析時間を微細に最適化するのではなく、読みやすさとツールの理由からシリアル化を選択する必要があります。

ETL パイプラインの一般的なモデルは、ストリーミングと差分抽出可能性のために RDF を N-Triple または N-Quad に配置し、メモリ内で変換し、JSON-LD を API 境界に公開することです。 ビッグ データ用の rdf シリアル化形式 ワークロードの場合、RDF は多くの場合、分析結合用の列形式表現に変換され、グラフはリレーションシップ クエリ用に保持されます。 オープンソース RDF シリアル化ライブラリ (および他の オープンソース RDF シリアル化形式) は、事実上すべての共通言語に存在するため、オープン データ形式を使用する言語にとってこのモデルは実用的です。

クラウドの相互運用性とエンタープライズ AI のためのデータシリアル化形式

クラウドの相互運用性は、信頼境界を越えるのに十分な自己記述型の形式に依存します。 Avro と Protobuf には、データを含むスキーマが含まれています。 Parquet はファイルのメタデータにスキーマを埋め込みます。 JSON スキーマと OpenAPI は帯域外ペイロードを記述します。実現可能なビジネス モデルは、ネットワーク上の Protobuf または Avro、保存中の Parquet、および信頼できる情報源としてのスキーマ レジストリです。

Enterprise AI では、2 番目の要件が追加されます。モデルには、適切に型指定されたデータだけでなく、一貫して 名前が付けられた データも必要です。ソース システム上の 5 つの異なるフィールド名で同じ概念が表示されると、フィーチャー ストア、フェッチ パイプライン、トレーニング セットのすべてでパフォーマンスが低下します。ここで、オープンソース データ モデリング形式が活躍します。アプリケーションに依存しない共有モデル (クラウド情報モデルはオープンな例です) により、基盤となるストレージ形式が変更されても存続する正規の語彙が AI チームと分析チームに提供されます。

ほとんどの企業に対する段階的な推奨事項: 分析の保存には列形式、ストリーミングにはバイナリ行形式、API には JSON、セマンティクスには共有オープン モデルを選択します。モデル レイヤーを耐久性のある資産として扱い、シリアル化レイヤーを置き換え可能なものとして扱います。

重要なポイント

• オープン データ フォーマットは、人気だけではなく、公開された仕様、複数の独立した実装、中立的なガバナンスによって定義されます。
• 実際には、テキスト (JSON、CSV)、列形式およびバイナリ (Parquet、ORC、Avro)、グラフ (RDF シリアル化)、およびスキーマ/モデリング (JSON スキーマ、Protobuf、共有エンタープライズ モデル) の 4 つのファミリーが考慮されます。
• 形式の選択はスタックの決定であり、単一の勝者が決まるわけではありません。ほとんどの企業では、1 つのカラム形式、1 つのストリーミング形式、API 用の JSON、およびセマンティクス用の共有モデルが必要です。
• RDF シリアル化形式のベンチマークでは、解析速度とサイズの点で一貫してバイナリ形式と圧縮形式が有利ですが、通常はトリプル ストアの取り込みが ETL コストの大半を占めるため、可読性とツールが ETL 用の RDF シリアル化形式の選択の指針となるはずです。
• オープン フォーマットで繰り返し発生する問題は、ライセンスではなく、断片化とセマンティック ドリフトです。共有データ モデルは、シリアル化フォーマットが残したギャップを埋めます。

出典と詳細情報

• オープンデータ — Wikipedia: オープンデータは、誰でも目的を問わずオープンにアクセス、活用、編集、共有できるデータです。オープンデータは通常、オープンライセンスに基づいてライセンスされます…
• オープンソース — Wikipedia: オープンソースとは、デジタル リソースをソース コードやソース ファイルとともに公に公開し、使用、研究、変更、再配布を可能にする実践です…
• ビッグ データ — Wikipedia: ビッグ データとは主に、大きすぎるか複雑すぎて従来のデータ処理ソフトウェアでは処理できないデータ セットを指します。多くのエントリ (行) を含むデータには次のような利点があります。
• データ モデリング — Wikipedia: ソフトウェア エンジニアリングにおけるデータ モデリングは、特定の形式的手法を適用して情報システムのデータ モデルを作成するプロセスです。適用される場合があります。

よくある質問

オープンデータ形式とは何ですか?

オープン データ形式は、準拠ツールであれば読み書きできるようにデータをエンコードするための、公的に文書化されたロイヤリティフリーの仕様です。これらには、JSON や CSV などのテキスト形式、Parquet や ORC などの列形式、Avro などのインライン バイナリ形式、RDF Turtle などのグラフ形式、JSON Schema などのスキーマ言語が含まれます。決定的な特徴は、サプライヤーの製品ではなく仕様が契約を構成することです。

オープンフォーマットとオープンスタンダードの違いは何ですか?

オープンフォーマットには、誰でも実装できる公開された仕様があります。オープン標準にはさらに、変更を管理する標準化団体や財団などの中立的なガバナンスがあります。広く使用されている形式の中には、オープンにライセンスされているものもありますが、事実上単一ベンダーによって推進されており、ロードマップに対するコミュニティの影響力が制限されています。長期的な企業データにとって、中立的なガバナンスが最良の保証です。

どのオープン データ形式が分析に最適ですか?

Apache Parquet は、列形式のレイアウト、圧縮、および広範なエンジンのサポートにより、分析ストレージのデフォルトの選択肢です。 Apache ORC は、Hive および Spark 中心の環境における興味深い代替手段です。どちらもスキーマを統合し、述語プッシュダウンをサポートします。通常、決定要因は、生のパフォーマンスの違いではなく、既存のエンジン投資とエコシステム ツールです。

オープンデータ形式は採用する価値がありますか?

データがツールを通過したり、組織の境界を越えたり、制御できない関係者によって読み取られたりする必要がある場合には、オープン形式を採用する価値があります。スキーマ管理とガバナンスのオーバーヘッドが追加されるため、実際の作業が必要になります。アプリケーション内の短期的な内部状態の場合、多くの場合、独自の表現の方が単純で高速です。トレードオフは、持続可能性と相互運用性と運用規律です。

オープンデータ形式はどのような問題を引き起こしますか?

主な問題は、競合する仕様間の断片化、同じ仕様の部分的または分岐した実装、1 つのベンダーがロードマップを制御する場合のガバナンス ギャップ、2 つのシステムが同じ形式を使用しているが意味が一致していない場合のセマンティック ドリフトです。これらの問題はいずれも、フォーマット自体では解決できません。スキーマ レジストリ、適合性テスト、共有データ モデルが必要です。

オープン データ形式はエンタープライズ AI をどのようにサポートしますか?

Enterprise AI は、すべてのソース システムにわたって適切に型指定され、一貫して名前が付けられたデータに依存します。オープン シリアル化形式はキャプチャとトランスポートを処理しますが、クラウド情報モデルなどのオープン データ モデリング形式は、フィーチャー ストア、取得パイプライン、トレーニング セットの整合性を維持する共有ボキャブラリを提供します。モデリング層がないと、AI チームはモデルを作成するのではなく、フィールド名と定義を調整することに不釣り合いな労力を費やします。