共著者の詳細については、ここをクリックしてください シュリフ灘.
共著者の詳細については、ここをクリックしてください デイヴィン・チア.
昨年、私たちのチームは、データ統合のユースケースについて200社以上の企業にインタビューを行いました。 私たちが発見したことは、 データ統合 2021年にはまだ混乱しています。
スケールできない現状
80件のインタビューのうち少なくとも200件は、Fivetran、StitchData、Matillionなどの既存のETLテクノロジーのユーザーに対するものでした。 ETL ソリューション (または ELT ソリューション - 簡単にするために、単に ETL という用語を使用します) を使用していても、それらのすべてが独自のコネクタを構築および保守していることもわかりました。 どうして？
XNUMXつの理由が見つかりました。
- コネクタのカバレッジが不完全
- データベースの複製に関する重大な摩擦
すべてのコネクタのニーズをカバーできない
私たちのインタビューでは、多くのユーザーの ETL ソリューションが、必要なコネクタをサポートしていないか、サポートしていても必要な方法でサポートしていないことがわかりました。
コンテキストの例：Fivetranは150年間存在し、10,000個のコネクタをサポートしています。 それでも、martechとadtechのXNUMXつのセクターだけで、XNUMXを超える潜在的なコネクタがあります。
ETL の最も難しい部分は、コネクタを構築することではなく、それらを維持することです。 これはコストがかかり、クローズド ソース ソリューションは ROI (投資収益率) の考慮事項によって制約を受けます。 その結果、ETL サプライヤーは最も一般的な統合に焦点を当てていますが、企業は毎月ますます多くのツールを使用し、コネクタのロングテールは無視されています。
そのため、ETLツールを使用しても、データチームは、社内コネクタの構築と保守に莫大な金額と時間を投資することになります。
データベース複製のユースケースに対応できない
ほとんどの企業はデータをデータベースに保存しています。 私たちのインタビューでは、既存のETLによって提供されるデータベースコネクタに関するXNUMXつの重要な問題が明らかになりました。
- ボリュームベースの価格: データベースは巨大で、増え続けるデータを提供します。 何億もの行を提供することを目的とした、何百万もの行を持つデータベースは一般的な光景です。 現在のETLソリューションの問題は、ボリュームベースの価格設定です。 従業員がクリックするだけで数百万行のデータベースを複製するのは簡単です。 そして、その単純なクリックは数千ドルかかる可能性があります！
- データのプライバシー： 今日の懸念とともに プライバシー とセキュリティ、企業はデータの管理をますます重要視しています。 既存のETLソリューションのアーキテクチャは、多くの場合、企業のプライベートクラウドからデータを引き出すことになります。 クローズドソース製品は、企業が基盤となるETLコード/システムを綿密に検査することを防ぎます。 可視性の低下は、信頼性の低下を意味します。
これらのポイントは両方とも、企業が追加の内部データベースレプリケーションパイプラインを構築することになった理由を説明しています。
データに合わせて拡張できない
ボリュームベースの価格設定とデータプライバシーについて前述した XNUMX つのポイントは、企業の規模にも当てはまります。 企業は、ETL ソリューションで維持されているのとまったく同じパイプラインを構築するためのデータ エンジニアの社内チームを持つことで、コストを削減できます。
オープンソースが唯一の前進である理由
オープン ソースは、上で挙げたポイントの多くに対応しています。 これがオープンソースが私たちに提供するものです。
- カスタマイズする権利: コードにアクセスして必要に応じて編集できることは、オープンソースがもたらす特権です。 たとえば、Salesforceコネクタに必要なデータが不足している場合はどうなりますか？ オープンソースでは、このような変更はコード変更を送信するのと同じくらい簡単です。 サポートチケットの長いスレッドはもうありません！
- コネクタのロングテールへの対応: 独自の ETL プロバイダーに、必要なコネクタを構築する価値があると説得する必要はもうありません。 プラットフォームが開発するよりも早くコネクタが必要な場合は、大規模なユーザー コミュニティの助けを借りて自分で作成し、維持することができます。
- データ ツールおよびワークフローとの幅広い統合: オープンソース製品は、オーケストレーション、デプロイ、ホスティングなどのためのさまざまなスタックとワークフローをサポートする必要があるため、データ スタックとワークフロー (UI ベース、オープンソースコミュニティを使用したAPIベース、CLIベースなど）。 それらのいくつかは、AirbyteのオープンソースAirflowオペレーターのように、コミュニティによって提供されています。 公平を期すために、理論的にはクローズドソースのアプローチでそれを行うことができますが、多くのツールをゼロから構築する必要がある可能性があります。
- 自律性のデバッグ: コネクタの問題が発生した場合、カスタマー サポート チームからの連絡や、サードパーティ企業の優先順位の高い修正を待つ必要はありません。 問題は自分で修正できます。
- すぐに使えるセキュリティとプライバシー コンプライアンス: オープンソースプロジェクトが十分にオープンである場合（MIT、Apache 2.0など）、どのチームも、インフラストラクチャにオープンソースコードをデプロイすることで、統合のニーズに直接対応できます。
コネクタ開発キットの必要性
ただし、オープンソース自体はデータ統合の問題を解決するのに十分ではありません。 これは、堅牢でフル機能のコネクタを作成するための参入障壁が高すぎるためです。
たとえば、REST API からデータをプルするスクリプトを考えてみましょう。
概念的には、これはデータベースに存在するいくつかのデータに対する単純な「SELECT * FROM エンティティ」クエリであり、潜在的にいくつかの基準でフィルタリングするための「WHERE」句を使用します。 しかし、このタスクを継続的かつ確実に実行するためのスクリプトまたはコネクタを作成したことがある人は、それがそれよりも少し複雑であることを知っています。
まず認証があります。認証には、ユーザー名/パスワードのような単純なものから、OAuth フロー全体の実装 (およびこれらの資格情報の安全な保存と管理) の実装のような複雑なものがあります。
また、同じデータを何度も読み直さないように、スクリプトの実行間で状態を維持する必要があります。
その後、レート制限を処理し、断続的なエラーを再試行する必要があります。それらを混同しないように注意してください。 リアル再試行できないエラー。
次に、データをダウンストリームのコンシューマーに適した形式に変換すると同時に、物事が必然的に壊れたときに問題を修正するのに十分なロギングを実行する必要があります。
ああ、これはすべて、十分にテストされ、簡単に展開できるようにする必要があります。
全体として、現在、新しいRESTAPIソースコネクタを構築するのに丸数日かかります。 この参入障壁は、コミュニティによって作成されるコネクタが少なくなることを意味するだけでなく、多くの場合、コネクタの品質が低下することを意味します。
ただし、この困難の80％は偶発的なものであり、ほとんど自動化できると考えています。 実装時間を短縮することは、コミュニティがコネクタのロングテールに貢献し、対処するのに大いに役立ちます。 この自動化がスマートな方法で行われると、標準化を改善できる可能性があり、したがって、貢献したすべてのコネクタのメンテナンスが向上する可能性があります。
コネクタ開発キットの外観
コネクタの構築に関連する作業を別の視点からもう一度見てみましょう。
- 偶発的な複雑性
- パッケージ構造の設定
- コネクタを Docker コンテナにパッケージ化し、リリース パイプラインを設定する
- 繰り返されるロジックがたくさん：
- すべてのコネクタ タイプ (REST API、データベース、ウェアハウス、レイクなど) に対して同じ設計パターンとコード構造を再発明する
- データを標準形式に変換するための同じヘルパーを作成し、増分同期、ロギング、入力検証などを実装します。
- コネクタがプロトコルに正しく準拠していることをテストします
- テスト 幸せな流れ とエッジケース
結局のところ、何千もの高品質コネクタを構築する方法は、 タマネギ層. と平行にするには ペット/牛 DevOps/Infrastructure でよく知られている概念では、コネクタは牛のコードであり、できる限り時間を費やす必要はありません。 これにより、生産性が大幅に向上します。
タマネギ層としての抽象化
高レバレッジの作業を最大化すると、タマネギ風の構造でアーキテクチャを構築できます。
センターは、APIの最低レベルを定義します。 そのレベルでコネクタを実装するには、多くのエンジニアリング時間が必要です。 しかし、それは、多くの制御が必要な非常に複雑なコネクタのエスケープ ハッチです。
次に、コネクタのファミリに非常に迅速に取り組むのに役立つ新しい抽象化レイヤーを構築します。 たとえば、送信元には特定のインターフェイスがあり、宛先には異なる種類のインターフェイスがあります。
次に、ソースには、HTTP-API ベースのコネクタやデータベースなど、さまざまな種類があります。 HTTP コネクタは REST、GraphQL、および SOAP に分割される場合があり、データベースはリレーショナル データベース、NoSQL データベース、およびグラフ データベースに分割される場合があります。 宛先は、ウェアハウス、データレイク、および API (リバース ELT 用) に分割される場合があります。
CDKは、これらの抽象化のフレームワークです。
すでに利用可能なもの
当社のCDKはまだ初期段階です。 現在、フレームワークには次の機能が付属しています。
- ソース コネクタを作成するための Python フレームワーク
- HTTPAPI用のコネクタを迅速に開発するための一般的な実装
- Airbyteプロトコルとハッピーコードパスへの準拠をテストするためのテストスイート
- 開発をブートストラップし、コネクタをパッケージ化するためのコードジェネレータ
最終的に、CDKにより、以前のXNUMX日間と比較して、XNUMX時間以内に堅牢でフル機能のコネクタを構築できます。
私たちのチームは、内部でフレームワークを使用してコネクタを開発してきました。これは、70を超えるコネクタを開発した経験の集大成です（ユーザーコミュニティの支援を受けて、年末までに200を目標としています！）。 私たちが自分自身の経験から学んだことはすべて、ユーザー コミュニティとともに、CDK の改善に使われます。
結論 – 今後の展望
新しいコネクタを構築するのに必要な時間を 10 分に短縮し、可能な統合のより多くのファミリに拡張できたら素晴らしいと思いませんか? ムーンショットはどうだ！
ユーザーコミュニティと一緒にそれを行うことができれば、データ統合パイプラインがオープンソースを通じてコモディティ化されることは言うまでもなく、ついに統合のロングテールにすぐに対処できるようになります。
コインスマート。 BesteBitcoin-ヨーロッパのBörse
ソース：https：//www.dataversity.net/why-etl-needs-open-source-to-address-the-long-tail-of-integrations/
