Trino が『データサイロ問題』を解消する
大企業・大規模SaaSでは、PostgreSQL・MySQL・S3・Snowflake・Kafka等の複数データソースに情報が分散しているケースが普通です。これらを統合するためには都度ETLでDWHに集約するか、各DBに個別クエリを送るか、というアプローチが必要でした。TrinoはこれをSQL 1本で横断検索可能にする分散クエリエンジン。Netflix・Airbnb・LinkedIn・Salesforceで本番運用されています。
採用すべき5つのシグナル
- データが複数DB（OLTP/DWH/Lake）に分散している
- BIツールから複数データソースを統合参照したい
- 都度ETLでDWHに集約するコストが重い
- アドホック分析で複数データソースを横断したい
- データガバナンス（権限・監査）を1箇所で管理したい
主要機能
- 50+ Connector: PostgreSQL・MySQL・Hive・S3・Snowflake・MongoDB等
- 分散実行: 大量データを並列処理
- ANSI SQL: 標準SQL対応・複雑なJOIN・Window関数
- セキュリティ: Row-level Security・Column Masking・Audit
- Federation: 異なるDB間のJOIN
- Iceberg/Delta対応: モダンテーブルフォーマット
Presto/Trino/DuckDB比較
Presto（旧）: Facebook発祥・現在はTrinoが本流。
Trino: 分散実行・本番運用向け・複数データソース。
DuckDB: シングルノード・組み込み・分析特化。
使い分け: エンタープライズ・分散はTrino・ローカル分析はDuckDB。
実装パターン
(1) Trinoクラスタ構築: Coordinator + Workers構成
(2) Catalog定義: 接続先データソースの設定
(3) SQL実行: 標準JDBC/CLI・BIツールから接続
(4) Federation: SELECT FROM postgres.public.users JOIN snowflake.warehouse.orders ON ...
(5) 監査: Apache Rangerでアクセス制御
料金感（実務目安）
- OSS: 完全無料・Self-host
- Starburst（商用）: マネージドTrino・エンタープライズSLA
- AWS Athena: マネージド版（旧Presto互換）
- Self-host: クラスタ運用に専任SREが必要
本番採用の判断基準
- 本番実績: Netflix・Airbnb・LinkedIn等で大規模本番
- 運用負荷: クラスタ運用に専任SRE必要
- パフォーマンス: ペタバイト級の分析実績
- 商用サポート: Starburst・Ahanaなどから選択可能
- クエリ複雑度: 大規模分散JOINでも実用
実装で詰まる3つの落とし穴
- クエリ最適化: Federationクエリのプッシュダウン設計
- メモリ管理: 大規模JOIN時のメモリ枯渇
- セキュリティ: 複数データソースの認証情報管理
30日学習プラン
- 1週目: Trino Docker構築・PostgreSQL接続
- 2週目: 複数Catalog・Federation SQL
- 3週目: パフォーマンス・チューニング
- 4週目: 本番クラスタ構築・監査設定
関連リンク
BigQueryは BigQuery深掘り、dbtは dbt深掘り、DuckDBは DuckDB深掘り を参照してください。データエンジニアキャリアは データエンジニアキャリア もどうぞ。