独占 | Zero-ETL、ChatGPT、およびデータエンジニアリングの未来

作者：Barr Moses
翻译：陈超
校对：欧阳锦


本文约3800字，建议阅读12分钟本文将会深入分析一些短期内最热门的观点，这些观点可能会成为后现代数据堆栈的组成部分，并对它们对数据工程的潜在影响进行论述。

ポストモダンのデータスタックが登場しました。準備はできているか？

画像は作者より無償提供

変化を好まない人には、データエンジニアリングは向いていません。この地域では何も変わらないものはありません。

最近の最も重要な例は、データベースの概念を覆し、最新のデータスタックの時代を到来させた Snowflake と Databricks です。

この変更の一環として、Fivetran と dbt は基本的にデータパイプラインを ETL (抽出、変換、ロード) から ELT に変更しました。ハイタッチディスラプションソフトウェアアズアサービス (SaaS) は、焦点をデータウェアハウスに移す試みで世界を席巻しました。Monte Carlo もこの議論に加担し、「エンジニアに手動で単体テストを作成させるのは、データ品質を保証する最良の方法ではない可能性がある」と主張しました。

現在、データエンジニアは、最新のデータスタックの啓蒙という上り坂の道に沿って、ハードコーディングされたパイプラインとオンプレミスサーバーを磨き続けています。そして、避けられない合併と幻滅の谷が、まだ安全な距離とは言えないところにすでに迫っている。

したがって、破壊者のための新しいアイデアがすでに現れているという事実は、もっともらしいとは思えません。

Zero-ETL は独自の可視領域にデータを取り込みます
AI と大規模な言語モデルは変形する可能性がある
データ製品コンテナは、データテーブルをデータの中核となる基本要素として扱います。

すべてを（もう一度）再構築するつもりですか？Hadoop (分散コンピューティング) の時代はまだ完全には冷めていません。

答えは当然です。私たちはキャリアの中で何度もデータシステムを再構築することがあります。本当の問題は、なぜ、いつ、どのように (この順序で) です。

私はすべての答えを知っているふりをしたり、答えを予測できる水晶玉を持っているつもりはありません。ただし、この記事では、ポストモダンデータスタックの一部となる可能性のある最も注目されている短期的なアイデアのいくつかを掘り下げ、データエンジニアリングへの潜在的な影響について説明します。

実用性とトレードオフ

Unsplash の Tingey Injury Law Firm 経由の画像

最新のデータスタックは、以前のテクノロジーよりも優れた機能を発揮するために誕生したわけではありません。そこにはトレードオフがあります。データは大きくなり、高速になりますが、その分、管理が煩雑になり、扱いにくくなります。費用対効果に関する試験はまだ結論が出ていない。

最新のデータスタックがトップに立つのは、ユースケースをサポートし、他の方法では非常に困難だったかもしれない方法でデータの価値を引き出すことができるからです。機械学習という用語は、単なるバズワードから「コードから富へ」へと変わりました。分析と実験は、意思決定をサポートするためにさらに深く行うことができます。

以下の各傾向についても同様です。良くも悪くも、主流の採用は、彼ら、または私たちがまだ発見していないダークホースが、データを活用する新しい方法を解き放つ方法です。さらに一歩進めてみましょう。

ゼロETL

それは何ですか:誤った名前です。データパイプラインはまだ存在します。

現在、データはサービスによって生成され、トランザクションデータベースに書き込まれることがよくあります。デプロイされた自動パイプラインは、生データを分析データウェアハウスに移動するだけでなく、途中でわずかに変更します。

たとえば、API はデータを JSON 形式でエクスポートしますが、パイプラインを取り込むには、データを転送するだけでなく、データがデータウェアハウスにロードできる表形式になるように簡単な変換を適用する必要もあります。取り込みフェーズ中に行われるその他の一般的な軽量変換には、データのフォーマットと重複排除があります。

