「5層データスタックの構築方法」

5層データスタックの構築方法

データプラットフォームを立ち上げることは複雑である必要はありません。スケールでデータ製品の採用を促進するために必要な5つのレイヤーを紹介します。

豆ディップやオーガと同様に、レイヤーは現代のデータスタックの構成要素です。

強力なツールコンポーネントの選択により、各レイヤーがデータパイプラインのユニークな機能を提供することで、一元化された拡張可能なデータプラットフォームが作成されます。

ただし、クラウドデータプラットフォームはおとぎ話ではありません。新しいツールや統合はほぼ毎日作成され、それを強化するための取り組みが行われています。

したがって、無限に拡大する統合とデータの動きの各機能や機能に新しいレイヤーを追加する機会があるという問題が生じます。どこから始めますか？あるいは、異なる言い方をすれば、複雑すぎて管理しきれないプラットフォームを構築することなく、ステークホルダーに実際の価値をもたらすデータプラットフォームを提供するにはどうすればよいでしょうか。

• 「人工知能による在庫管理の革命：包括的なガイド」
• 「データサイエンティストが読むべきトップ7のNLP（自然言語処理）の本」
• 「データサイエンスにおける頻度論者とベイズ統計学」

初めてクラウドネイティブのプラットフォームを構築する小規模なデータチームや、オンプレミスからの移行を行うチームにとっては、ビジネス成果に最も直接的な影響を与えるレイヤーにバイアスをかけることが重要です。

この記事では、Five Layer Data Stackをご紹介します。これは、プラットフォーム開発のためのモデルであり、ビジネスのニーズに合わせて成長することができる5つの重要なツールから構成されています。これらのツールには以下が含まれます：

• クラウドストレージとコンピューティング
• データ変換
• ビジネスインテリジェンス
• データ可観測性
• オーケストレーション

オーガや豆ディップについてはもう言及しません。

それでは、本題に入りましょう。（豆ディップではなく）コンテンツに。

クラウドストレージとコンピューティング

データツールやパンケーキを積み上げる場合、常に下から上に構築します。良いスタックのように、適切な基盤はデータプラットフォームの構造と機能の整合性を保証するために重要です。

ステークホルダー向けにデータをモデル化する前に、データを収集し保存する場所が必要です。スタックの最初のレイヤーは一般的に次の3つのカテゴリのいずれかに属します：主に構造化データを処理するSnowflakeのようなデータウェアハウスソリューション、より大容量の非構造化データに重点を置くデータレイク、および両方の要素を組み合わせたDatabricksのLakehouseのようなハイブリッドソリューション。

ただし、ここでは単にデータを保存する場所ではありません。ストレージソリューションは、クラウドデータスタックにおいて他のレイヤーの計算能力の主要なソースでもあります。 (同僚のシェーンによるストレージとコンピューティングをカップリングするか切り離すかの適切なタイミングについての詳細はこちらをご覧ください)。

今、データウェアハウス、データレイク、Lakehouseなどのメリットについて詳しく説明することもできますが、それはここでは本当に重要ではありません。重要なのは、現在と将来のプラットフォームのニーズに適合し、財務チームに受け入れられるリソースコストである解決策を選択することです。また、将来的に接続できるツールやソリューションを決定し、新しいユースケースに合わせてデータスタックを最適化するための手段を提供します。

必要な具体的なストレージとコンピューティングソリューションは、ビジネスのニーズとユースケースに完全に依存しますが、私たちの推奨は一般的なもの（Snowflake、Databricks、BigQueryなど）を選択し、サポートが充実しており、容易にスケーリングできるものです。

オープンソースは常に魅力的な解決策ですが、実際に必要とするスケールレベルに達していない限り、ストレージとコンピューティングレベルでのスケーリングにいくつかの重大な課題が生じる可能性があります。私たちの言葉を信じてください、最初に管理されたストレージとコンピューティングソリューションを選択することは、多くの頭痛と（おそらくは痛ましい）移行を防ぐことになります。

