クラウドデータ連携はココがポイント！～CTO によるドライバー技術解説 第一弾～

（本記事は、CData Software Inc. の Tomas Restrepo CTO によるブログ記事 の日本語訳です。）

本記事は、CData Software のデータドライバーの技術と開発手法についてCData Software のCTO が直接開設するBlog の第一弾目です。CData は300を超えるデータソースに対して、ODBC、JDBC、ADO.NET など多様なテクノロジーのデータドライバーを提供しています。

ユーザーやパートナーとの会話の中で、「ドライバーってそんなに難しい技術じゃないよね。」と言われることがあります。たしかに、多くのデータソースは、HTTP やOData という標準プロトコルをベースにしています。ですが、複数の技術プラットフォームで300を超えるデータソースのドライバーを開発することは、一見した印象よりもはるかに多くの複雑さや難しさを含みます。

これだけの種類のドライバーを開発するには、いくつかのカギとなるテクニカルなチャレンジがあります。この第一弾のBlog では、このドライバー開発を複数の技術ポイントに分け、CData のそれぞれへのアプローチ方法をカテゴライズすることで説明をしていきます。

プロトコルの確認

新しいデータソース向けのドライバー開発の一つ目のポイントは、使われているプロトコルです。

• REST: HTTP でJSON/XML を返す独自のREST ベースのAPI が多くみられます。CData では、これらの独自REST API に対して強力なドライバー実装の基盤を有していますが、それぞれのAPI は基本的な機能（ページング、フィルタリングなど）を異なる方法で実装しているため、ドライバー開発には存外に多くの手間がかかります。
• OData: 多くのデータソースはOData ベースのインターフェースとして公開されています（訳者注：OData は「Open Data Protocol」で、REST API のプロトコルで、Microsoft、Google、IBM などが主導して策定され、グローバルでは多くのAPI がOData 規格で設計されています。）CData では、高度なOData クライアント実装を有しており、OData ベースのAPI に対するドライバー開発をシンプルかつ簡単に開発できます。
• GraphQL: GraphQL でのデータ公開はモダンなアプローチです。コアとなるクライアントでの実装がGraphQL ベースのソースとして公開されているもので、ドライバーによりSQL クエリとGraphSQL ベースのクエリがマップされて利用可能です。
• SOAP: SOAP / WS プロトコルベースのデータソースも存在します。SOAP / WS は多くの場合オペレーションを意識したプロトコルとなっており、連携実装はREST などのAPI と比べて難易度が上がります。
• gRPC: 高いパフォーマンスやビッグデータ操作に利用されることが多いプロトコル。Web サービス間の通信やデータウェアハウス間の通信でよく知要されています。
• データベースワイヤプロトコル: データベースプロトコルとしては、SQL Server（TDS）、MySQL、PostgreSQL、DRDA、SAP Hana などのデータベースで使われているものがあります。通常データベースプロトコルのカテゴリは、データベースエンジンの機能をフル活用できるドライバーが担っており、クエリ機能は幅広いものになっています。それぞれのデータベースプロトコルは、XX 互換というような複数のデータベースにより使われていることが多いです。
• 他のプロトコル: CData では、他の標準プロトコルをドライバーとして開発・提供しています。TDS、LDAP、IMAP などのプロトコルです。これらのプロトコルをSQL に仮想化するためにいろいろな手法を使っています。LDAP は階層型であり、オブジェクトとアトリビュートがテーブルとカラムに定義されます。IMAP のようなE メールプロトコルではメールフォルダをテーブルに定義し、E メール一つ一つがレコード行にマッピングされます。SFTP やFTP のようなストレージプロトコルでは、フォルダをテーブルとして、フォルダ内のアイテムを行として定義します。

このカテゴリ分けにより、ドライバー開発にあたってそれぞれのテクノロジーでどこが難所かを特定することができます。私たちが基本的な機能のドライバー開発での開発工数概算に使われます。例えば、他のプロトコル系のドライバーでは、ネットワーク部分の開発およびデータソースのクエリ言語の方言のサポートが難所になります。

