ハウテレビジョンブログ

『外資就活ドットコム』『Liiga』『Mond』を開発している株式会社ハウテレビジョンのブログです。

データ分析基盤のカオスに平穏をもたらした話

データエンジニアリング

導入

こんにちは、データ分析PJTの縄司です。

寒気の流入が顕著になり、西高東低な気圧配置が頻繁に見られる冬が訪れてきましたね。今年は寒くなるのでしょうか？気になった方はAOI(北極振動指数)やエルニーニョ現象、ラニーニャ現象の詳細をぜひご覧になってください。肌の潤いは失われビニールの袋を開けるのに苦戦する日々を送っています。

さて今回は弊社データ分析基盤刷新のお話しをさせていただきます。

内容

従来のデータ分析基盤アーキテクチャ
弊社のデータ分析アーキテクチャは上のようになっており、MySQLやBigQueryで集めたデータをRedashに集約してデータの分析・可視化を行なっておりました。異なるデータソースを結合するQuery Resultsや豊富なチャート機能は便利ですが、日頃データ抽出やデータの整合性を確認する時にどのクエリを見ればいいの?といった疑問が業務の中でたくさんありました。

課題

上記アーキテクチャでの問題点は次が挙げられます。

  • 管理されていないクエリの溜まり場

    Redashは気軽にクエリを実行し、データ可視化を自動的に行ってくれ、容易に解析することができます。その反面Redashは構造上、クエリをArchiveにはできるも削除することができません。そのため、誰かが作成したクエリが残り続けてしまい欲しいクエリを容易に見つけることができないです。また、間違ったクエリも混在していました。

    これによって、KPIや解析のために作成したクエリで正しいデータはどれなのかわからない現象が起こっていました。

  • データの一元管理ができていないため柔軟に分析ができない

    MySQLとBigQueryをそれぞれデータソース、データレイクとして位置付けていますがそれらのデータを連携する場所はRedashのみとなっています。そのため、Data Ware HouseやData Martの作成はRedashに依存しており他の環境で分析することが困難でありました。また高い負荷がかかってしまい動かなくなることもしばしば起きていました。

  • SQLの知識が必須

    Redashではクエリやプログラミング(主にpythonやGA api)の知識があってこそ分析できるツールであり、非エンジニアにはハードルが高いです。そのため分析する際に属人的になってしまい、課題解決の速度や検証の柔軟性に大きな弊害となっていました。

  • 不要なコスト

    Redashでは、BigQueryとの連携が可能であるが、クエリの実行にはコストが発生します。そのために起きていた問題として、定期実行されていたクエリが、作り直しによって利用されなくなったあとも解除されず、コストが発生し続けていました。

これらを解消し、データ分析基盤として更なる進化を遂げるためにアーキテクチャを一から見直し次のように再構築しました。

基盤刷新後

新データ分析基盤アーキテクチャ

これにおいて改善されたことは大きく3個あります。

  1. データの一元化

    データレイク及びデータウェアハウス、データマートをBigQueryに置き、データソースや他ツールによるデータを一元管理するように変更しました。これによりBigQuery内でデータ加工が完結し、様々なデータの連携が可能になります。データソースをBigQueryに移送するツールとしてはAirbyteを採用しました。AirbyteはOSSでコストがかからずELTとしてGUIで直感的に操作できるのが魅力です。

  2. 重要なクエリの管理

    正しいデータがわからない。同様のクエリで無駄なコストが発生する。を防ぐため重要なクエリをDBTで管理することにしました。DBTはETLの”T”(Transformation)を担ってくれるOSSツールで、無料ながら機能が充実しており、コード管理やテスト機能、メタデータ管理を提供してくれるツールです。DBTを使用してSQLコードをGit管理でき、レビューを持って正しいデータを維持できる体制を整えました。

    また定期的に出力する必要があるデータのために、DBTをcronjobで定期実行するように環境を作っています。

  3. Tableauの導入

    非エンジニアでも属人的にならず、自主的に分析ができるようTableauを導入。直感的にデータ加工、データ可視化ができる環境を整えました。またTableauはRedashよりもvisualization機能が充実しており手軽に分析や予測が可能なのが魅力です。現在はRedashや自社開発した数値観測をTableauのダッシュボードに移行しています。

以上のように、安全で継続的に正しい数値を観測できる環境を目標にデータ分析基盤を再構築しました。

Airbyte・DBTの管理

弊社のサービスでは、本番環境と開発環境をAWSのECS、ECRで管理しています。SREチームと協力をいただき実装しました。

余談

まだまだ発展途上のAirbyteでは重要な課題がありました。それは、Airbyteには実行スケジュール機能が実装されていますが、例えば24hour実行に設定すると前回実行完了してから24hour後に再実行されることがたまに起こります。これでは5:30 AMに定期的に移送したいデータがあった場合徐々に時間が遅れていき、ユーザーが活発な時間に移送が実行されサービスに支障をきたす可能性があります。

この対策は公式には無かったのでこちらを元にカスタマイズしました。

幸いにもAirbyteにはAPIでの連携が可能であったため(https://airbyte-public-api-docs.s3.us-east-2.amazonaws.com/rapidoc-api-docs.html#auth)、任意なタイミングで実行することが可能でした。これを元にcronjobで理想的な時間にデータ移送ができるようになりました。

今後の課題

Tableauを導入してから日にちが浅く、全社的にデータドリブンな文化を築けているわけではありません。今後は、手軽に分析できる環境を周知および浸透させられればと思っています。また採用したDBTに関しても知識のキャッチアップや技術の活用が不十分であるため、より安全で継続的であり、活用しやすいデータ分析基盤に確立するために精進していこうと思っております。

終わり

ハウテレビジョンの開発部ではチームのプロダクト生産性を日々高めております。 ぜひ一緒に取り組んでくれるエンジニアの方、募集しております！ herp.careers