至る所でデジタルデータは増え続けていますが、誰もが大規模なデータの恩恵を常に受けれていると感じられているでしょうか。
むしろ「どこかにデータがあるけどどこに頼めばいいんだろう」「どんな分析をしたらいいのかそもそもわからない」「データをスプレッドシートにコピーした分析シートを作ったけれど、古くなった」「前任者のSQLは長くて読むのは不可能」などなど、様々な壁にぶち当たって諦めているケースが多いんじゃないでしょうか。
データ分析の分断
これらの課題の背景にあると私達がまず考えているのが「データ分析の分断」です。
データの世界にはDataLakeやETLの独自記述(UI)、SQL、Jupiter Notebook、それらにつながる各種DataMart、BIなど、様々な基盤やツールが散在しています。これら各ツールには得意なデータサイズがあり、それらが利用者の分断やパイプライン管理の複雑化を引き起こしています。
データ分析を継続的に行うこと（Continuous Analytics/DataOps）や、データ分析をチームの文化に根付かせることをしたいと考えた時、データのロード、抽出、一次加工、二次加工、可視化、利用といったプロセスは一方向ではなく、いつでも立ち戻って修正し続ける必要があります。特にどのような価値がどこに眠っているかもわからないような「データの探索」では、データの抽出や一次加工に戻りたいときに「すぐに戻れるか」はプロジェクトの成否そのものです。
利用者の分断やツールを跨いだパイプラインの問題が起きると、プロセスを巻き戻すことはほぼ不可能になり、価値のある大量のデータが利用できずに放置されていきます。欲しいデータやフィールドがどこにあるか誰に頼めばいいかわからず、コピーして持ってきた古いデータを見てため息をつき続けることになります。
この分断の課題自体の背景には、さらに次の3つの背景課題があると考えています。
1: インフラの進化
データ基盤としてのインフラの進化は著しいものがあります。
もともとデータサイズの分断は、処理できるデータ規模と問い合わせに対するレイテンシのバランスを、それぞれのインフラ（特にストレージの表現方法）が得意領域として棲み分けていたことが根幹にあると考えられます。
しかし、ある程度のレイテンシと安価で十分なデータ規模を兼ね備えることで、扱えるデータ量は大規模のままアプリケーションレイヤーやDataMartのバックエンドとして直接利用することも可能になってきました。これはDataLake、Warehouse、DataMartの境界が薄くなった、とも表現することができます。Lakehouse (DataLake + Warehouse) のような概念が出てきているのも同じような背景にあると考えられます。
分断を解消するために、このようなインフラの進化に合わせて、ツールの境界もなくしていく必要がありますが、まだそれにツール側が適応できておらず、データサイズに合わせた操作のためのツールを組み合わせて使うのがまだ一般的です。
2: 言語の課題
データ分析のツールの一つは、SQLというデータベース言語です。
少しでも触ったことがある人であれば、SQLのできることの素晴らしさを感じつつ、扱いづらさを感じることがあるのではないでしょうか。モダンなプログラミング言語を知っている人間であれば、そのアナロジーからさらに違和感を感じている人も多いのではないかと思います。
その管理しづらさや、読みづらさの反面、データ変換や加工、抽出や可視化に至るまで、データ分析のパイプラインの至る所で使われます。
この中心のツールが読みづらく、運用しづらいことから流れがブラックボックス化し、同じデータ分析担当者間であっても分断を引き起こしてしまいます。また処理同士の依存を記述する方法がないことも分断を起こしています。
かたやプログラミングの世界では、言語が定期的に刷新され、新しい概念の導入などを通して大規模で複雑なアプリケーションであっても素早く簡単に、そしてチームで開発・運用できるようになってきています。
クラスや関数などで分割し、名前付けをした上でファイルを分割することで、中身を全て知らなくてもどういうものかが分かるのは当たり前です。インターフェース定義をすることで再利用性を高めたり処理を切り替えることも可能です。反面SQLはどうでしょうか。WITH句などを使ってある程度分割はするものの1ファイルの中に1000行以上のコードになることもザラで、その中に抽出や加工・可視化のためのコードなどが入り混じっています。
SQLをモダンに書き換えることで、大規模で複雑なデータ分析のパイプラインであっても、処理の流れを分断せず、透明性がある形で複数人で開発・運用することができるのではないかと考えています。
3: UIの課題
少し見る世界を変えて、最近流行しているノーコード/ローコードと言われるカテゴリのSaaSのツール（CodaやNotion、Airtable など。この議論の中ではSpreadsheetのようなツールも含んでいます。）に目を移すと、それらは（一つの見方ですが）データモデリングやその操作に直感的なUIをつけていくことでデータの管理・分析・可視化を身近なものにしてくれていると考えることができます。また、Note/Markdown のようなアプローチはコンテキストを付与して処理のパイプラインをパッケージすることで、流れの意図を理解しやすく、そして頒布しやすくしています。
ただしこれらはあくまでスモールデータの世界での話であり、大規模データとの世界とは現状は分かれています。
上記の3つの課題をそれぞれ解決することで、私たちは最終的にデータ分析の分断の課題を解決し、データの恩恵に誰しもが預かれている社会を目指します。