Da Vinci Studio 分析チームの末安です。
今回は BigQuery で定数を使う方法をいくつか紹介します。
日付だけ変えて同じクエリを実行したいケースなどよくあると思いますが、変更箇所が漏れていたりして無駄に時間を消費してしまったりします。 こういう場合、定数にしておくと便利です。
まず前提として BigQuery では、定数を定義する機能はありません。( 2021年05月時点 )
ここで紹介する方法は、定数っぽくつかえる BigQuery の機能になります。
今回紹介する方法は以下の 3 つです。
ではひとつずつ説明していきます。
続きを読む
Da Vinci Studio 分析チームの末安です。
今回は 2021 年 1 月に公開した ETL ライブラリ inbulk について紹介します。
ざっくり言うと、ほとんど yaml で定義できる BigQuery の API の wrapper のようなものになっています。
分析チームでは BigQuery を利用することが多く、BigQuery 内のテーブルを加工して別のテーブルを作るといった作業がよく発生します。
以前まで、こういった処理は BigQuery の機能である Scheduled Query を利用して行っていましたが、利用していて幾つかの問題が見えてきました。
一つの処理が終わった後に別のテーブルを作りたいということはよくあると思います。
Scheduled Query ではそういった依存関係は定義できないため、実行時間をずらすことでどうにか実現していましたが、最初の処理が失敗しても次の処理が実行されてしまうという問題がありました。
バッチ処理においても冪等性を考慮することは重要だと思います。
これも BigQuery 上のみで実現できなくはないですが、宛先テーブルを全スキャンして新規追加分マージしてからそのテーブルを置換する必要がありました。
この方法の場合、宛先テーブルのデータ量が多いとかなりのコストがかかってしまうという問題がありました。
当時は BigQuery の UI 上で Scheduled Query を設定していたため、レビューがうまくできない状態でした。
この問題に関しては Terraform などで管理すれば解決できそうではありますが、こういった管理方法の場合、GitHub 上の定義と実態に差異が発生してしまうことが多いことと、他にも解決できない課題があったため別の手段を探すことにしました。
続きを読む
Da Vinci Studio インフラ基盤部データ分析チームの濱口です。
Da Vinci Studio のデータ分析チームでは、グループ内に溜まっている膨大なデータを日々分析・集計しています。そうして得られた学びについては、公開可能なものに限り Redash のダッシュボードとしてグループ内で確認できるようにしています。
ただ公開して終わりではなく、ダッシュボードがどれくらい見られているのかも計測して、グループ内のデータへの関心の把握やダッシュボードの改善などに繋げたいですよね。
というわけで今回は Redash 内のクエリやダッシュボードの閲覧状況を可視化した話についてまとめておこうと思います。
閲覧状況を可視化するにあたって Redash の内部データベースに貯まっている metadata を利用しました。 Redash の metadata には、登録ユーザーやユーザー権限、追加されたクエリやダッシュボードなど色々なデータが貯まっています。
events というテーブルがあり、その中にユーザーの閲覧履歴や操作履歴が記録されるようになっています。
これを利用して閲覧状況を可視化してみましょう。
続きを読むDa Vinci Studio インフラ基盤部データ分析チームの濱口です。 今回は Da Vinci Studio のデータ分析チームについて紹介したいと思います。
Da Vinci Studio のデータ分析チームは現在は 3 名体制で、くふうグループ横断のデータ分析を担当しています。 まだ最近できたばかりの比較的新しいチームで、データ分析を通してユーザーや社会により良い価値を届けるために日々活動しています。 まずはそんなデータ分析チームのミッション・ビジョン・バリュー(MVV)について紹介したいと思います。
紹介の前に、チームなのにMVV？と思われた方もいらっしゃるかもしれません。その疑問の通りで Da Vinci Studio 全体としてミッション・ビジョンは掲げられているので、全てのチームがミッションを定めているわけではありません。
しかしデータ分析チームは新しくできたばかりで、実績を積み重ねるために日々多くの業務をこなしながら、手探りで進んでいる状態でした。メンバーそれぞれのやっていることがチームの目指したい理想像や目的から逸れていないかを振り返ることができるようにMVVを決めるに至りました。
Da Vinci Studioサーバー部の徳元です。今回は私が関わっているプロジェクトでJestとGo（testing）のカバレッジやサマリーをAWS CodeBuildとGitHub Actionsを使って計測・表示した話を書いていきたいと思います。
自動テストを書きながらシステム開発をしている方も多いと思いますが、ただテストを書くだけでなくテストカバレッジを日頃から意識することで色々なメリットが得られます。例えば実装者はカバレッジの上昇がはっきりとわかることでテストを書くモチベーションが上がったり、レビュワーはカバレッジファイルを見ることでテストがされていない箇所や全体的にテストの手薄な箇所を認識できたりします。
カバレッジを見るために色々なツールを使うこともできますが、導入するのは手間やコストの面から面倒という方もいらっしゃるのではないでしょうか。実はCodeBuildとGitHub Actionsを使うことによって簡単にそれが実現できるのです。
私が担当しているプロジェクトではCIにAWS CodeBuild（以下 CodeBuild）を使っています。プルリクエスト（以下 PR）を作成したり、PRへコミットを追加してCIが回った後にJestとtestingのカバレッジファイルへのリンクや、それぞれの簡単なサマリーをPR上にコメントとして表示させるようにしました。
青文字となっている箇所をクリックするとAmazon S3（以下 S3）に置いてあるカバレッジファイルを見ることができ、カバレッジの詳細を見ることができます。
続きを読むDa Vinci Studio 代表の吉川です。
Da Vinci Studio は、くふうカンパニーグループ内にある開発会社です。 グループ内外の受託開発の他、自社でもサービス開発に取り組んでいます。
異色なのはその成り立ちです。
くふうカンパニーグループはオウチーノ、みんなのウェディング、Zaim、RCUBEといった、もともと自社に開発組織を持ち自社で提供するサービスを持つ会社が集まりました。 そんな中で全く新規の会社として設立され、当初からグループ外の案件の受託を事業内容に入れて組織されました。
自社でしっかりとした事業体があるにも関わらず何故あえてリソースを他に割くようなグループ外の受託を始めたのでしょうか。
前提として、くふうカンパニーはこの考え方を土台に据えています。 親会社はあくまで各事業会社を支援する立場であり、ユーザーの対面に立つ事業会社が主体的に意思決定をする。 お互い助け合いますし、グループ内での転籍・出向も積極的に行われていますが、グループ内の各社で人事制度などもバラバラです。
そんな中にある開発組織をどう設計するか。
続きを読む