DWH 最新動向

こんにちは、DataRobot の板垣です。一時期と比較するとビッグ・データという用語は浸透したこともあり、ブームは過ぎた感がありますが、蓄積したデータから価値あるデータを抽出し、人工知能（AI）による活用の取り組みを成功させている企業も多く、今後も蓄積した大量データを活用した AI プロジェクトへの取り組みは加速していくことが予想されます。それに伴い、AI と連携可能なデータプラットフォームも選択肢が増えてきました。本ブログではデータプラットフォームの一つである DWH（データウェアハウス）をテーマとし、AI の時代における DWH 選択のポイントを紹介します。

AI の業務利用の拡大と DWH の進化

まずは現在の代表的な DWH の選択肢についてそれらのソリューションが登場した順に見ていきましょう。

2000年代前半- DWH 専用リレーショナルデータベース

DWH と通常のデータベースとの違いは、DWH でははじめからデータ分析を目的としてデータが蓄積されるため、膨大な過去データを時系列に保持する必要があり、従来の SQL を使用した操作で大量データを複数サーバでの分散処理により高速に処理する DWH 専用の RDBMS が登場しました。TeraData は1980年代から並列処理の製品をリリースしていましたが Netezza、OracleExaData、Vertica などが代表的な製品が出揃ったのは2000年代の中頃から後半にかけてです。扱えるデータは数字や文字列といった構造化データが中心ですが、これらの製品は SQL を習得すれば操作可能であることから利用経験のあるデータサイエンティストも多く、当初は BI 用途での大規模データに対する分析クエリやバッチ処理によるデータ加工の高速化が主要な利用形態でしたが、分析サーバで作成したモデルを SQL 関数として実装することでデータの移動なしに DWH 内で予測処理を行う In-database アナリティクス（In-DB Analytics）の手法が登場してから AI での活用も進みました。現在でも AI 製品との連携機能などのエンハンスをしながら多くの環境で利用されています。

 2010年代前半 – Hadoop/Spark

JSON 形式の半構造化/データ非構造化データやさらには IoT などのリアルタイムデータへの対応など、従来の事前定義された表形式のフォーマットでの対応が難しい場合など、Hadoop（Diskベース）や Spark（メモリベース）に代表される分散プラットフォームの採用をする企業も多く現れるようになり、ビッグデータやデータレイクというキーワードもこの頃から使われ始めたのも2010年代前半頃からように思います。DWH としての利用では SQL でのデータ操作も可能であるものの、Hadoop エコシステムと呼ばれるオープンソース由来のソフトウェアの種類も多く、その複雑さから運用管理スキルを持つエンジニアもそれほど多くはないのが現状です。RDBMS をベースとした DWH 製品と比較すると Hadoop/Spark を自社運用するしている企業もそれほど多くはないでしょう。しかし様々なデータフォーマットの大量データを分散コンピューティングで処理することが可能であるため、SaaS 型のデータプラットフォームやサードパーティ製品のバックエンドのデータ処理エンジンとして現在でも広く利用されているテクノロジーとなっています。

2010年代中頃 -SaaS 型 DWH

登場したのは Hadoop がメジャーになり始めた2010年前半ごろですが、一般的に認知され企業での活用が進んだのは2010年の中頃かと思います。上の2つの技術と比較するとクラウド環境のアドバンテージを取り入れた比較的新しい技術ですが、現在では BigQuery/Redshift/Snowflake/Treasure Data など様々なメジャーなサービスが存在しており、市場は急速に拡大しました。クラウド上の各種アプリケーションとの連携により、ほとんどのユースケースにおいてデータ収集からデータ加工まで AI に必要なデータ準備プロセスをクラウド上で完結することができます。従来の SQL でデータ操作もサポートしており、JSON など半構造化データを SQL で操作するスキーマレス DB としての機能を備えた製品もあるため活用の範囲も広く、クラウド環境の特性を生かしたリソースコントールや自動バックアップなどの運用工数の削減も可能です。後発であることから技術的に従来の DWH よりも機能面や運用面において先行している部分もあります。

