わかりやすい UI と豊富なコネクタが魅力!データ活用推進に注力したい組織におすすめな ETL サービス
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
株式会社メドレー / 山邉哲生
EM / データエンジニア / 従業員規模: 1,001〜5,000名
最終更新日投稿日
利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
データ基盤へのデータ連携・リバース ETL・dbt ワークフローの実行 | 11名〜50名 | 2024年1月 | B to B B to C |
利用機能 | データ基盤へのデータ連携・リバース ETL・dbt ワークフローの実行 |
---|---|
ツールの利用規模 | 11名〜50名 |
ツールの利用開始時期 | 2024年1月 |
事業形態 | B to B B to C |
アーキテクチャ
アーキテクチャの意図・工夫
- スナップショットベースの連携によって静止点が確保されるので、テーブル間の整合性担保に加え、何らかの障害などで複数回連携を行なっても同一の状態を再現できるようになっています
- また Trocco のワークフローから dbt を実行することでバッチ実行環境を構築する必要がなくなり、稼働状況の確認先も一元化できています
- データ基盤への ETL だけでなく、Kintone などのツールへのリバース ETL も手軽に実現できるので、社内からの様々な要望に応えやすくなりデータ利活用の幅が広がっています
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
データ基盤構築時に必ず必要になるのがデータ連携処理ですが、プロダクトごとにデータソースやインフラが異なるため個々に開発・運用を行う必要がありました。一方でデータ組織の規模もまだ小さく、他にも様々なタスクがある中で連携処理だけに時間を割くのは難しいという状況でした。
どのような状態を目指していたか
できるだけローコード・ノーコードに近い形で、それぞれのプロダクトのデータベースとデータ基盤間での安定した連携処理を実現したいと考えていました。またマネージドサービスを使うことでインフラやワークフロー管理も簡易化・一元化し、データエンジニアが他の課題解決に専念できる状態を目指しました。
比較検討したサービス
- BigQuery Data Transfer Service
- 現在は用途に合わせて併用しています(参考記事 : BigQuery Data Transfer Service を通して学ぶ Google 広告のデータモデル)
比較した軸
- プロダクトや外部システムなどのデータソースとデータ基盤(BigQuery)間のデータ連携がサポートされているか
- 設定の簡易さやランニングコスト
選定理由
- 主要なデータベースはもちろん、外部システムとの豊富なコネクタをサポートしていること
- 転送ジョブだけでなく、ワークフローの定期実行設定などもわかりやすかったこと
- チームやリソースを分割できるため、コスト按分を含めた複数事業での運用管理がしやすかったこと
- 事業承継によって参画したプロダクトで既に利用実績があったこと
導入の成果
- データ基盤内外に対する日々のデータ連携について、データの欠損や連携処理の異常などを意識することなく安定して運用できています
- 連携するテーブルの追加・変更作業も軽微な修正で実現できるので、データ連携依頼対応のリードタイムもかなり短縮できていると思います
- 結果として、データエンジニアのリソースを他の課題(データマネジメントや利活用推進)に向けられています
導入時の苦労・悩み
- 導入初期はそれなりの量のテーブルを登録することになるため、個々に連携設定をつくっていくのが大変でした
導入に向けた社内への説明
上長・チームへの説明
- 上記の通り、既に利用実績があったためそこまで論点はありませんでした
- また、複数プランが用意されている他、チームごとのリソース利用状況がわかるので社内でのコスト按分もしやすく、段階的に利用を始められたのがよかったと思います
活用方法
- データエンジニアのチームでデータ連携の設定時に利用しています
- 基本的に日次で行う連携処理について、異常があれば設定や連携ログを確認しにいくという形です
よく使う機能
- データ連携機能
- データ連携元・連携先との接続設定、および連携対象ファイル・テーブルの設定
- データ連携時のカラム定義や、型変換やマスキング処理などの定義・実行
- ワークフロー機能
- DAG(Directed Acyclic Graph : データ連携ジョブ間の実行順序や依存関係を表すグラフ)によって転送設定を一まとめにするワークフローを定義
- スケジューリングや通知設定を割り当てることで定期データ連携を実現
- dbt ワークフロー機能
- 2 の派生形として、外部リポジトリで定義した dbt ジョブを起動する Trocco ワークフローを設定
- dbt build を通した dbt snapshot の取得・ビルド・マート生成・テストまでの一連のデータ変換処理を実行(2025/09/29 現在、dbt-core を使用)
ツールの良い点
- データ連携設定からワークフローの定義まで、 GUI ベースでわかりやすく実現できる
- 多様なコネクタをサポートしているため、メジャーなデータベースはもちろん、サードパーティのツールであっても大体はすぐに連携できる
- API や Terraform Provider が提供されており、ある程度はプログラマブルにデータを抽出したり処理を記述・管理することが可能
- 設定変更時の差分が YAML の git diff として表示されるため、変更内容の確認がしやすい
ツールの課題点
- 連携対象のテーブルが多くなってくると GUI 経由での手動設定・管理が難しくなってくる。これは個々の転送設定だけでなくワークフローも同じで、コード管理(IaC)に移したくなるタイミングがくるが現状まだやりづらい
- すでにあるデータからスキーマ定義を推定して連携を行う思想なので、テーブルはあってもレコードがない状態での連携設定定義が難しい
- コネクタが多い分、設定に関する説明の詳細さや対象サービスの API への追従状況にはややばらつきがある印象
ツールを検討されている方へ
- Trocco の GUI はわかりやすく操作性も良く、エンジニア以外の方でも簡単にデータ連携の設定・運用を行えることが魅力だと思います。一方で連携対象のテーブルやワークフローが一定規模を超えてくるとコード管理をしたくなりますが、本稿執筆時点では Git 連携は pull のみ(Trocco の一部設定 -> Git リポジトリへの同期)です。API および Terraform Provider によるリソース変更もサポートされていますが、設定項目はそれなりに複雑な印象なので今後、より手軽にできるようになると嬉しいですね。
- また、単純にコネクタの数が豊富なだけでなく、国内でよく使われているサービスをサポートしているというのも国産ツールのメリットだと思います。データ連携のために API 仕様から調べて開発したり、連携先のバージョンに追従していくのも大変ですので、十分な数のデータエンジニアがいない、あるいは他に注力するべき課題が多い場合などには間違いなく有力な選択肢ではないでしょうか。
今後の展望
上述の通り段々と規模が大きくなってきて GUI での管理が大変になってきているため、API や Terraform 経由でのプロビジョニングも生成 AI を絡めて試していきたいです。
また、現状は日次・あるいは数時間間隔でのデータ連携が主ですが、今後リアルタイム性を上げていく中で先日発表された CDC(Change Data Capture)なども検討していければと思っています。
株式会社メドレー / 山邉哲生
EM / データエンジニア / 従業員規模: 1,001〜5,000名
よく見られているレビュー
株式会社メドレー / 山邉哲生
EM / データエンジニア / 従業員規模: 1,001〜5,000名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法