DataOpsを実践するうえで、あらかじめ予測できる課題があります。DataOpsを成功裏に実践するために、あらかじめ予測しうる課題について理解する必要があります。

DataOpsチーム、特にビッグデータを扱うチームは、他の運用チームにはないいくつかの課題に直面することがあります。

なお、下記記事については以下の書籍を参考元とし執筆を行っております。
(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

目次

• DataOps実践における課題1: アプリケーションデータインターフェイス
• DataOps実践における課題2: データ処理アーキテクチャ
• DataOps実践における課題3: クエリインターフェイス
• DataOps実践における課題4: スキーマ変更
• DataOps実践における課題5: ガバナンス
• DataOps実践における課題6: リソース集約
• まとめ

DataOps実践における課題1: アプリケーションデータインターフェイス

ソフトウェアパッケージを1つの製品に統合する際、アプリケーションプログラミングインターフェース（API）を活用します。それぞれ別のシステム同士は、APIのおかげで、互いに適合し、相互運用することができます。

しかしデータ領域においては、APIに相当するものはありません。必要なのは、アプリケーション・データ・インターフェース（ADI、データの構造的・意味的モデルの規定）です。ADIにより、データ提供者とデータ利用者が独立して検証でき、かつ両者が互いに適合し信頼できるようになることです。

データ構造とセマンティクス(データやコマンドの表現が正しく動作するか判断する基準)の表現を標準化する試みは複数ありますが、広く受け入れられた標準はありません。そのため、データモデルやセマンティクスを表現・確認するためのツールは、各組織に所属する DataOps チームが独自に選択・採用する必要があります。

(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge. Application Data Interface” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

DataOps実践における課題2: データ処理アーキテクチャ

データには 2 つの基本的な方式があります。テーブルで表されるスナップショットと、ストリームで表されるトランザクションです。

この 2 つは、構造からセマンティクス、クエリ、ツール、インフラに至るまで、あらゆる点で異なります。データウェアハウス(DWH)の領域では、この 2 つに対する方法が確立されていますが、データレイクにおいては確立された方法はありません。

• 参考記事：【用語集】DWH（Data Warehouse）
• 参考記事：【用語集】データレイク

現在、DataOps チームがスナップショットとストリーミングの両方をある程度同期しつつ処理するための実装例が提供されています（例: ラムダアーキテクチャ、カッパアーキテクチャ）。しかし、ベンダーが提供するツールでは、こうした実装に対して十分なサポートが得られません。そのため、組織のニーズを満たすアーキテクチャを決定し、それを展開および管理するのは、DataOps チームのタスクです。

(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge. Data Processing Architecture” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

DataOps実践における課題3: クエリインターフェイス

データはクエリインターフェイスがないと利用できません。しかし、ほとんどのクエリインターフェースはベンダーやバージョンに依存し、ベンダーはクエリインターフェースの1つの実装しか提供しません。

SQLは、標準的なデータクエリAPI といえますが、ベンダーの実装レベルにはばらつきがあります。全てのベンダーがカバーしているのは、最も単純なクエリのみです。また、優れたパフォーマンスを得るには、常にベンダー固有の言語拡張を使用する必要があります。

こうした背景のため、別ベンダーへの移行やアップグレードが難しいのが実情です。

この問題は、データ利用者が複数のクエリインターフェースを必要とするため、さらに難しくなっています。DataOpsチームは、複数のインタフェースを提供する必要に迫られるためです。

• 個別または少量のレコードを検索、フェッチ、更新するためのRESTインターフェイス
• 大規模なデータの集合をサポートするバッチ・クエリ・インターフェイス
• リアルタイムの分析およびアラートをサポートするストリーミング・インターフェース

これらのクエリインターフェースに対応するシステムのインフラ、技術、設計は、それぞれ大きく異なります。多くのベンダーは、これらのうちの1つまたは2つだけを提供し、複雑な展開の多くをデータ運用チームに委ねています。DataOpsチームは、全体的なデータ処理アーキテクチャを設計する際に、この点を考慮する必要があります。

(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge. Query Interface” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

DataOps実践における課題4: スキーマ変更

ベンダーは、リリースごとにデータを変更します。アナリストは、新しい分析や可視化のたびにデータを変更する必要があります。

これらの変更により、スキーマ、ひいてはADIは永久に変更される状態になります。変更のたびに、関連するデータパイプラインとアプリケーションの深さ全体を調整する必要があるかもしれません。

DataOpsエコシステム全体をバージョン管理されたテスト済みコードとして管理し、開発環境と本番環境を明確に分離することで、これらの変更に迅速に対応し、問題を迅速に発見することが可能になります。

(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge. Schema Change” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

DataOps実践における課題5: ガバナンス

政府および業界の規制は、データへのアクセス、保持、追跡可能性、説明責任などを対象としています。DataOpsはこれらの規制をサポートし、データ処理インフラ全体でアラート、ログ記録の収集、プロバンス（データの起源）などを提供する必要があります。

データガバナンスツールは急速に成熟していますが、ガバナンスツールと他のデータインフラ間の相互運用性は、依然として大きな課題です。DataOpsチームは、データガバナンスツール間のギャップを埋めることで、規制対応を行う必要があります。

• 参考記事：データガバナンスをどう守る？BigQuery編

(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge. Governance” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

 DataOps実践における課題6: リソース集約

データ処理インフラには大きな負荷がかかるため、プロビジョニングもDataOpsの課題の1つです。DataOpsは、データ保存、移行、クエリ処理、データ起源、ログを考慮する必要があります。

• ストレージは、データの複数リリースや異なる環境に対応できるようにプロビジョニングする必要があります。
• コンピューティングについても、データ転送が許容範囲内に収まるようにプロビジョニングする必要があります。
• ネットワークについても、回避できないデータ転送をサポートするようにプロビジョニングする必要があります。

(参考元：Nik Bates-Haus “Chapter 3. DataOps as a Discipline. DataOps Challenge. Resource Intensive” In Getting DataOps Right, edited by Palmer, Andy, et al., 13-27. Sebastopol, CA: O’Reilly Media, Inc., 2019)

まとめ

DataOpsにおける課題は、DevOpsやその実践であるSRE(Site Reliability Engineering、Google社が提唱、実践しているシステム管理とサービス運用の方法論)とは大きく異なり、データ基盤を扱うが故の特有なものが挙げられます。

DataOps実践の際には、当社がご支援いたします。当社のETLツールである「Reckoner（レコナー）」は、GUIからの直観的な操作を実現し、プログラミング知識なくETLを利用できます。DHW、データレイク等でご相談されたい場合は、是非ご連絡ください。

また、ETLツールについて詳しく知りたい、ETLツールの選び方を知りたいという方はこちらの「ETLツールとは？選び方やメリットを解説」をぜひご覧ください。