パイプラインを Python でハードコーディングすることで、より負荷の高い変換を行うことができ、事前にモデル化されたデータをウェアハウスに配信するためにそうすることを推奨する人もいますが、ほとんどのデータチームは便宜性と可視性のためにそれを行っています。品質上の理由からこれを行わないことを選択しています。。

Zero-ETL は、トランザクションデータベースをデータウェアハウスに自動的にロードする前に、データクレンジングと標準化を実行できるようにすることで、この取り込みプロセスを変更します。データはまだ比較的未加工の状態であることに注意することが重要です。

現在、ほとんどのゼロ ETL アーキテクチャでは、トランザクションデータベースとデータウェアハウスが同じクラウドプロバイダーからのものである必要があるため、この緊密な統合が可能です。

長所:遅延が減少します。重複したデータストレージはありません。失敗の原因が 1 つ減ります。

短所:取り込みフェーズでのデータの処理方法をカスタマイズする機能が少ない。部分的なサプライヤーのロックイン。

誰がそれを推進しているか: AWS はバズワード (Aurora から Redshift) の原動力ですが、GCP (BigTable から BigQuery) と Snowflake (Unistore) はどちらも同様の機能を提供します。Snowflake (安全なデータ共有) と Databricks (デルタ共有) も、いわゆる「コピーフリーのデータ共有」を追求しています。このプロセスには実際には ETL は含まれませんが、保存されたデータへの拡張アクセスが提供されます。

可能性を解き放つ実用性と価値:一方で、ゼロ ETL の背後にあるテクノロジー大手とすぐに使える機能のおかげで、ゼロ ETL の推進は時間の問題であるように見えます。その一方で、予期せぬスキーマの変更によって運用全体が停止するのを防ぐために、データチームが運用データベースと分析データベースをより緊密に統合するのではなく、切り離しているのを観察しました。

この革新により、ソフトウェアエンジニアのサービスが生成するデータに対する可視性と説明責任がさらに低下する可能性があります。コードがコミットされた直後にデータがすでにウェアハウスに送られている最中に、なぜアーキテクチャを気にする必要があるのでしょうか?

ストリーミングデータとマイクロバッチのアプローチは、今日の「リアルタイム」データのニーズの大部分を満たしているため、このようなイノベーションの主なビジネス推進力はインフラストラクチャの簡素化であると私は考えています。理解できることですが、長期にわたるセキュリティレビューのハードルを取り除くために重複データを共有しない可能性は、長期的にはそのようなメカニズムの報復的な使用につながる可能性があります（ただし、これはトレードオフではありません）。

OBT と大規模言語モデル

内容:現在、ビジネス関係者は要件、指標、ロジックをデータ専門家に表現する必要があり、データ専門家はそれをすべて SQL クエリやダッシュボードに変換します。すべてのデータがデータウェアハウスにすでに存在している場合でも、このプロセスには時間がかかります。言うまでもなく、アドホックデータリクエストは、データチームのお気に入りのアクティビティのリストの根管と文書の間にランクされます。

GPT-4 のような大規模言語モデルの力を利用して、消費者が滑らかなインターフェイスで自然言語でデータを「クエリ」できるようにすることでプロセスを自動化することを目指している新興企業のグループがあります。

少なくとも、私たちの新しいロボットの覇者がバイナリを新しい公用語にするまでは

これにより、セルフサービス分析プロセスが大幅に簡素化され、データがさらに民主化されますが、基本的な「メトリクスの取得」を超えた、より高度な分析のためのデータパイプラインの複雑さを考慮すると、問題の解決は困難です。

しかし、すべての生データを 1 つの大きなテーブルに詰め込んで、この複雑さを単純化するのはどうでしょうか?

これは、データ分野で最も優れた先見の明のあるライター/創設者の 1 人である Benn Stancil によるアイデアです。彼ほど現代のデータスタックの終焉を予測した人はいませんでした。

概念としては、それほど突飛なものではありません。一部のデータチームはすでに 1 つの大きなテーブル (OBT) 戦略を使用しています。

