Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
イオンが立ち上げる超巨大データ基盤/Super huge data platform laun...
Search
AEON
December 14, 2023
Technology
2
3.6k
イオンが立ち上げる超巨大データ基盤/Super huge data platform launched by AEON
https://techplay.jp/event/924680
データマネジメントの勘所 大手企業3社から学ぶ!データ分析基盤と組織のリアル
AEON
December 14, 2023
Tweet
Share
More Decks by AEON
See All by AEON
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
270
Snowflakeで実現したスピード感あるデータ基盤開発 / rapid data infrastructure development achieved with Snowflake
aeonpeople
1
40
プラットフォーム転換期におけるGitHub Copilot活用〜Coding agentがそれを加速するか〜 / Leveraging GitHub Copilot During Platform Transition Periods
aeonpeople
2
500
JTCにおける内製×スクラム開発への挑戦〜内製化率95%達成の舞台裏/JTC's challenge of in-house development with Scrum
aeonpeople
0
470
2025年にHCP Vaultを学び直して見えた景色 / Lessons and New Perspectives from Relearning HCP Vault in 2025
aeonpeople
0
310
イオン店舗一覧ページのパフォーマンスチューニング事例 / Performance tuning example for AEON store list page
aeonpeople
2
540
会社もクラウドも違うけど 通じたコスト削減テクニック/Cost optimization strategies effective regardless of company or cloud provider
aeonpeople
2
670
SREがコストセンターではないことを大きな声と実例で伝えたい/SRE Is Not a Cost Center: Real-World Stories That Prove True Value
aeonpeople
1
990
SREチームの越境と対話〜どのようにしてイオンスマートテクノロジーは横軸運用チームの廃止に至ったか〜/the-Cross-border-and-dialogue-of-SRE
aeonpeople
13
8.5k
Other Decks in Technology
See All in Technology
コンパウンド組織のCRE #cre_meetup
layerx
PRO
1
240
「タコピーの原罪」から学ぶ間違った”支援” / the bad support of Takopii
piyonakajima
0
130
Claude Code Subagents 再入門 ~cc-sddの実装で学んだこと~
gotalab555
10
17k
HonoとJSXを使って管理画面をサクッと型安全に作ろう
diggymo
0
170
MCP ✖️ Apps SDKを触ってみた
hisuzuya
0
330
アウトプットから始めるOSSコントリビューション 〜eslint-plugin-vueの場合〜 #vuefes
bengo4com
3
760
ViteとTypeScriptのProject Referencesで 大規模モノレポのUIカタログのリリースサイクルを高速化する
shuta13
2
160
Claude Codeを駆使した初めてのiOSアプリ開発 ~ゼロから3週間でグローバルハッカソンで入賞するまで~
oikon48
10
5.4k
もう外には出ない。より快適なフルリモート環境を目指して
mottyzzz
13
9.5k
Digitization部 紹介資料
sansan33
PRO
1
5.7k
AI時代、“平均値”ではいられない
uhyo
8
2.4k
What's new in OpenShift 4.20
redhatlivestreaming
0
120
Featured
See All Featured
Automating Front-end Workflow
addyosmani
1371
200k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Done Done
chrislema
185
16k
It's Worth the Effort
3n
187
28k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Documentation Writing (for coders)
carmenintech
75
5.1k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Optimizing for Happiness
mojombo
379
70k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
4 Signs Your Business is Dying
shpigford
185
22k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Transcript
イオンが⽴ち上げる超巨⼤データ基盤 イオン株式会社 CTO 兼 イオンスマートテクノロジー CTO ⼭﨑 賢
イオン株式会社 CTO 兼 イオンスマートテクノロジー CTO ⼭﨑 賢 ⾃⼰紹介 ・Yahoo︕ JAPANでエンジニアとしてオークション/ショッピングの開発
・リクルートで⼤規模サービス複数の開発責任者 ・アソビューCTO ・トラストバンクCTO ・2024年3⽉から現職 イオンをTechカン パーに化するために ⾊々発信していま す。 ⼭﨑 賢 ( やまけん @yamaken_66 )
数字で⾒るイオングループ
成り⽴ち ! " # $ 歴 史 ' ︑ 合
併 $ 歴 史 + , - . / 0 連 帯 +
成り⽴ち 膨⼤な顧客がそれぞれに存在するが、 多くは相互に連携されていない ✗ ✗ ✗ ✗ ✗ ✗ ✗
✗
成り⽴ち まず、共通の会員IDを⽤意し相互に接続を実施
そして、グループ全体のデータを統合していく データ基盤 会計 商品 店舗 顧客 ⾏動 ポイント 天気 出荷・配送
グループ全体のデータを統合していく データ基盤 会計 商品 店舗 顧客 ⾏動 ポイント 天気 出荷・配送
⽬的は個⼈の特定ではなく、顧客価値の最⼤化のため。 お客様が望んでいるもの/価値 更に⼼地よい顧客体験 データを⽤いた経営の最適化 こららの実現のためにデータを集約し活⽤することを⽬指しています。
超巨⼤とは (規模の話) 述べ会員数 1億⼈以上 店舗数 20,000 店舗以上 年間来店客数 14億以上 グループ連結売上
9兆円以上 ⼦会社数 300以上
DM ETL ETL ETL Storage API MQ DB link ETL
㊙ 超加⼯ プロセス アーキテクチャの触りだけ ( 今後の展開も含む ) Azure Japan Region カスタマーデータプラットフォーム/従業員向けの業務サポートツール/各種ダッシュボード アドホック分析/データサイエンス/Openデータとのコラボレーション/各社とのオーケストレーション
超巨⼤データ基盤の勘所って︖ 今はアーキテクチャが進化している。 単純な⼤量データ基盤なら何も⼼配ない。 集めて貯めるだけなら、⼭程事例はある。 超巨⼤のKnow Howはそこではない 特にイオングループは合併で⼤きくなってきた会社。 それぞれの会社には ・違うシステムがあり ・違うビジネスがあり
・違うデータがある
超巨⼤とは ( 実は最も重要な観点 ) 超巨⼤ ≠ データ量 超巨⼤ = 多様性
多様性 = 利害関係 多様性 =データ構造 多様性 =連携システム 多様性 = 利⽤者
最も考えるべきこと1 連携システムの多様性
最も考えるべきこと1 連携システムの多様性 連携システム。特にデータ源泉は多様。 ・インフラ環境も違う ( オンプレだったり、違うクラウドだったり ) ・稼働しているOSも違う( Windowsだったり、Linuxだったり )
・連携⽅式が違う ( APIだったり、TCPだったり、HULFTだったり、CSVだったり) ・連携タイミングが違う ( リアルだったり、バッチだったり ) ・連携鮮度が違う ( 当⽇分だったり、前⽇分だったり ) 多様な要件に合わせに⾏かない ・データ基盤は正しく運⽤し続ける必要がある ・データ源泉の多様性に合わせにいくと、無限に障害点が増える ・標準的な連携パターンを複数⽤意し、その連携パターンのどれかを選択する設計
最も考えるべきこと2 データ構造の多様性
送信されるデータ構造もデータ源泉では多様 ・データ階層 ・データ型 ・データカラム名 などなど 概念毎にフォーマットを正規化/標準化する ・データ源泉のデータ構造は無邪気に変更されると思え ・その度にデータ連携が失敗しないための備えをする ・データ基盤取り込み⽤のデータフォーマットは標準化し、データ源泉から送る側で 標準化してもらう責任分解の設計をする
最も考えるべきこと2 データ構造の多様性 源泉 源泉側システム データ基盤 標準化変換 標準IF ETL DM
最も考えるべきこと3 利害関係の多様性
複数の組織や事業会社から成り⽴つデータ基盤の場合、利害関係に差異が⽣まれる ・必ずしも⼤規模データを連携する源泉がデータ基盤の最⼤受益者とはならない ・むしろ保有データが少ない組織/事業ほど、⾃分らで補完出来ないデータ基盤にニー ズがある ・Give & Takeにはならない。限りなくGiveのみ。限りなくTakeのみが存在する 個別単位のベネフィットにスコープしない ・組織/事業単位の短期的なROIを考えると破綻する ・もっと⼤きな枠組み。会社全体とかグループとか。全体最適で最上位組織が
号令を出す ・データが集まるとイノベーションが発⽣する。結果として全体が利 益を享受出来る 最も考えるべきこと3 利害関係の多様性 デ ー タ 基 盤 事業A 事業B うちで既にデータいっぱい持ってるから内部 分析で⼗分なんやけどな・・ うちデータ全然無いから、事業Aのデータ めっちゃ助かるわー デ ー タ 基 盤 事業A 事業B 全体でデータ基盤に集約することを決めよう 結果としてデータが集約されることで、新しい 発明が起き、⾮連続な成⻑が発⽣する
最も考えるべきこと4 利⽤者の多様性
データ基盤の利⽤者は⼈であれ、システムであれ多様となる。 ・アドホックに分析したい ・⾼度なモデルを開発したい ・⾃分⽤のダッシュボードを作りたい ・WEB接客をぶん回したい ニーズは宝。制限しない。 ・利⽤の間⼝は広げる。 ・⾃由度をあげる ・それを可能なシステムを作り上げる ・中央は聖域化し⼲渉しない
・中央は使わせない。衛星を作る データ基盤 最も考えるべきこと4 利⽤者の多様性 あれやりたい これやりたい もっともっと カリカリカリカリ データ基盤 あれやりたい これやりたい もっともっと カリカリカリカリ ⾃由 分析 環境 ⾼度分析⽤ リソース BI DB 専⽤ リソース 専⽤ リソース
考えるべきこと 〜 まとめ 〜
考えるべきこと 〜 まとめ 〜 データ基盤 聖域化zone ⾃由に使わせない 堅牢に。安定的に。 多様なニーズを受け⼊れる 必要に応じて仕組みを追加する
標準化zone 多様性を受け⼊れない ⼀定のルールで厳格化する ETL ETL ETL Storage API MQ DB link ETL 多様的利⽤zone 意志統制zone 個別でなく、組織全体/グループ全体としてデータを集めることを意思決定し推進する
そして今後の展望
データを⾼度に抽象化し個⼈を特定出来ない状態にした上で、クリーンルームを利⽤して 他社とコラボレーションを実現 各種マーケティングとの接続を実施し、リテールメディア/広告の最適配信を実現 サプライチェーン全体に対する需要予測/商品開発の分析 ⽣産や配送の全体効率化と、地域社会の⽣産者に対する還元 ⽇本全体の⼩売の最適化への貢献
いつもの
https://recruit.aeon.info/find-my-aeon/?recruit_type=career We Are Hiring !!! 〜 ご清聴ありがとうございました 〜 ⼩売企業でエンジニアリングとしてのイメージが薄いイオングループですが、現在その⾵⼟を⼤きく変えようと 仲間が集結しています。
イオンを起点に⽇本全体にポジティブなエンジニアリングイノベーションを起こしていきます