REST およびSOAP データソースのドライバー開発の難所はクエリ機能実装です。Salesforce などのAPI は高機能で、相対的に複雑なクエリが可能です。他のAPI では、クエリ機能は弱く、エンドポイントの全レコードを返す機能だけの場合や、1つのキーにより1つのレコードを返すだけの機能といったものもあります。CData では、基本的にはサーバーサイドに可能な限り複雑なクエリ機能を寄せつつ、多様ななクエリ機能を実装することに力を注いでいます。

シリアライズ

新しいデータソースでまず考慮すべき点のひとつにシリアライゼーション形式があります。ごく一般的なシリアライゼーション形式にはJSON やXML があります。これらのシリアライゼーション形式はパフォーマンスに大きな影響を与えます。過度に冗長なシリアライズは通信時により多くのバイトが交換されるためです。とはいえ、JSON やXML フォーマットは、Arrow、Avro、Protobuf、Thrift などのシリアライゼーションと比べ利用が簡単という点でよく使われています。

単一のシリアライゼーションしか許容しないサービスが連携実装がその分シンプルです。一方、複数のシリアライゼーションを許容するサービスがあります。複数のシリアライゼーション形式が許容される場合は、パフォーマンスに大きなインパクトがあるため、どの形式を使うかを選択することには注意が必要です。例えば、Google BigQuery は、JSON over REST、およびArrow over gRPC のシリアライゼーション形式を提供しています。Arrow over gRPC は転送されるデータが10x の増加となります。

データモデル：構造化データ vs 非構造化データ

CData Drivers では、データをリレーショナルモデルとして利用可能にしています。つまり、テーブルとカラムとしてデータソースをモデル化し、リレーショナルなクエリ言語（SQL-92 ベース）でクエリ可能としている、ということです。ところが、データソースの中には非リレーショナルなものがあります。

非リレーショナルなデータソースは以下のようなものです：

• ドキュメント型データストア： MongoDB、CosmosDB、Cloudant などのJSON ドキュメントストア。
• Key/Value 型データストア： Redis など。
• Graph データベース： Neo4j など。
• 階層型データストア： LDAP、Active Directory など。
• 分析型データストア： Google Adwords、Bing Ads、などの分析処理に密接したもの。
• Raw ストア： JSON、XML、CSV ファイルなど。

それぞれで難所が異なります。よく見られるものでは：

• データソースのクエリ機能: データソースによって機能にばらつきがあります。Raw ストアではビルトインされたクエリ機能はありません。
• 結果セットをテーブルとカラムという形にモデル化する方法。

データをリレーショナルなモデルで利用可能にすることは、多くのケースで有効です。顕著な例は、BI、アナリティクス、データビジュアライゼーションなどのツールから連携してデータを利用するケースです。これらのツールはリレーショナルデータに対してSQL クエリを扱うことで最大の機能を発揮できるようになっています。CData では、horizontal および vertical flattening 機能を最大限に駆使し、これらの分析系のツールが幅広いデータソースを効果的にクエリできようにしています。

メタデータ検出

ドライバーにおいて、リレーショナルモデルのメタデータを検出することは、ドライバー開発のもう1つの難所です：

