もし誰かが海で取り残されたとしたら、やっと救助されたときに最初に欲しがるものは何でしょう?それは飲料水です。皮肉なことに、たとえ彼らが水に囲まれていたとしても、それは「消費できるもの」ではなかったのです。そして、この状況は多くの組織に当てはまります。データはたくさんあるのに、それを消費できないのです。
AWS のシニアソリューションアーキテクトであるラムクマール・ノッタス氏は、このように言いますが、そこでローコードまたはノーコードの ETL プラットフォームの出番です。これでデータの消費や民主化できるようになります。そこで本記事では、筆者の経験からローコードとノーコードについて見ていきます。
主なポイント
- ノーコード ETL とローコード ETL の実践的な説明
- ノーコード ETL とローコード ETL のどちらを選択すべきかの明確な理解
目次
- ローコード と ノーコードの大きな違い
- ローコード ETL プラットフォームについて
- ノーコード ETL プラットフォームについて
- ローコードプラットフォーム と ノーコードプラットフォームの比較
- ローコード と ノーコード と ハイコードのプラットフォーム
- ローコード と ノーコード の未来はデベロッパーに取って代わるのか
- まとめ
次に、ラムクマールが言ったことをもう少し掘り下げて、ローコードとノーコードが具体的にどのようなものなのかから考えていきましょう。
ローコードとノーコードの大きな違い
こちらの場面を考えてみましょう。
多くのデータチームがデータ統合をまだ旧式のツールに頼っています。問題は、ビジネス変換ロジックが独自のコードに固定され、革新的なテクノロジーへの移行を阻害していることであり、それでデータエンジニアは、ビジネス上の問題に集中するよりも、インフラが利用可能になるのを待つか、インストール構成の一部となっています。
ストリーム処理用、バッチ処理用、そしてイベント処理用の3つ目のツールなど、ツールを複数学ばないといけないので、コンタクトの切り替えが大変になります。そして旧式ツールの主な問題は、それを使うのに必要な技術レベルと、変更/インフラ維持/更新のプッシュなどにかかる時間です。
では、ローコードプラットフォームはどうやってこの問題を解決するのでしょうか?
ローコードおよびノーコード ETL のプラットフォームは、ETL 業界において画期的なツールです。ローコードプラットフォームでは、デベロッパーはビジュアル開発ツールを使うことで、最小限の手作業のコーディングでパイプラインを構築することができます。また、ノーコードプラットフォームだと、さらに一歩進んで、デベロッパーでなくても直感的なドラッグ&ドロップのインターフェースを使ってパイプラインを作成できるようになります。
ここでは1つのケースを取り上げましたが、もうひとつのケースは、社内でデータパイプラインを構築しているが、データの準備やクリーニングに多くの時間と労力が要る場合です。その結果、手作業によるエラーが多発することもあるかもしれません。
ローコード ETL プラットフォームについて
Microsoft のローコード・トレンド・レポート2022によると、81%がローコードによって連携が緊密になったと回答しており、ここでは、ユーザーに優しい UI(ユーザーインターフェース)が大きな役割を果たしています。
間違いなく、ローコード開発プラットフォームが顧客体験の向上にもたらす影響は計り知れません。
ローコード ETL プラットフォームで、モデル駆動型ロジックと統合機能を備えた、迅速なパイプライン生成と管理手法やアプローチが実現します。そしてここでは、通常のビジュアルツール、ポイントクリック、ドラッグ&ドロップにアクセスし、UX(ユーザーエクスペリエンス)を優先するフレンドリーな UI を通じて、ビジネスニーズを実行することができますが、プログラミング言語やコーディングスキル、スクリプティングを使うこともできます。
例えるなら、BI ツールのようなものです。Tableau では、フィールドをキャンバスにドラッグ&ドロップすることでダッシュボードを作成できます。また、Power BI のような、より高度なデータ可視化ツールを使うことを想像してみてください。ドラッグ&ドロップでのビジュアル作成ができますが、DAX 計算式を書いたり、カスタム API に接続してより複雑なデータ操作を行うこともできます。つまり、ローコードというのは、両者の良いとこ取りをしたようなものなのです。
それで、誰がこの恩恵を受けるのでしょうか?
これは、コードを使って構築したいデベロッパー向けであり、データアナリストのようなビジネス技術者向けでもあります。
次に、ローコードとノーコードの違いをより分かりやすく示すために、ローコード ETL プラットフォームの例を挙げてみましょう。
ローコードプラットフォーム の変換 UI
画像 は integrate.io のプラットフォームの変換コンソールで、真のローコードです(そうですね、十分なコーディング知識が求められるローコードツールもありますが、それはローコードに分類されます。なので、このような用語が使われています)。これについては後で見ていきましょう。
図を見てわかるように、対象者にデータを送信する前に、データに加えたいあらゆるタイプの修正に対応するテンプレートがあらかじめ用意されており、データ型のフォーマットによるデータのクリーニング、冗長なレコード、機密データをマスクするためのハッシュ化など、すべてオプションを選択するだけで行うことができます。
では、長所と短所を天秤にかけてみましょう。
ローコード ETL の利点 |
ローコード ETL の制約 |
従来の開発スケジュールのスピードが上がることから、より迅速なパイプラインの作成とビジネスアプリケションでの作業ができるようになる。 |
技術的なバックグラウンドを持たないユーザーには、まだ複雑すぎるかもしれない。 |
ノーコードプラットフォームに比べて高度なカスタマイズが可能なため、より複雑なアプリケーションに適している。 |
パイプライン管理のスピードが上がると、適切に管理されなければ、技術的負債の蓄積につながる可能性がある。 |
開発時間による大規模なコーディングの必要性が減ることから、プロジェクト全体のコストが削減される。 |
ローコード ETL についてはこんな感じです。ノーコードについてはどうでしょうか?それは文字通り「ノーコード(コード不要)」という意味なのでしょうか?それを早速以下で見てみましょう。
ノーコード ETL プラットフォームについて
ノーコードの ETL プラットフォームの機能は、目に見えるものを操作することであり、ポイント&クリック、ドラッグ&ドロップで完了します!事前構築済みのモジュールが、皆さんに代わって全作業を行ってくれますからね。このようなツールは、完全に視覚的なツールであり、実際にコーディングをすることは全くありません。
アプリ開発におけるより広い定義では、ノーコード プラットフォームで、ビジネスルールやドキュメント処理などの意思決定を行うための他の開発プロセスの自動化を構築することができますが、それから、アプリケーション間の多くのやり取りを実際に促進する統合タイプのテクノロジをバックグラウンドで構築できるようになります。
ETL に関して言えば、あらゆる種類の変換、データ取り込み、デスティネーションへの格納、パイプライン管理などのコードを柔軟に記述できるということであり、それはツールが提供する機能によりけりです。
では、ノーコード開発プラットフォームは誰のために作られたのでしょうか。
プロのデベロッパー、ベテランの技術者、ETL プロジェクトに遭遇したことのある市民デベロッパー向けではありますが、まったく新しいクラスの技術者も大歓迎です。つまり、技術者でなくても、ノーコードソリューションを使いたいだとか、コーディングの経験が少しだけある、というだけでいいのです。
ノーコード ETL の利点 |
ノーコード ETL の制約 |
ビジネスユーザーやその他の非デベロッパーが、コードを学ぶことなくデータ統合を実行できるようになる。 |
複雑なアプリケーションに必要なレベルのカスタマイズができない場合がある。 |
データパイプラインの迅速な作成と管理が可能で、アイデアのテストに最適。 |
シンプルになったレプリケーションプロセスは、時としてデータパイプラインのセキュリティやコンプライアンスの見落としにつながることがある。 |
このアプローチにより、データのレプリケーションが民主化されることから、より幅広いユーザーがアクセスできるようになる。 |
ローコードプラットフォームとノーコードプラットフォームの比較
パラメータ |
ローコード ETL |
ノーコード ETL |
企業 |
エンタープライズレベル |
小規模ビジネス |
ビジュアル |
有 |
有 |
データ修正用のコード/スクリプト |
有 |
無 |
誰が使えるか |
プロのデベロッパー、パワーユーザー、市民デベロッパー |
ビジネスユーザーおよび非デベロッパー |
習得 |
複雑であるため、習得が難しい |
習得しやすく、使いやすい |
(一般的な)費用 |
ノーコードよりかかる |
費用対効果 |
データ業界の例 |
Integrate.io |
Zapier |
ローコードとノーコード - コードのコラボレーション - アプリケーションの一部のコンポーネントをノーコードで実行できる場合に、ローコードの人々はプロジェクトに取り組みます。
ローコード と ノーコード と ハイコード プラットフォーム
前述したように、あるツールがローコードと表示されている場合、そのツールがどこまでコーディングを許可しているかは決められておらず、それはユースケースによって全く違うものになります。例えば、(地域別、商品別、期間別の)複数の次元の売上データを集計して、特定の閾値以上の売上だけを含める、特定の地域を除外するなどの条件ロジックを適用するようなユースケースが挙げられます。
これはデータ量や適用する条件によって複雑になります。プラットフォームが本当にローコードであれば、integrate.io のように変換のためのテンプレートを提供してくれますが、本当にローコードでない場合、インフライトで変換を行う機能は残っていますが、コーディングの範囲は広くなります。それは例えば SQL ベースの Rivery や Python ベースの Matillion などが挙げられます。
ローコードとノーコードの未来はデベロッパーに取って代わるのか
それは簡単な問題ではありません。DX(デジタル変革)の一環として、多くの自動化が行われるのは間違いありませんが、正しい見方をすれば、デベロッパーはビジネスに関連する他の問題を効率化することに集中できるようになります。ローコードやノーコードの ETL ツールで、統合プロセスの自動化が実現するでしょう。また、Snowflake によって導入されたイノベーションは有望であり、今後、ML(機械学習)と AI(人工知能)を使ったこのような画期的な進歩が、データ業界の他の大手企業からも期待できるでしょう。そうすると、新しいテクノロジーを常に把握して、変化への適応を学び、それをより早く利用できるようにならないといけないですね。
まとめ
本記事では、ノーコードとローコードの ETL プラットフォーム、そしてそれらを選択する前に考慮すべき様々なパラメータについて見てきました。そして、業界ではどのツールが本当にローコードなのか、常に混ややこしいことになっていますが、データプレパレーションとクリーニングのために提供される事前構築されたコンポーネントを明確に理解することで、それを理解することができるようになります。
また、ETL などの開発分野をローコードやノーコードが席巻するとの騒ぎもあります。進歩は有望ですが、その技術に求められるスキルに追いつけるかどうかが懸念されるのではないかと思います。