概要:このケーススタディでは、主に、長年にわたり複数の自社構築データ ウェアハウス製品システムに直面してきた Semir Group が、Alibaba Cloud MaxCompute + Hologres + DataWorks の統合データ ウェアハウス プラットフォームを使用して、データ生成の安定性とデータ品質を確保し、ETL リンクとコンピューティング時間を削減し、年間の総データ ウェアハウス コストを 300 万人民元以上から 180 万人民元に削減した方法について説明します。

講師：浙江セミールデータウェアハウスシニアマネージャー、ジン・インロン氏

このケーススタディでは、主に、長年かけて構築された複数の自社開発データ ウェアハウス製品システムに直面していた Semir Group が、Alibaba Cloud MaxCompute + Hologres + DataWorks の統合データ ウェアハウス プラットフォームを使用して、データ生成の安定性と品質を確保し、ETL リンクとコンピューティング時間を削減し、年間のデータ ウェアハウスの総コストを 300 万人民元以上から 180 万人民元に削減した方法について説明します。

I. セミールグループの紹介

セミールは1996年に設立され、製品とブランドを、若々しくファッショナブルでエネルギッシュ、そしてコストパフォーマンスに優れたマスマーケット向けカジュアルウェアとして位置付けています。2023年には100億人民元を超える売上高を達成し、メインブランド「Semir」と「Bala」に加え、ファッション、スポーツ、ホームファニシングなどを扱うサブブランドを展開しています。セミールは2010年に最初のブランドを上場し、2014年にはeコマースプラットフォームを立ち上げました。2022年から2023年にかけて、両社の合併に着手し、セミールのビッグデータプラットフォームとeコマースプラットフォームの統合も行いました。

II. クラウドへのデータ移行の検討

Semirのデータ分析・探索プロセスは、基本的な自社開発のオープンソースデータウェアハウスから商用製品のデータウェアハウスへと進化しました。最終的に、Alibaba Cloud MaxCompute + Hologres + DataWorksを選択してビッグデータプラットフォームを構築しました。当初はSQL Serverを使用して、3000～4000店舗の小売データを分析していました。その後、Semirが株式公開した際に、ERPシステムを備えたデータ分析スイートを含むSAPプロジェクトを実装しました。このスイートは2015年まで使用されていました。店舗数とブランド数が増えるにつれて、データ量は膨大になりました。当時、データが変更されると、データ抽出から最終的なデータ可視化まで約12時間かかりました。そのため、2015年に、データ分析のニーズを満たすために、Hadoop、Spark、またはその他の商用MPPデータベースを使用するかどうかを検討し始めました。

選定プロセスでは、Semir の現状を踏まえ、データチーム全体で 3 ～ 4 人程度しかいませんでした。当時のオープンソースのビッグデータソリューションは、技術変革とデータ保守の両方に多大なコストがかかると評価しました。そのため、2015 年には、特定の段階で一定量のデータを分析するために SAP HANA を使用しました。e コマース部門が設立された後、既存の小売データ分析には EMR などのオープンソースのビッグデータプラットフォームを使用することを希望しました。2022 年に Semir とグループが統合プロジェクトを開始したとき、私たちの目標は商用プラットフォームを使用してデータをクラウドに移行することでした。当初、選定プロセスでは、データウェアハウスとデータサービスを構築するために、おそらく Workflow と Spark、または Hive を備えたオープンソースのクラウドプラットフォームを使用するという社内コンセンサスがありました。しかし、このプロセス中に多くの落とし穴に遭遇しました。これについては後の章で説明します。

2022年までに、Semirのデータウェアハウスは15TBのデータに達し、10を超えるブランドと20を超えるデータベースが単一のデータウェアハウスプラットフォームに集約されました。eコマース向けには、約60TBのデータを含むデータパフォーマンスを向上させるため、データウェアハウス内に多数のデータ統合テーブルを実装しました。私たちの主な目標は、データをクラウドに移行し、その分散コンピューティング機能を活用して膨大なデータ量を処理することでした。データウェアハウスは、毎日午後10時に店舗が閉店した後、またはオンライン小売決済データがビッグデータプラットフォームに送信された後、ETL計算を開始し、翌朝7時までにデータを分析データベースに配信することで、翌日のビジネス分析とレポートクエリを確実に実行できるようにする必要があります。Semirがビッグデータコンピューティングを導入した当初、SAP HANAを使用していましたが、当時、SAP HANAサーバー1台のコストは約500万人民元でした。IDCデータセンターには、合計メモリが20TBを超えるサーバーが約6台あり、全体的なコストが非常に高くなっていました。そのため、コスト削減のためには、弾力的なスケーリングが必要でした。

