ETLの理解

第2章 データ変換 データの変換

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

データ取り込みが単にデータをA地点からB地点に転送するだけであるのに対して、データ変換はデータライフサイクルの様々な段階を通じて生データを価値ある洞察に変える。この章では、データ実務者がデータ変換を実行するために利用できる多様な言語、プラットフォーム、テクノロジーについて掘り下げていく。

ここでは、データ変換を効率的かつうまく座標調整された方法で確実に行う方法について説明し、効率性、スケーラビリティ、可観測性について、このガイドの後半でより詳しく説明するための土台を作る。

データ変換とは何か？

データ変換とは、ユーザやプロセスをより良くするためにデータを操作し、強化する技術である。変換には、生データであれ、ほぼ原始的な状態であれ、あるデータを取り込み、それを使用目的に近づけるために1つor多くの演算子を実行することが含まれる。ETLパイプラインでは、変換は一つではなく、多くの場所で行われる。データは取り込まれた時点で変換されるかもしれないし、下流のいくつかの点で再度変換されるかもしれない。データ変換の目的は、データを資産に変えることであり、分析とサイエンスを駆使してビジネスにとって価値あるものを作成することである。

変換は、例えばフィルタリングのように不要なレコードを削除するような単純なものから、ソースデータを完全に再構築するような複雑なものまである。データを変換する方法はほぼ無限であり、それが物事を面白くしている！

同様に、変換はクラウド・プロバイダー、サーバ、ソースの枠にとらわれず、どんな言語でも、どんなテクノロジーでもオーケストレーションできる。これは、振り付けされたSparkジョブ、Lambda関数、SQLワークフローとして現れるかもしれないし、Python、JavaScript、Rust、Scala、R、または（息を止めて）スプレッドシートであろうと異なるものかもしれない。我々は、馴染みのある一般的な言語を選ぶことを提唱しているが、データを「変換」する習慣がどこにでもあることに触れないのは不注意だろう。

この章では、トランスフォーメーションとは何か、そして実務者としてデータをどのように変換するのかについて概観する。そして、データの変換と更新の一般的なパターンから始まり、ストリーミング変換のベストプラクティスと考慮事項へと続く、変換ソリューションの構築について説明する。我々の目的は、効率的なトランスフォーメーション・システムを構築するための一連の検討事項を提供し、この知識を独自の問題に適応させるためのツールを提供することである。

我々は今どこにいるのか？

進化し続けるデータエンジニアリングの世界において、データ変換の歴史は成長、簡素化、適応の物語である。インターネットの黎明期には、GoogleやYahooのような巨大企業が先駆者だった。彼らはHadoopやMapReduceのようなビッグデータ・フレームワークでイノベーションを起こした。しかし、これらのテクノロジーは、大学院レベルの線形代数よりも少し複雑であったに過ぎない。

業界が成熟するにつれ、ツールは簡素化され、民主化された。Sparkが登場し、Python、SQL、ScalaのAPIを備えた合理的な分散エンジンを提供した。ほどなくして、Sparkのデプロイを簡素化することを使命とするDatabricksが登場した。同時に、データウェアハウスがジムを襲った。BigQuery、Redshift、Snowflakeが拡張可能なテクノロジーとして登場し、最終的にはストレージとコンピュートを分離した。Presto、Trino、Athenaがこの争いに加わり、電光石火のクエリパフォーマンスを提供し、SQLをビッグデータ言語に拡張した。 ...