アーカイブ動画
インテージグループがSnowflakeを採用するまでの試行錯誤
株式会社インテージテクノスフィア
データビジネステクノロジー本部
IT基盤推進室 室長 川口 真氏
最初に登壇した川口真氏は、Webシステム開発からミドルウェア、インフラ領域にも精通しており、Snowflakeを活用した社内システムの刷新、データ分析基盤の提案・開発などを担当している。
川口氏は、まずインテージグループの膨大なマーケティングデータとの関わり、これまでの歩みについて紹介した。
インテージグループのビジネスは、1960年代のパネル調査から始まった。パネル調査とは、同じ対象者に同じ質問を定期的に複数回行っていく調査手法であり、得られたデータはパネルデータと呼ばれる。インテージグループの最初のサービス、ビジネスの根幹でもあり、その後「SCI（全国消費者パネル調査）」というサービスに成長していく。
1980年代に入ると、小売店のデータにも着目し、POSデータ活用に取り組む。スーパーマーケットやコンビニエンスストア、ドラッグストアなどのPOSからデータを集めた、「SRI」である。
現在では「SRI+（全国小売店パネル調査）」に進化し、全国約6000店舗から収集した、日本最大規模のPOSデータベースとなっている。なおSCIならびにSRI＋については、後述で改めて詳しく紹介する。
データを効果的に活用するためには、高速な集計が必要だ。「パネル調査の歴史≒集計エンジンの歴史」だと、川口氏は語る。
実際、インテージグループでもIBMのメインフレーム、大型コンピューターなどを導入し、コンピューターセンターなどを竣工していった。しかし、当時はまだ十分な集計システムとはいえない状況であった。
そのため、各種マスタデータやパネルデータを独自のバイナリ形式で保持することで、できる限り情報を圧縮。データ項目によってはビット単位で管理し、メモリ管理も自前で行い、ビット演算で高速に集計するといった工夫を重ねていった。
「こうした取り組みの結果、一般的なDBやDWHと比べて、かなり高速でコスパも高い集計エンジンとなりました。一方でコードが古くなり、調整できる後継の技術者が不足していく課題。今後さらに増えるであろうデータや、大きな設計変更に耐えられるかという不安もありました」（川口氏）
それらの課題を解決するために、次世代集計エンジン基盤構築の検討を進めていった。まず、Hadoop系での構築を検討した。その後、BigQueryなどの各種DB、DWHで再検討するが、満足のいく内容にはならなかった。2017年からは、PostgreSQLベースの自社DWHを開発する。それでも「納得のいく集計エンジン基盤ではなかった」と、川口氏は振り返る。
「Hadoop系はバッチ処理であったため、大量データを同時に捌くのに向いていませんでした。BigQueryはコスト的に厳しかった。当時はハードウェア、オンプレにこだわっていたため、PostgreSQLベースのDWHは厳しいと感じていました」（川口氏）
このような状況の中で、Snowflakeと出会う。川口氏は、Snowflakeの2つの特徴である「Unlimited Performance」「Near Zero Management」に、最初はかなり驚いたと語る。
だが、マルチクラスタ、シェアードデータのアーキテクチャを見ることで納得。当時は日本での導入事例が少なかったため、さらに深く調べながら導入を進めていった。
Snowflakeは、大きく3つのレイヤーから構成されていることがポイントであり、それぞれが疎結合となっている。クラウドサービスのため、必要に応じてスケールアップが容易であり、マルチクラスタリングなどの特徴がある。
もう1つの特徴が、これこそがSnowflakeのパワーの源と川口氏が評価する「マイクロパーティション」である。
マイクロパーティションとは、テーブル内のデータを非常に細かい単位となるマイクロパーティションで分割・管理する技術。ユーザーは必要なデータのみを呼ぶことができる。ユーザーによる保守は不要だ。
導入当初は1システムのみ、SRIと集計エンジンのみであったのが、現在ではグループ内、顧客に対してさまざまなシステムで、Snowflakeを活用している。
「単一のプラットフォームで分析データに加えて、トランザクションデータも組み合わせて扱える『Unistore』という新機能に着目しています」（川口氏）
インテージテクノスフィアでは、Snowflake以外にもTableauなど、さまざまなパートナー・サービスと協業しながら、最適なデータ活用基盤の構築に務めている。 川口氏は、具体的なアーキテクチャ事例を紹介してセッションを締めた。
マーケティングデータ提供・分析システムの大規模刷新の裏話
株式会社インテージテクノスフィア
データビジネステクノロジー本部
リサーチシステム1部 2グループ 笹岡 正隆氏
続いては、社内DWHの構築、維持保守などグループ向けシステム開発業務に従事後、SRIの集計システムの開発を担当している笹岡正隆氏が登壇。まずは改めてパネル調査、SCI、SRI＋について解説した。
SCIはエンドユーザー、消費者向けのパネル調査であり、SRI＋は小売店向けのパネル調査である。そのため店舗の面積や地域、利用者の属性といったセグメントでのデータ分析が可能であり、属性を増やすことでより詳細な分析が可能になる。
一方で属性を増やせばデータ量が増し、システムは複雑化していく。そのためSRIの大規模リニューアルが行われることになった。
リニューアルにおけるポイントは、以下スライドのように大きく3つある。データ量の増加だけでなく、データの粒度がより細かく、さらに高頻度でデータ更新が行える。加えて、データを公開した際にユーザーが一気にアクセスすることが予測されるため、しっかり稼働する性能が求められたという。
笹岡氏は、大まかなシステム構成も紹介した。以下スライドの右側、各店舗から上がってきたデータは緑枠内の基幹システムで、集計可能なデータにクリーニングされる。クリーニングが施されたデータはクラウドストレージを経由して、中央赤枠内のSnowflake領域に入り、集計データや各種マスタデータとしてロードされる。
集計されたデータを顧客や社内の営業・アナリストが、各種提供システムからAPI経由で、集計エンジンにキューを投げる。すると集計エンジンがSnowflakeにクエリを投げ、データが参照できるという仕組みだ。クエリには数千行という複雑な指示もあった。
当初はSnowflakeではなく他のDWHを利用していたが、数年間分のトランザクションデータの分析が頻繁に行われることで、スキャンコストが高くなる。だが、同時実行数が増えると1本当たりの速度が落ちるなど、性能がなかなか出なかった。
この課題を解決するため、現在のSnowflakeに入れ替えるわけだが、通常は大きくかかる移行コストが、Snowflakeではかからなかったと笹岡氏は振り返る。
具体的には、コネクタの入れ替え、データをシンガポールリージョンSnowflakeへロード（当時は東京リージョンがなかったため）の2作業だけだったという。そしてSnowflakeに移行した成果を次のように語った。
「1時間あたりのスループット、処理可能本数が以前と比べて3〜4倍になりました。1本あたりの処理時間も同じく3～4倍に高まり、ほぼ目標値を達成することができました」（笹岡氏）
一方でSnowflakeを導入した直後は、性能を存分に発揮できていなかった。その結果を示したグラフが以下である。
笹岡氏はそこからどのようにSnowflakeにチューニングを施し、性能を上げていったのか、引き続き紹介していった。
具体的には同時実行数と処理速度の最適解を、主に4つのパラメータを調整することで、探っていった。まずは以下図の①だ。1台だった処理サーバー、ウェアハウスを複数台に増やした。
データ量に応じたウェアハウスのサイズも試した。それがスライド②の部分であり、XL、2XLなどが該当する。③の「hot／cold」とは、キャッシュの有無による性能差であり、初回起動時とキャッシュがある場合ではかなり性能差が出る。
④は、Snowflake3つのレイヤーの上段、クラウドサービスレイヤーにおいて、単純に分散数を増やすだけでは全体性能が出ないため、注意が必要だ。
だが、目指している性能はこれらの調整だけでは不十分であった。そこで今度はクエリを対象としたチューニングを実施した。クエリのチューニングにおいては、Snowflakeのクエリプロファイリングを使った。
しかし、同機能を使うことでトランザクションデータのスキャンにおいて、膨大なコストがかかっていることがわかった。また同タスクは、スキャンの中で最も負荷がかかっていることも示されていた。
対策として、こちらも再びSnowflakeの機能であるクラスタリングキーを検討したという。具体的な使用方法も紹介された。
Snowflakeではデータはマイクロパーティションという小さなファイル単位で保存されている。クラスタリングキーは、このマイクロパーティション内のテーブルデータに設定を施すことができる機能だ。
設定値を工夫することで不要なマイクロパーティションのスキャンを減らし、結果としてデータ量、スキャンコストを減らすことができた。
チューニングを行うと37秒かかっていた集計速度は、28秒に減らすことができた。スキャンしたパーティションの合計も1万3440から1万444と、約3000も減った。そして見事、目標性能を達成することに成功した。
POSのデータ統合から考える「データ分析基盤」
株式会社インテージテクノスフィア
データビジネステクノロジー本部
IT基盤推進室 システムコンサルタント 新 俊駿氏
続いて登壇したのは、SIerで経験を積んだ後、2017年に長野に移住してインテージテクノスフィアに転職した新俊駿氏。前職では全国5000箇所に導入された給食栄養管理システムの開発責任者として、新規設計から開発・導入・保守業務など、10年以上携わったキャリアを持つ。
顧客への提案、教育、各種講演、業務運用改善といった領域の業務にも携わっており、入社後はビッグデータ基盤構築とデータ分析処理開発、データ活用支援に従事。2020年からはこれまでの経験を活かし、プリセールス的なシステムコンサルタントとして、技術面からも顧客をサポートしている。
新氏は、まずPOSデータマーケットの変化について説明を行った。これまでは棚に商品を置き、CMを流せば売れる時代であった。だが、コロナ禍を経て変化が起きた。大きくは2つある。多様な価値観や購買行動、生活スタイルなど、生活者の変化だ。もう1つは、商品を販売する大手チェーン側の変化である。新氏は次のように状況を語った。
「大手チェーンがより大きくなり、寡占化状態となっています。バイヤーのリテラシーも向上し、テレビCM以外も信頼されるようになりました。一度失敗すると商品を置いてもらえない、そのような状況も生まれています」（新氏）
これらの変化により、消費財メーカーの営業は統合されたPOSデータに限らず、他のさまざまなデータの分析と、生活者に対する深い理解に基づいた訴求力のある提案が求められていると、新氏は言う。
つまり営業自らがさまざまなデータを分析し、最適解を判断する。その上でメーカーのバイヤーに直接提案する。このようなスキルが求められているのだ。
一方、POSデータはデータ量が大量にある。フォーマットがチェーンにより異なるなど、統合するには課題が多いのだ。そこで、ここでもSnowflakeを活用したPOSデータの分析基盤を構築することで、課題を乗り越えていった。
新氏は、具体的なシステムの設計思想を以下のように示した。
設計思想においては「できるだけSnowflakeに寄せて開発した」と新氏。実際、データ基盤の領域はSnowflakeで統一されていることが分かる。一方でストレージはAmazon S3など、冒頭に川口氏が紹介した内容と重なる。
POSデータの統合や他のさまざまなデータの取り扱いにおいても、チェーンごとに異なる拡張子のファイル、在庫や販促、市場、気象データなども統合できる基盤であることがわかる。
このようなアーキテクチャとすることで、秒課金のためコストパフォーマンスが向上する。チェーンが増えて大量データが同時に入ったとしても、取り込み時のパフォーマンスが落ちない。まさに笹岡氏が指摘していた、同時実行性能の高い設計であると新氏は説明した。
新商品のチェック、消費税の処理など、チェーンが異なっても共通している内容、領域については共通・汎用化を行う。
Snowflakeの開発者向けフレームワークのSnowpark、データベースに対する連続した複数の処理を一つのプログラムにまとめ、データと共に保存できるストアドプロシージャー機能で実現する。汎用・共通化処理を施し、クレンジングされたデータをDWHに格納していくのだ。
新氏は、データ統合ならびにデータをコラボレーションする理由・可能性について、コンビニで展開している新商品の売上が下がっていた事象を例に、次のように語った。
「今見ているデータは、一部の領域に限られている可能性があります。そのため本当の答えが何なのか、見つけられない場合があります。見つけるためにはデータを増やし、コラボレーションしていく必要があります」（新氏）
例えば、市場や気象といったデータをデータ基盤に集めて統合することで、データから真の答えを見つけていく。メーカーの営業担当者が適切な提案をバイヤーに、自ら行える状態の実現につながる。
営業担当者のスキルや経験に問わず、誰でもデータを活用でき、的確な提案をできることも大切だ。実際、昨今はそのようなサービス、いわゆるBIツールが増加しており、さまざまなダッシュボードが作られている。
一方で、このような定型的なデータ分析情報だけでなく、自分なり、あるいは企業ならではのダッシュボード、セルフサービスBIを作りたいというニーズがある。場合によってはデータを数百種類増やしてほしいというニーズもあるという。
当然、出口・保管場所であるデータマートの量も増えていくため、管理が難しくなると新氏は指摘。対応としては、スタースキーマの採用を検討していると語った。
自由分析が拡大していけば、「すべてのデータを公開してほしい」という、究極的なニーズに行き着くだろうと新氏は言う。一方で、データガバナンスの観点からそのような対応は難しいと続けた。
そこでデータマネジメント組織を設立したり、データスチュワードを任命するなど、データガバナンスを強化することが大切だと指摘し、セッションを締めた。
「ユーザーも我々もデータマネジメント環境を整えることで、攻めのデータガバナンスを実現する。その結果、自由自在にデータを分析できる。そのような環境を構築していくことが目指すべき未来だと考えています」（新氏）
【Q＆A】参加者からの質問に登壇者が回答
セッション後は、イベントを聴講した参加者からの質問に登壇者が回答した。
Q．Snowflake導入に際し、整備しておくべきことや決めておいた方がいいルールとは？
笹岡：どのようなロールを設けて、アクセス権を付与するかが重要になってきます。
新：Snowflakeに限ったことではありませんが、データカタログ的なものがあると、使いやすいと思います。
川口：アカウント全体で持っているパラメータのタイムアウトが長いため、調整しておかないとずっと走っているので、気をつける必要があります。
Q．Snowflakeのデータを効果的に分析・活用できるおすすめBIは？
川口：Tableauですね。
新：私もTableauをおすすめします。Snowflakeとの相性がいいからです。BIユーザーがたくさん増えても、マルチウェアクラスタが機能する同時実行性能も理由の1つです。アドホック的、セルフBI的な分析は、Tableauが一番使いやすいと思います。
株式会社インテージテクノスフィア
https://www.intage-technosphere.co.jp/
株式会社インテージテクノスフィアの採用情報
https://www.intage-technosphere.co.jp/recruit/
関連するイベント