• 静的（Static）メタデータ検出: 多くのデータソースでは、ドキュメントに記載された静的な（決まった）メタデータを有しています。ドライバーでは、それらのスキーマを独自のスクリプト言語によって定義しています。
• 動的（Dynamic）メタデータ検出: データソースには、動的にスキーマを取得できるものがあります。OData ソースはその最たる例で、[$metadata](https://www.odata.org/blog/queryable-odata-metadata/) をクエリすることで、エンドポイントのリスト、プロパティ、リレーションを取得できます。ほかにも、Salesforce では、テーブルおよびフィールドを検出するためのAPI が用意されています。
• ハイブリッドメタデータ検出: 静的と動的のハイブリッドモデルのデータソースも存在します。例えば、Email（IMAP）ドライバーでは、テーブル（フォルダ）は動的に検出されますが、カラムメタデータは静的（固定）です。逆にテーブルのリストは静的（固定）でも、カラムが動的に変化するデータソースもあり、ランタイムで検出される必要があります。
• RowScan によるメタデータ検出: MongoDB などのJSON ドキュメント型データベースなどでは、スキーマは完全に動的で、ストアされたデータをクエリする固定された方法が示されない場合があります。MongoDB では、同じコレクションの二つのJSON ドキュメントが全く違うフィールドを持ち、単一のスキーマで表現できない場合があります。これらに対しては、CData では、実際にストアされているデータをスキャン（"RowScan"）することで効率的にメタデータ検出を行います。RowScanDepth プロパティでスキャンするレコード数を指定できます。

検出方法は違えど、メタデータの扱いは大きな問題です。データソースによっては、メタデータ検出は大きな負荷とパフォーマンスの悪化を引き起こします。メタデータの適切なキャッシュは、ドライバーのパフォーマンス維持の対策の一つです。また、他のデータソースでは、メタデータモデルが大きく、使用メモリを圧迫することがあります。CData では、メタデータ検出の効率化やパフォーマンス向上を絶えず意識してドライバーを開発・向上させています。

認証モデル

クライアントからデータソースへの認証も開発のポイントです。一般的な認証メソッドは以下を含みます：

• Username/Password/Tokens: 多くのデータソースはベーシック認証を行います。ユーザー名/パスワードや追加トークンという形です。
• OAuth: 近頃のREST ベースのデータソースでは、OAuth 1/2 をサポートするものが多くなっています。OAuth 認証のサポートはドライバー開発を一層複雑にします。それはOAuth の実装にはいくつかのタイプがあるからです:

• id/secret が必須か？その場合、クライアント登録はどこか？
• アクセストークンのリフレッシュ方法は？
• トークンの有効期間は固定か、それとも動的？
• Token signing/encryption キーは、発行されているか、それともユーザーが提供？
• 複数セッションが許容されているか？

• 証明書ベースの認証: 多くのサービスでは証明書ベースの認証が取り入れられています。TSL Client Certificate やJWT Token などが例です。
• SSO: いくつかのデータソースでは、シングルサインオン（SSO）がサポートされています。OAuth ベースのデータソースではシンプルですが、SAML やWS－Federation が使われている場合には、複雑になります。

クエリ機能

ドライバー開発の一番難しい点は、データソース毎のクエリ機能をどこまで実装するかです。新しいデータソースのドライバー化において共通でチェックする点は以下です：

• クエリ結果のページングがサポートされているか？データソースによっては、戻り値のレコード数を制限しています。ページングがフルでサポートされている場合もあれば、まったくサポートされていない場合もあります。
• どんなフィルタリングがサポートされているか？データソースによっては、特定のフィールドにしかフィルタリングが効かないものがあります。また、比較処理の種類が少ないデータソースもあります。
• 対象データソースに集計関数やグルーピングのサポートはあるか？どんな集計関数がサポートされているか？
• JOIN がサポートされているか？よく見られるケースでは、JOIN が片方向、もしくは特定のエンドポイントでしかサポートされていません。OData ベースのデータソースでは、$expand 機能で一定のJOIN 機能がサポートされていることが多いです。
• クエリ結果のORDER がサポートされているか？ORDER 機能のサポートは部分的な場合が多いです。CosmosDB では、クエリ結果に対するORDER はすべてのフィールドには行えません。データソースによっては、ORDER が一方向のみの場合もあります。
• Bulk 処理 がサポートされているか？INSERT/UPDATE/DELETE においてバルク処理がサポートされている場合があります。バルク処理がINSERT だけのデータソースもあります。
• ネストされたデータや、複数のエンティティにわたりリレーションのあるデータを単一のオペレーションでクエリできるか？もしくは、複数のリクエストを単一の処理で行うことができるか？

まとめ

異なるデータソースに対して、高機能のデータドライバーを提供することは単純ではありません。多くの技術的なチャレンジを含んでいるのです。この記事では、CData が新しいデータソース開発の技術的な複雑さを見積る際に判断材料とするポイントを説明しました。

次回は、300を超えるデータソースに対するドライバーを複数のテクノロジーで安定して提供するための製品アーキテクチャについて説明する予定です。

CData のコネクティビティソリューションを実際に試してみませんか？ハイパフォーマンスなデータドライバーの広範なライブラリはこちらからご覧ください。

関連コンテンツ