データベースと機械学習プロセスの関係
さて、ここから上述のプロセスとデータベースの関係について考えてみます。活用対象のデータの全部あるいは一部がデータベースにある場合、機械学習というアプリケーションはデータの利用者という立場でデータベースと相対する形となります。
そのため、いくつかの利用形態があります。まず、データベースには「データを管理し、必要なデータを検索して渡す」という基本的な役割があります。そのままの立ち位置である場合、データベースは機械学習プロセスに必要とされるデータを渡す処理までとなります。
また、データベースはSQL等のクエリ言語によって、集計したり、様々な関数でデータを変換する機能を有しているため、機械学習に必要とされるデータ変換等を実施した上でデータを渡す形で「データ準備」のフェーズの一部までを担う場合も少なくありません。そうすることで、分析システムでのデータ変換コストを抑え、分析システムに渡すデータも減少させることが可能となるため合理的な選択肢となっています。
しかしながら、データベースとしての立ち位置のままでは、結局のところモデル作成や評価の段階でデータは分析システムに移動させなければなりません。そしてそのコストはデータが増えれば増えるほど大きな問題となってきます。活かすべき財産であるデータ量が増え、それを有効に使うために機械学習による分析のニーズが上がったにも関わらず、データ量の増加に対して学習プロセスがスケールできない構造が内在している状態でこれまで機械学習は利用されてきました。
最近、この課題はクラウドの普及によって大きく顕在化しています。自分たちでネットワークから全てを自由に設計可能なオンプレミスと違い、クラウド上のシステムでは、ネットワーク設計における自由度は少なく、多くの場合、データの移動のコストは大きくなりがちです。また、多くのクラウドサービスは、各種サービスは再利用性が高くなるよう汎用的に部品化され、設定ベースで容易に連携できるよう疎結合に設計されていますが、疎結合であるがゆえに各部品間でのデータの移動コストが発生しやすくなってしまっています。
この課題の解決方法の1つとして、データの所在地に軸足を置いた、データストア側での機械学習の実装という流れが生まれているという側面があるのではないでしょうか。
データ構造の差
データストア側に機械学習を実装することで上述の課題の解決を目指す場合、どのような実装が必要となるのかについて、考えていきたいと思います。
その検討に必要な観点の１つとして、データの構造の違いがあります。
機械学習では分析対象のデータ（データセット）を行と列の形で取り扱うことが多く、代表的なものとして、RのDataFrameやPythonのPandas DataFrameが挙げられます。
これらは、リレーショナルデータベースの表とほぼ同じ構造を持ち、列ごとに型を持ち、行が個々のデータを表す構造になっています。つまりデータの構造としては機械学習のデータセットはリレーショナルデータベースの表と適合性が高いという面があります。
ただ、データベース内の表と機械学習の入力となるデータセットでは目的が大きく違います。データベースの表は多くの場合、アプリケーションが規定したデータをそのまま保管しておくものになりますが、データセットは基本的に機械学習のアルゴリズムに合わせて作られます。例えば、表ではnot null制約などが科せられない限り、値にNULLというものが許容されます。しかしながら、機械学習ではnullを許容しないアルゴリズムは少なくありません。その場合、データセットからnullを除外するか何らかの値で補完する必要がでてきます。また、データベースの表では、値をそのまま保持することが求められますが、機械学習で利用する場合には、事前にすべての列の値を0～1の範囲に正規化しておくことが求められるようなアルゴリズムもあります。
これらの違いはデータ構造が似ているからといって、データベースの表をそのまま機械学習のデータセットにはできないケースが多々あるということを表しています。
つまり、この点はデータベース内で機械学習を実装していく上で避けて通れない問題となり、この２つの違いを吸収するような何らかの仕組みが必要となります。
