CData Software Blog

クラウド連携のCData Software の技術ブログです。

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

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

f:id:cdatasoftware:20181118223313j:plain

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

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

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

プロトコルの確認

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

  • OData: 多くのデータソースはOData ベースのインターフェースとして公開されています(訳者注:OData は「Open Data Protocol」で、REST APIプロトコルで、MicrosoftGoogleIBM などが主導して策定され、グローバルでは多くのAPI がOData 規格で設計されています。)CData では、高度なOData クライアント実装を有しており、OData ベースのAPI に対するドライバー開発をシンプルかつ簡単に開発できます。

  • REST: HTTP でJSON/XML を返す独自のREST ベースのAPI が多くみられます。CData では、これらの独自REST API に対して強力なドライバー実装の基盤を有していますが、それぞれのAPI は基本的な機能(ページング、フィルタリングなど)を異なる方法で実装しているため、ドライバー開発には存外に多くの手間がかかります。

  • SOAP: SOAP/WS プロトコルベースのデータソースも存在します。

  • 他のプロトコル: TDSLDAPIMAP などのプロトコルが存在します。これらのカテゴリのドライバー開発の場合には、たいていフルデータベースエンジンへの多様なクエリ機能が必要です。

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

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

リレーショナル vs 非リレーショナル?

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

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

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

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

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

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

メタデータ検出

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

  • 静的(Static)メタデータ定義: 多くのデータソースでは、ドキュメントに記載された静的な(決まった)メタデータを有しています。ドライバーでは、それらのスキーマを独自のスクリプト言語によって定義しています。

  • 動的(Dynamic)メタデータ検出: データソースには、動的にスキーマを取得できるものがあります。OData ソースはその最たる例で、$metadata をクエリすることで、エンドポイントのリスト、プロパティ、リレーションを取得できます。ほかにも、Salesforce では、テーブルおよびフィールドを検出するためのAPI が用意されています。

  • ハイブリッドメタデータ検出: 静的と動的のハイブリッドモデルのデータソースも存在します。例えば、Email(IMAP)ドライバーでは、テーブル(フォルダ)は動的に検出されますが、カラムメタデータは静的(固定)です。逆にテーブルのリストは静的(固定)でも、カラムが動的に変化するデータソースもあり、ランタイムで検出される必要があります。
  • RowScan によるメタデータ検出: MongoDB などのJSON ドキュメント型データベースなどでは、スキーマは完全に動的で、ストアされたデータをクエリする固定された方法が示されない場合があります。MongoDB では、同じコレクションの二つのJSON ドキュメントが全く違うフィールドを持ち、単一のスキーマで表現できない場合があります。これらに対しては、CData では、実際にストアされているデータをスキャンすることで効率的にメタデータ検出を行います。RowScanDepth プロパティでスキャンするレコード数を指定できます。

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

認証モデル

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

  • Username/Password/Tokens: 多くのデータソースはベーシック認証を行います。ユーザー名/パスワードや追加トークンという形です。
  • OAuth: 近頃のREST ベースのデータソースでは、OAuth 1/2 をサポートするものが多くなっています。OAuth 認証のサポートはドライバー開発を一層複雑にします。それはOAuth の実装にはいくつかのタイプがあるからです:
    • id/secret が必須か?その場合、クライアント登録はどこか?
    • アクセストークンのリフレッシュ方法は?
    • トークンの有効期間は固定か、それとも動的?
    • Token signing/encryption キーは、発行されているか、それともユーザーが提供?
    • 複数セッションが許容されているか?
  • SSO: いくつかのデータソースでは、シングルサインオン(SSO)がサポートされています。OAuth ベースのデータソースではシンプルですが、SAML やWS-Federation が使われている場合には、複雑になります。

クエリ機能

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

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

まとめ

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

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