ビッグデータの解析技術を理解するための視点
ビッグデータ解析の現場が抱える課題
「ビッグデータ」という言葉が使われ始めてから、随分と月日が経ちました。
昨今のデータ分析では、「データ」と言えば当たり前にビッグデータのことを指すと考えても、もはや大げさではありません。
こうした変化は、データ解析を取り巻く環境の歴史的経緯を背景に、データ解析の基本となる考え方や活用される技術、例えばデータベースや処理方法といったものに対する、解析者たちのニーズが大きく変化したことの表れだといえます。
しかし、その一方で、それらの変化は、データ解析の現場で十分に理解されているとは言い難いのが現状です。
なぜなら、データ解析、とりわけ機械学習のプロジェクトは、データエンジニアよりもむしろマーケッターやビジネスアナリストといった出自の人がその中心を担うことが多いからです。
彼ら彼女らはその出自ゆえに、データエンジニアリングの基礎理論に触れる機会が少なく、データベースを始めとする基本的な知識が不足しがちだと言えます。
ビッグデータ解析を深く理解するためには、環境変化に伴うデータ解析プロセスの変化を踏まえた上で、解析技術の流行を正しく理解することが必要です。
そこで、以下では、そうした「解析の現場が抱える課題」を解消すべく、ビッグデータの基礎知識を解説していきます。
データ解析環境の変化：「ペタバイトの時代」
この十数年の間に、データ解析を取り巻く環境は大きく変化しました。
特に、最も変化が著しく、データ解析のあり方そのものに影響を与えたのが、データ処理量の増加です。
ハードウェアやネットワーク通信設備の進化に伴い、時間と費用の両面でコストが大幅に下がった結果、事業者が処理しうるデータ量が格段に増えたのです。
ほんの15年ほど前では、状況が今と全く異なりました。
当時は、MB（メガバイト）単位のデータ量でも事業者が処理するには大きく、GB（ギガバイト）単位では「奇跡のデータ」と呼ばれ、TB（テラバイト）ともなると処理するだけで１億円ものコストを投じなければなりませんでした。
こうした状況は、ネットワーク回線（電話線）の弱さに起因するもので、「ピジョンプロトコル」（ネットワークなんて使わずに電子鳩を使ったほうが早い、という仮説に基づいたプロトコル）などという規格が話題になっていたほどです。
ところが、その後、RFC等を通して”http”（Hypertext Transfer Protocol）などのネットワーク規格が整備されたと同時に、ハードウェアも進化を続けたことで、データ処理の環境は大きく改善されました。
そして、2020年現在では、１億円かかっていたはずのTB単位のデータを個人のハードディスクに収納することができるまでになりました。
データ解析環境は、PB（ペタバイト）単位のデータを取り扱うことすらできる「ペタバイトの時代」とでも呼びうる状況になったのです。
ちなみに、こうした変化が起こることを知ってか知らずか、我先にと「ペタバイトの時代」を先取りしていたのがGoogleです。
世に出始めた当時、後発であったGoogleは「大した検索エンジンではない」との評価を受けていました。
しかし、蓋を開けてみれば、現在のGoogleは、中国の百度（バイドゥ）を度外視すれば、検索エンジン界で他の追随を許さない圧倒的な存在にまで成長しています。
この成長の間、Googleがやり続けていたことといえば、「ただひたすらにデータを貯めて、検索して、出す」という基本動作です。
まだデータ処理量が非常に小さかった頃からデータ蓄積へと投資をし続けていたことは、現在のGoogleの躍進と決して無関係な話ではないでしょう。
データ解析プロセスの変化：「データレイク」の流行
処理できるデータ量の著しい増加は、データ解析の考え方（解析プロセス）を変えました。
データ解析プロセスは、従来の「仮説検証型」から、「全量処理サイクル型（※本記事における便宜上の造語です）」へと変化したのです。
そして、その変化に伴い、「データレイク」と呼ばれるデータ蓄積の考え方も流行するようになりました。
順を追って、みていきましょう。
従来のデータ解析プロセス：「仮説検証型」
メガバイト、あるいはギガバイトの時代、データ解析は「仮説検証型」と呼ばれる考え方に基づいて行われていました。
仮説検証型とは、次のプロセスを経るデータ解析のことを指しています。
- データの蓄積
- 仮設立案
- データサンプリング
- 仮説検証
用途に合わせたデータを集めてきて、調べたいことに対して有力と思われる仮説を立て、仮説に沿ったデータを選び、その仮説が正しいと言えそうかどうかを一部のデータから確かめる、という流れです。
このプロセスは、統計学における「検証」の考え方をもとにしており、データ量が十分とは言えない状況下での分析に適ったやり方です。
実際に、専門的な「データ解析」ではなく、ビジネスの現場における「データ分析」では、仮説検証型が推奨されます。
ビジネスの個々の場面では、そもそも十分なデータを確保できるケースが少ない上に、Excel等の処理可能データ量が少ないツールを用いてデータ処理を行うことがしばしばだからです。
こうした状況下では、少ないデータを有効活用するために、まずは用途を限定する目的で一次情報等（営業パーソンの”肌感”など）に基づいた「よりそれらしい筋の」仮説を立案し、データのバイアスを取り除いた上で検証を行うのが適切な方法だと言えます。
そのため、データ処理量自体が小さかった頃には、データ解析の現場でもこのやり方が通例でした（もちろん、今でも状況に合わせて仮説検証型の分析を行うことはあります）。
ペタバイト時代のデータ解析プロセス：「全量処理サイクル型」
ところが、可能なデータ処理量が著しく増加した現在においては、この限りではありません。
- まず、解析処理を施すのに十分な量のデータが確保されているために「少ないリソースでなんとかやりくりする」必要はなくなりました。
- また、非構造データ（構造、サイズが決まっていないデータ）を含む、これまで取扱えなかったデータも処理できるようになったことで、「それらしい筋」の幅が大きく広がりました。
- さらに、ビッグデータならではの解析手法（例えばディープラーニングなどの機械学習）も登場したことで、もはや人間では出せないような考察を計算から弾き出すことも可能になりつつあります。
これらの状況変化を背景に、2020年現在のデータ解析現場では、「全量処理サイクル型」とも呼ぶべき解析プロセスが主流になっています。
全量処理サイクル型とは、次のプロセスを経るデータ解析のことを指しています。
- 全量データの蓄積
- 解析
- 仮設生成
- 検証
- 全量サンプリング
まずはとにかくありとあらゆるデータを貯めて、そのデータに対してアプローチをかけてみる。
その上で、「この角度で調べてみよう」という仮説をたて、それに対して検証を行った上で、検証結果から全量データに対してサンプリングを行う、という流れです（なぜ「サイクル」型と呼ぶのかについては、次の節で触れます）。
全量処理サイクル型が従来の仮説検証型と異なるのは、主に次の3点です。
- 蓄積するデータを限定しない（後述する「データレイク」の考え方）
- 仮説生成の前に解析をはさみ、まずはデータから言えそうなことを先に抽出する
- 検証結果を全量データを用いてサンプリングし、仮説の精度を高める
これらは、いずれも処理可能なデータ量が大きくなったことで可能になりました。
2020年現在、およそ「ビッグデータ」と呼ばれる領域での解析は、一様に、こうした解析プロセスを経ていると言えるでしょう。
全量処理サイクル型解析におけるデータ蓄積の考え方：「データレイク」
先ほどみた解析プロセスの変化ポイントのうち、特に重要なのが1点目の「蓄積するデータを限定しない」という考え方です。
「データレイク」と呼ばれるこの考え方は、2020年現在のデータ解析、とりわけ機械学習の現場で流行しています。
データレイクの要点は、次の2点です。
- 構造などについては一切考えずに、生成されたデータはとにかくまず、一旦貯める。
- データの用途についてはあとで考える。
かつて、処理可能なデータ量が少なかった時分には、「データの質」を問うことが重要でした。
「そもそも何のために分析を行うのか」、「ゴールとなる要件は何か」、「要件を満たすために求められる分析は何か」、「そのためにはどういった仮説を出す必要があって、どういったデータの準備が必要か」といった目的志向の要件定義が求められ、データを蓄積するにあたってはその用途が大切な要素でした。
「今はよくわからないけど、後々なにかの役に立つかもしれないからとりあえず録画しておこうか」といった贅沢なデータ蓄積は夢のまた夢だったのです。
ところが、データ処理量が格段に増えた現在では、蓄積時点ではデータに質を求める必要がなくなり、とにかく玉石混交、さながら湖のようにデータを集めるようになりました。
こうしたデータレイクの考え方の背景には、機械学習を始めとしたデータ解析における次のような事情があります。
- データ解析では、機械学習のように予測したいものに応じて、必要なデータが変わる。
- データは一回捨ててしまったらもう使えない。
- 解析の目的は都度つど変わるので、データの母数を定める為には「母数の母数」を定める必要がある。(目的が多岐に渡る)
データの価値をその時々の主観で決めるのではなく、将来を踏まえて、とにかく価値があるものとして保存しておく。
この考え方は、ビッグデータの解析を理解する上で非常に重要なので、覚えておきましょう。
ビッグデータの解析には「大量・高速」が必要
前節でみたデータ解析プロセスの変化は、解析技術に対するニーズの変化も引き起こしました。
2020年現在、新しいデータ解析の手法には、従来以上に、大量データの高速処理が求められるようになっています。
「全量処理サイクル型」の解析では、サイクル型の名の通り、下記プロセス（再掲）をいちサイクルとして、このサイクルを何度もぐるぐると回すところに特徴があります。
- 全量データの蓄積
- 解析
- 仮設生成
- 検証
- 全量サンプリング
データ量が増加して幾通りもの解析が可能になると、解析を行うごとに異なった仮説や考察が導かれる可能性があります。
また、データは見方によって変わるので、一つの結果が必ずしも正しいとは言えません。
したがって、一回の解析の結果を鵜呑みにしてしまうと、「隠された」より精度の高い仮説や考察を無視してしまうことになってしまうのです。
そのため、ペタバイトの時代における解析プロセスでは、全量データに対して何度も解析サイクルを回すという手法を採っています。
そして、ここで必要になってくるのが、「大量・高速」処理に耐えうる技術・手法です。
ただでさえ量の多いデータを精度が高まり切るまで何度も解析し続けようとすると、大変な時間がかかってしまいます。
さらに、これを複数人によるプロジェクトで同時作業を行う前提で考えると、大量データの処理速度の問題は、より深刻な事態になります。
この問題は、一方では、データの収納先であるサーバー側の課題として捉えることができます。
また、他方では、データを処理するクライアント側の問題として捉えることもできます（現在の標準的なパーソナルコンピュータの仕様である「メモリ8GB（開発用でも32GB）」で機械学習を行うのは、「かなりキツい」と言わざるを得ません）。
こうした事情から、ビッグデータ解析では、大きく次の2点について、技術・手法の変化が求められることになりました。
- サーバー側：データベースの処理速度を速くする
- クライアント側：PCの処理速度を速くする
結論を先取りすれば、2020年現在では、データベースは「NoSQL（ないしエッジコンピューティング）」、PCは「並列分散処理」による課題の解決が試みられています。
次章で、これらの概念について、順にみていきましょう。
ビッグデータ解析を支える技術①：データベース
技術ニーズの変化：「大量」志向のデータベース
前章で解説したデータの「大量・高速」処理に向けた、一つ目の対応策は「データベース」の改善です。
全量データサイクル型の解析プロセスを高速に回すため、「大量」志向のデータベースが求められるようになってきました。
そもそもデータベースとは、「複数人でデータを共有・利用するために、検索や蓄積が容易にできるよう整理されたデータの集合」のことです。
ここで大事な視点は、データベースが「複数人による作業の共有やデータの加工」を暗黙の前提としていることです。
ペタバイトの時代には、データベースが、先に見た「データレイク」としての役割を果たすことを求められます。
データレイクには、音声や動画などの非構造データを含む、玉石混交の多種多様なデータが大量に格納されることになります。
それらの大量のデータを複数人で同時に共有・加工していくためには、次節でみるように、いくつかの点で従来のデータベースには限界があるのです。
こうした事情を背景に、次の2つの方向で、データレイク向きのデータベースに対する技術的ニーズが高まっています。
- 大量蓄積＆大量同時加工できるデータベース → NoSQL
- 大量蓄積＆大量同時加工を回避できるデータベース → エッジコンピューティング
次節以降で、従来のデータベース、NoSQL、エッジコンピューティングのそれぞれについて、順に説明していきます。
従来のデータベース：RDBMS
RDBMSとは？
従来のデータベースは、RDBあるいはRDBMSと呼ばれるものが主流でした。
RDB（Relational Database、リレーショナルデータベース、関係データベース）とは、データ全体を複数の「表（ひょう、テーブル）」の形に分割して、それぞれの「表」の関連性を定義づけることで、データ同士を関連づけるような構造をしたデータベースのことです。
RDBでは、データの一つ一つが表内の列（カラム）と行（レコード）のカテゴリごとに区分けされたセルに格納されており、利用するときは反対にその列と行を頼りに表からデータを取り出します。
身近なもので例えるならば、Excelのシート１枚１枚がテーブル、複数のシートが集まったファイルがRDBといった関係です。
Excelでも似た経験があるかと思いますが、RDBは、格納されるデータの種類や量が増えてくると、テーブル間の関係が複雑になり、扱いづらさが増してきます。
そこで生み出された、RDBを効率的に管理するためのソフトウェアがRDBMS（Relational Database Management System、リレーショナルデータベースマネジメントシステム、関係データベース管理システム）です。
RDBMSでは、SQL（Structured Query Language）と呼ばれるコンピュータ言語を用いて、データベースの格納先であるテーブルをつくったり、そのテーブルにデータを納めたり、逆にそこからデータを取り出したり、あるいは加工したりできます。
先ほどの例で言えば、Microsoft社の開発したExcelというソフトウェアそのものがRDBMSにあたると考えればわかりやすいでしょう。
Excelでも、”if”や”sum”といった関数を打ち込むことで表計算を行わせたり、GASやマクロといった機能を用いて高度な処理を行わせることができるのと、考え方としては同じです。
RDBMSには、次のような特徴とメリットがあります。
- データが複数の表の連関として構造化されている → データの整合性を維持しやすい
- 直感的に理解しやすいSQLという専用言語がある → データの加工が行いやすい
これらのメリットから、NoSQLが登場するまでは、「データベースといえばRDB（あるいはRDBMS）」が常識でした。
RDBMSの種類
RDBMSと一口に言っても、開発元の事業者によって複数の種類があります。
ちょうど、MicrosoftがExcelを出し、AppleがNumbersを出し、GoogleがSpreadsheetを出しているようなものです。
2020年現在、主要なRDBMSと事業者は次の通りです。
|
ソフトウェア名 |
事業者 | 料金 | 主な用途 | サイズ |
特徴 |
| Oracle Database | オラクル | 有料 | ・金融機関などの基幹システム | 〜500TB | ・安定したソースコード（バイナリ）
・ドキュメントの充実性 ・宣言の容易さ ・規則の集中化 ・データロードする場合の柔軟性 |
| Microsoft SQL Server | マイクロソフト | 有料 | ・業務
・基幹システム（金融を除く） |
〜10TB | ・GUIがとても優れている |
| MySQL | オラクル
（オープンソース→サンマイクロシステムズによる買収→オラクルによる買収） |
無料 | ・研究
・学習 |
〜1TB | ・世界規模で考えた場合、ポスグレよりコミュニティが広い
・ドキュメントも最近は大分揃ってきた印象がある |
| PostgreSQL | オープンソース
（開発元：PostgreSQL Global Development Group） |
無料 | ・研究
・学習 |
〜10TB |
利用者の割合は、世界で50％近いシェアを持つOracle Databaseを筆頭に、次いでMicrosoft SQL Server 、MySQL、PostgreSQLの順になっており、この４ソフトでシェアの大半を占めています。
RDBMSの限界点
データ処理量の増加と解析プロセスの変化を受けて、近年、RDBMSの課題が浮き彫りになり始めています。
RDBMSの限界点は、大きく次の3点です。
- 増加する非構造データに対応しにくい
- 分散アーキテクチャに向いていない
- 大人数での作業に向いていない
1点目は、ウェブサイト、音声データ、言語データといった、構造やサイズが決まっていない非構造データとRDBの構造との整合性がうまく取りにくいことです。
非構造データは、その名の通り構造化、つまりCSV（テーブル）の形式ではないため、RDBMSへの格納が難しいという問題点があります。
また、格納できたとしても、今度はデータを取り出すときに形式変換が必要となり、作業の手間やストレスが増してしまいます。
2点目は、RDBMSの構造が、データの分散処理に向いていないことです。
後に説明するように、データの大量・高速処理の必要性は、データの分散並列処理に対するニーズを大きくしました。
しかし、RDBMSは分散並列処理を前提としてつくられてはいません。
そのため、RDBMSはビッグデータを取扱う際の処理速度が十分に上がらないという問題を抱えています。
3点目は、「ロック」による作業効率の悪化の問題です。
RDBMSでは、複数人数での作業の際、他の人が動かせないようにするためのロックという機能が働きます。
しかし、ビッグデータを扱うような大掛かりなプロジェクトの場合、作業人数も多くなるため、ロックによる作業停止時間がそれだけ増えてしまうのです。
そのため、実際の現場ではデータの加工時間が重ならないような工夫をうまく施すなどの対応が必要となり、作業者にとっての手間とストレスが大きくなってしまっています。
このように、RDBMSは、ビッグデータの解析を行う上で、とりわけ複数人数で同時作業を行う上でのデータベースとしての課題を抱えています。
次に紹介するNoSQLは、まさにこうした課題を克服するものとして考案され、ペタバイト時代のデータベースとして急速にニーズが高まっているものです。
データベースの大量化：NoSQL
NoSQLとは？
NoSQLとは、「関係データベース管理システム（RDBMS）以外のデータベース管理システムを指すおおまかな分類語（Wikipediaより、丸括弧内は筆者追記）」のことで、NoSQLの”No"は”Not only SQL”の略語であると解釈されることが通例です。
NoSQLは、データの大量生産・大量同時加工に対応するための解決法として登場し、RDBMSと比べて次の3点に優れると言われています。
- スケーラビリティ
- パフォーマンス
- フレキシビリティ
これらの特徴は、ビッグデータ解析のソリューションとしての適性をNoSQLに与えており、2020年現在、とりわけ機械学習分野での必要性が叫ばれています。
このNoSQLを産業界でいち早く導入したのが、GoogleとAmazonの二社です。
前者は2005年に”Big Table”、後者は2012年に”Amazon DynamoDB"と呼ばれるデータストレージシステムを開発しています。
両社がビッグデータソリューションとしてのNoSQLに素早く乗り出したことは、Googleが（本記事でも紹介したように）データ処理量が小さかった時代からひたすらに「データを貯めて、検索して、取り出す」ことに投資をし続けていたことや、Amazonが基幹事業であるECサイトでのトラフィック量をビジネスモデル上の生命線としていたことから、経営判断として自然な流れだったのかも知れません。
NoSQLの事業者
2020年現在、NoSQLには、いくつかのサービス提供事業者が存在します。
データ解析の現場でよく聞かれる主な事業者は、次の通りです。
| 事業者名 | 特徴 |
| cassandra | ・ペタバイト以上のデータ管理、大量データの書き込み、更新に強い
・メール、ストリーミング、IOT ・マルチデータセンタ間連携（ituneとかで使われている） |
| redis | ・高速処理
・1プロセス、1ノード数百万秒 |
| mongoDB | ・非構造データに強い、スキーマ定義なしでJSONを保存（とりあえずためておくようなイメージ）
・インプットしたデータを引っ張るシステムが強い |
データベースの大量化に対するアンチテーゼ：エッジコンピューティング
エッジコンピューティングとは？
NoSQLは、データ処理量の増加と解析プロセスの変化に対応するために、データベースそのものを「大量化」していこうという考え方でした。
これに対して、中央サーバーであるデータベースそのものだけで対応するのではなく、「現場側である程度のデータを処理してしまおう」という「プロセスの効率化」の考え方に基づくソリューションが、「エッジコンピューティング」です。
エッジコンピューティングとは、「データの生成元、または、その近くでのデータ処理を容易にするソリューション」のことです。
例えば、利用者のスマートフォン内でデータをそのまま処理してしまったり、利用者に近いエリアのネットワークにサーバを配置して、処理を行ってしまったり、といった具合に用いられます。
これは、AWSやGCPなど、クラウドコンピューティングがサーバを集約してデータを集中処理する「集中処理型」のデータベースとは一線を画するやり方だと言えます。
欧米では集中処理型が流行しているのに対して、日本ではこのエッジコンピューティングが流行しています。
エッジコンピューティングのメリット
エッジコンピューティングには、クラウドサービスと比較して、次のようなメリットがあります。
| エッジコンピューティング | クラウドサービス |
| 近いエリアのため、数ミリから数十ミリのタイムラグで低遅延によるデータ処理が可能 | クラウドサービスへのアクセスする場合は、通常数百ミリから数秒のタイムラグが発生する |
| データを収集する端末機器から近いエリアのエッジ側で処理するため、クラウドサービスの故障の影響を受けずに、一定の時間、エッジ側で稼働させるなど持続可能性を担保できる | クラウドサービスが何らかの障害でサービスがダウンした際、重大なビジネス機会の損失する |
| エッジ側のローカルデバイスでデータを収集処理するため漏えいリスクが少ない | クラウドサービスは個人情報などの機微なデータを集中的に蓄積するため、外部からの攻撃によるデータ漏えいなど、データを悪用されるリスクがある |
こうした特徴から、エッジコンピューティングは、次のような目的で用いられる傾向にあります。
- 低遅延によるリアルタイムでのデータ処理
- 分散処理やトラフィックの最適化
- 通信コストの削減
- セキュリティやBCP対策、データガバナンスの強化
エッジコンピューティングとIoT
エッジコンピューティングが日本で流行している背景の一つに、「IoT（Internet of Things）時代の到来」があります。
IoTとは、「世の中のあらゆるモノをネットワークに接続することで、さまざまな付加価値を生み出すことを目的としたITインフラストラクチャ」のこと（JRIレビュー（北野2017））で、身近な例で言えば「スマート家電」などのイメージです。
IoT時代には、あらゆるモノやコトがインターネットにつながることで、膨大なデータ量が流通し、従来のクラウドコンピューティングでデータを集約・処理するだけでは対応が追いつかなくなる可能性があります。
膨大なデータをネットワーク経由でクラウドサービスに転送すると、データ転送量が膨大となってしまうからです。
そこで、注目を集めているのがエッジコンピューティングです。
IoT時代の膨大なデータ量に対応するためには、低遅延での通信が求められるリアルタイムアプリケーションの利用が必要になります。
エッジコンピューティングでは、利用者に近いエリアのエッジ側でデータを処理することができるため、ネットワーク通信の速度を落とすことなく、リアルタイムにデータを処理することができるのです。
20世紀を代表する製造業大国である日本で、モノのインターネットであるIoTの補完的な役割を果たすエッジコンピューティングが流行していることは、決して偶然ではないでしょう。
ビッグデータを支える技術②：処理方法
技術ニーズの変化：「高速」志向の処理方法
データの「大量・高速」処理に向けた、二つ目の対応策は「処理方法」の改善です。
全量処理サイクル型の解析プロセスでは、全量データをうまく処理し続けるための処理方法が必要になります。
具体的には、「並列分散処理」と呼ばれる処理方法が採用され、その実行のために、spark（データ処理ライブラリ）とHadoop（処理実行エンジン）というツールが用いられることが一般的です。
並列分散処理とは、簡単に言えば、「1台のパソコンで行なっていた処理を1,000台のパソコン（サーバー）で実行する」という考え方です。
これは一見、良さそうな考え方ですが、この処理を行うためには、各パソコンへのデータの転送、エグゼキュートのタイミング、各サーバーの制御、ハードの制御、メモリの制御、整合性、結果の集約と数多くの付随タスクが発生してしまうため、大変な労力がかかってしまいます。
そこで、これらの付随タスクを自動的に行なってくれるのが、sparkとHadoopです。
このように、sparkとHadoopを組み合わせることで、並列分散処理による全量データの高速処理が可能になりました。
では、これらの概念について、順に詳しくみていきましょう。
二つの処理方法：シリアル（直列集中処理）とパラレル（並列分散処理）
データ処理には、シリアル（直列集中処理）とパラレル（並列分散処理）という二つの考え方があります。
両者は、1台のパソコンだけで作業を行うか、複数のパソコンで同時並行的に作業を行うか、の違いです。
シリアルとパラレルは、互いにメリット・デメリットがあり、一概にはどちらがいいと言えない関係にあります。
このことを、具体的に、二つの例から考えてみましょう。
まずは、プールにホースで水を入れる場面を考えてみます。
このとき、1本のホースと多数のホースのどちらで水を入れるのが早いでしょうか？
直感的には多数のホースで入れる方が早そうですが、実は、必ずしも常に多数のホースが早くなるとは限りません。
多数のホースで水を入れるという処理を行うためには、当然のことながら、多数のホースを同時に取り扱うための別の処理が発生します。
あるいは、蛇口が一つしかなく、一つの蛇口から多数のホースへと水を分散させる場合はどうでしょう。
こういった事情を鑑みると、場合によっては、1本のホースが早く水を入れられることも十分にありえます。
次に、別の例として、トランプの並び替え作業を考えてみましょう。
このとき、1人でトランプを並び替えるか、4人で並び替えるか、どちらがより効率的でしょうか？
実は、この場合も、必ずしも4人の方がうまくいくとは限りません。
4人で並び替えを行った後には、整合性を見て、集約処理（どう4人に作業を分散し、どう結果をまとめるか）を行う必要が別途出てくるからです。
これらの例と同じく、実際に、機械学習における並列分散処理でも、分散、集約という別作業が発生してしまうために、一概に並列分散処理が良いという見方はできません。
また、機械学習の主なプログラミング言語であるpythonは、実態の仕様として、並列分散処理を用いた高速処理には不向きであるという難点もあります。
このように、並列分散処理はあくまで、大量のデータを処理する際に、処理方法に沿ったツールを用いることで初めて効果的になる方法だという点に注意してください。
並列分散処理のためのデータ処理ライブラリ：spark
sparkは、並列分散処理においてデータの処理速度を向上させるためのデータ処理ライブラリです。
並列分散処理では、データを一時的にある場所におかなければらならず、それをハードディスクにおいていたりすると非常に時間がかかってしまいます。
sparkでは、ハードディスクに一時的にデータを貯めることをできる限りなくそうとした結果、データの送受信が少なくなり、結果として処理速度を向上させることができました。
sparkには、使い勝手の良いライブラリが豊富にのせられています。
例えば、SQLを組み込むことができる「sparkSQL」、spark用の機械学習のライブラリとツール群、グラフ処理エンジンがついている「Millib」などが有名です。
中でも、「pyspark」は、pythonの実行環境を十個、二十個使うことで、pythonで書いたコードを並行処理できる仕組みで、並列分散処理におけるpythonの実行処理の遅さをリカバーすることができます。
並列分散処理のための実行エンジン：Hadoop（Hadoop yarn）
全量データの並列分散処理では、一つのクエリを投げるだけでも、立ち上げて、分散させて、集約させるという処理がかかるため、本来1秒で終わるはずの処理が15秒もかかってしまいます。
こうした課題に対して、1000台単位のサーバーを繋いで同時並行的にデータ処理させるための実行エンジンがHadoop（Hadoop yarn）です。
Hadoopでは、データを分ける先を分類させて、仕分けされたデータ毎に処理を行うことで処理の高速化をはかっており、1台のパソコンだと処理に1週間を要する1TBのデータソートを、わずか62.5秒で実行することができます。
Hadoopの構成は、次の通りです。
- HDFS（分散ファイルシステム）
- yarn（リソース制御、分散させるという制御そのものが独立する）
- spark
- ストーム処理
- map,reduce（バッチ処理）
- MAP（データを分ける先）
- REDUCE（分類、仕分けされたデータ毎に処理）
ここで、構成からもわかるように、先ほど説明したSparkは、Hadoop yarnと使うことで初めて効果を発揮することに注意が必要です。
なお、センサデータなどの桁違いなビッグデータでは、HadoopとSparkをセットにした状態で、かつCassandra（NoSQLの一つ）を用いることができる、「apache Cassandra 」がよく用いられます。
apache Cassandraは、Instagram,prestation,netflix,apple,facebookといった主要アプリケーションで使える他、どれだけデータが大きくなっても処理できるという特徴があり、apache Cassandra＋Hadoop+sparkのセットでは、500万〜600万円という安価でビッグデータの高速処理を行うことができます（ちなみに、Oracle Exadataは1億円以上かかります）。
まとめ
以上、機械学習を中心に、ビッグデータの解析現場において重要な技術について、ニーズが高まった歴史的背景をもとに紐解いてきました。
本記事で説明した内容を改めてまとめると、次の通りです。
- 機械学習の現場でビッグデータを取り扱う上では、データ解析環境の歴史的経緯を背景とした、データ解析の基本となる考え方の変化と、それに伴うデータベースや処理方法に対する解析者のニーズ変化を理解しておくことが重要である。
- アナリスト出自の人は特にデータベースやネットワークの知識が不足していることが課題となりやすい
- データ解析環境の歴史的経緯
- ハードウェアやネットワーク通信設備の進化に伴い、時間と費用の両面でコストが大幅に下がり、事業者が処理しうるデータ量が増えた（“ペタバイトの時代“）
- 処理できるデータ量の増加に従い、データ解析の考え方も変わった（仮説検証型 → ①データレイクを母体にした②全量データのサイクル処理型）
- ①データレイク：「用途は据え置いて、とにかく（非構造データを含む）あらゆるデータを貯める」という考え方ないしそのデータ群
- ②サイクル処理型：「全量データ（データレイク） → 解析 → 仮説生成 → 検証 → 全量サンプリング」というデータ処理の一連の流れ
- Cf. 仮説検証型：仮説→サンプリング→検証
- 新しいデータ解析の手法には、従来以上に、データの高速処理が求められる。
- ビッグデータを高速処理する必要から、技術へのニーズも変化した（以下、ビッグデータを支える技術たち）
- ①データレイク向きのサーバーが必要
- → 大量蓄積＆大量同時加工できるサーバー → NoSQL（Cf. RDBMS）
- → 大量蓄積＆大量同時加工を回避できる方法 → エッジコンピューティング
- ②全量データをうまく処理できる方法が必要
- → 並列・分散処理（Cf. シリアル）が必要 → ライブラリと実装エンジンが必要 → SparkとHadoop
- ①データレイク向きのサーバーが必要
具体的な用語以上に、こうした全体の流れを体系的に理解しておくことが、とても重要です。
とはいえ、一回で理解しきることはなかなか難しいため、本記事を何度も読み返して自分の言葉で腹落ちさせるようにしましょう。
