明治薬科大学講義_ビッグデータ解析を支えるデータベース技術とクラウドコンピューティング

5/22に行われた明治薬科大学での講義資料_座学パートになります。

ハンズオンパート資料はこちら
https://zenn.dev/sde_lab/articles/snowflake-multiomics-handson

Transcript

1. ビッグデータ解析を⽀えるデータベース技術 とクラウドコンピューティング クラウドデータベースの考え⽅をSnowflakeで体験する GA technologies / 是枝 達也 1
2. ⾃⼰紹介 是枝 達也 / GA technologies Data Division • データ基盤‧データエンジニアリングを担当 • データベース設計‧クラウドデータ基盤‧Snowflake 活⽤の設計‧運⽤に携わる • 趣味: バイオインフォマティクス研究 今⽇のテーマ：データ解析を⽀えるデータベース技術 2
3. 今⽇のアジェンダ 1. データベース技術に関する座学 30分 2. Snowflakeを⽤いたハンズオン研修 30分 3. レポート課題への回答時間 20分 3
4. 今⽇のゴール（前半30分） ✔ データベースとは何かを理解する ✔ SQLがデータ解析で使われる理由を理解する ✔ 業務⽤DBと分析⽤DBの違いを理解する ✔ ⼤規模データ解析を⽀える技術を知る ✔ 後半でSnowflakeを使ってクラウドDBを体験する 4
5. 5 お願い 学⽣からのレスポンスを確認したく、私の⽅ からTeamsのチャットにてリアクションを求 めるときがあります。 必ずクリックしてリアクションを返すように してください。
6. データベースとは？ データを整理‧蓄積し、条件を指定して素早く取り出せる専⽤ソフトウェア 01 収集‧保管 ⼤量のデータを構造化して格納する 02 検索‧集計 条件を指定して素早く絞り込む 03 共有‧連携 複数⼈が同時にアクセスできる 6
7. なぜデータ解析にデータベースが必要なのか データが⼤きすぎる Excel の限界は約 104 万⾏ 実際のデータは 数億⾏規模に達することも データが散在している 複数ファイル‧複数システム にデータが分断されていると 統合‧横断分析が困難に 処理が遅い 全データをメモリに読み込 んでから計算するため 時間とリソースを⼤量消費 7
8. ファイル管理 vs データベース CSV / Excel データベース 保存⽅法 ファイルとして保存 構造化して格納 検索 全⾏を順番に確認 インデックスで⾼速検索 データ型 すべてテキスト 型を強制‧保証 同時利⽤ 上書き競合が発⽣ 同時アクセスを制御 ⼤規模化 104万⾏で限界 数億⾏以上も対応 整合性 ⼿動管理 ⾃動で保証 8
9. リレーショナルデータベース（RDB）の基本 患者テーブル 処⽅テーブル 患者ID ⽒名 年齢 診療科 P001 ⽥中 22 薬学部 P002 鈴⽊ 35 外科 P003 佐藤 28 内科 処⽅ID 患者ID 薬剤名 R001 P001 アスピリン R002 P001 イブプロフェン R003 P002 メトホルミン ★ 主キー（Primary Key）：各⾏を⼀意に識別する列 ★ 外部キー（Foreign Key）：患者テーブルの患者IDと紐 付く列 リレーショナル（Relational）＝ 複数のテーブルを「キー」で繋ぎ、データの重複を排除して管理する 9
10. SQLとは何か Structured Query Language ⸺ データベース操作のための⾔語 「どう処理するか」ではなく「何が欲しいか」を書く SELECT 性別, count(*) as 人数 FROM 患者 WHERE 年齢 >= 20 GROUP BY 性別 基本の命令 SELECT 取得する列を指定 FROM どのテーブルから取得するか WHERE 絞り込み条件 GROUP BY グループごとに集計 ORDER BY 並び替え ID ⽒名 年齢 性別 1 ⽥中 22 男 2 鈴⽊ 35 ⼥ 3 佐藤 28 男 4 加藤 16 ⼥ 性別 ⼈数 男 2 ⼥ 1 患者 テーブル SQLした結果 10
11. SQLがデータ解析に向いている理由 ① ⼤量データから必要な部分だけ取り出せる ② 集計‧結合‧絞り込みをDB側で実⾏できる ③ PythonやRにデータを全部読み込む必要がない ④ 同じ処理を何度でも再実⾏しやすい ⑤ 処理内容がそのまま「仕様書」として読める 11
12. 業務⽤DBと分析⽤DBは「⽬的」が違う 業務⽤ DB（OLTP） → ⽇々の処理を正確‧⾼速に記録する → 1件ずつの登録‧更新‧削除が得意 → 現在のデータを正確に保持することが 最優先 分析⽤ DB（OLAP） → ⼤量の過去データを横断的に集計‧分 析する → ⼤量の⾏をまとめて読む処理が得意 → 履歴データを保持し続けることが重要 ⽬的が違うから、内部の設計も根本から違う 12
13. OLTP（オンライントランザクション処理） Online Transaction Processing：アプリ・業務システムの裏側で動く 【例】注文を1件登録する　／　ユーザー情報を更新する　／　在庫を 1つ減らす • ⾼速な単件処理 1件ずつの登録‧更新‧削除をミリ秒単位で⾼速に処理できる • ⾼並列アクセス 同時に多数のユーザーがアクセスしても安定して動く • データ整合性の保証 データの整合性‧⼀貫性を厳密に保ち続ける 13
14. OLAP（オンライン分析処理） Online Analytical Processing  ⼤量の過去データを集計‧分析するために使われる 【例】1年分の売上を⽉別に集計する ∕ カテゴリ別‧地域別の傾向を⽐較する • ⼤規模データ読み込み 何百万〜何⼗億⾏をまとめて⾼速に読み込める • 横断的な集計‧分析 複数テーブルを結合してデータを横断的に分析できる • 集計処理が得意 集計‧グループ化‧ランキング処理が⾼速 14
15. OLTPとOLAPの⽐較 項⽬ OLTP（業務⽤ DB） OLAP（分析⽤ DB） ⽬的 ⽇々の業務処理を 正確‧⾼速に記録する ⼤量の過去データを 横断的に集計‧分析する 処理単位 少数⾏（1件ずつ） ⼤量⾏（数百万〜数⼗億） レスポンス ミリ秒単位 秒〜分単位 最優先 データの整合性‧⼀貫性 読み取りスループット 例 注⽂登録‧在庫更新など ⽉次集計‧売上分析など 15
16. なぜ分析専⽤のDBが必要になるのか 問題：業務DBへの重い分析クエリ ‧本番処理が遅くなりサービスに影響が出る ‧⼤量の⾏を読む処理はOLTPが苦⼿ ‧複数システムのデータを横断できない → 解決策：分析専⽤DBを⽤意する OLAPに最適化されたDWH（データウェアハウス）を導⼊ → 本番DBへの影響をゼロに → 複数システムのデータを統合できる → ⼤量データの⾼速集計が可能になる 16
17. ⼤規模データ処理でボトルネックになるもの 特に「いかに読むデータを減らすか」が重要 → 列指向‧圧縮‧スキップの⼯夫へ ボトルネック 内容 ① I/O ディスクからデータを読み込む速度 ② メモリ ⼀度に扱えるデータ量の上限 ③ CPU 集計‧演算の処理速度 ④ ネットワーク データ転送の遅延 ⑤ 並列度 複数の計算資源で処理を分担できるか 17
18. 分析向けDBの⼯夫①：列指向ストレージ ⾏指向ストレージ（Row-oriented） → 4列すべて（ID‧名前‧年齢‧薬剤）を   ディスクから読み込む • I/O量：100%（全データ） • 不要な列まで読み込むため低速 ⚠ 分析クエリには⾮効率な設計 列指向ストレージ（Column-oriented） → 年齢列だけをディスクから読み込む   ID‧名前‧薬剤列はスキップ • I/O量：約25%（1/4に削減） • 必要なデータだけ読む設計 ✓ 分析クエリに最適化された⾼速処理 ID 名前 年齢 薬剤 1 ⽥中 22 アスピリン 2 鈴⽊ 35 メトホルミン 3 佐藤 28 イブプロフェン ID 名前 年齢 薬剤 22 35 28 18
19. 分析向けDBの⼯夫②：圧縮とデータスキップ 圧縮（Compression） • 同じ値が続く列は⾮常に圧縮しやすい   例：国名「Japan」が100万⾏続く場合 • 列指向と組み合わせることで   ⾼い圧縮率を実現 • ディスク使⽤量とI/Oを   同時に削減できる データスキップ（Data Skip） • 各ブロックの最⼩値‧最⼤値を   事前にメタデータとして記録する • 例：「2024年以降のデータ」という   クエリで2023年以前のブロックを   まるごと読み⾶ばせる • 全データを読まずに処理できる 19
20. 分析向けDBの⼯夫③：並列分散処理 ⼤きなデータ（例：1億⾏） ↓  ↓  ↓  ↓   4 分割して各ノードへ割り当て Node 1 ⾏ 1 〜 2,500万 部分集計 完了 ✓ Node 2 ⾏ 2,501 〜 5,000万 部分集計 完了 ✓ Node 3 ⾏ 5,001 〜 7,500万 部分集計 完了 ✓ Node 4 ⾏ 7,501 〜 1 億 部分集計 完了 ✓ 各ノードの結果を結合   最終集計 完了  ⚡ 4 ノード並列処理により直列⽐で約 4 倍の⾼速化 20
21. クラウドコンピューティング 従来：⾃前でサーバーを購⼊‧設置‧管理 → 初期費⽤が⼤きい → 使わないときも電⼒‧管理コストがかかる → 急なデータ増加に対応しにくい クラウド：インターネット越しに計算資源を利⽤ → 初期費⽤なし、使った分だけ⽀払う → 数分でサーバーを増やせる → ⼤規模データ基盤と⾮常に相性が良い 21
22. 社内データを一元管理できるビッグデータ用のデータレイク 。最近は、AI・LLM機能も充実しており データ解析も可能となっている。データを外に出すことなくクラウド上で セキュアにデータ共有 も可能 クラウドDB製品 22
23. クラウドDBのメリット ① ⼤量データを低コストで保存できる ② 計算資源を柔軟に増減できる（使った分だけ課⾦） ③ 複数⼈‧複数チームが同じデータを同時に利⽤できる ④ 権限管理でセキュアにデータ共有できる ⑤ BIツール‧Python‧AIとの連携が容易 ⑥ サーバー管理の負担がなく、データ活⽤に集中できる 今回はSnowflakeというクラウドDWH製品を使ってハンズオンをやっていきます 23
24. Snowflake reference image: https://www.snowflake.com/blog/beyond-modern-data-architecture/ クラウドベースのAI・コンピュートリソースといったビックデータに関わるオール・インプラットフォーム 24
25. Snowflakeの主な特徴① 伸縮性のある高性能エンジン • 複雑なデータパイプライン、大規模アナリ ティクス、特徴量エンジニアリング、アプリ ケーションを自動でスケール • 即時かつコスト効率の良いスケーリング で、性能に影響を与えることがない • SQLを始め、Python、Java、Scala用 Snowpark開発者フレームワークが用意さ れている reference image: https://www.snowflake.com/ja/data-cloud/platform/?utm_cta=websi te-homepage-platform-card-elastic-compute 25
26. Snowflakeの主な特徴② 最適化されたストレージ • PDFなどの非構造化データも一元的に管 理可能 • 最適化された圧縮、自動マイクロパーティ ション、ACIDコンプライアンス、Time Travelなどを活用 • オープンテーブル形式（Iceberg Tableな ど）が利用可能 reference image: https://www.snowflake.com/ja/data-cloud/platform/?utm_cta=website-ho mepage-platform-card-elastic-compute 26
27. 後半ハンズオンへ ① ログイン Snowflakeの Webコンソールへ ② Worksheet SQL Worksheetを 開く ③ SQL実⾏ テーブル検索‧ 集計するSQL書く ④ Snowflake Notebooksにて Pythonで解析 ゴール クラウドDB上でSQLを実際に実⾏する感覚をつかむ 「必要なデータだけ取り出す」を体験する 27
28. 28 ハンズオン進めるうえでの注意点 ハンズオンの進捗を確認するため、私の⽅か らTeamsのチャットにてリアクションを求め ます。 必ずクリックしてリアクションを返すように してください。
29. 29 ハンズオン資料の場所 webで「koreeda マルチオミクス」と検 索し、【ハンズオン】Snowflakeでマ ルチオミクス解析を体験してみる とい うページを開く こちらのwebページを参考に進めます。
30. 30 ハンズオン進めるうえでの補足 ‧講師側の都合上、全員の進捗をチャットで確認しつつハンズオンを進めて いきます。私も実演しながら進めますが、先にできる⽅は記事を参考にハン ズオンをどんどん進めていただき構いません。
31. 31 本日の課題について 本⽇の課題は、web記事の「本⽇の課 題」というセクションの中に記載してい ます。クリックして展開して確認してく ださい。