JAWS_ICEBERG_BASECAMP

Transcript

1. ICEBERG BASECAMP 佐野千紘（さのちひろ）
2. OVERVIEW – 概要
3. 今⽇のおはなし – ICEBERG BASECAMP ＜イベントページより＞ ⼊⾨から実践・深掘りまで、レベル別のLTを通じてApache Icebergの全 体像を⼀気にキャッチアップできます。 START GOAL BASE CAMP ⼭が険しくなる⼿前で 装備を整えたり、 作戦を⽴てるための場所 今⽇のおはなし ICEBERG⼭を登る準備として、 ・どんな⼭なのか（全体像） ・初⼼者コースの注意点
4. もともと話そうと思っていたこと ＜イベントページより ※(①) のような数字はあとから追加＞ 本当に初⼼者向けに、 そもそも Iceberg というものがなぜ⽣まれ（①）、 何がいいのか（②）、 それをどのようなアーキテクチャが⽀えているのか（③）、 レベルの話をしたいと思っています。 また、「Iceberg にすれば無条件にパフォーマンスが良くなる」という 思い込みへの注意として、 パーティション設計のコツ（④）や MOR&COW（⑤）、 メンテナンスジョブの重要性について（⑥）も触れたいと思います。
5. もともと話そうと思っていたこと ＜イベントページより ※(①) のような数字はあとから追加＞ 本当に初⼼者向けに、 そもそも Iceberg というものがなぜ⽣まれ（①）、 何がいいのか（②）、 それをどのようなアーキテクチャが⽀えているのか（③）、 レベルの話をしたいと思っています。 また、「Iceberg にすれば無条件にパフォーマンスが良くなる」という 思い込みへの注意として、 パーティション設計のコツ（④）や MOR&COW（⑤）、 メンテナンスジョブの重要性について（⑥）も触れたいと思います。 ⾵呂敷広げすぎました ごめんなさい ▲またの機会に・・・︕
6. ICEBERGの勉強会で必ず出てくる絵 予想︓今⽇、私以外にあと 最低2⼈はこの絵を使う 今⽇の⽬標 この絵の意味を、 「なぜこれがいいのか」とからめて 理解する ▲…の、⽚鱗だけ…!
7. ⾃⼰紹介
8. ⾃⼰紹介 佐野千紘（さのちひろ） ⽂学部 倫理学専攻卒業（哲学学⼠） ⾦融系IT企業でSE（2010〜）→ 外資系RPAベンダー（2019〜）→ Cloudera（2023〜今） はじめての翻訳（共訳）は 『Apache Iceberg 活⽤⼊⾨』 ▲Iceberg を創った Ryan Blue が 過去に勤めていた⽼舗データ基盤企業 2026年4⽉に翻訳出版 『AIの仮⾯を剥いでやる』 AI x 倫理の 全⽶ベストセラー
9. ICEBERGとは何か
10. ＜本当にICEBERGを初めて聞く⼈にしている説明＞ ⾃由な形式のデータを、テーブル形式で読めるようなメタデータ と対応させることでSQLで分析できるようにする仕組み ICEBERGとは何か ＜ある程度⽂脈が伝わりそうな⼈向けの説明＞ データレイクハウスの実装を可能にする中で、 Hive Meta Store の問題点を解決した後継ソリューション 現時点ではORC, Parquet, Avro に対応 ※ ⽂脈が伝わる = この界隈の経験がありそう、くらいの意味で、伝わる＝えらいではないし Hive Meta Store が何かを今⽇初めて聞いたとしても全然⼼配いりません
11. ICEBERG を使うと 何がいいのか
12. ICEBERGのメリット Ø アトミックな更新に対応 Ø パーティションを意識したSQLを書かなくても、速い検索を かけられる Ø 過去の任意の時点のデータを復元できる（タイムトラベル） → こうしたメリットのもとになるのが、先ほどの図︕ ・・・だがその前に・・・
13. ICEBERGのメリット・・・︖ Ø アトミックな更新に対応 Ø パーティションを意識したSQLを書かなくても、速い検索を かけられる Ø 過去の任意の時点のデータを復元できる（タイムトラベル） たしかにこれは嬉しいかも これは別に普通の話じゃないか︖︕ → ⼀⾒普通のことが、なぜ ICEBERG 以前はできなかったのか︖
14. ICEBERG のメリットは 本当にメリットなのか 〜5分でわかるデータ基盤の歴史〜 ※5分はむりかも
15. 1960年代〜 データウエア ハウス 〜今も残る影響⼒〜
16. 分析システム - OLAP 基幹システム - OLTP ⼯場システム 営業系システム データウエアハウス（1960年代〜） 会計系システム ⽣産管理システム 営業DB 経理DB ⽣産DB ⼯場データ データウエアハウス 分析者 営業担当 経理担当 仕⼊担当 ⼯場担当
17. 分析システム - OLAP 基幹システム - OLTP ⼯場システム 営業系システム 当然の疑問① 会計系システム ⽣産管理システム 営業DB 経理DB ⽣産DB ⼯場データ データウエアハウス コピーめんどくない︖ データを⼆重に持つの 無駄じゃない︖ 営業担当 経理担当 仕⼊担当 ⼯場担当 分析者
18. 基幹システム - OLTP ⼯場システム 営業系システム 当然の疑問① 会計系システム ⽣産管理システム 全社統合のDBで 業務も分析も やればよくない︖ 営業担当 経理担当 仕⼊担当 ⼯場担当 分析者
19. 基幹業務でのデータの使い⽅ 顧客ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 1 ⽥中 太郎 2023/01/15 ORD001 2 DTL001 テレビ 1 ⽥中 太郎 2023/01/15 ORD001 2 DTL002 テレビ台 2 ⼭⽥ 花⼦ 2023/02/20 ORD002 1 DTL003 冷蔵庫 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL004 スマートフォン 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL005 スマートフォンケース 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL006 充電器 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL007 イヤホン 4 佐藤 次郎 2023/04/10 ORD004 3 DTL008 洗濯機 4 佐藤 次郎 2023/04/10 ORD004 3 DTL009 洗濯ネット 4 佐藤 次郎 2023/04/10 ORD004 3 DTL010 洗剤 私が去年の１⽉に買ったテレビは 買い替えキャンペーンの対象ですか︖ ⽥中太郎 （顧客） 特定の⾏を 絞り込み検索
20. 分析業務でのデータの使い⽅ 顧客ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 1 ⽥中 太郎 2023/01/15 ORD001 2 DTL001 テレビ 1 ⽥中 太郎 2023/01/15 ORD001 2 DTL002 テレビ台 2 ⼭⽥ 花⼦ 2023/02/20 ORD002 1 DTL003 冷蔵庫 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL004 スマートフォン 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL005 スマートフォンケース 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL006 充電器 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL007 イヤホン 4 佐藤 次郎 2023/04/10 ORD004 3 DTL008 洗濯機 4 佐藤 次郎 2023/04/10 ORD004 3 DTL009 洗濯ネット 4 佐藤 次郎 2023/04/10 ORD004 3 DTL010 洗剤 2023年の、⽉別の購⼊点数の 推移を調べたい データ サイエンティスト 列の値を 集計
21. 違いをまとめると 顧客ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 1 ⽥中 太郎 2023/01/15 ORD001 2 DTL001 テレビ 1 ⽥中 太郎 2023/01/15 ORD001 2 DTL002 テレビ台 2 ⼭⽥ 花⼦ 2023/02/20 ORD002 1 DTL003 冷蔵庫 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL004 スマートフォン 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL005 スマートフォンケース 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL006 充電器 3 鈴⽊ ⼀郎 2023/03/05 ORD003 4 DTL007 イヤホン 4 佐藤 次郎 2023/04/10 ORD004 3 DTL008 洗濯機 4 佐藤 次郎 2023/04/10 ORD004 3 DTL009 洗濯ネット 4 佐藤 次郎 2023/04/10 ORD004 3 DTL010 洗剤 基幹業務では、⾏ごとの データを知りたいケースが多い 分析業務では、列ごとの データを集計したいケースが多い ⾏指向 列指向
22. 分析系 - OLAP 基幹系 - OLTP ⼯場システム 営業系システム データウエアハウス（1960年代〜） 会計系システム ⽣産管理システム 営業DB 経理DB ⽣産DB ⼯場データ データウエアハウス 営業担当 経理担当 仕⼊担当 ⼯場担当 分析者 ⾏ごとのデータを 素早く抽出・処理できる ＝⾏指向 列単位の集計で ⾼いパフォーマンスを発揮 ＝列指向
23. ⼩まとめ データウエアハウスが築いた、今も根強く残る影響 Ø 基幹業務と分析業務でシステムを分けるという ”考え⽅” Ø 基幹業務 – OLTP ⾏指向で処理 Ø 分析業務 – OLAP 列指向で集計
24. データ基盤の 変遷 〜ウエアハウス（倉庫） からレイクハウス（湖上 のおうち）へ〜
25. データウエアハウス = データの倉庫 １ 倉庫 データ ください これを倉庫に ⼊れて これも倉庫に ⼊れて すべて私が 管理します ▲ストレージ ▲処理エンジン この⼀連の仕組みがデータウエアハウス データベース ベンダーの 独⾃規格 受け渡しは表形式で︕
26. データウエアハウス = データの倉庫 １ この⼈を通さないと データにアクセスできない
27. データレイク = データの湖（厳しい⼤⾃然） 2 すべては ⾃⼰責任︕ ワイのデータ どこ・・・ ▲⼀般⼈ ◀熟練スイマー ⾃由で イイネ︕ とりあえず ぶちこむ︕ 表形式はもちろん 画像、⾳声、動画、 グラフ、ベクトル、なんでもOK! S3などをこの役割で 使うことができる
28. データレイク = データの湖（厳しい⼤⾃然） 2 流れがぐちゃぐちゃ
29. データレイクハウス = 湖上の家・船着場（観光リゾート） 3 ご⾃由に どうぞ これなら楽しく 遊べそう︕ 表形式はもちろん 画像、⾳声、動画、 グラフ、ベクトル、なんでもOK! 各種のデータを探したり、 アクセスしやすい仕組みを提供 この「湖上のおうち」を 英語で lakehouse という
30. データレイクハウス = 湖上の家・船着場（観光リゾート） 3 スッキリ︕ なぜなら、ここに テーブルフォーマット＝ ICEBERG がいるから︕
31. データレイクハウス = 湖上の家・船着場（観光リゾート） 3 ご⾃由に どうぞ これなら楽しく 遊べそう︕ 表形式はもちろん 画像、⾳声、動画、 グラフ、ベクトル、なんでもOK! 各種のデータを探したり、 アクセスしやすい仕組みを提供 この「湖上のおうち」を 英語で lakehouse という Hadoop 上のレイクハウスの元祖︓ Hive テーブル è Hadoop 上のデータにテーブル フォーマットを当てはめて SQL 検索ができる仕組み Hive テーブルの限界を克服 è ICEBERG
32. 倉庫が湖上のおうちになっても データウエアハウスが築いた、今も根強く残る影響 Ø 基幹業務と分析業務でシステムを分けるという ”考え⽅” Ø 基幹業務 – OLTP ⾏指向で処理 Ø 分析業務 – OLAP 列指向で集計 → 集計 への強みを残したまま、⾏指向っぽい機能を備え パフォーマンスを出すには︖
33. ICEBERGのメリット・・・︕ Ø アトミックな更新に対応 Ø パーティションを意識したSQLを書かなくても、速い検索を かけられる Ø 過去の任意の時点のデータを復元できる（タイムトラベル） たしかにこれは嬉しいかも これは別に普通の話じゃないか︖︕ ⾏指向のOLTPの 標準的な機能 → ICEBERG は分析⽤だが、OLTP的な標準機能（の⼀部） を備えている︕ ※ ただしOLTPとしての利⽤が推奨されているわけではない
34. ICEBERG は なぜ⽣まれたのか 〜 Hive テーブルの何を克服したのか 〜
35. データレイクハウス = 湖上の家・船着場（観光リゾート） 3 スッキリ︕ なぜなら、ここに テーブルフォーマット＝ ICEBERG がいるから︕
36. データレイクハウス = 湖上の家・船着場（観光リゾート） 3 ご⾃由に どうぞ これなら楽しく 遊べそう︕ 表形式はもちろん 画像、⾳声、動画、 グラフ、ベクトル、なんでもOK! 各種のデータを探したり、 アクセスしやすい仕組みを提供 この「湖上のおうち」を 英語で lakehouse という Hadoop 上のレイクハウスの元祖︓ Hive テーブル è Hadoop 上のデータにテーブル フォーマットを当てはめて SQL 検索ができる仕組み Hive テーブルの限界を克服 è ICEBERG
37. ICEBERG の先輩 – Hive テーブル データレイクのデータに、 SQLでクエリを発⾏するための クエリエンジンとして Hive が⽣まれた ▲名前のとおり、 メタデータを管理するストレージ ※ （この⽂脈での意味合いは）データを テーブル形式で読み込むために必要な情報 データレイクの⾃由な形式のデータに SQLを発⾏するためには、それを テーブル形式で読み込むための⽅式が必要︕ → そこで Hive Meta Store が⽣まれた
38. ICEBERG 処理エンジンの機能を切り離し、 Hive Meta Store の限界を克服し メタデータ管理の仕組みを改善したのが ICEBERG 処理エンジンの実装は⾃由︕ カタログも、要件は規定するけど 実装は⾃由︕
39. ICEBERGのメリットを ⽀える仕組み 〜の、さわり〜
40. ICEBERGのメリットを⽀える仕組み ◀ICEBERG 関係の勉強会に 毎回必ず登場する絵
41. ICEBERGのメリットを⽀える仕組み Hive Meta Store の仕組み ICEBERG の仕組み
42. ICEBERGのメリットを⽀える仕組み Hive Meta Store ICEBERG HMSにはなかった 3層構造の 「メタデータ層」により、 従来の課題を克服したのが ICEBERG !!
43. 共通点は・・・ Hive Meta Store ICEBERG 「データファイル」は ほぼ共通
44. データファイルとは︖ 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 → テーブルを構成するデータを、ある程度まとまった単位で持つファイル
45. パーティションとは︖ 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 → パーティションに指定した列の値ごとに、データファイルが物理的にわかれる 購⼊年 でパーティションを切ると ※ [⾖知識] ICEBERG は列の値そのままだけじゃなく、列から算出した値でもパーティションを切れる 例︓⽇付項⽬の年、年⽉、年⽉⽇、⽂字項⽬の先頭◦⽂字、ハッシュ値・・・
46. Hive Meta Store におけるパーティション Hive Meta Store ICEBERG 検索時︓ パーティションを検索条件に指定した場合、 (SQL の WHERE 句) そのパーティションが格納されている ディレクトリだけを探す （他は探さない -> 効率UP） SQLの検索条件にパーティション列を 直接指定しないと、 全ファイルを開いて検索をかける → 効率が落ちる データ格納時︓ パーティションごとに データファイルの格納先となる ディレクトリが分かれる
47. パーティションを指定しないクエリ 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 購⼊年 でパーティションが切られた Hive テーブルの場合 WHERE 購⼊⽇の年⽉ = “2025/12” のようなクエリでも全件検索がかかる Hive テーブルの場合 効率Down↓
48. ICEBERGのメリットを⽀える仕組み Hive Meta Store ICEBERG マニフェストファイル ⾃分が管理するデータファイルの 最⼤値・最⼩値を持っている -> これを⾒て、関係あるデータファイルだけ開く︕
49. パーティションを指定しないクエリ 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 WHERE 購⼊⽇の年⽉ = “2025/12” のようなクエリを打鍵した場合 ICEBERGの場合 マニフェストファイル（の⼀部） 購⼊⽇ 最⼩︓2025/12/25 最⼤︓2025/12/25 マニフェストファイル（の⼀部） 購⼊⽇ 最⼩︓2026/01/03 最⼤︓2026/04/10 これは読んでも意味ないね︕ → 読み⾶ばそう︕ という判断ができる （プルーニング） 効率UP↑ 購⼊年 でパーティションが切られた ICEBERG テーブル
50. ICEBERGのメリット Ø アトミックな更新に対応 Ø パーティションを意識したSQLを書かなくても、速い検索を かけられる Ø 過去の任意の時点のデータを復元できる（タイムトラベル） これの秘密が マニフェストファイルを利⽤した プルーニング︕
51. この話をすると出てくる勘違い なるほど︕ ICEBERG は パーティションを使わなくても 性能が出るんですね︕
52. 正しい理解 テーブルの利⽤者は、パーティションの例を WHERE句の条件指定に含めなくても速い検索がかけられる テーブルの設計者は、アクセスパターンに応じた 適切なパーティションを定義すべし この仕事をさぼらせてくれる ソリューションではない
53. パーティションをSQLで指定しなくても速いのは︖ 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 ICEBERGの場合 マニフェストファイル（の⼀部） 購⼊⽇ 最⼩︓2025/12/25 最⼤︓2025/12/25 マニフェストファイル（の⼀部） 購⼊⽇ 最⼩︓2026/01/03 最⼤︓2026/04/10 これは読んでも意味ないね︕ → 読み⾶ばそう︕ という判断ができる （プルーニング） プルーニングによって クエリの効率が上がるような テーブル構造になっている ことが前提 WHERE 購⼊⽇の年⽉ = “2025/12” のようなクエリを打鍵した場合 購⼊年 でパーティションが切られた ICEBERG テーブル
54. パーティションが定義されていないと… 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 データの並びや データファイルの区切りが 保証されない︕ ※ より正確には、データファイルの区切りを保証するのはパーティション、 データの並びを保証するのはソート順
55. パーティションが定義されていないと… 顧客 ID 顧客名 購⼊⽇ 注⽂ID 点数 明細ID 商品 購⼊年 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL001 テレビ 2025 2 ⼭⽥ 花⼦ 2026/01/3 ORD002 1 DTL003 冷蔵庫 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL004 スマートフォン 2026 3 鈴⽊ ⼀郎 2026/02/14 ORD003 4 DTL005 スマートフォンケース 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL006 充電器 2026 3 鈴⽊ ⼀郎 2026/03/05 ORD004 2 DTL007 イヤホン 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL008 洗濯機 2026 1 ⽥中 太郎 2025/12/25 ORD001 2 DTL002 テレビ台 2025 4 佐藤 次郎 2026/04/10 ORD005 3 DTL009 洗濯ネット 2026 4 佐藤 次郎 2026/04/10 ORD005 3 DTL010 洗剤 2026 マニフェストリスト（の⼀部） 購⼊⽇ 最⼩︓2025/12/25 最⼤︓2026/03/05 マニフェストリスト（の⼀部） 購⼊⽇ 最⼩︓2025/12/25 最⼤︓2026/04/10 両⽅のファイルを開かないと 該当データが取得できない︕ WHERE 購⼊⽇の年⽉ = “2025/12” のようなクエリを打鍵した場合 効率Down↓
56. 正しい理解 テーブルの設計者は、アクセスパターンに応じた 適切なパーティションを定義すべし テーブルの利⽤者は、パーティションの例を WHERE句の条件指定に含めなくても速い検索がかけられる 検索条件によく使うカラムで パーティションを切る必要あり 利⽤者がどういう検索をかけるのかを 知っておく必要あり ◀アクセスパターンが変わったり、最初に完璧に 知れなくても、あとから変えることができる︕ テーブル作成後に パーティションを変更できるのも ICEBERG のメリットのひとつ︕ ＋ソート順も重要 （数値項⽬など）
57. ICEBERGのメリット Ø アトミックな更新に対応 Ø パーティションを意識したSQLを書かなくても、速い検索を かけられる Ø 過去の任意の時点のデータを復元できる（タイムトラベル） ここは理解できたはず︕ 今⽇カバーしきれなかった論点（T_T）
58. ICEBERGのメリットを⽀える仕組み Hive Meta Store ICEBERG 下から更新・・・ すべての準備が整ったら、 世代をパチっと切り替える︕
59. もしよかったら・・・︕ 「⼊⾨」の名前のとおり 基本がわかる⼀冊︕ ⼀⽣懸命訳したので ぜひ読んでください・・・︕
60. もしよかったら・・・︕ その２ 2026/8/6(⽊) 18:30〜 現地︓Otemachi One タワー17階 オンライン参加あり 今⽇の話を聞いたみなさんなら ついていける・・・︕︕
61. THANK YOU