StarRocks Introduction for Iceberg Meetup Japan #4

Transcript

1. StarRocks を活用した Apache Iceberg の高 速分析と最適化事例
2. 目次 01 Apache Iceberg の現状 02 Iceberg が抱える課題 03 StarRocks のソリューション 04 導入事例
3. 3 Apache Iceberg の現状
4. Apache Iceberg - オープンレイクハウスのデファクトスタンダード 2025年、「Apache Iceberg × StarRocks」のイベントを10回以上開催しました。 Iceberg は、データレイクに信頼性と機能性をもたらし、 次世代のデータ基盤の標準となった。 ACID トランザクションとタイムトラベル: データの整合性を保証し、 過去の状態へのアクセスを可能にした スキーマ進化とパーティション: ビジネス要件の変化に柔軟に対応 できる 。 Single Source of Truth (SSOT): 全てのワークロードが単一 のデータコピーを参照する理想的な世界を目指している 。 シアトル サンフランシスコ ドイツ
5. 5 Icebergが抱える課題
6. 課題① - 検索パフォーマンスとリアルタイム性の壁 既存のレイクエンジンは、ウェアハウスレベルの「低レイテンシ・高同時実行」な分析には設計されていない。 メタデータのオーバーヘッド: 大規模テーブルでは、クエリ時間の80%以上がメタデータのパース（Plan）に費やされることがある 。 データのフェッチ遅延: S3などのオブジェクトストレージ上の小さなファイルを大量に読み込む際のI/Oストーム 。 実行エンジンの限界: 従来のJavaベースのエンジンは、CPU効率が悪く、SIMDなどの最新ハードウェア機能を活かしきれていない 。
7. 課題② - "データのコピー"によるSSOTの崩壊 パフォーマンス不足を補うために、結局データをプロプラ イエタリな DWH にコピーしており、アーキテクチャが複 雑化している。 二重管理のコスト: ユーザー向けの高速な分析（Customer- facing Analytics）のために、Iceberg からデータを抜き出し、 ClickHouse や Snowflake へロードしている 。 パイプラインの複雑化: 2つのインジェッションパイプライン、2つの データコピー、整合性の欠如 。 本来の目的の喪失: 「Iceberg による SSOT」という約束が守ら れていない 。
8. 8 ACID Schema evolution Hidden partitioning Time travel Multi-engine and open Simple Metadata overhead Network overhead Engine bottlenecks Throughput
9. 9 StarRocksによる解決策
10. StarRocks - Icebergのために設計されたクエリエンジン • ベンチマーク（TPC-DS 1TB） において Trino 比で約6.9倍の 高速化を実現。 • さらにユーザーさんの実環境デー タへの最適化により、その性能差 は最大10倍に達します。 StarRocks StarRocks Data on Disk Data on S3 StarRocks Data on Iceberg Trino
11. 技術的特長① - Icebergのために設計されたクエリエンジン StarRocks は、データ移動なしに Iceberg 上でデータ ウェアハウスのパフォーマンスを実現する。 Linux Foundation プロジェクト: オープンかつ標準的な 技術。 Object Storage Parquet ORC Apache lceberg Data Lake StarRocks Catalog Manager Coordinator FE Catalog Manager Coordinator FE Catalog Manager Coordinator FE Execution Engine CN Cache Data ネイティブ統合: 外部依存なしで Iceberg を直接クエ リ可能。データのロードや移動は不要。 Execution Engine CN Cache Data Execution Engine CN Cache Data FE が「データの場所」を、CN が「データの中身」をキャッ シュすることで、遠隔ストレージのデータも手元にあるかの ように超高速で処理します。 https://docs.starrocks.io/ja/docs/data_source/catalog/iceberg/iceberg_catalog/
12. 技術的特長② - 真のボトルネックである「メタデータ Planning」を解決 Iceberg が遅くなる主因（多くは使い方の問題） • Iceberg の性能問題は、エンジン以前にメタデータとファイル 設計で決まる • Manifest ファイルが最初のボトルネック • 大きすぎる → 並列性が出ない • 小さすぎる → メタデータ爆発 • Manifest Rewrite により、同一パーティションのファイルを適 切にグルーピング • 小さなデータファイルは致命的 • スキャン性能を劣化 • メタデータサイズ増大 • S3 / オブジェクトストレージのリクエストコスト増 Iceberg メタデータ Planning の分散実行 • メタデータ処理を MPP ノードへオフロード デシリアライズ済み Manifest Cache • 小規模メタデータでは Planning を ~1秒 → ~100ms に短縮 自動切り替え • 大規模メタデータ → 分散 Planning • 小規模メタデータ → ローカル + Cache
13. 技術的特長③ - ベクトル化実行エンジン (Vectorized Execution) C++で開発されたMPPエンジンが、ハードウェアの性能を極限まで引き出す。 SIMD命令の活用: CPU のベクトル処理を利用し、行単位ではなく列単位のバッチ処理を行うことで、演算効率を劇的に向上 。 Plan Plan Rewrite Task Scheduler Rules Transformation Implementation Cost Estimation Cost Model Statistics Property Enforcement Sort Partition Best Plan Memo Init Extract Vectorized SIMD Instructions CPU prefetch and cache friendly Branch prediction friendly CPU acceleration コストベースオプティマイザ (CBO): 統計情報（Statistics）を基に複数の実行計画候補を生成し、それぞれの「実行コスト」を数値化して、最もコストが低い計画を選択する 仕組みです。主に I/O、CPU、ネットワーク転送量、メモリ使用量を総合的に見積もったものです。
14. 技術的特長③ - ベクトル化実行エンジン (Vectorized Execution) 項目 RBO（Rule-Based Optimizer） CBO（Cost-Based Optimizer） 判断基準 固定ルール・優先順位 統計情報に基づくコスト計算 実行計画 ほぼ決め打ち 複数候補から最適選択 データ分布 考慮しない 考慮する Join 順序 書かれた順 or 固定ルール カーディナリティに基づき再順序化 Bloom Filter 原則なし 自動生成・適用 適応性 低い 高い
15. 技術的特長④ - マテリアライズド・ビュー (MV) によるさらなる加速 複雑な結合や集計を透明性高く加速し、管理コスト を削減。 クエリの自動書き換え: ユーザーは元の Iceberg テーブルをクエ リするだけで、StarRocks が自動的に最適なMVを使用する 。 柔軟な更新: パーティションごとの更新や、必要な期間 （直近データ）のみのマテリアライズが可能 。 外部テーブルとのJoin: Iceberg 上のデータと StarRocks 内部のデータをシームレスに結合可能 。 Standard Reports Ad Hoc Analysis raw data View/Materialized View Modeling MV Acceleration External catalog MV OLA Analysis Aggregation Table (roll up) Denormalized Table Normalized Table
16. 16 導入事例
17. 17 日本事例 - StarRocksによる基盤統合 ユーザの課題 ソリューション • Apache Iceberg をオープンなテーブルフォーマットとして活用し、柔軟かつ拡張 性の高い Lakehouse 基盤を構築します。 • StarRocks は Iceberg 上のデータを高速に分析し、低レイテンシかつ安定した クエリ性能を提供します。 • ストレージとコンピュートを分離することで、運用をシンプルにしながら、バッチ・スト リーミング・BI を統合的に支援します。 • ClickHouse（広告主向けリアルタイム分析）は同時実行数が増えると レイテンシが悪化し、Join に弱く、スケーラビリティに運用保守が困難。 • Trino（社内分析）はコストが高く、安定性に課題があった 。 StarRocks 導入の価値 • 高負荷耐性: 800 QPS の高負荷下でも安定した低レイテンシを維持 （ClickHouseは 400 QPSで性能劣化が発生）。 • データモデル: ClickHouse ではJOIN回避のために巨大なワイドテーブル（Wide Table）と複雑な前処理パイプラインが必須だった課題を解消。 • 対 Trino 性能: Trino と比較して、読み取り性能で 3.6倍、ETL性能で 1.8倍 の 高速化を実現。 • Trinoコーディネーターの単一障害点リスクと運用負荷の解消。 ≈ $ 2 B 広告配信・IT企業
18. 18 圧倒的なパフォーマンス向上と脱ベンダーロックインの実現 ユーザの課題 ソリューション • 次世代データインテリジェンスプラットフォームへの移行: データウェアハウス、データレイク、ストリーム処理を単一のプラットフォームに統合し、 アーキテクチャの抜本的な簡素化を実現。 • Iceberg クラスターへのネイティブで強力なサポート: Iceberg 上のデータに対し、高速かつスケーラブルな分析・計算サービスを直接 提供。 年間数億ドルに達した Snowflake の高コスト: • 事業成長率を上回るペースで運用コストが増大し、抜本的な改善が不可避 になっています。 世界最大級の Iceberg クラスターの計算要件: • ユーザは世界最大の Iceberg クラスターを管理しており、全社的な業務利 用のため、高性能・高可用性を両立する強力なデータウェアハウス機能が必 須。 StarRocks 導入の価値 • クエリ全体のパフォーマンスを4倍に引き上げ、膨大なデータに対する分析スピードと意 思決定の速度を劇的に改善しました。 • 大幅なコスト最適化 データウェアハウスのコストを25%、データガバナンスにかかるコス トを50%削減し、TCO（総保有コスト）の大幅な圧縮に成功しました。 • 「Single Source of Truth（信頼できる唯一の情報源）」を確立し、透明性が高 く持続可能なデータ活用環境を実現しました。 大手IT電子企業 ≈ $ 4 T
19. 19 金融業界データの鮮度向上 • 管理機能の強化: スナップショットやタイムトラベル機能により、データの変更履歴 追跡が容易に • アーキテクチャ統合: S3 や GCS 上のデータを移動せず（Zero-ETL）、 StarRocks から直接統合・分析 • クエリ最適化: 統計情報を活用し、大規模データの集計 （COUNT/MIN/MAX）パフォーマンスを向上 • リアルタイム性の欠如: MongoDB→SnowflakeのETL処理により、データ連 携の遅延が高い • パフォーマンスとコスト: 複雑なクエリで性能が低下。Snowflake の従量課金 によりコストが高 • データ管理の複雑化: 複数ソースの乱立により、マルチクラウドデータの一貫性 確保が困難に • 鮮度向上 : データ取り込みからクエリ実行までのレイテンシを「1 分以内」に短縮 • 性能向上 : 列指向アーキテクチャとマテリアライズドビューにより、、Snowflake と比較して4〜5 倍の高速化を実現 • コストと拡張性 : 必要なリソースのみを最適利用してコストを削減しつつ、高い 同時実行性を確保 ≈ $ 60 B ユーザの課題 ソリューション StarRocks 導入の価値
20. 20 大規模データの金融犯罪検知 • MPP アーキテクチャとベクトル化エンジンにより、複雑な多次元分析もミリ秒レベル で即座に応答します。 • 独自の主キーモデルが高速な Update/Delete を可能にし、秒単位のリアルタイ ムデータ分析を実現します。 • 単一クラスタで数万 QPS の高並列アクセスを処理でき、BI ツールからの直接参 照もスムーズです。 • デプロイ環境の制約: セキュリティ要件により GCP の VPC 内（およびオンプレミス）で の展開が必須であったが、SaaS 型の BigQuery では柔軟な対応が困難だった。 • ビジネス要件厳しいため、従来 BigQuery案のコストが高い • 100TB 以上のデータ（年率25-45%成長）に対し、複雑なJOINと高カー ディナリティな集計が必要 • 顧客向け分析において、P95 レイテンシ3秒以内の SLA • 顧客向けクエリの P95 レイテンシを50%短縮し、SLA 要件を余裕を持ってクリア。 • クエリのタイムアウトエラーを54%削減。高負荷時の信頼性が大幅に向上。 • 毎分500件以上の複雑な顧客クエリを、サブ秒〜数秒レベルで安定処理。 • 30以上のブロックチェーンにまたがるペタバイト級データの統合分析を実現。 ≈ $ 600 M ユーザの課題 ソリューション StarRocks 導入の価値
21. 21 eコマース・スポーツ • Iceberg による履歴管理: 30日以上のデータをS3で安価に保存し、スキーマ進 化やタイムトラベルクエリに柔軟対応。 • Kafka によるリアルタイム統合: 多源イベントを疎結合化し、目標 100K msg/s の水平スケールとデータの整合性（At-least-once）を確保。 • StarRocks による高速化 (Hot): 直近30日間のデータをJSONから直接取り込 み、マテリアライズドビューで検索を加速。 • 統一クエリゲートウェイ: データの移動なしで、StarRocks 上の「ホットデータ」と Iceberg 上の「コールドデータ」をシームレスに結合分析。 • 複雑な分析が困難: Druid の JOIN 性能が低く、高度なビジネス要件に応え られない。 • Redshift/Snowflake/S3にデータが散在し、倉庫間の結合が困難 • データ鮮度の欠落: 可視化までに 15分のタイムラグ が発生し、即時判断を阻 害。 • ダッシュボード性能: サブ秒（1秒未満） で応答（以前は数分）。 • アドホック分析: Iceberg データに対するクエリ速度が Athena と比 較して 10倍 高速化。 • コスト最適化: Snowflake を入れ替え重複するETLパイプラインと データエンジンの TCO 80%を削減。 • スケーラビリティ: 週あたり 2-3 TB のデータ増加にも柔軟に対応可能。 ≈ $ 25 B ユーザの課題 ソリューション StarRocks 導入の価値
22. 22 CelerData と StarRocks 紹介
23. 23 0 1.5K 3.0K 4.5K 6.0K 7.5K 9.0K GitHub スター 2022 2023 2025 2024 StarRocks StarRocks とは • StarRocks はオープンソースの分析プラットフォームです • 2020 年に開発され、既に 500 社以上の企業で本番稼働中です 業界認定 等のエンジニアを含む 300 名以上の貢献者がいます • GitHub 上で10K 以上のスターを獲得
24. 24 StarRocks と CelerData エンタープライズ向け StarRocks BYOC クラウドサービス • SOC 2 および GDPR 認証取得済み • セキュリティ：SSO 認証、LDAP 同期、行・列アクセスマスキング • 運用：監視・アラート、クラスタ管理用 GUI およびAPI、クエリプロファイ リング • 24 時間 365 日 SLA サポート 本社： カリフォルニ ア州 メンロパーク オープンソース OLAP+Lakehouse • 2020 年 5 月設立 • 2023 年 2 月に Linux Foundation へ寄贈 • 400 社以上の時価総額 10 億ドル超企業で本番利用中
25. 25 世界 500 社超の企業導入事例 25
26. 26 CelerDataはプレミアムサポートで最高の顧客 エクスペリエンスを提供します グローバルに複数のサポートオフィス プレミアムサポートレベル 7 × 24 応答 グローバル オフィス 複数のサポートチャネル Zendesk チケットシステム Slack サポートチャネル プロジェクトに定期的な会議 北京 東京 シンガポール シアトル メンローパーク サンパウロ
27. 27 IcebergやStarRocksなどに関する話題、 ぜひ気軽にご相談ください。 ソン セイ(Marko SUN) marko.sun@celerdata.com CelerData, Inc.
28. 28 ありがとうございます