見出し画像

新卒データアナリストがデータ分析基盤を構築した話


こんばんは。データアナリストの志賀です。
最近NETFLIXのペーパーハウスにどハマりしています。造幣局を強盗するのに強盗犯それぞれの人間らしい優しさや愛が垣間見えたり、強盗犯の名前が世界各国の都市名で設定されていて各強盗犯のストーリーが頭に入ってきやすいなど語り尽くせないほどの面白さがあるので是非見てください。


今回はデータ分析基盤を構築した経緯についてお話しします。


データ分析基盤の簡単な前提知識

近年ビッグデータやデータサイエンティストブームもあり、「データ分析基盤」の在り方が重要視されるようになりました。
一般的にデータ分析基盤を構築したり管理する人のことを「データエンジニア」と呼んだりします。


データ分析基盤は大まかに3つの層に分かれており、データレイク、データウェアハウス、データマートに分類されます。

・データレイクとは生データを集約するデータベースのことを指します。得られたデータを何も加工せずにそのまま蓄積している状態です。
・データウェアハウスはデータレイクで貯まっているデータを分析者が扱いやすいように予め加工されたデータが集約されたデータベースのことを指します。
・データマートは特定の目的や特定の部署に対して必要なデータだけが抽出された利用可能データのことを指します。

画像3

▲データ分析基盤の概要


一般的にデータウェアハウスを持っている企業が「データ分析基盤が構築されている状態」と言えると思います。

また、分析基盤の概要図ではBigQueryを例として出しましたがクラウドサービスではなくともオンプレミス環境でもデータウェアハウスとしての活用は可能です。ただし環境構築のしやすさやノウハウの蓄積などといった理由からクラウドのデータウェアハウスが主流のように思えます。



そもそもなぜデータ分析基盤が必要なのか

極端に言うと、データ分析基盤自体はなくともデータ分析をすることは可能です。

ただし、データ分析基盤がない状態すなわち生データのままデータ分析を行おうとすると、データクレンジングや加工、別データの結合などデータ分析とは本質的に関係のない部分で大幅に時間が奪われてしまいます。

特に施策を高速で回したいベンチャー企業などにとっては分析に充てる時間も限られてきます。
データ分析基盤が整っていないだけで簡単なデータ抽出でさえ、かなりの時間を要することもしばしばあります。

他の理由として、データの一元管理が可能になるということが挙げられます。WEBサービスのデータはデータベースに集約されますが、他部署のCRMデータなどは他のツールでデータ管理されています。
データが別々のところにあると分析においては不便になります。


このようなことを避けるためにデータ分析基盤は必要になってきます。


データ分析基盤を構築する前の分析環境

ツクリンクでの以前の分析環境は下図になります。

画像1

とてもシンプルな分析環境ですね。PostgreのDBにBIツールであるredashで参照しているといった構成になっています。

数百TBといった膨大なデータ量ではないので一応これでも対応はできていたのですが、やはり複雑なデータ抽出作業が伴うとそれなりに時間的なコストがかかってかなり辛い状況が散見されていました。


以前の分析環境での問題点


1. データ加工の手間に大幅な時間がかかっていた

以前の分析環境ですと、データレイクからそのまま分析をしようとしていたので当然生データのままだと分析側からすると処理しづらいデータが格納されていたり、欲しいカラムがなかったりします。

以前は「中間テーブルを挟んで何とかすれば欲しいデータが得られる!」といった状態でした。しかし新しいデータ抽出をする度に中間テーブルで操作する作業はかなりのコストがかかっていました。


2. 他部署との協業が難しい

営業チームやCSチームではCRMツールを使って顧客管理をしています。
他部署からの依頼ではしばしばCRMデータが絡む分析依頼があります。

そうなると、DBとCRMを結合させるためには

両方のデータを一旦CSV出力する

そのCSVデータをスプレッドシートにインポートする

vlookup関数などで結合する

といった手順が必要になります。この手順だとかなり時間がかかる上に、データの整合性が取れないといったことが結構ありました。