データ変換

では、データはクラウド上に存在する必要があります。理解できました。データプラットフォームには他に何が必要ですか？Five Layer Data Stackの第2レイヤー、変換を見てみましょう。

データが最初に取り込まれるとき、さまざまな形やサイズで提供されます。異なる形式、異なる構造、異なる値があります。単純に言えば、データ変換とは、さまざまな異なる形式のデータを一貫性のあるものに変換し、モデリングに役立つ形にするプロセスを指します。

伝統的に、変換は手動のプロセスであり、データエンジニアがCLI内で各パイプラインを手作業でハードコードする必要がありました。

しかし最近では、クラウド変換ツールがデータモデリングプロセスを民主化し始めています。データパイプラインをよりアクセスしやすくするために、dbt Labs、Preql、Dataformなどの自動化されたデータパイプラインツールを使用することで、ユーザーはコードを一切書かずに効果的なモデルを作成することができます。

dbtなどのツールでは、「モジュラーSQL」と呼ばれるものを使用して、一般的な、事前に書かれた、最適化されたSQLコードのプラグアンドプレイブロックからパイプラインを構築します。

クラウドデータの旅を始めると、データをモデル化し、データの利用者に価値を提供する新しい方法をすぐに見つけることでしょう。財務やマーケティングからの新しいダッシュボードの要求に対応します。既存のモデルに導入する必要のある新しいソースを見つけます。機会は急速かつ猛烈に訪れます。

データスタックの多くのレイヤーのように、自分自身の変換をコーディングすることは小規模なスケールでは機能します。しかし、成長し始めると、変換を手動でコーディングすることはデータプラットフォームの成功におけるボトルネックとなります。競争力を維持し、異なるドメイン全体で新たな価値を提供し続けるために、既製のツールを投資することはしばしば必要です。

しかし、自分自身の変換をコーディングすることだけが手間になるわけではありません。スケーリングに必要なケースをカバーするために十分な変換をコーディングできたとしても、変換が壊れた場合にはどうなるでしょうか？1つの壊れたモデルを修正するのはたぶん大したことではありませんが、100個のモデルを修正することは夢物語です。

スケーリング組織のための改善されたバリュータイム

dbtのような変換ツールは、拡大するエンジニアリングチームや開発者チームにとって、複雑なモデルの作成と管理をより迅速かつ信頼性の高いものにします。データエンジニアに制限されがちな手動のSQLコーディングとは異なり、dbtのモジュラーSQLを使用することで、SQLに精通した人であれば誰でも自分自身のデータパイプラインを作成することが可能です。これにより、忙しいチームにとってより早いバリュータイム、エンジニアリングの負担の軽減、そして場合によってはプラットフォームを前進させるための専門知識への需要の軽減が実現します。

変換シーケンスの実験の柔軟性

自動化されたクラウド変換レイヤーは、パイプラインの異なるステージでデータ変換を行うことができるため、ETL、ELT、そしてその間のすべてを実験する柔軟性を提供します。プラットフォームが進化するにつれて、異なる方法でデータ変換を試すことができます。

セルフサービス機能を可能にします

最後に、オペレーショナライズされた変換ツールは、将来的には完全なセルフサービスアーキテクチャの道を開拓するための基盤を提供します – もしその道を選択することを選ぶのであれば。

ビジネスインテリジェンス（BI）

変換が第2レイヤーであれば、ビジネスインテリジェンスは第3レイヤーである必要があります。

データプラットフォームのツールとしてのビジネスインテリジェンスは、特定のユースケースを満たすためにエンドユーザーに提供する分析機能を指します。私たちのデータは外部の製品に供給される場合もありますが、ビジネスインテリジェンス機能はほとんどのチームにとって主要なデータ製品です。

