第5回となる今回のData Engineering Studyでは最近日本でも有名になってきたDWH(データウェアハウス)の「Snowflake」について学んでいきます。
第1回では主にGoogle BigQueryとAmazon Redshiftの事例から学びましたが、それらとどのように使い分けていくのか、Snowflakeのアーキテクチャはどうなっているのか、などをテーマに学んでいきます。
また基調講演ではSnowflake内のエンジニアの方をお呼びし、技術的な特徴・アーキテクチャについてご講演いただきました。事例講演では、実際に本番運用されている企業のエンジニアの方をお呼びし、生の事例や他のDWHとの使い分けなどをお話しいただいています。
当日の発表内容はこちらになります。
基調講演「Snowflake のアーキテクチャがどう「筋がいい」のかを解説する」
引用：Yoshi Matsuzaki、Snowflake のアーキテクチャがどう「筋がいい」のかを解説する、
https://speakerdeck.com/indigo13love/data-engineering-study-number-5 より
Snowflakeの中のエンジニアのMatsuzaki氏に、Snowflakeの技術的な特徴やアーキテクチャの詳細をお話しいただきました。Snowflakeを支える機能そして将来性についてもお話して頂いたので、DWHを選定している方・Snowflakeの特徴を知りたい方には大変勉強になる内容です。
Snowflake Principal Cloud Support Engineer
Yoshi Matsuzaki氏
twitterアカウント
Yoshi Matsuzaki氏：「Snowflakeはデータウェアハウスのイメージが強く、確かにデータウェアハウスの機能を一部に持っています。しかし、最近は様々なワークロードに対応できるようにしています。データサイエンス、データエクスチェンジ、データプラットフォームなどに変わっていっています。」
まずはSnowflakeの概要について解説していただきました。
Snowflakeは３層から構成されている
Yoshi Matsuzaki氏：「Snowflakeのアーキテクチャーは外側からCloudServices、Compute、Storageの3層構造でできています。CloudServicesは接続の管理、認証などを行っていますが、クエリのコンパイルが一番重要な役割です。
Computeの層はユーザーからは仮想ウェアハウスとして認識されている箇所で、CloudServicesでコンパイルされたクエリが移され、新しくデータが必要になれば適宜、Storegeからデータを持ってくる流れになっています。」
さらにディープなSnowflakeの話
Yoshi Matsuzaki氏：「Snowflakeのアーキテクチャーを理解する上で、二つの重要ポイントがあります。それが「マイクロパーティション」とそこから派生した「ストレージとコンピュートの分離」です。
マイクロパーティションとはSnowflakeのテーブルの物理的な実体で、オブジェクトストレージに格納されている圧縮前で50~500MB程度の小さなファイルのことを指します。
マイクロパーティションで重要なのはファイルがメタデータを持っている点です。それによりPartition Pruningという形でスキャンを減らすことができます。
普通はデータを全て読み込んでからフィルターをかけて探す必要がありますが、Snowflakeではメタデータにアクセスするだけでファイルになっているレンジがわかるため、テーブルスキャンの量を減らす事ができます。」
マイクロパーティションのもう一つの利点
Yoshi Matsuzaki氏：「マイクロパーティションのもう一つ重要な特性として、イミュータブル（変更不可能）である点です。
イミュータブルなファイルの集合でできていることから、機能の実装がすごくシンプルになります。通常、行の更新をする際は部分的なI/Oでの書き換えや複雑なテーブルスペース管理をするため、次第にフラグメンテーションに陥りやすくなります。
しかし、イミュータブなファイルを持ったオブジェクトストレージだと更新済みのオブジェクトを作成し、そのテーブルのバージョンを新しくするだけで済みます。」
デメリットを上回るメリット
Yoshi Matsuzaki氏：「しかし、イミュータブルであるデメリットもあります。書き込み・読み込みをツリーからのダウンロード・アップロードで行っているので、オブジェクトの作成はブロックデバイスより断然遅いです。
しかし、これはOLAPだと問題にはならないと考えています。多少アップロードに時間がかかっても大量にデータをアップロードできる仕組みにすることが重要で、OLAPだとテーブルスキャンのパフォーマンスの影響が大きいため、Partition Pruningのメリットは非常に大きいといえます。
イミュータブルなオブジェクトのもう一つのメリットはバージョン管理がしやすいところです。古いデータをリストアしたい場合、ブロックデバイスだとUNDOログを書いたり、テーブルスペース内で特別領域を作ってそこから呼び出す必要があります。しかし、オブジェクトストレージだと、古いデータを残してそれを読むだけで済みます。」
続いて、同氏はマイクロパーティションの性質がSnowflakeの機能にもつながった事についてお話ししてくださいました。
ユーザーもサポートも安心の機能に
Yoshi Matsuzaki氏：「こういったシンプルなアーキテクチャーがTImeTravelという機能へとつながりました。TImeTravelは最大90日間のデータが直感的に参照・復元できます。さらにもう1段階、SnowflakeにはFailSafeという機能が存在します。TimeTravelが切れてから7日間は顧客はアクセスできませんが、サポートが復元できる機能です。これはサポートエンジニアからすると、すごい機能だと考えています。
サポートエンジニアをやっていて一番悲しい問い合わせは「削除してしまったがどうにかならないか」というものです。大体の場合どうすることもできないが、Snowflakeの場合は問い合わせれば復元できます。この機能のおかげで、FailSafeが切れたデータは顧客のワークロードを止めて静止点を作らずに簡単にガベージコレクションができるので、ユーザーだけでなくSnowflakeにとっても嬉しい機能だと実感しています。」
「マイクロパーティション」から「ストレージとコンピュートの分離」へ
Yoshi Matsuzaki氏：「Snowflakeはマイクロパーティションであることで、仮想ウェアハウスとストレージが疎結合になり、複数の仮想ウェアハウスが同じテーブルを大量に読み込んだりしても性能が律速することはありません。つまり、どのウェアハウスからもどのストレージにもアクセスできる、「ストレージとコンピュートの分離」が可能になりました。
また、論理テーブルだけを新しく作り物理実体はコピーせずにポイントするだけで、テーブルのクローニングを行えます。さらに、複数のアカウントでストレージそのものを他のアカウントからアクセスできるような形で共有する機能を実装することができました。
こういった機能はデータ上で動くアプリケーションを売れるData Service Marketplaceまで拡張していきました。このような拡張ができるのはシンプルなアーキテクチャーであるからこそだと考えています。アーキテクチャーから機能に有機的に演繹されるので、無理やりな機能追加がなく問題が起きにくいので、ロバスト（頑健）なプラットフォームを維持していくことができます。」
最後に、同氏はSnowflakeの強み、そして将来性についてお話ししてくださいました。
シンプルなアーキテクチャーは廃れない
Yoshi Matsuzaki氏：「シンプルなアーキテクチャーは自然な形で応用が効くので、拡張性（Extensibility）が高いです。SnowflakeはExtensibilityを時代やニーズに合わせて機能拡張できるのが強みの一つとして捉えています。
未来は予測できないため、どのような方向にも進んでいけるアーキテクチャーが重要だと考えいます。ただし、いろいろな機能を取り込みすぎるとモノリス的になり、ある性能に特化していくと拡張が難しくなるため、トレードオフが大切です。
Snowfakeは取捨選択を行い、シンプルなアーキテクチャーであることは維持しつつ、バランスをとっているセンスの良いアーキテクチャーだと言えます。プロダクトとして時代やニーズを追従でき、未来があると言える「筋の良さ」が入社の一つの決め手でした。」
事例講演1「DWH御三家の各特徴と選び方について〜SnowflakeとBigQueryとRedshiftと〜」
引用：玉井励、DWH御三家の各特徴と選び方〜SnowflakeとBigQueryとRedshift〜、https://speakerdeck.com/cmtamai/dwhyu-san-jia-falsege-te-zheng-toxuan-bifang-snowflaketobigquerytoredshiftto
1つ目の事例講演では、Snowflake / BigQuery / RedshiftのDWH御三家を題材に取り上げ、様々な観点で比較を行っていきます。クラスメソッド様はDWH御三家の構築支援をたくさん行われているため、ノウハウがまとまっています。その知見を活用し、第三者的な立場からフェアに比較（使い分け）を行っていただき、初学者の方も参考になるお話になっています。
クラスメソッド株式会社 データアナリティクス事業本部
玉井 励 氏
Developers IOのリンクはこちら
データウェアハウス（DWH）の選び方の結論
玉井励氏：「普通のデータベースはアプリケーションのバックエンドして設計されたものですが、巨大なデータを集約・分析に最適化されたデータベースがデータウェアハウス（DWH）です。
DWHの選び方における結論は、「これさえ選んでおけば問題ない」というDWHは存在しません。自分達のデータ分析における要件に合ったDWHが選択していく必要があります。
まず最初に行わなけらばならないことは自分達がやりたいデータ分析の要件を徹底的に洗い出しておくことです。WordやExcelでデータ分析計画書を作る必要はなく、どういうデータをどこから持ってきてどういう形にして、誰がそれを見て、分析結果の解釈からどうアクションをとっていくか、などは描いておかないと適切なDWHは選べません。」
Snowflakeの基本的特徴
玉井励氏：「Snowflakeはフルマネージドサービス、つまりインフラの管理を面倒見る必要がなく、インフラのミドルウェアのアップデートが必要ありません。そして使った分だけお金がかかる従量課金を採用しています。
Snowflakeの代表的ないいところとして面倒な管理が不要である点と、DWHの中ではTImeTravelなどの未来を先取りした機能が多数存在する点です。
ただ、Snowflakeの注意点として、契約する際にAWS（Amazon Web Services）やGCP（Google Cloud Platform）で動くSnowflakeを選ぶことができますが、サービスとしてはあくまでSnowflakeのものなので、主要なパブリッククラウドサービスとは独立してしまいます。料金の支払いが別立てになったりするものの、他のパブリッククラウドとは各種連携が可能です。あとは従量課金による事前の見積もりが難しいので、POCなどのトライアルを通して自社の使い方をするとどのくらいかかるのかを想定しておくことが大切です。」
Google BigQueryの基本的特徴
玉井励氏：「Google BigQuery（以後BigQuery）はGCPサービスの一つです。フルマネージドサービスで従量課金の形態をとっているものの、Snowflakeとは課金方法が多少異なります。
BigQueryはSnowflakeに比べて、仮想ウェアハウスのサイズ決定や個数を決める必要がありません。そしてGCPの他のサービスとの連携は柔軟で、Googleサービス（スプレッドシート）との連携も可能です。BigQuery MachineLearningを利用しSQLだけで機械学習が可能です。
BigQueryの注意点として、コストマネジメントに一定のスキルが必要で、BiqQuery独自のデータの扱い方があります。事前の見積もりがわからないので、トライアルをする必要があります。」
Amazon Redshiftの基本的特徴
玉井励氏：「Amazon Redshift（以後Redshift）はAWSのサービスの一つです。クラスターやノードをユーザーが決める必要があるものの、マネージドサービスでクラスターが起動している時間にお金がかかる従量課金の形態をとっています。
Redshiftのいいところは従来のDBと似たような感覚で使えるので、とっつきやすい点です。オンプレDWHの知見を流用でき、事前の見積もりも他のDWHより行いやすいことが特徴です。
注意点として、他のDWHに比べて、スケールアップ・ワークロードマネジメント・VACUUMなどの管理が必要になります。カラムの圧縮タイプをどうするか、分散スタイルどうするか、ディストリビューションキーをどうするかを考える必要があります。」
同氏にはDWHを３つ説明していただいた上で、どのような観点でDWHを選んでいけばいいのかを解説していただきました。
DWHを選ぶために必要な観点
玉井励氏：「DWHを選ぶ観点の例として、パフォーマンス・セキュリティ・バックアップ（&リカバリー・スケーラビリティ・エコシステム・コストがあります。
パフォーマンスは誤解を恐れずにいうと、紹介した3つは同じだと思います。いついかなる時もどのDWHが早いということはなく、どういったデータに対してどういったクエリをかけるかで結果は変わってきます。
次に、セキュリティとバックアップですが、これもどのDWHもしっかりしています。クラウドサービスなので、各ベンダー重々承知しているので問題はありません。機能としてのセキュリティはオフィスのI Pからしかアクセスできないようにするとか、サムルの認証をかけたりとか、このテーブルを観れる人を限定したり、データが暗号化したりは全てのDWHが行えます。」
Snowflakeはバックアップで優れている？
玉井励氏：「バックアップについては各社方法は違う対策が取られており、snowflakeはTimeTravelを有しているので、バックアップについては少し強いかもしれません。ただ、他二つが劣っているかというとそんなことはありません。
セキュリティー・バックアップ面以外でデータへの対応力も問われています。自社のデータを扱っていると日に日に感じているかと思いますが、会社が扱うデータは加速度的に増えているのが現状です。どんどんデータが増えていっても簡単に追従できるようなDWHを選択することが望ましいです。」
完全自動スケーリングのメリット・デメリット
玉井励氏：「BigQueryはスケーラビリティは完全に自動に行なってくれますが、Snowflakeは仮想ウェアハウスのサイズをマウスで変更すればよく、Redshiftはインスタンスタイプやノード数などのスペックを変更して対応していく必要があり、Snowflakeに比べて仮想ウェアハウスのサイズ調整に時間がかかります。一見BigQueryが優れているように感じますが、BigQueryはユーザーが全く介入する余地がないので、特殊な要件があって一部分をコントロールしたくてもできないという反面を有しています。」
同氏はDWHの選定基準としてパフォーマンス以外の面でも重要な点をお話ししてくださいました。
基盤を一つのエコシステムに統一する
玉井励氏：「SnowflakeはSnowflake社のサービスなのに対して、RedshiftはAWSのサービス、BigQueryはGCPのサービスの一つです。自社で既にAWSのサービスを利用しているなら、Redshiftを導入することでアーキテクチャーがシンプルになり、柔軟性も高くなります。
異なるクラウドサービスを利用すると、マルチクラウドとなり両方のクラウドに精通している必要があります。また、連携も同じクラウド内で済ませるより難しくなるという弊害もあります。さらに、クラウドを統一することは運用や料金請求の観点だけでなく、他の部署にとってもメリットがあります。」
コスト比較にするにあたって、三つで比較するのではなく、よく比較されるSnowflakeとBigQueryで比べて解説をしてくださいました。
Snowflake vs BigQuery
玉井励氏：「Snowflakeはクエリの処理の有無に関係なく、仮想ウェアハウスが起動していた時間に対して課金が発生します。それに対して、BigQueryはクエリが処理するデータの量、つまりクエリを処理したときにスキャンした量に応じて課金額が決まります。
Snowflakeは仮想ウェアハウスの扱いでコストをコントロールしていくのがメインになります。仮想ウェアハウスはワークロード別に用意ができるので、BIツール用・データサイエンス用・ETLでデータを入れる用等を用意して、それぞれ個別に調整していくことができます。スペックを決める際は、サイズ×稼働時間がコストになってくるのでSQLを処理し終わったら自動で一時停止の設定もできるので、そういったところを駆使して短い時間でワークロードを処理できるようにする必要があります。
対して、BigQueryはコンピューティングがユーザーから見てないので、クエリを実行した際のスキャン量をいかに減らすかがコストマネジメントになってきます。例えば、テーブルを日付別に分割するなどのパーティショニングを行なったり、必要なカラムのみを選択して分析に必要なものだけを取り出すなどのコストカットをする必要があります。」
SnowflakeとBigQueryはどっちがいいのか
玉井励氏：「一概にどちらがいいとは言えませんが、考え方の例として常に大量のデータを処理し続ける場合は、BigQueryだとクエリの量が膨大になることが考えられるので、Snowflakeの方がいいかもしれません。逆に特定のタイミングだけ巨大なデータを処理するが、それ以外はあまり利用しない場合はBigQueryがいいかもしれません。」
管理の観点からRedshiftという選択肢も
玉井励氏：「ここで、Redshiftについても考えていきます。Redshiftは立ち上がっている時間に応じてコストがかかるので、クエリの処理量や処理時間は気にする必要はないので管理が楽です。また、立ち上がっている時間がコストなので見積もりが非常にやりやすいです。そういった点でRedshiftはSnowflakeやBIgQueryとは違う強みがあります。
この三つを比べて、自社のデータ分析の要件にそれが一番マッチしているのかを考えるのが、コストの観点の選び方になります。」
事例紹介2「デイリーレコード数2億超え！大規模ゲームサービスにSnowflakeを導入したお話」
引用：伊藤寛起・安部永、デイリーレコード数2億超え！大規模ゲームサービスにSnowflakeを導入したお話、https://speakerdeck.com/elfeuille/deirirekodoshu-2yi-chao-e-da-gui-mo-gemusabisuni-snowflakewodao-ru-sitaohua
2つ目の事例講演では、オンラインゲーム開発のデータ分析基盤においてSnowflakeを導入した事例についてお話をしていただきました。技術選定やPoC、またアーキテクチャを作っていく流れをお話しいただき、初学者の方は学びになるのではないかと思います。伊藤寛起氏にはSnowflakeの導入までの流れ、そして安部永氏にはSnowflake運用時の事例や所感を共有していただきました。
株式会社Colorful Palette エンジニアリングマネージャー /
伊藤 寛起氏
Twitter / Facebook
株式会社Colorful Palette 2020年新卒サーバサイドエンジニア
安部 永氏
プロダクトに適したDWHの選定
伊藤寛起氏：「プロダクトは「project SEKAI COLORFUL STAGE! feat.初音ミク」というスマートフォンリズムゲームです。大規模参加型のバーチャルライブ機能が目玉で、イベント開催日のアクセスが多い日だと約３億レコードに達します。
数あるDWHの中からSnowflakeを選ぶ際に重視したのが、コスト・パフォーマンス/スケーラビリティ・技術的チャレンジでした。」
同氏は元々はBigQueryを使うと考えていたため、主にBigQueryと比較してどのように選定に至ったかを紹介してくださいました。
プロダクトに対するSnowflakeの強み
伊藤寛起氏：「Snowflakeの強みは、ウェアハウスの起動時間による課金システムがスキャンしたデータ量より直感的でわかりやすい点だと考えています。
ゲームの特性上ログの量がとにかく多かったり、対象となるデータの傾向などもある程度運用してみないと見えてこないので、スキャンのデータ量でコストが決まるより起動時間でコストが決まる方がイメージしやすかったです。
また、DWHに慣れていないメンバーがほとんどだったので、不要なスキャンを回避できるよう最適化された設計を施したり、それを加味した適切な運用を実施するのは敷居が高かったです。
さらインフラがAWSだったので、転送料といったコストの面だったり、環境周りに起因する導入するコストが低いと考えています。」
Snowpipeによりデータロードが簡単に
伊藤寛起氏：「導入周りのコストを支えてくれていたのがSnowpipeでした。元々DWHの導入以前から、S３に配置するという機構は組めていたので、そこから追加することなくSnowflakeにデータを流し込める機能が魅力的でした。」
パフォーマンス・スケーラビリティの点でもSnowflakeは相性がいい
伊藤寛起氏：「ゲームはログの量や種類が膨大で、運用するにつれて新しいログの形態が増えていきます。それら大量のログから目的のデータを迅速に抽出する必要があるといった点でパフォーマンスは重要です。また、そういったデータを扱う職種が多様なので、オペレーターの職種ごとに権限の管理を行えることも重視しました。パフォーマンス面ではBigQueryとSnowflakeとの大きな差別化になりませんでしたが、権限管理の部分が柔軟で堅牢なのがSnowflakeでした。
パフォーマンス面に関して、マイクロパーティションが仕組みとして素晴らしいと感じています。大量のデータに対して迅速に動いてくれたり、とりあえずデータを入れるだけでも軽快に動作してくれていたのが助かりました。
演算ノードとストレージが分離しているので、重たいクエリを飛ばしたときにすぐに大きいサイズのウェアハウスを流したり、用途ごとに柔軟にノードサイズを決めれたのも運用において扱いやすかったです。」
Snowflakeは細かい権限管理が可能
伊藤寛起氏：「ユーザーとロールが分離しているので、それらを組み合わせて細かく権限設定ができるという点が職種が多様なゲームサービスの特性上、大きな選定理由となりました。
そして、ウェアハウスとロールを用途ごとに分割して用意できるので、処理の内容に応じて適切なパフォーマンスチューニングができたり、コストレポートによってどういったところの処理がどういったコストが発生しているかの可視化がしやすく、最適化が行いやすいです。
扱うデータの特性に応じて運用すれば、どのDWHも大きな差はないが技術的チャレンジか否かが大きな選定の決め手であったかもしれません。Snowflakeは国内のゲーム市場で導入事例が少ない点と自社としてBigQueryとRedshiftの導入の事例は過去にあるが、Snowflakeはどの部署もないということでチャレンジできるときには積極的にチャレンジしてみようと思ったのもありました。」
導入フェーズで唯一ハマったのが権限設定まわり
伊藤寛起氏：「柔軟に設定できるのもメリットに違いありません。しかし。その分専門性を求められ設定する項目が多く、導入時の学習コストであったり、設計管理の運用をイメージしながら進行していくのは苦労しました。ただ、導入時に時間をかけて設計管理を行えば、ユーザーやロールが増えたときにどういった形で運用していくかのイメージをしっかり持っていれば、以降の運用は柔軟性というメリットを享受できると考えています。」
サポートが手厚いので1ヶ月でも導入・運用できる
伊藤寛起氏：「リリースの約1ヶ月前から本格的なトライアルを開始しましたが、前半トライアル期間では運用を見据えた権限設計・テーブル設計を行いつつ、Snowflakeの学習期間に費やしました。後半から分析を行うデータアナリストを交えて、BIツールを使って連携し運用検証を行ったり、権限設計の見直し・最適化を行なってリリースに間に合わせることができました。Snowflakeはドキュメントやチュートリアルが丁寧に作られていて、サポートも迅速丁寧で、初心者でも１ヶ月で導入できます。」
次に、安部永氏に運用時の事例や所感をお話していただきました。
Snowflakeの運用事例
安部永氏：「Snowflakeへの取り込み方は、ログなどの追記型データはSnowpipeを用いてオンラインで取り込んでおり、更新データや非定常データはオフラインで取り込んだり、Externalテーブルとして直接参照しています。SnowflakeはTableauや管理画面から見ていて、分析者がtableauのダッシュボードを作成し、ユーザーフォローの分析に使用していたり、Snowflakeを通じてユーザーのログを検索してカスタマーサポートの調査を行なったりするところに使用しています。」
運用時に起きた二つのトラブル
安部永氏：「一つ目はSnowpipeでのデータ取り込み時に欠損が発生した事例です。不正行のあるjsonを取り込むとそれ以降が読み込まれません。この問題のため、リリース直後はKPIが一致しないなどの問題がありました。
フォーマットを変更することで解決することができました。JsonではなくCSVを使用して一見、魔法のような解決策であるが、これはSnowflakeのサポートの方から教えていただいたものでした。」
安部永氏：「二つ目はデータ格納方法に起因するトラブルです。元々ゲーム内のユーザー行動ログを書くレコードがJsonの1行に対応するテーブル構造を使用していました。データを整理することなく入れておいてもsnowflake側で対応してくれるだろうと考え、雑な設計になっていました。しかし、このテーブル構造だとユーザーの行動タイプを検索するクエリを発行する際に、ほぼフルスキャンが発生してしまいます。」
安部永氏：「この問題を解決するために、Jsonをパースして共通で入っているデータはカラムとして保持し、カラムにクラスタリングキーを設定するようにしました。
可変なデータはボディーというカラムでデータを保つようしたことで、ほぼフルスキャンしていたものを大幅にスキャン量を減らすことができ、コスト削減に繋がりました。
Snowflakeではクラスタリングキーのチューニングは自動でやってくれると思っていましたが、依然として大切だと実感しました。基本はSnowflakeの方で賢くやってくれるが、脳死でできるほど甘くはなかったです。」
最後に、運用してみての所感とまとめをお話しいただきました。
Snowflakeはいいところがたくさんあるが、独自要素もある
安部永氏：「運用して感じたことして、Snowpipeは非常に便利です。デイリーでかなりのクエリを実行しますが、遅延や欠損なくデータを取り込めます。一枚のシートで範囲選択実行ができるので試行錯誤するのが非常に楽で、シートが増えることはありません。クエリのプロファイリングをグラフィカルに行えて、チューニングも非常にやりやすいです。
考えるべきポイントして、Snowflake独自の仕様が存在します。プライマルキーであったり、NOTNULL制約が効きません。あとは、分析担当の方が言っていたこととして、BigQueryにある関数がないなどの対応が難しい部分もあります。
脳死でコストが下がるかというとそうではなく、クラスタリングキーのチューニングやDWHの使い方などの知識は依然として必要だと感じました。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/channel/UCFde45ijA-G9zs7s2CuftRw