ビッグデータ プラットフォームを選択する際に、Semir も同様のプロセスを経てきました。まずクラウド サーバーを購入し、次に Spark のコンピューティング能力を活用するために独自の Hive インスタンスを構築し、最後にデータの ADS レイヤー、つまりデータ ウェアハウス モデル レイヤーを ClickHouse に配置しました。このプロセス全体を通して、ジョブのスケジューリングには Airflow を使用しました。私たちのチームは約 3 名で構成され、このシステムのセットアップ、メンテナンス、およびデータ レポート要件をサポートしていました。しかし、このオープンソースのビッグデータ アーキテクチャの使用には多くの課題がありました。たとえば、ClickHouse を初めて統合したとき、分散 MPP データベースの構築や、ZooKeeper キューでほぼ毎週タイムアウトや OutOfMemoryErrors (OOM) が発生するなど、データ最適化の問題が発生しました。その後、データ ウェアハウス アーキテクチャ全体にクラウドベースの Data Factory と Synapse を使用することを検討しました。しかし、全体的なデータ処理速度と MSSQL ライセンスのコストが懸念されました。プロジェクトの実装初期段階では、コストが制御不能になると判断しました。そこで、Semir e-commerce は Alibaba Cloud と密接なパートナーシップを築いていたため、昨年 9 月に MaxCompute + Hologres + DataWorks を使用して構築しようと試み始めました。

III. Semirの旧式のサイロ型データアーキテクチャ

2022年から2023年にかけて、プラットフォームアーキテクチャの構築作業に多大な労力を費やしました。データウェアハウスは主に構造化データを使用しており、ERPシステム、一部の顧客フローデータ収集システム、マスターデータ、一部のオンラインCRMシステムなどが含まれます。データウェアハウスプラットフォームは2つあり、1つはSemir Groupが構築し、もう1つはSemir e-commerceが構築しました。

最初のリンクでは、このデータをクラウド A に同期し、Spark を使用してクラウド A で実行し、データ結果を生成し、それを CK クラスターにプッシュしてデータを消費します。

2つ目のリンクは、Bojunの過去の小売注文に基づいており、緑色のセクションの計算を実行するためにHANAデータベースに同期されています。クラウドからの注文は、オープンソースコンポーネントを使用してデータベースに直接抽出され、Sparkで処理された後、CKに送信されます。CKには、ビジネスアナリスト専用の分析ライブラリであるCK39が含まれています。ビジネスアナリストは通常​​、Pythonコード、またはPower BIやTableauなどの独自のBIツールを使用してデータベースに直接接続し、本質的に制御不能なデータを利用します。そのため、CK専用のクエリライブラリを作成しました。HANAは主にDaoxunシステムとSAPシステムのデータを処理しており、これは2015年から継承されたデータ資産です。

右端にある3つ目のリンクは、当社のeコマースプラットフォームです。このeコマースプラットフォームは、JushitaからAlimamaへのデータを同期します。AlimamaもHIVE + Impalaテクノロジーを採用しています。

Semirとeコマースのデータ統合に取り組んだ際、私たちは基本的に2つのデータウェアハウスの間に橋を架けました。データ交換はOracleを介して実現し、サービスレイヤーではCK、HANA、Hologresの3つのサービスレイヤーを通じてデータサービスを提供しました。最終的に、これらのサービスを利用して、デジタルストアとSemirのデータ分析プラットフォーム（商品分析、商品オペレーション分析、ライブストリーミング分析など）を接続しました。Guanyuan、FineReport、SAPなどのBIツールに加えて、独自に開発したデータアプリケーションもいくつか接続しました。