大規模な言語モデルを活用することで、OBT を使用する際の最大の課題の 1 つである発見とパターン認識の難しさ、そして組織化の完全な欠如が克服されるようです。人間にとっては、ストーリーの目次や適切なラベルが付けられた章があると便利ですが、AI は気にしません。

長所:セルフサービスのデータ分析の約束がついに果たされる可能性があり、迅速に洞察を得ることができ、データチームがデータ価値の解放と構築により多くの時間を費やし、アドホックなクエリに応答する時間を短縮できるようになります。

デメリット：自由すぎる？データの専門家は、データの厄介な癖 (タイムゾーン!「アカウント」とは何ですか?) に精通していますが、ほとんどのビジネス関係者はそうではありません。私たちは直接データ民主主義ではなく、代表制から恩恵を受けているのでしょうか?

それを推進しているのは誰ですか: Delphi と GetDot.AI のような超初期段階のスタートアップです。ナレーターのようなスタートアップ。Amazon QuickSight、Tableau Ask Data、ThoughtSpot など、より確立されたプレーヤーがこれのいくつかのバージョンを実行しています。

実用性と価値を解き放つ可能性:驚くべきことに、これはユースケースを探しているテクノロジーではありません。価値と効率は明らかですが、技術的な課題も同様です。このビジョンはまだ構築中であり、開発にはさらに時間がかかるでしょう。おそらく、導入への最大の障害は必要なインフラストラクチャの停止でしょう。これは、より成熟した組織にとってはリスクが大きすぎる可能性があります。

データ製品コンテナ

概要:データテーブルは、データ製品を構築するためのデータの構成要素です。実際、多くのデータリーダーは、本番テーブルをデータ製品と見なしています。ただし、データテーブルを製品として考えるには、アクセス管理、検出、データの信頼性など、多くの機能を階層化する必要があります。

コンテナ化は、ソフトウェアエンジニアリングにおけるマイクロサービスの動きに不可欠な部分になっています。これらは移植性とインフラストラクチャの抽象化を強化し、最終的には組織がマイクロサービスを拡張できるようにします。データ製品コンテナの概念は、データテーブルの同様のコンテナ化を想定しています。

データ製品コンテナは、特にデータの基本単位に関連付けられたセマンティック定義、データ系統、品質指標などの情報をより適切に表現できる場合、データの信頼性と管理性を高めるための効果的なメカニズムであることが証明される可能性があります。

長所:データ製品コンテナは、データグリッドの 4 つの原則 (フェデレーションガバナンス、データセルフサービス、製品としてのデータ、ドメインファーストのインフラストラクチャ) をより適切にパッケージ化して適用する方法であると考えられます。

短所:この概念により、組織はデータ製品を拡張しやすくなりますか、それとも難しくなりますか? こうした将来のデータトレンドの多くに関するもう 1 つの基本的な疑問は、データパイプラインの副産物 (コード、データ、メタデータ) には、データチームが保持する価値のある価値が含まれているかということです。

誰がそれを推進しているか: Nextdata は、データグリッドの作成者である Zhamak Dehgahni によって設立されたスタートアップです。Nexla もこのスペースでプレーしています。

実用性と価値を解き放つ可能性: Nextdata はステルスから登場したばかりで、データ製品コンテナはまだ進化中ですが、多くのデータチームはすでにデータグリッド実装の熟した結果を目の当たりにしています。データシートの将来は、これらのコンテナの正確な形状と実装に依存します。

データライフサイクルの無限の想像力に富んだ再構築

Unsplash 経由の画像、ゼロ

データの未来を覗くには、過去と現在のデータを振り返る必要があります。過去、現在、未来 — データインフラストラクチャは絶えず破壊と再生の状態にあります (ただし、さらなる混乱が必要になるかもしれません)。

データウェアハウスの意味は、1990 年代にビルインモンが導入した用語から劇的に変わりました。ETL パイプラインは ELT パイプラインになりました。データプールは 2 年前ほど形のないものではありません。

最新のデータスタックによってもたらされたこれらのイノベーションにおいても、データエンジニアは依然として、データがどのように移動するか、データ利用者がどのようにデータにアクセスするかを決定する上で中心的な技術的役割を果たしています。しかし、一部の変化は他の変化よりも大きく、恐ろしいものです。

