データ分析基盤において必須の構成要素であるDWHとBIツール（可視化・ダッシュボードツール）。昨今では多くのツールが存在し、これから分析基盤を作る方にとっては最も悩ましい選択を強いられるでしょう。
2020年7月15日に開催されたオンラインセッション「Data Engineering Study #1『DWH・BIツールのこれまでとこれから』」では水先案内人にゆずたそ氏をお招きし、データ分析基盤の全体像を説明して頂いた上で、DWH/BIツールの位置づけを確認しました。また、実際にDWH・BIツールを最大限活用されているZOZOTOWNとfreeeの2社に、選定の理由・運用してみてのリアルな声をご紹介いただきました。
当日の発表内容は上記YouTubeでご確認頂けます。
基調講演「Data Platform Guide – 事業を成長させるデータ基盤を作るには」
ゆずたそ氏（@yuzutas0）
データ基盤人材への需要が年々増えていることからも、企業のデータ活用はより注目を集めています。しかしゆずたそ氏によると、そこには「そもそもどのような基盤を作ればいいのか分からない」「基盤を作ったのに全然使われない」という2つの落とし穴があるそうです。そこで、実際に使われるデータ基盤の構築について、「使われるデータ基盤」構築の勘所を学ぶことをゴールに「なぜ作るのか（Why）」「どんな要素が必要なのか（What）」「どのように実現するのか（How）」の3つに分けて語られました。
ゆずたそ氏：「まずなぜ作るのか、この答えの1つは『お客様』のためです。特にレコメンドやAI活用が増えていく中でデータを活用すること自体が顧客の価値提供になっていきます。もう1つは『現場で働く人』のためです。しっかりとデータを見ながら現場の改善活動によって、業務が磨かれていきます。そして『経営』のためです。しっかり会社全体のデータを統合して一つひとつの活動がちゃんと全体にとって意味があったのか、モニタリングするためだと思っています」
ではデータ基盤を作るためには何が必要なのでしょうか。同氏は「ツール」「システム」「プロセス」の3つが必要だと解説しています。
データを参照するための「ツール」
ゆずたそ氏：「まず、手軽にデータを参照できるツールが必要です。エンジニアがやりがちな失敗として、とりあえずデータを集めたものの、全然使われていないことがあります。ちゃんと利用者に届けることを考える必要があります。
1つの発想としては『Model』と『View』を分ける方法があります。
主要指標の定義としては『Model』を統合し、データを『見る』部分では部署ごとに分けていく方法です。特に『View』がポイントで、適切なツールは部署と役割によって違ってくるのです。ここで大事な考え方は、自分にとってベストのツールが、必ずしも他の人にとってのベストのツールではないこと。データを統合する上で利用者にとってどうすれば使いやすいかを考えましょう。これは『現場と向き合う』ということでもあります。」
レイヤーごとにデータを分ける「システム」
ゆずたそ氏：「システムでは、共通箇所をいかに担保するのかが重要になります。その回答の1つとして、データの階層を分けるということが挙げられます。『データレイク』『データウェアハウス』『データマート』という、3つのレイヤーに分けることを提案させていただきます。
『データレイク』とはログやデータを一切加工せずにそのままシステムに集約したものであり、この『何も加工していない』ということがポイントです。データが汚くても、汚いまま入れることがポイントです。後からデータクレンジングをしようとしても、元のデータが残っていないと直せないからです。『データウェアハウス』は共通の指標を担保するレイヤーになります。『データマート』は、特定の利用者向けにしっかりとデータを分離したものです。このユースケースごとに分離することがポイントかなと思っています。」
安心してデータを扱うための「プロセス」
ゆずたそ氏：「最後に、『プロセス』では、部署や用途ごとに期待されている品質を洗い出すことがポイントです。こ期待された品質が満たされないときに、どのような対応をするのかを明確に決めてあげた方がいいでしょう。そしてインシデント対応手順も決めておきましょう。
オペレーションを型化しておくと、安定して管理されているように見えるので、不安感はなくなります。そして、その品質を計測、モニタリングすることもポイントかなと思っています。この手順は定期的に見直せるように、ミーティングを進めていけば、結果的に改善に向かっていく仕組みになるはずです。
これらを踏まえた上で、利用者の目線にちゃんと立ってテクノロジーを組み合わせていくことが、データ基盤を作り、運用して行く上で気をつけたいポイントです。この分野はある意味でソフトウェアエンジニアリングという分野の面白さと難しさが全部詰まっていると思っています。」
ZOZOTOWNの事業を支えるBigQueryの話
続いて、ZOZOTOWNの塩崎氏からは、同社のデータ分析を支えているBigQueryの選定理由や、一部分でまだ利用しているオンプレのDWHアプライアンスと比較した運用の容易さが紹介されました。LookerのLook MLを利用したKPI定義の標準化・構築中のリアルタイムデータ基盤など、BigQueryと他のツールとの組み合わせ事例も併せて紹介しています。
塩崎 健弘 氏（@shiozaki）
塩崎氏：「ZOZOTOWNのデータ基盤では、まず基幹のオンプレミスのデータセンターの方にデータベースがいくつかあります。そこがSQL Serverで動いています。中間DBにデータを集めた後、今度はそこからBigQueryにデータを流し込んでいます。最終的にそれを表示する先として、Power BIといったBIツールやLookerがあったり、AI活用もしています。」
塩崎氏：「次がワークフローエンジン。Arm Treasure Data社のOSSである『Digdag』を使っています。中間DBからBigQueryにデータをコピーするところでは、ETLツールとして『Embulk』を自前で運用しています。後は、EC2の上にオートスケーリングするようなクラスターを自前で組んでいます。」
塩崎氏：「最後のデータのアウトプット先として、Power BIやLookerがあったりします。Power BIの方がオフィシャルに導入されているBIツールでして、専門チームがダッシュボードを作っています。閲覧専用アカウントは全社員が持っており、全社的なKPIはここで共有されています。また、Lookerはデータガバナンスのためのツールとしても利用しています。
弊社ではDWHとして『BigQuery』だけを使っていますが、オンプレにもDWHがあります。Redshiftより以前から使っているもので、メルマガやプッシュ配信のデータマート作成もここで行なっています。個人的な感想として、圧倒的にクラウドのほうが運用が簡単でした。ネットワーク構築やバックアップにおいて、クラウドだと一瞬で終わります」
しかしその一方で、「BigQuery」の活用にも辛い点はあると、塩崎氏は語ります。
塩崎氏：「使い勝手が良すぎていつの間にかいろんな人が使い出し、気軽な”SELECT *”を実行することによって数千円が一瞬で溶けてしまいました。対策として地道にauditログから無駄遣いしている人を見つけて、違反者講習を行なったり、初心者向けの資料を用意しています。あとは使った分だけの課金なので、コスト予測がしづらい点は懸念かと思います。
まとめとして、データ基盤に『BigQuery』とオンプレDWHを運用してみた結果、やはりクラウドDWHが圧倒的に楽でした。オンプレのDWHや『Redshift』では、CPUやディスク使用率が高くなりすぎないようにモニタリングする必要がありますが、『BigQuery』にその必要はありません。その代わり、クエリのレスポンスタイムなど、より分析者に近い高レイヤーのメトリクスをモニタリングする必要はあります。また、セキュリティ系が弱いとは昔から言われていますが、最近では他のデータベースと同等にはセキュリティ系機能が充実してきていると思っています」
freeeのデータ基盤におけるDWH/BIの運用事例紹介
freeeで構築しているデータ基盤において、DWHは「Redshift」、BIには「Redash」を主に使用しています。今回はセッションでは、それらを数年運用してみた感想や苦労した点について発表されました。
中山 裕介 氏
中山氏：「freeeのデータ基盤には3つの特徴があります。
まず、さまざまなユーザーに使われる基盤であることです。データサイエンティストや機械学習エンジニアだけでなく、セールス、プロダクトマネージャー、アプリ開発エンジニアも、プロダクトの利用調査やサポートチケットの対応状況、プロダクトのログイン調査で使っています。特に部署のKPIモニタリングで使われている基盤だと言えます。
２つ目として、大量のデータソース、つまりプロダクトのデータ以外のデータも必要に応じて取り込んでいることです。他社のクラウドサービス（SaaS）を使って、日々の業務を効率化することに積極的であり、それらのデータも実際に集計し、モニタリングしてほしいとの要望があったのです。
３つ目として、セキュリティ重視であることです。サービスの特性上、センシティブなデータが多く含まれるため、利用できるデータのセキュリティのレベルがそれぞれ定義されており、それにあった処理を行なっています。
これらの特徴を踏まえて、データ基盤の全体感をお伝えします。基本はAWSの世界線になっており、シンプルに左から右へデータを流していく、いわばデータパイプラインになっています。外部SaaS系（Salesforce、GitHub、Jira）は継ぎ足して運用しています。」
中山氏：「次にDWHの「Redshift」のついてお話します。ある程度生のデータから、マスク処理とカラム落としを行なって格納しています。Redshiftのクラスターは『primary』『replica-1』『replica-2』の3台を使い分けております。
使ってみての感想として、良いところはノード単位の時間あたり課金であるため、どんなにクエリを投げてもコストは一定であり、見通しを立てやすいことが挙げられます。あとはS3からの取り込みや書き出しもできるようになっています。
苦労しているところは、キャパシティ管理が難しいことでしょうか。よく言われているのが、テーブルのチューニングです。『DISTSTYLE（分散スタイル）』『DISTKEY（分散キー）』をどうやって分散するかが結構重要で、ノード間の再分散が始まると重くなって大変なことがあります。他のクエリも流れなくなってしまい、大変なことはあります。」
中山氏：「続いて『Redash』をBIツールのメインで使っているお話です。
個人的に便利だなと思うのは、『JIRA』もデータソースにできていて、特定のプロジェクトのチケット一覧やクローズした件数もさくっと出せるので、そこは便利だなという気がしています。また、クエリリザルトという機能も結構便利に使わせていただいています。運用としてはEC2インスタンス上にDockerで入れて稼働させています」
最後に中山氏から今後の課題として、大きく3つのポイントが挙げられました。
中山氏：『Redshift』の新しいインスタンスタイプが出たので、それを試してパフォーマンスが上がるかを見てみたいですね。
あとはデータカタログの整理です。テーブルやカラムの意味が何を指しているのか、使う側の視点からすると足りていない部分があるので、今後取り組んでいけたらなと思っています。
３つ目として、ETL周りの処理です。レガシーなものを新しい場所に移行していく地道な部分がまだまだなので、取り組んでいきたいなと思っています」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/channel/UCFde45ijA-G9zs7s2CuftRw
TROCCO®は、ETL/データ転送・データマート生成・ジョブ管理・データガバナンスなどのデータエンジニアリング領域をカバーした、分析基盤構築・運用の支援SaaSです。データの連携・整備・運用を効率的に進めていきたいとお考えの方や、プロダクトにご興味のある方はぜひ資料をご請求ください。