ご覧のとおり、データパイプライン全体は非常に複雑で、中断が発生しやすい構造になっています。初期データから最上位の3つの分析データベースに至るまで、3つのレイヤー、つまりeコマースクラウドプラットフォームからEMR、データセンター内のOracle、そして最終的にHANAへと進みます。一部のデータは、Cloud A上のデータウェアハウスに転送され、さらに処理されます。いずれかのノードでエラーが発生すると、パイプライン全体が麻痺する可能性があります。そのため、AirflowとDataWorksに電話通知アラートを設定するという、手間のかかる解決策を採用しました。いずれかのノードで障害が発生した場合、チームを復活させるために電話をかけます。個人的には、これはかなり無謀なアプローチだと思いますが、このような状況下では他に選択肢がありませんでした。これが、2022年の統合前のデータプラットフォームの状態でした。

IV. Semirデータプラットフォーム構築目標

今ご覧いただいたアーキテクチャ図を要約すると、私たちのペインポイントが極めて重大であることがはっきりとわかります。私たちが普段使う言葉で言えば、それはデータサイロ、つまり一種のデータ煙突構造に関するものです。これは、私たちの組織が進化したためです。私たちはオープンソースのデータウェアハウスから始め、次にオープンソースウェアハウスを構築しながらデータサービスの継続性を確保することに注力し、HANAデータチェーンを維持し、最終的にそれをeコマースデータウェアハウス、つまりOSS + EMRに基づく単一のデータウェアハウスに統合しました。これら3つのデータウェアハウスは同時に稼働しており、CK、HANA、Oracle、Hologresの4つの異なるデータベースを通じてサービスを提供し、合計1200のテーブルがありました。かつて、上司は、分析ニーズが非常に多いにもかかわらず、データウェアハウスに1200を超えるテーブルがあるのはなぜかと尋ねたこともありました。これは、サイロ化されたモデリングによってデータの計算と保存に冗長性が生じたことの必然的な結果です。

これら 3 つのデータ ウェアハウスでは、運用と保守を同時に実行する必要があります。これらの 3 つのデータ ウェアハウスは、Airflow、CK 最適化、HANA、Spark 開発という 3 つの異なるテクノロジー システムに属しており、各メンバーの技術的背景と専門知識は異なります。e コマース統合から来た同様の技術的背景を持つパートナーもいますが、1 人の担当者が担当できるのは 1 つの業務ラインのみです。その業務ラインに問題が発生した場合、そのパートナーはその日の業務を続行できなくなり、運用と保守に集中しなければならず、問題への対応をその 1 人の担当者にのみ依存することになります。これは、データ ウェアハウスの管理、データ品質、およびサービスの継続性にとって重大なリスクとなります。そのため、運用と保守、リークの防止、新しいデータ要件の開発サポートを同時に実行しています。

様々なプラットフォーム上に構築された新旧両方のデータ製品から得られるデータは、データフローとマージプロセスにおいて必然的にデータの不一致を引き起こします。複雑なデータ処理を通して単一のデータセットを基盤レベルで利用することは可能ですが、異なる技術的背景、知識ベース、そして多様なニーズを持つ担当者が複数のデータウェアハウスを利用すると、異なるデータ製品間でデータの不整合が発生する可能性があります。例えば、一部のメトリクスはオンラインとオフラインの両方で計算される場合があり、開発リソースの分散化が進み、冗長な計算によってデータコストが増加します。このプロセスにおいて、主要なオープンソースシステムはCKクラスターであり、非同期処理にZookeeperを使用しています。主な問題は、データを削除できずに書き込みが続けられる非同期書き込みです。ある日、データ量が数倍に増加し、上司は私たちがかなりの利益を上げたと考えました。しかし実際には、ログパーティションがいっぱいになったり、特定のZookeeperノードが特定のジョブに書き込みできず、キュー全体がフリーズしたりすることがありました。その結果、深夜に何度も電話がかかってくるようになり、週末はほとんど休みませんでした。データリンクは長く複雑で、多様な技術が運用・保守を困難にしています。企業のチームがそれほど大きくない場合、この道は多くの落とし穴に陥るでしょう。

