Data Wrangling

こんにちは。ソフトウェアエンジニアの 太田浩行です。
今記事では、データの価値を引き出すための Data Wrangling とはどういうプロセスなのか、なぜ必要なのかについて共有します。
プロダクト開発において、データが大きな価値を持つことは今や広く認知されています。ビッグデータを活用したビジネス決定は今では一般的なものになり、昨今のAI・データサイエンスの目覚ましい発展によってデータを集める重要性はいよいよ高まっています。またBigQuery などのデータウェアハウスによって、エンジニアでなくとも、SQLの知識さえあれば誰でも簡単に分析できる基盤が整ってきています。
しかしデータを集めるだけで、本当にデータの価値を引き出せるのでしょうか？ログデータそのものは、分析に適した形式になっていないため、分析を行う前に、ログの解釈、構造化、壊れたデータの除去、詳細情報の付加などの前処理が必要になります。そういった前処理の重要性が見逃された場合、信頼できない分析結果に基づいて正しくない決断をしてしまったり、秘伝のタレのように積み重ねられた複雑なクエリによって、メンテナンスの困難な分析プロセスができてしまいます。
データの前処理（Data Wrangling）を行うことで、信頼性のある分析結果を作ることができます。このような前処理は共通化し、整理されたデータ基盤を提供することによって、データの価値を誰でも簡単に引き出せるようになるのです。

ログと解析

そもそもログとは何か、改めて定義してみましょう。ログと呼ばれるものには、ウェブサーバーのアクセスログや、アプリから集めたユーザーの行動ログ、ECサイトの購入履歴など、さまざまなフォーマットで書かれた多様な種類のデータが存在します。Confluent の CEO である Jay Kreps が LinkedIn ブログに書いた記事¹では「追記のみ可能な時間によって順序付けされたレコードの列」と定義しています。たしかに上記に上げたようなログは、特定のイベントを記録したレコードの列で、各レコードはイベントの起きた時刻とその付加情報をもっており、基本的に一度書き込まれたら更新されることはないという共通する特徴を持ちます。反対に、ログのフォーマットや保存されるストレージなどは、それぞれの目的や書き方によって多岐に渡ります。 JSON や CSV、XML などの構造化されたデータから、Apache の Web Log など独自のフォーマットを持つものや、はたまた自然言語で書かれたデータが、サーバーのローカルディスクや、MySQL などのデータベース、S3などのオブジェクトストレージや、BigQueryなどのデータウェアハウスなどさまざなストレージで保存されています。
フォーマットも揃わず保存先が分散されているログデータを分析するのは容易でありません。各ログを見るだけでも、サーバーのログを見るためにはサーバーにログインして grep などのコマンドラインツールを使い、MySQLに保存されたデータを解析するためにプロダクションのデータベースに繋いでSQLを走らせる、といったように手間がかかります。
そのためすべての書き込まれたログは、データレイクと呼ばれる、ログに限らずさまざまなデータを一元管理するためのリポジトリに集約するのが一般的です。データレイクへログデータを収集すること自体は難しくなくなってきており、事実上標準となったオープンソースの fluentd を使ったり、GCP の Stackdriver など各クラウドにおいて標準で提供されるデータコレクションのソリューションを使うことで達成できます。
しかしログそのものはいわば磨いていない鉱石のようなものであり、分析に適する形式へ整形する作業が必要です。Forbes の記事²によると、データサイエンティストの80%もの時間がデータの分析ではなく、データを準備することに当てられているという統計が出ています。またMicrosoftのデータサイエンティストによる調査³によると、データを分析する上で共通する課題として、データを分析する前のステップに以下のような大きな課題があると指摘されています。

• データの収集。複数のデータソースからデータを集め、整形することはたやすくない。データレイクに保存されていないデータは、所在を見つけ集めてくる必要がある。
• 質に問題のあるデータ。収集する方法やサンプリングの仕方が間違っていると、データの質に影響し、出てきた解析結果の正確性を保証できなくなる。
• 存在しないデータ。収集できていなかったり、遅延が生じるデータを扱うのは困難を伴う。とくに古くからあるシステムへ新たにログを取るためには大きなコストがかかる。
• 構造の解釈。複雑で入り組んでおり、歴史的経緯に満ちた「スパゲッティデータ」を解釈するのは単純な作業ではない。古くなってしまった、もしくは存在しないドキュメンテーション、一貫性のないスキーマ、複数の解釈ができるデータラベルなどは、データの理解を困難にする。

アメリカでは、分析用にデータを整形する Data Wrangling の重要性が認識されており、大きなビジネスになっています。 たとえば Trifacta⁴ は Data Wrangling を簡単にするツール「Wrangler」および「Google Cloud Dataprep by Trifacta⁵」を提供しています。Bank Of America や eBay などが顧客であり、時価総額は1.24億ドルに登ります。⁶

Data Wrangling – ログ分析の下準備

Data Wrangling には以下のようなステップを含みます

• Structuring: 構造化されていないデータを解釈し、一貫した構造を持ったデータ形式に置き換える
• Cleansing: 壊れていたり、重複していたりするデータを修正、もしくは取り除く
• Cleaning: セットされていないフィールドにデフォルト値をセットし、データを正規化する
• Enriching: 複数のログやデータベースを照合し、詳細を足す

