Apache Spark
読み: アパッチ スパーク
Sparkとは大規模データ分散処理
Apache Sparkは、大規模データの並列分散処理を高速に実行するためのオープンソースフレームワーク。Hadoop MapReduceの後継として位置づけられ、インメモリ処理による高速化とPythonやSQLでの操作性の高さから、データエンジニアリングと機械学習の基盤として広く使われている。
かんたんに言うと
1台のコンピュータでは何時間もかかる巨大なデータの処理を、数十台から数百台に分散して数分で終わらせるための仕組みである。
Hadoop MapReduceの限界を超えたインメモリ処理の基本概念
2000年代後半、大規模データ処理の標準はHadoop MapReduceだった。Googleの論文を基にしたこのフレームワークは、ペタバイト級のデータを安価なサーバー群で処理できる点で当時は衝撃的だった。
しかしMapReduceには致命的な弱点があった。処理の中間結果を毎回ディスクに書き出す設計のため、複雑な処理を何段階も重ねるとディスクI/Oがボトルネックになる。機械学習の反復計算には壊滅的に向いていなかった。
Apache Sparkはこの問題をインメモリ処理で解決した。中間結果をメモリ上に保持し、次の処理に直接渡す。UC Berkeleyの研究チームが2009年に開発を始め、2014年にApache Software Foundationのトップレベルプロジェクトに昇格した。ベンチマークではMapReduceの10倍から100倍の速度を記録するケースもあり、大規模データ処理の主役が一気に交代した。
RDDからDataFrameへ、処理モデルの変遷
Sparkの初期は、RDD(Resilient Distributed Dataset)という分散データ構造が中心だった。耐障害性に優れた設計だが、プログラミングが低レベルで、データ分析者には敷居が高かった。
Spark 2.0以降、DataFrameとDataset APIが主流になった。DataFrameはリレーショナルデータベースのテーブルに近い構造で、SQLに慣れた人なら直感的に操作できる。Catalyst Optimizerというクエリ最適化エンジンが裏で動いており、ユーザーが書いたコードを自動的に効率のよい実行プランに変換する。
PySpark(PythonからSparkを操作するAPI)の普及も大きかった。データサイエンティストの多くはPythonユーザーで、JVMベースのScalaやJavaを書きたがらない。PySparkによってPythonのエコシステムからシームレスにSparkの分散処理を呼び出せるようになり、利用者の裾野が広がった。
バッチ処理とストリーミング処理の統合
Sparkの当初の強みはバッチ処理だったが、Spark Structured Streamingの登場でリアルタイムデータの処理にも対応した。
従来のバッチ処理は「過去24時間の売上を集計する」といった遡及型の分析。ストリーミング処理は「今この瞬間に発生しているイベントを即座に処理する」というリアルタイムの分析。IoTセンサーの異常検知や、ECサイトのリアルタイムレコメンデーションに必要になる。
Structured StreamingはDataFrame APIの延長として設計されているため、バッチ処理と同じコードをストリーミングに転用できる。開発者にとっては、2つの別々のフレームワークを学ぶ必要がない。
とはいえ、真のリアルタイム性が求められる場面ではApache FlinkやApache Kafkaのほうが適している場合もある。Sparkのストリーミングはマイクロバッチ方式で、数百ミリ秒の遅延が発生する。これが許容できるかどうかはユースケース次第になる。
MLlibと機械学習パイプライン
SparkにはMLlibという機械学習ライブラリが組み込まれている。分類、回帰、クラスタリング、レコメンデーションといった基本的なアルゴリズムが揃っており、分散環境で大規模データに対してモデルを訓練できる。
scikit-learnと比較されることが多いが、棲み分けは明確。scikit-learnは1台のマシンのメモリに収まるデータ向け。MLlibはメモリに収まらない規模のデータ向け。数百万行程度ならscikit-learnで十分で、Sparkを持ち出す必要はない。
ディープラーニングについてはMLlibの守備範囲外で、PyTorchやTensorFlowとの連携が必要になる。Horovod(Uber開発の分散深層学習フレームワーク)をSpark上で動かす構成が実務ではよく見られる。
クラウド環境での運用と選定基準
オンプレミスでSparkクラスタを構築する時代はほぼ終わった。Amazon EMR、Google Dataproc、Azure HDInsightといったマネージドサービスを使えば、クラスタの起動から廃棄までをAPIで制御できる。Databricksは、Sparkの創始者が立ち上げた企業が提供するマネージドプラットフォームで、ノートブック環境やジョブスケジューラまで含めた統合体験を売りにしている。
導入判断で重要なのは「そもそもSparkが必要か」の見極めである。データ量が数GB程度なら、Pandasで事足りる。DuckDBのような軽量な分析エンジンも台頭しており、中規模のデータなら分散処理なしでも高速に処理できる。Sparkが真に必要になるのは、テラバイト以上のデータを定常的に処理する場合か、リアルタイムのストリーミング処理が必要な場合に限られるだろう。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。