この課題に対処するため、私たちは解決策を検討してきました。私たちの最大の目標は、テクノロジープラットフォームの統一です。誰もが統一されたテクノロジープラットフォームを用いて、綿密な開発、データ蓄積、そして処理を行っていなければ、この状況は永遠に続くことになります。これでは、KPIの達成やデータサービスの継続性確保は不可能です。そのため、まずはプラットフォームを統一し、全員が同じテクノロジースタックを利用できるようにすることが私たちの課題です。そして、この統一されたテクノロジープラットフォームの下で、データウェアハウス全体のビジネスモデル、分析モデル、そしてデータサービスの蓄積を完了させます。

2つ目の目標は、商用プラットフォームを確実に活用することです。オープンソースプラットフォームが悪いと言っているわけではありませんが、Semirのような小売業を営む衣料品会社にとって、最優先事項は技術的な問題の解決ではなく、営業担当者が的確な業務判断を下せるよう、安定した効果的なデータサービスを提供することです。社内には技術的な問題に対応できる技術専門家がいますが、これらのプロセスがタイムリーに行われるとは限りません。そのため、タイムリーで効果的な技術サポートと保証を得るためには、商用プラットフォームが不可欠だと私たちは考えています。さらに、成熟した商用プラットフォームの安定性には、より強い信頼を置いています。オープンソースプラットフォームと比較して、商用プラットフォームは多くの複雑さを軽減します。

第三に、データ統合、保存、管理といったデータレイクの機能を含め、将来の開発も考慮する必要があります。データ統合には、構造化データと非構造化データの両方へのバッチおよびリアルタイムアクセス、そしてさまざまなデータサービスへのアクセスが必要です。例えば、データ保存後の権限やセキュリティの管理には、ビッグデータプラットフォームのデータストレージ管理機能を活用します。さらに、データウェアハウスを構築する際には、いくつかの標準化要件があります。現在のデータウェアハウス構築は独自の経験に基づいていますが、このプラットフォームを選択するには、データウェアハウスの標準化をサポートするためのデータモデリングスイートが必要です。さらに、データ品質、データガバナンス、データサービス、データセキュリティ制御については、これらの側面をサポートするためのスイートが必要になります。これが、実装に商用ビッグデータプラットフォームを選択した理由でもあります。Semirでこれらのスイートが必要になった場合、パートナーとコミュニケーションを取って活用することができ、これにより多くの開発ステップも削減されます。

4つ目の要件はデータ処理能力です。商用クラウドプラットフォームのデータ処理能力は概ね同程度ですが、最も重要な要素は弾力的なコンピューティング能力です。私たちの現在の目標は、2つのOMSシステムと8つのDaoxunサービスからのETLプロセス全体を、クリーニングと変換を経てデータウェアハウスに統合し、最終的にフロントエンドデータベースに配信するまでのプロセスを7時間以内に実現することです。これが私たちの選定と構築の目標であり、これらの目標に基づいて、Alibaba Cloudのパートナーとニーズを共有しています。

V. Semir データ プラットフォーム ソリューション - MaxCompute + Hologres + DataWorks

最終的に、オフラインコンピューティングにはMaxCompute、OLAP分析プラットフォームにはHologres、統合開発プラットフォームにはDataWorksを選択しました。当初、プロジェクトではバッチ処理のみを使用していました。MaxComputeにデータを完全または段階的に抽出し、ODSレイヤーに格納した後、DWD（データ詳細ビュー）レイヤーを構築し、データ集約と要約を行ってDWS（データ詳細ビュー）レイヤーを生成するというものでした。最終的には、モバイルデバイスからのデータリクエスト、ユーティリティツールからのリクエスト、QRコードデータダッシュボードからのリクエストなど、分析モデルとBI要件全体がADSレイヤーに実装されました。