Looker、Tableauなどのビジネスインテリジェンスツールや様々なオープンソースのツールは、複雑さ、使いやすさ、機能セットによって大きく異なるかもしれませんが、これらのツールは常にデータの視覚化を通じてデータ消費者が洞察を得ることを支援する能力を共有しています。

これはかなり自明です。スタックの他のすべてが目的に向かう手段であるのに対して、ビジネスインテリジェンスはしばしばそれ自体が目的です。

ビジネスインテリジェンスは、データスタックの中心にある消費可能な製品であり、クラウドデータプラットフォームにおいて不可欠な価値ドライバーです。企業がデータを作成し消費する意欲が高まるにつれて、データに迅速かつ簡単にアクセスする必要性も同様に高まります。

ビジネスインテリジェンスツールは、ステークホルダーがデータプラットフォームから価値を抽出することを可能にします。データを活性化し消費する方法がなければ、どれだけ多くのレイヤーがあっても、クラウドデータプラットフォームの必要性はありません。

データの可観測性

平均的なデータエンジニアリングチームは、おおよそ1週間に2日間を悪いデータの対処に費やしています。実際、ガートナーの最近の調査によると、悪いデータは組織に平均して年間1290万ドルのコストをかけています。その財務リスクを緩和し、プラットフォームの信頼性を保護するために、第4レイヤーであるデータの可観測性が必要です。

データ観測性の前では、データ品質の問題を発見する最も一般的な方法の1つは、手動のSQLテストを通じてでした。Great Expectationsやdbtなどのオープンソースのデータテストツールを使用することで、データエンジニアはデータに関する組織の仮定を検証し、問題が下流に伝わるのを防ぐためのロジックを作成することができました。

データ観測性プラットフォームでは、生産テーブル全体にわたる新鮮さ、ボリューム、スキーマ、ヌル率などの品質チェックを自動的に生成するために、手動のコーディングではなく機械学習を使用します。包括的な品質カバレッジに加えて、良いデータ観測性ソリューションは上流および下流の依存関係に基づいて、どこで問題が発生し、何が影響を受けたかを迅速に特定するためのテーブルおよび列レベルの系譜も生成します。

データプラットフォームの価値、およびそれに関連する製品の価値は、それに供給されるデータの品質と不可分です。ゴミを入れればゴミが出ます。（または破損したインジェスションジョブがある場合は何も出ません。）信頼性のある、実行可能な、有用なデータ製品を持つためには、基礎となるデータを信頼できるものにする必要があります。データを信頼できなければ、データ製品も信頼できません。

残念ながら、データが増えるにつれて、データの品質の問題も同様に増えます。プラットフォームが複雑になるほど、インジェストするソースが増えるほど、サポートするチームが増えるほど、品質の問題が発生する可能性が高くなります。また、チームがデータを利用してAIモデルやMLのユースケースを活用するにつれて、その信頼性と信頼性を確保する必要性は指数関数的に増大します。

データテストは一部の品質カバレッジを提供するかもしれませんが、その機能は既知の問題と特定のテーブルに限られています。また、各チェック手動テストは手動でコーディングする必要があるため、スケーラビリティは利用可能なエンジニアリソースに比例するだけです。一方、データ観測性は自動的にすべてのテーブルに対してプラグアンドプレイのカバレッジを提供するため、既知の品質インシデントや未知の品質インシデントが下流の利用者に影響を与える前に警告が発生します。また、プラットフォームとデータがスケールするにつれて、品質カバレッジもスケールします。

さらに、データ観測性はBIレイヤーまでのエンドツーエンドの系譜を提供するため、品質インシデントの根本原因を特定し、解決することが可能です。これにより、データチームにとって何時間もの時間が節約されることがあります。手動テストは一部の品質インシデントをキャッチすることができるかもしれませんが、それらを解決するのには役立ちません。データチームの解決までの時間は、年々ほぼ倍増していることに気づくとさらに驚くでしょう。

