ISID X（クロス）イノベーション本部 アドバンスドテクノロジー部の米谷です。本記事は電通国際情報サービス Advent Calendar 2021の9日目のポストです。
私は現在、 Microsoft Azure を使ったデータ分析基盤の案件支援や研究開発の業務を行っています。本記事では、個人的に最近注目している DataOps というキーワードについて書いていきたいと思います。
- DataOps とは？
- DataOps の必要性
- DataOps で利用する Azure サービス
- Azure データ分析基盤における DataOps
- DataOps のために進化し続ける Azure サービス
- まとめ
DataOps とは？
DataOps とは「データの利用者と管理者が協力してツールやプロセス、組織文化を継続的に改善していく仕組み」という DevOps や MLOps のデータ分析基盤版ともいうべきものです。核となる要素技術としてはデータカタログやオーケストレーションツールの他、 Infrastracture as Code (IaC) や CI/CD といった DevOps や MLOps と共通するものもあります。
DataOps は2018年ごろから注目され始め、2021年現在はガートナーのハイプ・サイクルでも黎明期から流行期に移りつつあり、少しずつではありますが認知度が広がり始めています。 Azure のサービス群でも DataOps の実践に役立つ新サービスやアップデートが増えており、この点も自分が注目している理由となります。
DataOps の必要性
そもそも論として DataOps はなぜ必要なのか？というところですが、最近お客様とデータ分析基盤についてお話するとスモールスタートで徐々に拡張していきたいというご要望を多くいただきます。これには以下のような背景があります。
- 全ての利用者/部門の要件を取りまとめてから構築となるとスピード感が出ないため、限られた利用者/部門を対象として始めそのフィードバックも活かしながら少しずつ拡張していきたい。
- クラウドの特徴を活かし、サイジングなどは利用状況を見ながら適宜スケールさせていきたい。
これらの要望に対してアジャイルというキーワードが出ることもあるのですが、目的に対する実現手段という意味で個人的にはむしろ DataOps の方がマッチするのではと考えています。
※このあたりの違いについて書き始めると長くなるため、本記事では割愛します。ご了承ください。
DataOps で利用する Azure サービス
DataOps が求められる背景を理解できたところで、 Azure のデータ分析基盤で DataOps をどのように行っていけばよいかを考えてみたいと思います。まず、 Azure のデータ分析基盤を構成するサービス群を列挙すると以下のようになります。
| 用途 | サービス |
|---|---|
| データレイク | Azure Data Lake Storage Gen2 |
| データウェアハウス | Azure Synapse Analytics |
| ETL /オーケストレーション | Azure Data Factory |
| データカタログ/データガバナンス | Azure Purview |
上記はデータ分析基盤として使われるであろう必要最小限の構成となります。これ以外でも要件によって Azure IoT Hub や Azure Databricks 、 Power BI などを使われるかもしれませんが以降の説明には大きく影響しないため割愛します。
また、 DataOps の実践にはソースコード管理や CI/CD も必須となります。これらについては、 Azure DevOps や GitHub/GitHub Actions などを環境に応じて選定する形となり、このツールを使わなければいけないというものはないです。私は GitHub/GitHub Actions を使うことが多いですが、メンバーのスキルセットや希望なども考慮して都度決めています。
Azure データ分析基盤における DataOps
利用サービスが整理できましたので、実践方法について説明します。先ほどスモールスタートの例としてあげた「利用者/部門の増加」の場合、新規利用者/部門向けに分析用データを新しく収集し加工した後に BI ダッシュボード用のテーブル/ビューを追加することになります。よって Azure の環境は以下のような影響を受けます。
| 変更内容 | 影響を受けるサービス |
|---|---|
| データソースの追加 | Azure Data Factory |
| ETL ジョブの追加 | Azure Data Factory |
| テーブル/ビューの追加 | Azure Synapse Analytics |
つまり、これらのサービス定義をあらかじめコード化しておき、要件に応じた追加・修正を行った後に CI/CD を回し環境をアップデートしていくことで DataOps が実現されることになります。文章で書くとシンプルですが、実際はそうとも限りません。
例えばソースコード一つ取っても、上記の中には ARM テンプレートで管理されるものもあれば SQL スクリプトのものもあります。CI/CD のパイプラインもレビューやテストをどのように組み込むのかを考えなければいけませんし、それらに対して一定の正解はなく都度検討となります。
一つ言えることは、初めから完璧な仕組みを整える必要はなく、できるところから少しずつ始めていけばよいのではということです。小さく始めて組織の中で徐々に育てていくことが、 DataOps の本質にも通ずるのではないかと思います。
DataOps のために進化し続ける Azure サービス
冒頭で「 Azure で DataOps の実践に役立つ新サービスやアップデートが増えている」と書きましたが、ここで一つ具体例として Azure Data Factory を紹介します。 Azure Data Factory は ETL ジョブを GUI で開発できるサービスです。コーディングレスな実装が可能な一方でこれまでは修正変更なども全て画面上で行わなければならず、またバージョン履歴も持っていなかったため継続的な開発やメンテナンスという面では課題を抱えていました。
この Azure Data Factory がアップデートされ、 Git リポジトリとの連携が可能になりました。
Git 連携にはソースコード管理の他 GitHub Actions などによる パイプライン連携も含まれます。つまりこのアップデートにより GUI での開発生産性を維持しつつ CI/CD を回すという DataOps 実践のための仕組みが整備されたといえます。
このように Azure のサービスは常にアップデートされているため、使い続けることで少しずつ自分たちの環境が理想的な DataOps の姿に近づいていくことが期待されます。
まとめ
本記事は Azure データ分析基盤での DataOps の実践方法について解説しました。今回は概要についての記述のみでしたが、 DataOps は非常に奥の深いテーマです。 Microsoft Docs や GitHub にも参考となるリファレンスがあるのですが、非常に重厚で私自身まだ完全には読み切れていません。
これらについても理解を進め、そのエッセンスを自身の関わる案件に少しずつ適用していけるといいなと思います。
最後までお読みいただきありがとうございました。 ISID のアドベントカレンダーはまだまだ続きますので、明日以降もお楽しみに！
執筆：@yoneya.fumihiko、レビュー：@nakamura.toshihiro （Shodoで執筆されました）