これらのアプリケーションリクエストはすべてHologresによって処理されます。Hologresのアーキテクチャはマスタースレーブアーキテクチャで、1つのマスターHologresインスタンスがデータの更新と書き込みを処理し、3つの並列実行ライブラリが分析を実行します。なぜこのマスタースレーブアーキテクチャが必要なのでしょうか？実際のアプリケーションでは、アナリスト、地域運用管理、店舗運用、キーオペレーションのニーズは、必要なデータ量、クエリ方法、リソース要件が異なるためです。このマスタースレーブアーキテクチャは、全員が同じデータを分析してデータの一貫性を維持するだけでなく、異なる部門のニーズに基づいて分離を実現し、各分析要件の分離を保証し、相互干渉を防ぎます。さらに、各部分は弾力的なスケーリングを維持できます。将来的には、エージェントがデータ製品にアクセスできるようにし、データエンパワーメントなどを提供する予定です。Hologresを通じて、アーキテクチャをマスタースレーブアーキテクチャ（マスター1台、スレーブ5台、マスター1台、スレーブ6台）に水平スケーリングする予定です。実装中にいくつかの問題が発生しましたが、Alibaba Cloudのサポートは非​​常に良好で、多くの問題は2時間以内に解決されました。 DataWorks データ プラットフォームは、データ品質、データ保護アンブレラ、データ資産、運用および保守監視など、さまざまなスイートのニーズを満たします。

VI. Semirデータプラットフォーム構築プロセス

Alibaba Cloud統合プラットフォームでは、まず15のシステムから1800以上のテーブルを抽出し、ODSレイヤーに移動しました。実際には、データが一時テーブルに保存されていたSTGレイヤーから始めました。処理後は基本的に転送するだけで、正式なODSテーブルに移行しました。データのフォーマット調整など、若干の修正はしましたが、データ自体は一切変更していません。主なデータソースは、SAPの財務、購買、在庫データなどのHANAや、各種オフラインEMR業務システムでした。Oracleデータベースは、バージョン12cと19cで、ブランドごとに1つずつ、約12個ありました。

ECサイトでは、主にMySQLを使用しています。CDMレイヤーは、8つのブランドの基本的なビジネスバリューチェーンの分析をサポートしています。アパレル業界における最初の受注会から、SAPへの発注、在庫の生成、代理店との契約締結、SAPの販売アウトバウンド出荷の成立、店舗への在庫配分、そして様々なオンラインECプラットフォームまで、包括的なオムニチャネルデータモデルを構築しています。また、このフレームワーク内で会員モデルも開発し、DAMOやYiKeなどのCRMプラットフォームからCRMデータを抽出して会員データモデルを構築しました。これらの基本モデルが、SemirのCDMレイヤーデータビジネスバリューチェーンの基盤となっています。

この基盤に基づき、発注、調達、卸売、オムニチャネル在庫、オムニチャネル小売、オムニチャネルメンバーシップ（CDP）という6つのコアモジュールをサービスとして開発し、1,500を超える履歴テーブルを網羅しています。データ移行中、ADSレイヤーのすべてのデータは最終的にこれらの6つのテーブルから生成されます。これらの6つのテーブルのデータ品質が適切に管理されていれば、移行中のデータ品質全体を保証できます。さらに、デジタルストアやユーティリティツールなどのシナリオにおけるデータニーズに対応するため、これらの6つのコアテーブルをベースに500を超える追加のADSテーブルを開発しました。

VII. Semirデータプラットフォーム構築の成果

2023年12月末から2024年2月初旬まで、春節明けの約2ヶ月で稼働を開始しました。どのような改善がもたらされたのでしょうか？稼働開始後、私たちは大きな安堵感を覚えました。ようやく週末を丸々過ごせるようになったのです。店舗運営担当者がプラットフォームの技術的な問題でデータが欠落している理由を尋ねるケースはほとんどありませんでした。これは、店舗運営担当者が通常週末にデータを確認するためです。アパレル小売業界では週末が売上のピークです。店舗運営担当者は毎日午前10時、正午、午後4時、午後6時、あるいは午後9時に売上データを確認します。これらの時間帯にデータが欠落していると、店舗運営担当者や地域マネージャーはすぐに苦情を申し立てます。稼働開始後、データ異常は毎週発見されていた状態からほぼ完全に消失するまで大幅に減少しました。月次の異常はまだいくつかありますが、これらはデータ開発と管理をさらに改善できる領域です。ETL異常を引き起こす開発上の問題によるものもありますが、データ出力には影響しません。