データテストは本質的に反応的な性質であるのに対して、データ観測性は既知および未知の問題に対してプロアクティブな可視性を提供し、リアルタイムでパイプラインの系譜の記録を提供することで、チームの時間やリソースを犠牲にすることなくデータプラットフォームを成長させるための位置づけを可能にします。

データオーケストレーション

分析のためのデータの抽出と処理を行う際には、操作の順序が重要です。すでに見てきたように、データは単にデータスタックのストレージレイヤー内に存在するわけではありません。一つのソースから摂取され、別の場所に格納され、そして変換および可視化のために別の場所に運ばれます。

最も広範な意味で、データオーケストレーションは複数のタスク（一部は自動化されている場合もあります）を単一のエンドツーエンドのプロセスに構成することです。これは、データが予測可能な方法で正確なタイミングで、正しいシーケンスで、適切な速度でプラットフォーム全体を通じて流れるようにするために、重要なジョブがいつ、どのようにアクティブ化されるかをトリガーします。（まるでデータ製品のためのコンベアベルトのようなものです。）

ストレージや変換とは異なり、パイプラインには機能的にオーケストレーションが必要とされるわけではありません。ただし、データプラットフォームがある一定のポイントを超えてスケールすると、ジョブの管理は自社基準ではすぐに扱いにくくなります。

データの少量の抽出と処理を行う場合、ジョブのスケジュールには少ない努力しか必要ありません。しかし、複数のソースから非常に大量のデータを抽出し処理し、無数のユースケースに使用する場合、それらのジョブのスケジュールには非常に多くの努力が必要となります。人間の努力では対応できないほどです。

オーケストレーションが5層データスタックの機能的な必要性となる理由（文字通りでなくても）は、ハンドコードされたパイプラインのスケーラビリティの欠如にあります。変換やデータ品質と同様に、スケジュールやパイプラインの管理においてエンジニアリソースが制約要素となります。

現代のデータスタックの多くが可能にする美しいところは、エンジニアリソースの制約を解消するツールや統合を可能にすることで、エンジニアが組織に新たな価値を提供できるようにすることです。これらが自己正当化するツールです。まさにそれがオーケストレーションが行うことです。

組織が成長し、データごとに自然にシロができ始めると、オーケストレーション層が整備されていることで、データチームはデータソースの管理を続け、ドメイン間で価値を提供し続けることができます。

データオーケストレーションの最も人気のあるソリューションには、Apache Airflow、Dagster、そして比較的新しいPrefectがあります。

最も重要な部分は何か？影響力とスケールのために構築することです

もちろん、5つは魔法の数字ではありません。優れたデータスタックは6層、7層、または57層を持つかもしれません。そして、それらの潜在的なレイヤーの多くは、組織の段階とプラットフォームに応じて、ガバナンス、契約、さらにはいくつかの追加のテストなど、非常に有用です。

ただし、始めたばかりの時点では、現代のデータスタックで利用可能なプラットフォームツールのマリアナ海溝を煮詰めるためのリソース、時間、さらには必要なユースケースがありません。さらに、新しいレイヤーごとに、新しい複雑さ、新しい課題、そして正当化する必要がある新しいコストが導入されます。代わりに、データの潜在能力を実現し、近い将来の企業の成長を推進するために、最も重要なことに焦点を当ててください。

上記で言及された各レイヤー（ストレージ、変換、BI、データの可観測性、およびオーケストレーション）は、近い将来のプラットフォーム、ユースケース、チームの迅速な成長に必要な、最大の影響力を持ち、即座のスケーラビリティを提供する、完全に運用可能なモダンデータスタックの重要な機能を提供します。

データの旅を始めたばかりのデータリーダーで、コストを抑えながらパワーを犠牲にしないスリムなデータプラットフォームを提供したい場合は、5層データスタックが最も優れています。

異論はありますか？コメント、質問、または豆のディップレシピについては、LinkedInのBarrに連絡してください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!