Zero-ETL という用語は、パイプラインの停止を (不正確に) 暗示しているため脅威に思えます。パイプラインが存在しない場合、データエンジニアは必要なのでしょうか?

ChatGPT のコード生成機能が誇大宣伝されているにもかかわらず、そのプロセスは依然としてテクニカルデータエンジニアの手に委ねられており、レビューとデバッグが必要です。大規模な言語モデルの恐ろしい点は、それらがデータパイプライン、つまりデータの消費者との関係 (およびデータの供給方法) を根本的に歪めることです。

ただし、この未来が現実になったとしても、依然としてデータエンジニアに大きく依存することになります。

古代から存在しているのは、データの一般的なライフサイクルです。それはリリースされ、形作られ、使用され、そしてアーカイブされます（ここで私たち自身の終焉について言及するのは避けるのが最善です）。

基盤となるインフラストラクチャが変化し、自動化により時間と注意が右か左に移る可能性がありますが、ヒューマンデータエンジニアは、当面はデータから価値を引き出す上で重要な役割を果たし続けるでしょう。

これは、将来のテクノロジーやイノベーションによって今日の複雑なデータインフラストラクチャを簡素化できないためではなく、データに対する需要と使用が今後も複雑さと規模を増し続けるためです。

ビッグデータはこれまでもこれからも、前後に揺れる振り子です。私たちは能力を飛躍させた後、次の飛躍が必要になるまで同じくらい早くその限界に到達する方法を見つけます。このサイクルで安心してください。必要とされるのは良いことです。

Shane Murray はこの記事の共著者です。購読すると、彼のストーリーがあなたの受信箱に届けられます。

データ品質の将来に興味がある場合は、モンテカルロチームにご連絡ください。

原題:

Zero-ETL、ChatGPT、そしてデータエンジニアリングの未来

元のリンク:

https://towardsdatascience.com/zero-etl-chatgpt-and-the-future-of-data-engineering-71849642ad9c

編集者: ユウ・テンカイ

校正：チェン・アンレ

翻訳者プロフィール

Chen Chao氏、北京大学応用心理学修士、データ分析愛好家。私はかつて学部時代にコンピューターサイエンスを学び、その後、心理学の道を執拗に追求しました。学習の過程で、データ分析には幅広い用途があることがますます分かってきました。学んだことを活かして、有意義な成果を上げたいと思っています。データスクールという大きなファミリーに加わることができて、とてもうれしく思います。謙虚な姿勢を保ち、熱心に続けてください。

翻訳チーム採用情報

仕事内容：厳選された外国語記事を流暢な中国語に翻訳する細心の注意が必要です。データサイエンス/統計/コンピュータを学ぶ留学生、海外で関連する仕事に従事している方、または外国語の運用能力に自信のある友人がいる方は、翻訳チームへの参加を歓迎します。

ボランティアの翻訳レベルを向上させるための定期的な翻訳トレーニング、データサイエンスの最前線に対する意識の向上、海外の友人と国内技術応用の開発について連絡を取り合うことができる、THUのデータベースの産学連携の背景などが得られます。 -調査研究はボランティアに多大な利益をもたらします開発の機会。

その他のメリット:有名企業のデータサイエンス担当者、北京大学、清華大学、海外の有名学校の学生がすべて翻訳チームのパートナーになります。

記事末尾の「原文を読む」をクリックしてDatapaiチームに参加してください~

重版のお知らせ

転載する場合は、記事冒頭の目立つ位置に著者と出典を明記し（出典：Datapi ID：DatapiTHU）、記事末尾に目を引くQRコードを設置してください。オリジナルロゴ記事をお持ちの場合は、連絡先メールアドレスに[記事名 - 承認する公式アカウント名とID]を送信し、ホワイトリスト承認申請を行い、必要に応じて編集を行ってください。

「原文を読む」をクリックして組織を受け入れてください