そのため、夜間シフトシステムは維持しており、将来的には夜間シフトを完全に廃止することを目標としています。もう一つのメリットは、ETL時間の短縮です。以前は、3つのデータウェアハウスシステムでETLに約10時間、実際には10時間以上かかっていました。これは、重要なネットワークレポート頻度データ分析プロセスに多大なリソースが消費され、午後11時から深夜0時までかかることがあったためです。私たちは、プロセス全体を10時間から6時間に短縮し、チームが午後7時までにデータを確認できるようにすることを目指しています。さらに、テストチームがデータ製品を監視して、その日のデータ出力の品質を評価しています。ETLデータに異常があれば、データ利用者に直接公開され、苦情につながる可能性があります。

最後に、基本リソースのコスト削減と効率化です。Semir Groupのeコマース統合では、HANA（コンピューティング費用なし）、EMR、A Cloud上のストレージおよびコンピューティングリソースを含むデータウェアハウス部分だけでも約300万ドルの価値があります。今年8月末までに、A Cloud上のすべてのデータウェアハウスおよびビッグデータ関連リソースがリリースされ、社内の移行とクリーンアップ作業も完了する予定です。これにより、全体のコストは180万ドル、あるいはそれ以下まで削減できると見込んでいます。

VIII. 将来の見通し

今後の展望として、まずは統合テクノロジープラットフォームの構築、クラウドへの移行、テクノロジースタックの統合、そしてデータサイロ化への対応としてデータウェアハウス開発の標準化を進めていくことが基本的な側面です。次に、データ製品ラインの合理化が必要です。ご覧のとおり、当社には約5つのBI製品があり、これらを統合する必要があります。これは今年既に実現しています。今年の計画は以下の通りです。まず、Flinkのリアルタイムモデルをベースとしたリアルタイムコンピューティングを検討し、618ワークダッシュボードに導入することで、ビジネス上の意思決定を支援します。次に、当社のアナリストの多くはPythonによる分析スキルを有しており、中にはJavaやSQLの開発能力を持つアナリストもいます。彼らが様々なデータクエリライブラリに依存して処理を行うことは避けたいと考えています。オープンデータインターフェースを提供することで、彼らがコードを統合し、ビッグデータプラットフォームに接続してデータ処理を行えるようにしたいと考えています。これは現在、計画と検証の段階にあります。最後に、統合データプラットフォームが構築された後、2つのサービスレイヤーを構築します。 1つのレイヤーはビジネスバリューチェーンに基づくクエリサービスであり、もう1つはデータ分析システムからマッピングされたデータウェアハウスレイヤーの分析モデルです。これには、これらの分析の使用方法、データが使用されるシナリオ、データ品質、主要なサービス管理、主要な責任者が含まれます。私たちは、このデータサービスをデータアナリストや代理店に提供し、データウェアハウス内のデータ資産と、それらの資産がデータ分析にどのように役立つかを確認できるようにしたいと考えています。

もう一つはデータ品質です。以前は開発体制が異なっていたため、データ処理やコード開発の品質にばらつきがありました。今年はデータプラットフォームプロジェクトのおかげで、基本モデル層でのデータ統一が実現し、データ品質は向上しました。しかし、指標の定義が異なることで、製品間でデータの不整合が発生する場合があります。例えば、Semirのセルスルー率についてですが、ブランドのセルスルー率は仕入れと販売に基づいていますが、顧客や店舗の場合は販売数量の算出が中心となります。以前の開発プロセスでは、一部はeコマース関連、一部は社内の分析システムに基づくものなど、これらの指標に対する理解が不十分だったため、データの見方や解釈に誤りが生じやすかったのです。そこで、今年はSemirの分析指標システム開発を専門とする中央管理部門を設置しました。データモデル、データサービスなどを含むこの指標システムは、私たちのデータ資産を形成しています。

製品面では、クライアントのエンパワーメントを目指しています。現在、すべての代理店や販売店はERPシステムを通じてデータを取得していますが、データ分析への投資は限られています。本社は、店舗運営や事業運営に関するガイダンスを強化しています。現在、大ヒット商品創出に向けた戦略を策定しており、今年はデータサービスを通じて、データ製品に分析に基づく意思決定機能を提供する予定です。例えば、販売員や店長が在庫補充を行う際、大ヒット商品が出現した際、あるいは店舗が在庫不足に陥った際など、データ製品を通じて、データに基づいた意思決定サービスを事業運営に直接提供することができます。