AI 活用での DWH 選択のポイント

データの収集からデータ準備、予測の実行後の結果の格納までを行う AI ライフサイクルにおける DWH の製品選定では、AI 活用を前提とした機能要件/非機能要件を十分に検討をしていく必要があります。先ほど上でご紹介した DWH はいづれも多くの機能要件をカバーできていますが、サポートしている機能のレベルは製品それぞれに異なります。特に以下のような機能要件の充実度については実際のユースケースに照らし合わせて検討しておくと良いでしょう。

非構造化/準構造化データの格納

従来のデータ型が固定のテーブル形式で表現する構造化データを高速処理できるだけでははなく、AI 活用においても数値や文字以外の音声、画像データなど、収集できるデータも多種多様になってきています。AI で使用する DWH はこれらの非構造化/準構造化データを格納できる「スキーマレス」をサポートする DWH を選択すると変化に強い分析環境を構築可能です。これは分散ファイルシステムをベースに構成される Hadoop/Spark が最も得意とする分野です。

スナップショット機能

テーブルデータのコピーでは DWH のストレージ領域を大量に消費する可能性があるため、データの変更部分のみを差分で保持しながら過去時点のデータを参照可能なスナップショットを取得できる製品を検討すると良いです。スナップショットによりモデルを作成した時点のデータを効率的に保存することが可能です。複数の断面でのデータを使用した検証も可能ですのでスナップショットをうまく利用すると AI 活用において大きなアドバンテージとなります。こちらはストレージの機能でスナップショットを取得するか Snowflake や Hadoop エコシステムの一部の NoSQL など任意の時点のデータにアクセスする機能をもつ DB を検討すると良いでしょう。

ユーザ定義関数（UDF）

DWH 内のデータに対してデータの移動なしに予測処理を行う In-database 分析（In-DB analytics）を実装できると大量データのスコアリング処理の時間を大幅に削減できる可能性があります。SQL 関数で予測結果が取得できるようになると、BI ツールから任意の SQL を使ってのスコアリングが可能になるなど適用範囲が広がります。例えば DataRobot との連携では Prime モデルで外部出力した Python/Java のソースコードやスコアリングコードを UDF で SQL 関数として実装することが可能です。ほぼ全ての DWH がこの機能をサポートしますが利用可能な言語には注意が必要です。

リソース管理/構成変更機能

データ準備のプロセスでは負荷の高い非定型クエリが多数実行されることもあります。スケールアップ/スケールアウトのしやすさとデータ準備/加工処理のリソース要求に柔軟に対応できる構成が取れ、特に異なるワークロードの同時実行が想定される場合にはリソース競合を完全に排除可能なマルチテナント構成が取れると良いでしょう。SaaS 型 DWH では処理のピーク時とオフピーク時に柔軟に構成変更を実施しコストを軽減するなどの運用が容易な製品も登場しています。こちらは SaaS 型 DWH の得意とするところです。

AI の時代に選択すべき DWH は？

どの DWH が AI 活用において最も優れているか？という明確な回答は様々なユースケースに依存するため一概には答えられません。どのようなデータをどの場所に格納し、どのように活用するかにより最適な DWH を選択していただく必要があります。たとえば、セキュリティ上の理由からクラウド環境にデータを保存できない場合には、構造化データのみの分析であればオンプレ環境に DWH 専用リレーショナルデータベースで構築するのが良いでしょう。また、文章や画像データなどを分析する場合には分散ファイルシステムベースの Hadoop/Spark によるデータ管理が適しています。

