PlaidとAPIの力
Plaidは退屈な金融の配管を抽象化し、他者がより速くイノベーションできるようにします。
最近、データパイプライン業界について分析をまとめる必要があり、それを共有しようと思いました。以下について詳しく説明します。
データパイプライン業界のTAMは>1000億ドルにのぼり、その価値に近づく企業もあります1。データパイプラインは幅広い分野なので、ここではデータ分析に関連性の高い分野に議論を限定します。上場企業と非上場企業が、データを活用する組織の技術スタックに組み込むために競い合っており、これは今日のほぼすべての大企業が2しています。
顧客やサプライヤーからのやり取りが生のトランザクションデータベースに流れ込みます。その後、データは移動され変換され、分析データウェアハウスに適したモデルに変換されます。そこから、アナリストは分析したいデータをクエリできます。彼らはその結果をエンドユーザー向けのビジネス指標のデータ可視化**に利用します。
これらすべてのプロセスは、ソフトウェア開発や導入コンサルティングを専門とする企業です。新しい企業の多くはクラウドベース(一部オンプレミスもあり)、Amazon Web Services(AWS)3のようなサービスプロバイダーの上に位置し、スケーラビリティ、柔軟性、節約を活かして高利益率の企業を構築しています。
データ生成の成長率と関連収益(前年比>20%)を考慮すると、この分野の多くのスタートアップは非対称的なリスク/リターン比率と高い出口倍率を誇り、投資の機会として非常に刺激的です。スタートアップ業界の成長を信じるなら、それを支えるデータパイプライン業界も信じなければなりません。
まずはユーザーが見えるもの、つまり**可視化*側から始めます。アナリストがすでに望む構造で整理されたデータを整理している場合は、その情報を整理する必要があります。これは通常、グラフや表を含むダッシュボードの形をとります。この分野のツールには、Tableau、Looker、Google Data Studio、R Shiny(ブラウザベースのユーザーフレンドリーなダッシュボード)、Streamlit(インタラクティブなデータアプリ)、さらにはGoogle Sheetsなどがあります。
ここでツールを選ぶ際のトレードオフは、ユーザーの技術的な能力とデータの複雑さのバランスです。もし組織に多くのユーザーが同じプロジェクトで協力したい場合、Sheetsのようなシンプルなツールが機能します。ユーザー数や機能リクエストが少ない場合は、ダッシュボードソフトウェアでより大きな負荷を扱えるものを作るのが理にかなっているかもしれません。
可視化の前に、アナリストはデータを分析する必要があります。彼らは構造化データベースからクエリ言語を使ってデータをクエリします。これはPresto(低遅延、低スループット)やHive(高遅延、高スループット)のようなものかもしれません。
これらの計算はデータウェアハウス層で行われ、Snowflake、Redshift、BigQuery、Azureなどがあります。人気が高まっているのはクラウドベースで、中には計算量とストレージ使用量のスケーリングや請求を別々に行うものもあります。データウェアハウスは分析に適している場合があり、データベースはデータの保存に適している場合があります。
ここでのトレードオフには価格、スケーリング、サポートが含まれます。例えば、最初はオープンソースのPostgresを使っていますが、会社がPostgresに適した規模を超えてスケールし、より技術的なバグに直面したときにSnowflakeに切り替えるかもしれません。
そのデータをウェアハウスに届けるために、データ移動やデータモデリングレイヤーを用意することができます。Stitch、Fivetran、Segment、Airbyteなどの企業は、生のソースからデータを抽出し(これについては後ほど説明します)、データベースに取り込むことでクエリを行っています。データムーバーは一般的に、Extract, Load, Transform(ELT)、Extract, Transform, Load(ETL)などの組み合わせとして知られています。
dbt、Matillion、Lookerなどのデータモデラーは、その生データをウェアハウスが必要とする構造にマッピングできます。例えば、dbtは統合開発環境(IDE)でデータを変換したり、変換ジョブをスケジュールしたり、データのドキュメントを作成したりできます。
ここでのトレードオフは、通常の価格、複雑さ、その他の技術的特徴です。例えば、Fivetranはより多くの統合機能を持っているのに対し、Stitchは少ないと思います。データ移動ツールの選択も使用するデータモデリングツールに影響します。つまり、データを二度変換する必要がないと考えることができます。
そのすべてのデータは、顧客とサプライヤーのやり取りから生のソースデータとして得られます。これにはSalesforce、Zendesk、Hubspot(CRM)などのソフトウェアツールも含まれます。これらはすべて異なる企業なので、データ形式も異なり、国ごとに異なる通貨と考えてください。だからこそ、先に述べたデータ移動やデータモデリングの層が必要なのです。
ソースデータはおそらくPostgres、MongoDB 6、あるいは面倒な方にはOracleのようなデータベースに保存されているでしょう。データウェアハウスとは異なり、これらのデータベースはリアルタイムで生成されるインタラクションデータを保存するのが得意です。書き込みは速く、読み取るのは遅いです。
まとめると:

Paul Tune、Recurse Center参加者のShae Matijs Erisson、Ori Dean Bernstein、Mikkel Paulson、Steven Li、Ryan Prior、Luke Barone-Adesi、Chirag Davé、Nathan Goldbaum、そしてLocally OptimisticのメンバーであるJacob Matson、Arpit Choudhury、Gordon Wong、Kevin Hu、Itto Korneckiの皆様に感謝します。
分析のためにTAMの提供が求められましたが、私の意見ではそれらはたいてい架空の数字です。とにかく、私の例を挙げます:Snowflake(SNOW)だけで2億ドルのリリューに対して700億ドルの市場上限で取引されています。データビジュアライゼーションは100億ドル、データ分析は400億ドル、データウェアハウジングは200億ドル、ELT/ETLは100億ドル、データベースは1つの業界プレスリリースあたり500億ドルです ↩
一定規模を超えると、無料の個人プランのスプレッドシートソフトにデータを保存することはもはや現実的ではありません ↩
AWSは100億ドルのリリューで数千億ドルの価値がある可能性が高いです。簡便化のために、AWSと他の主要プロバイダーは分析から除外しています ↩
そのデータはオンラインで売られたり、詐欺に使われたり、身代金目的で押収されたりする可能性があります。ほとんどの企業にとって、ハッキングされるかどうかの問題ではなく、いつハッキングされるかの問題です。 ↩
ほとんどの層での競争を考慮すると、通常はインフレではなく全体としてコストデフレが起きています ↩
Paul Tuneさんが指摘するように、リレーショナル(Postgres、MySQL)とMongoDBやDynamoDB(AWS製品)のような非リレーショナルデータベースの両方を持つことができます。後者の非構造化的な性質は、分析を行う企業にとって課題をもたらします。 ↩