さらに、ビッグデータプラットフォームはこぞって大規模モデルについて議論しており、AIをデータウェアハウスやデータサービスと対話や質問を通して組み合わせることで、より大きなデータ価値をもたらす方法が模索されています。私たちもこれを模索しています。今年、データ資産を徐々に構築・改善できれば、AI技術と組み合わせ、大規模モデルを通して何らかの成果やハイライトを達成できるかどうかを検討します。データウェアハウスの構築は、まさに継続的な蓄積のプロセスです。ビジネスの変化に伴い、データ分析のスタイルやシナリオも変化しています。これらの分析シナリオと過去の分析の蓄積はすべてデータ知識に属します。この知識をモデルや指標の形で蓄積し、Semirのビジネス分析知識ベースを形成できるかどうかは、長期にわたる反復的なプロセスになるでしょう。データプロダクトに関しては、データ意思決定サービスを構築できれば、データプロダクトは端末ビジネスとのより緊密な連携が可能になります。これが、今後2～3年を見据えた私たちの開発方向性と構想です。

以下は、私たちが段階的に構築していくべき目標を示した、将来のテクノロジーアーキテクチャ全体の図です。PLM、DRP、OMS、SAP、CRMといった社内システムに加え、非構造化データ、半構造化データ、動画データなど、より多くの業界データを取り扱うようになります。オフライン店舗にはすでに多くの動画・音声データが蓄積されているため、まずはそれらを保管し、ビッグデータプラットフォームを構築した後にマイニングすることが可能です。例えば、Semirの顧客トラフィックの音声・動画分析から3年間の履歴データに基づいて知識を抽出できるでしょうか？このように、私たちのビッグデータプラットフォームはデータレイクへと発展していくでしょう。

メインスイートには、統合スイート、ストレージ管理、コンピューティングエンジン、そしてデータベースを管理し、要件を設定するためのデータ管理またはセキュリティ制御が含まれています。データウェアハウスは既に構築されていますが、その中に蓄積された知識は継続的な反復が必要です。現在、アナリストやビジネスオペレーションチームと協力してBIソリューションを選定しており、主な目標は分析モデルレイヤーをどこに組み込むかを決定することです。データレイク上のコンピューティング機能（オフラインおよびリアルタイムコンピューティングを含む）は、これまでのところ問題に遭遇していません。データガバナンスは、データソースのビジネスバリューチェーンモデルの構築、メタデータ構築、あるいは分析モデルのメタデータ構築など、データ資産の形成を含む、今年の主要目標です。現在、マスターデータの統合に取り組んでいます。以前は2～3セットのマスターデータ管理システムがあり、各ブランドが独自のマスターデータを管理していました。しかし、バックエンドに統合されると、すべてのマスターデータを管理・配信するには、統一されたマスターデータ管理プラットフォームが必要になります。これは、今年のデータガバナンスの重要な側面の一つです。機械学習とAIに関しては、ルールベースモデルに基づくデータ分析を長年検討してきました。過去3年間はプラットフォーム構築に注力してきたため、機械学習とビジネスの側面を深く探求し、データウェアハウスの知識機能を活用することを目指します。

最終的には、サプライヤープラットフォームを通じて、あるいは上流のデータ利用者に標準化されたAPIサービスを提供することで、BIツールとデータサービスを活用することを目指しています。これは、ビジネスレイヤーの基盤となる包括的なデータウェアハウスを基盤としており、製品企画から生産、調達、在庫、発注、発売、流通までを網羅しています。また、柔軟なサプライチェーン管理、在庫・売上分析、そして約70～80の指標を組み合わせた販促活動の評価も含まれています。さらに、オンライン小売の利益率や端末店舗運営など、小売業務のための堅牢なデータ分析フレームワークも提供します。このフレームワークは、粗利益、コスト、在庫回転率、製品ライフサイクル、店舗収益性、業務効率など、店舗業績の360度包括的な分析をサポートします。これらの分析に基づき、オペレーションレベルでの戦略立案と運用計画、商品の一元的な補充・在庫一掃セール、そして小売業務における様々なチャネルやプラットフォームをまたいだ集客、利益率、そして運用健全性の分析をより効果的にサポートします。