Zenn
Aidemy Tech BlogPublicationへの投稿
🌊

いろいろ盛りの ELTツール Rivery.Io 触ってみた

snhryt
2022/12/19に公開
modeling
elt
moderndatastack
tech

はじめに

アイデミーのデータエンジニア？の Yuto Shinahara です。

世はデータ戦国時代。Modern Data Stack に類する様々なデータプロダクト（主に海外製）が熾烈な戦いを繰り広げています。
データの Extract, Load, Transformation (ELT) のそれぞれを担うツールとして、E&L 部分は Fivetran が天下を取りつつあり、 Airbyte がその後ろを追いかけている印象があります。[1]
また、 T 部分はすっかり dbt の独壇場となっております。

そんな中、各位に第三勢力としてプレッシャーをかけ始めている（？）のが Rivery.Io （リヴァリー）です。

https://rivery.io/

見かけたときから気になっていた一方で、日本語の記事が見つからなかったので、この機に少し触ってみました。

Rivery.Io とは

Rivery.Io はニューヨーク発のプロダクトで、公式ページの Product Overview によると

The Complete SaaS ELT Platform

らしいです。
・・・つまりどういうことなんだってばよ？？ はい、具体的には

Rivery provides a unified solution for Ingestion, Transformation, Orchestration, Activation, and Data Operations.

とのことです。要は、全部盛りツールです。

2022年5月には VC から $30M を調達しており、海外では徐々に勢いを増している模様です。
とはいえ、「初耳なんだが？」という人がほとんどだと思います。
おそらく日本での知名度はないに等しく、私自身、まだ日本で導入している企業やチームを見たことはありません。

特徴

ざっくりまとめるとこんな感じです。

  • E&L (Reverse ETL 含む) フローをノーコードで設定可能
  • 200以上の豊富な Integration が用意されている
    • 数だけでいうと Fivetran や Airbyte にも負けていない
  • T (Transformation) や Orchestration の機能も備わっている
    • T は SQL はもちろんのこと、Python でも記述可能[2]
    • GUI ベースで柔軟に、複雑なワークフローでも構築可能
  • 3つの実行環境（例: production, staging, development）を設定可能[3]
  • CLI も用意されている

みんな大好き Python で T 部分を記述できる機能を、dbt や Snowflake (Snowpark for Python) よりも先にプロダクトに盛り込んでいたのは、なんというかセンスが良いなぁって思っています。

他の特徴はこちらから↓
https://rivery.io/product/

課金体系

少し独特です。課金額は Rivery Pricing Unit (RPU) という、 API 実行の従量課金+転送データ量を足し合わせた独自単位で計算されます。


プランは全部で3つ。機能限定の無料版みたいなものは存在しない。

公式ページにコストシミュレーターがあって、これで概算見積が可能です。

https://rivery.io/pricing/

どうでしょうか？計算してみた私の所感としては、結構高いなぁと感じました。

触ってみた

Rivery.Io は14日間の無償トライアルが可能であり、今回はそれにあやかって実際に触ってみました。

ちなみに、少し罠だったのが以下の画面では "access to all features" と記載がありますが、全部が使えるわけではありませんでした。
たとえば、ツールの大きな強みでもある Transformation を Python で記述する機能は、トライアルには開放されていませんでした（一番使ってみたかったのに・・・）

チュートリアル

サインアップするとこんな感じで E&L 部分のチュートリアルが始まります。

今回はよく使う MongoDB をソースに、Google Cloud Storage (GCS) をデスティネーションに設定してみました。

MongoDB との接続設定部分。右に情報出てるのいいですね。


GCS との接続設定部分。適当な権限を振ったサービスアカウントを作って登録するだけでOK。

次に、MongoDB 内で Sync するコレクションを選択します。

"Edit" から、コレクションごとのカラム絞り込みとマッピング設定、および Load 時の設定を変えることができます。正直、結構ポチポチすることになるので、本番で使うときはこのへんは CLI 不可避だなぁって気はしました。


カラムの絞り込みとマッピング


Load 時の設定。たとえば、"Loading Mode" は4つのオプションから選択可能。

最後に、実行スケジュールを指定します。今回はテスト用なので特に設定なし。

チュートリアルとしてはこれで終了です。


チュートリアル完了を祝福するおっちゃん

タスクの実行状況はこんな感じで確認ができ、各実行ログのダウンロードも可能です。

複数コレクションの E&L を行う場合、コレクションごとに別々の Run として扱われる

実行キャンセルするときは一度ポップアップが出てきて、こんな感じで警告されます。

「今キャンセルしてもロールバックはできないし、RPU にも加算されるけどええんか？」と聞かれている。余談ですが、"Yes" をもう少し強調する UI にしてほしい・・・

1つ罠だったのが、GCS の場合は Rivery.Io から Load する用のバケットは事前作成する必要がありました。
これをやっていなかったせいで最初は実行エラーが起きていましたが、バケットを作ってあげると無事に[4] Load が成功。