一方で近年では、高度なスキルをもつ一部のデータ・サイエンティストだけでなく、DataRobot のような 自動化ツールの登場により幅広いユーザーがデータ活用に取り組んでいます。今後もこのような傾向は更に加速するでしょう。シチズンデータサイエンティスト、ビジネスアナリスト、AI エンジニア、データサイエンティスト、などなど、今後様々なデータ活用の担当者が生産性を向上させるためには、それぞれが必要とする種類のデータに随時、簡単で迅速にアクセスすることができる環境が必要とされます。環境構築と構成変更を柔軟に実行することができるだけでなく、製品の開発サイクルが速く技術的に先行しているSaaS 型の DWH をうまく活用していくことが AI 活用を成功させるポイントとなるでしょう。

大手企業が次々にクラウド基盤の採用を打ち出していることもあり、今後 SaaS 型 DWH がパッケージ型（オンプレ）の選択肢を遥かに凌駕していくトレンドは下記の市場レポートにも如実に現れています。

今後 DWH に求めれる要件は？

今後予想される DWH に対する先端的な要件についてもいくつかご紹介させていただきたいと思います。

リアルタイム・ストリーミングデータのロードと分析

定期なバッチで CSV ファイルをロードするのでなく、Kafka などのメッセージキューを連携し、リアルタイムにデータを取り込む機能です。リアルタイムで変動する株価データや10分前のデータではデータの価値が落ちてしまうといったような IoT データ分析やデータの鮮度が重要な場合には必須の機能ですが、 これまでは１秒間に数千万レコードというようなデータボリュームに対しては DWH へのリアルタイムでの取り込みは実現できませんでした。多くの場合、定期実行のバッチ処理で DWH にロードするか、NoSQL-DB のようなリアルタイム取り込みができるソリューションで代替することがありましたが、NoSQL-DB では大量データの加工や分析処理に不向きであり、結果、リアルタイム性が失われ、多くのユースケースにおいてこのソリューション構築は課題となっておりました。

地理空間データのサポート

地理空間情報のデータを使った分析も処方分析には重要な機能です。地理空間特徴量の生成を行うために特定の手法（ある地点や道路または特定の地域などの緯度/経度の情報をジオコーデディングと呼ばれる手法を使い、1つのオブジェクトとして表現する）でデータをストアする必要があるため、一般に Geospatial 機能ともいわれている地理空間情報データを処理する関数をサポートする DWH を選定する必要があります。地理空間データを活用したリアルタイム処方分析の例ではシンプルなものでは現時点の交通量や道路での工事や事故の情報を考慮しながら、最も効果的な配送ルートを提供するといったものがありますし、携帯の GPS 情報から現在の混雑状況を把握し基地局のアンテナをチューニングするといった事例もあります。また地理空間情報の計算は CPU リソースを消費するため、コンピューティング性能と拡張性の高いプラットフォームを検討する必要があります。

これらは既存の DWH 製品やツールを組み合わせることでも実現は可能ですが、現時点では複数の異なるプラットフォームの管理が必要になることが多く、管理の複雑さ、コスト、データ移動などのシステムのサイロ化の課題がありました。近年ではこのような課題を解決し、より高度な分析をリアルタイムに行うためにインメモリ+コンピューティングリソースに GPU を使用した AI との親和性の高い新しいタイプの DWH も登場し始めています。

最後に

いかがでしたでしょうか。AI 活用の視点で DWH 選定のポイントと今後の動向についてお話をさせていただきました。本ブログでご紹介した以外にも DataRobot では様々なデータベースに対応しており、データベースでのみ利用可能な連携機能もございます。これらの機能については次の機会にご紹介させていただければと思います。

執筆者について

板垣 輝広（Mitsuhiro Itagaki）

AI エンジニア

DataRobot AI エンジニア。DWH、Hadoop などのビッグデータのベンダのエンジニアとして物理/論理設計からチューニングなどの技術支援を従事していた経験から、DataRobot では製品サポートからモデルデプロイなど技術的な支援を担当。

板垣 輝広（Mitsuhiro Itagaki） についてもっとくわしく