こちらの記事はDatabricks Advent Calendar 2022の23日目の記事です。

はじめに

初めまして。カケハシにてデータサイエンティストをしている赤池です。業種的に、自己紹介の際に統計学のビッグネームとの関係性を聞かれることがたまにありますが全く関係ありません。統計学もがんばります。

突然ですが、あなたの分析環境では「DBから抽出したデータをPythonやRなどで利用する際にうまく連携できていない」なんてことはありませんか？そして「この処理だけはRでやりたいが、そのためだけに別環境を開きたくない」なんて思うことはありませんか？

このブログでは、データサイエンティストの立場からみた上記の苦しみや悩みが、Databricksの導入により一発で解決した というお話をさせていただきます。最後までお付き合いいただけると幸いです。

Databricks導入前

私は社員として2人目のデータサイエンティストとして去年の12月にカケハシに入社しました。入社当時はデータ分析用のDBやデータ、スクリプトの実行環境がまだ完全には整備されておらず、前処理にはRedash¹、分析にはColaboratory（カーネルはPython）を利用していました。そのため、前処理から分析までのフェーズにて大きく2つの課題が生じていました。

【課題】
1. 【前処理】大規模データの前処理の効率が悪い
2. 【分析】統計学的なモデルをColaboratoryでは利用しづらい

1.【前処理】大規模データの前処理の効率が悪い

以前はDBの操作をRedashで行う必要がありましたが、そもそもRedashはBIツールでありローデータなどの大規模なデータの出力は想定されておらず、弊社のRedashのサーバーもそのようなユースケースに対応していませんでした。さらに、当時はRedashの利用者にテーブル作成の権限がありませんでした。

それにより、以下の2つの非効率が発生していました。

a. 非効率なデータ加工・出力

上記の事情から、大規模データを出力するクエリを実行すると、長い待ち時間の後にOOMで落ちてしまう問題が生じていました。言うなれば、期待して長時間待ったのにドタキャンされる・・・そんな感じです。そのためRedashサーバーが出力できる大きさまでデータを小さくする必要があり、 抽出条件だけが異なる複数クエリでデータを小分けに出力してからColaboratoryで取得・結合 する手間が発生していました。さらに、タイミング次第では 同じクエリでもデータ取得の成功・失敗が不安定 だったため、 予めデータを取得し、Colaboratoryがアクセスできる社内の共有ドライブに保存しておかないと、分析に支障をきたしてしまう 状況が生じていました。

b. 非効率なデータチェック

前述の通り当時はRedashの利用者にテーブル作成の権限がなかったため、1つのクエリにWITH句で多くの処理を詰め込むケースが頻発していました。そのため、各WITHブロックの内容のチェック時に 毎回最初のブロックから処理が走ることで非常に長い時間を要してしまい非効率 でした。WITHブロックを中間テーブルに置換してクエリ実行の手戻りを削減しながらデータチェックを行うのが一般的かと思いますが、当社環境ではそれもできません。

無念を噛み締め、今日も長いクエリを書く。Databricks導入前の私はそんな日々を過ごしていました。

2. 【分析】統計学的なモデルをColaboratoryでは利用しづらい

私は学生時代のみR、データ分析職に就いてからはPythonを主に使ってきて、今は 「なんか慣れてるから」という理由でPython を主に使っています。

弊社におけるデータ分析は現象の仕組みや理由を解釈・説明する類の分析も必要なケースが多いため、予測精度重視の機械学習モデルではなく、解釈性重視の線形回帰などのモデルが必要になることもあります。しかし、線形回帰モデルの実行はPythonよりもRの方が圧倒的に楽なので、分析の最中に「あぁ、この線形回帰だけRでやりたい・・・」など感じることもしばしばありました。