こうなると他部署的には「軽くこのデータが見たい」といった依頼でさえ躊躇ってしまい、データアナリストの存在意義が疑われてしまいます。


現在の分析環境

ツクリンクの現在の分析環境

画像3

まだまだ未完成ではありますが、大方このような形でデータ分析基盤を構築しました。

データウェアハウスの選択としてはBigQueryを選択しました。
選択理由としては、やはり分析環境としてのノウハウが多かったことと環境構築のしやすさと分析ツールとしてイケていると言うのが主な理由になります。


次にBigQueryにデータ転送するためのツールとしてembulkとdigdagを使用しています。

embulkとはETLができるようになるOSSです。YAML形式で設定ファイルを作成することができ、プラグインなども豊富なので非常にお手軽にデータ転送できるようになります。

※ETL…Extract(抽出)Transfer(加工)Load(書き込み)の頭文字も取ったもの
※OSS…オープンソースソフトウェア。無償で使えるソフトウェアでソースコードの改変などが認められている。

digdagとはワークフローエンジンと呼ばれるソフトウェアです。複数タスクの依存関係からなるワークフローを定義し、そのワークフローの実行及び管理ができるようになります。
データ転送の自動化をdigdagに任せているといった感じです。

以上のBigQuery+embulk+digdagを用いてデータ分析基盤を構築した、ということになります。


分析基盤を構築して思ったこと

分析基盤の知識が一切なかったので、分析基盤を構築しよう!ってなった際にまず何をすればいいんだ...という状態になっていました。

そもそも世の中には分析基盤という体制があることすら知らなくて、当時はデータレイクって何だろうというレベルでした。
学生の頃からデータ分析の経験はあったものの、生データがCSVでポンと渡されていたので生データから分析することが当たり前だと思っていました。

しかし調べていくうちに、データウェアハウスと呼ばれる枠組みがあってそこで予めデータ加工したものが渡されるのか!と理解した時は便利すぎて感動と興奮が凄かったことを覚えています。


また、データアナリストとしてデータ分析基盤に触れることができたという経験はとても大きいと感じました。
データ分析基盤構築を経験していなかったら、データ分析者に渡ってくるデータの仕組みを理解しないまま使用することになっていました。

データエンジニアとしての役割を実際に経験して少しでも理解に近づけたことは、自身の知見が広がったという点においてもとても嬉しかったです。


分析基盤を構築してから変わったこと

1つ大きく変わった点としては、分析に対するモチベーションがかなり高まりました

分析屋あるあるだとは思うのですが、簡単に抽出できそうだけど実は複雑なクエリ書かないと抽出できないデータって割とあると思います。
この類のデータ抽出となると取り掛かる段階で結構億劫になったりします。

サブクエリを何個も書いて理想のデータが得られるようになって、やっと分析のスタートラインに立てるといった感じです。それも少しでもクエリの記述にミス抜け漏れがあるとおかしいデータになるといったこともあります。
スタートラインに立つ頃には既に体力がボロボロでした。

しかし、現在は綺麗な形でテーブルデータが既に手元にある状態なので非常に快適に分析ができる環境です。

例えば以前の環境では数百行のクエリを記述しなければマッチング数を出すことができなかったのですが、現在の環境だとたった1行WHERE句を追加するだけで算出することが可能になっています。


あとはBigQueryの処理速度が高速なのでノンストレスでクエリをぶん回せるところもいいですね。


最後に

かなり長くなってしまいましたが、以上データ分析基盤を構築したお話でした。
最初は構築に関して右も左もわからない状態で辛かったですが、一度仕組みを理解してしまえば結構簡単に構築できて楽しかったです。


ツクリンク株式会社では建設業界を変えていく仲間を絶賛募集中です!!市場規模の大きくてポテンシャルの大きいこの業界を是非一緒に変えていきませんか?
最初はカジュアルなお話だけでもOKなので少しでも興味ある方は是非応募してみてください!

プロダクト開発
セールス
CS
コーポレート



この記事が気に入ったらサポートをしてみませんか?