Structuring

Structing のステップでは、そのままでは解析ツールであつかえなかったり、効率的ではないログに構造を与えます。たとえばApacheサーバーの出力するログは以下のようなフォーマットをしており⁷、時刻([10/Oct/2000:13:55:36 -0700])、リクエスト (“GET /apache_pb.gif HTTP/1.0”), レスポンスコード(200) などを含みます。

	127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

「特定のURLへの時間ごとのアクセス数」をApache のアクセスログから調べたいケースを想定します。各ログレコードを見れば、時刻やメソッド、URLは含まれていますが、そのままSQLで取り扱うには、

• 正規表現を使ってURL、メソッドおよび時刻を抜き出す
• 時刻をTimestamp型に解釈する
• メソッドやパスによって興味のないリクエストをフィルターする

といったステップを経る必要があり、正確に行うのは容易ではありません。しかし、もしログレコードが解釈され次のようなJSON形式に構造化されていれば、 method でフィルターし、path と time フィールドで集計するだけで簡単に分析ができます。

 {
  "user" : "frank",
  "method" : "GET",
  "code" : 200,
  "size" : 2326,
  "host" : "127.0.0.1",
  "path" : "/apache_pb.gif",
  "referer": null,
  "agent" : null,
  "time" : "2000-10-10T13:55:36-07:00"
}

また解析ツールにデータを取り込む際に、構造化データならば解析するのに都合の良いフォーマットに変換することもできます。たとえば列指向形式⁸で保存することにより、各分析に必要のないフィールドを読み飛ばすことが可能になり、分析を効率化し結果をより早く得ることができます。

Data Cleansing

Data Cleansing とは壊れていたり、間違っていたり、重複していたりするログを検出し、修復することです。
ログは簡単に不正な値を持ちえます。クライアントから送られてきたログは、クライアントサイドや転送される間に、途中で途切れていたり不正な値が入ることで、想定していない値を持ちえます。そのようなログレコードは、平均値などの集計値を意味のないものにし、想定外の値が入っていることで分析システムの障害に繋がります。
またログを転送するデータコレクターやメッセージブローカーは各レコードが正確に1回転送されることを保証するものばかりではなく、最低1回転送されることのみを保証しているもの（at least once）や、最大1回転送されることのみを保証しているもの（at most once）もあります。そのようなシステムでは、ログの欠損や重複の可能性があり、エラーを検知し修正・除去することが必要です。

Data Cleaning

Data Cleaning のステップでは解析上必要のないイベントや情報を落とします。たとえばウェブログには各HTTPリクエストが乗っていますが、写真やCSSファイル、JavaScript などは自動的にダウンロードされるものであり、ユーザの行動を解析する上ではとくに必要のないものです。必要のないデータを早い段階で削っておくことは、分析のスピードを何倍も速め、とくにデータを対話的に探索する際の生産性に大きく影響します。

Enriching

このステップではきれいになったログへさらに付加情報を追加します。ログを書き込む際には、あとからデータベースと照合すればわかるようなデータを省くことで、データを転送する負荷や、保存するコストを減らします。その一方、そのままでは解析するには十分なデータが含まれていません。たとえば購入履歴からユーザーの購買行動について複雑な分析を行うことを考えたとき、購入履歴自体にはアイテムのIDとユーザーIDを保存しておき、データを準備する際に詳細情報（カテゴリや評価などのアイテム情報・プロファイルや過去の購買情報などのユーザー情報）を付与することで、複雑な分析を簡単に効率良く行うことができます。
またデータベースを照合するだけでなく、他のログと組み合わせることも分析を容易にします。次の回にて詳しく解説するセッション化を行うと、複数のログを各ユーザーによってまとめることで、複数のログに散らばった各ユーザーの行動をデバイスやログイン状態に関係なく追えます。ユーザーの行動を各点で分析するのではなく、一連の流れの中で解析することは、プロダクトへの深い理解を得て効率よく施策を打つためには必要不可欠です。たとえば、新規登録プロセスを最適化する際、最終的な登録人数だけを見るのではなく、各ユーザーがどのステップで脱落しているかを追ったり、ユーザーの流入経路ごとの登録完了率を比較したりすることで、とくに脱落率の高いステップを改善するための施策を打ったり、流入経路毎に違った登録フローを見せるなどの最適化ができるようになります。

まとめ

ログデータは収集した段階ではまだ簡単に活用できる状態になっていません。ログを一箇所に集めて見つけやすくし、データを解釈して構造を与えることで機械的に扱いしやすくし、欠如した値や壊れた値を修復し、必要な情報を足すことで、はじめて分析できる状態になります。そのような Data Wrangling のプロセスを共通化することで、データの扱いに詳しい人やログを生成しているサーバーに詳しい人のみが扱えていたデータが、チームの垣根を超えてだれでも利用できる基盤となります。

自己紹介

太田浩行
2013年、新卒でGoogleに入社。Google Play のクーポンシステムやそれを元にしたキャンペーンプラットフォーム、Google Mapsの口コミのソーシャル機能や、2018年のエイプリルフールなどの開発に携わる。2018年よりFLYWHEELに参加。

Notes