今回は以下のような構造で、選択したコレクションのデータが JSON ファイルとしてアップロードされていました。

rivery_example/    # Bucket
└ xxxxx/           # File zone Path
  └ <yyyymmdd>/    # File Zone Folders Period Partition
    └ <yyyymmdd>_<hhMMSS>_<hash>/
      └ <hash>_mongodb_<collection name>__0.json

全体像

Rivery.Io では先程のように作成した1つ1つのフローを River という単位で管理します。
その River は、さらに3タイプに分類されます。

  1. Source to Target River: E&L + ちょっと T （カラム選択やリネーム等）を定義。チュートリアルで作ったのはコレ
  2. Action River: ソースおよびデスティネーションに対する REST API の Request を定義（触ってないから詳細不明）
  3. Logic River: 上記2つの River や、SQL, Python による Transformation を組み合わせたワークフローを定義

Logic River (Orchestration)

Rivery.Io の1つの肝になる機能です。
ここでは、Logic step という実行単位を複数定義し、それを重ねていくイメージです。

「MongoDB のデータを BigQuery に E&L し、それを同じ BigQuery 上で T して別のテーブルに吐き出す」 Logic River

Logic step 内で設定可能なものは以下の通り。

  • SQL / DB Transformation
  • River
    • Source To Target River, Action River, Logic River のいずれも Sub-River として入れ子にして組み込むことが可能
  • Action
    • （上述のとおり River メニューから選択できるので、この選択肢の存在意義が分からん・・・）
  • Python

たとえば BigQuery 上での Transformation を表現する場合には以下のようにポチポチ・カキカキしていきます。

  1. DB 選択
  2. Source 設定
    • ここでクエリを書くことになりますが、残念ながら入力アシストはかなり貧弱です
  3. Target 設定
    • Columns Mapping からはカラムごとの型指定だったり、クラスタ・パーティション設定だったりが可能

とはいえ、これだけだと ELT の一連のプロセスを直列に並べただけに過ぎません。
しかし、さすがは Orchestration を銘打ってるだけあり、各ステップのループ設定や条件分岐もばっちりできます。

Container （仮想化技術のコンテナとは全く関係なし）という複数のステップをまとめた箱を作り、その中に分岐条件や、分岐ごとのアクションを記述していきます。

条件分岐のコンテナ

つまり、やろうと思えば「条件分岐するコンテナの中に、ループ処理用のコンテナを作って、その中に既存の Logic River を配置する」みたいな、めちゃくちゃ複雑なこともできちゃいます。
反面、UI 上では各ステップは直列x縦並びで表現されてしまうので、複雑な Logic River を組んだ後の保守性としては辛いものがありそうです。
ぜひとも、いい感じのビジュアライズ機能が欲しいところ。

Environments

ちゃんと触ってないので使い勝手の良し悪しは不明ですが、こんな感じで環境ごとに変数であったり、デプロイ時の設定であったりを定義することができます。

Dashboard

結構分かりやすい。RPU もここから確認できるので、請求金額ぱっと分かるようになっているのはいいですね。

おわりに

使ってみた感想としては、面白くはあるが、「自社のデータパイプラインに組み込みたい！」とは思わなかったのが正直なところです。主な理由は以下のとおりです。

  • Transformation[5] と Orchestratiton の機能がまだまだ中途半端
  • ツールとしての強みを享受しようと思ったら Professional プラン不可避で、金額的に高くなる
  • しかも課金体系が分かりづらい

1つ specific にはなりますが、個人的にいいなと思ったのは、GCS や Azure Blob Storage などのクラウドストレージ系サービスをデータソースとして指定可能な点ですね。
（Airbyte だと、現状は S3 以外はデスティネーションとしてしか指定できない[6]）

とはいえ、こういう全部盛り！なコンセプトのツールは個人的に大好きでして、今後の改善・発展にとても期待しています。
Shipyard なんかも割と似たコンセプトのツールだと思うので、どういう違いがあるのか見てみたいですね。

脚注

  1. ゴリゴリに Fivetran を意識している Airbyte: https://airbyte.com/etl-tools/fivetran-alternative-airbyte ↩︎

  2. Professional プラン以上でのみ利用可能。 ↩︎

  3. Professional プラン以上でのみ利用可能。Enterprise プランでは利用できる環境数が無制限になる（そんなに使う人おるんか？） ↩︎

  4. Unicode 文字がちゃんとエンコードされておらず "\u3053\u306e\u554f\u984c" みたいな状態で格納されていたのは残念ポイント・・・だけど、割とあるあるなのかなとも思っている。 ↩︎

  5. Transformation 部分は dbt と併用しているケースもある模様。参考: Keyrus 社のデータスタック ↩︎

  6. 代わりに、AWS Datalake や Databricks Lakehouse など、Airbyte でしか対応していないものもあるので、一概に Reivery.Io のほうが強いわけではない。 ↩︎

Aidemy Tech Blog
Aidemy Tech BlogPublication

株式会社アイデミーの技術ブログです。

Discussion