そう思った時点で、私の頭の中ではRのlm関数が微笑みながらこっちを見ています。あの楽しかったlm関数との思い出が駆け巡ります。それを思い出すと、ちょっとした線形回帰の実行にscikit-learnやstatsmodelsを使うのも、rpy2やPypeRでPythonからRを実行するのも処理の手数が多くめんどくさい・・・。そして、ごく一部の処理のためだけにR-Studioなどの別環境を開きたくない・・・とは言え、昔少し使った程度のRに今すぐ完全移行するのはキャッチアップコストの面でハードルが高い・・・わがままな私は、そんなモヤモヤを抱えて業務を行っていました。

Databricks導入後

Databricks導入後は、RedashやColaboratoryが担っていた機能が丸々Databricksに内包され、分析環境がDatabricksに一元化されました。これにより従来発生していた悩みは粉々になり、粉雪のように冬の空へ消えていきました。

「1. 【前処理】大規模データの前処理の効率が悪い」のその後

a. 非効率なデータ加工・出力

Databricks導入後は、以前のようにサーバーダウンを過度に気にしてクエリやデータを分割する必要がなくなりました。今やもう、確率的に発生するOOMに怯える必要はありません。それだけに止まらず、以下の恩恵により前処理の業務効率が飛躍的に向上しました。

PySparkやPandas API on Sparkを使用でき、SQLを使用せずに大規模データの前処理 ができる
特にPandas API on Sparkを使用すると、Notebook上で大規模データをpandasライクな使い心地で操作できる

b. 非効率なデータチェック

こちらDatabricksの機能とは異なりますが、Databricksの全社導入に伴い、社内のデータ運用ルールが整備されて任意のテーブルを作成できるようになりました。これにより中間テーブルを作成しながら前処理できるようになったため、WITH句に処理を詰め込む事による処理時間の非効率を改善でき、さらに前述のPandas API on SparkによりそもそもSQLを使用する必要がなくなったことで操作性が向上し、データチェックの効率も向上しました。

「2. 【分析】統計学的なモデルをColaboratoryでは利用しづらい」のその後

DatabricksのNotebookは、セルの上部にマジックコマンドを記載することでセルごとに言語を切り替えることができます。² さらにNotebook内ではSpark DataFrameとして複数言語間でデータを共有できるため、1つのNotebook内でPythonで加工したデータをtemp viewとして保存し、R側で処理することもできます。この機能により、例えば以下のようにDBからのデータ読み込み、可視化をPython側で実施し、モデリングはRで行う（できるだけ簡単に）・・・という、以前からの夢が叶いました。

feature1

マジックコマンドを書くだけで簡単にRを実行できるため、現在の私のようにRの習熟度が高くないユーザーでも必要な狭い範囲についてRをキャッチアップするだけでPythonとRを併用でき、非常にコストパフォーマンスがよく助かっています。

おわりに

上記の通り、弊社ではDatabricks導入により分析環境が非常に快適になり、さらに主にPythonで処理を書きながらも一部分だけRを使うという、これまで手が届かなかった「かゆいところ」にも対応できるようになりました。しかし、個人的に快適すぎるからこそ感じている課題もあります。

【個人的な課題 1】PythonとRを1つのスクリプトで細々切り替えすぎると、R実行時にマジックコマンドの記載を忘れてしまう
【個人的な課題 2】1つのスクリプトに処理を詰め込みすぎてしまう

1については、これは「人による」し「慣れ」もあるかと思いますが、私は言語を細々切り替えて実行していると、ついセルにマジックコマンド（%r）を指定し忘れてしまいエラーが出て混乱する・・・なんてことがままあります。そのため、あくまでも「部分的にRを使う」「Rの学習の過渡期に併用し、徐々にPythonからRに切り替える」などの使い方が良いのかもしれないなと感じています。

2については、1つのNotebook内でなんでもできてしまうからこそ、1つのNotebookがDatabricks導入前と比べてつい長くなりやすいと感じています。可読性やメンテナンス性の観点でも、意識的にNotebookを切り分ける必要がある・・・とDatabricksが教えてくれました。

長くなりましたが、最後にこの文章が同業者のどなたかの分析業務の生産性向上の足しになれば幸いです。