データ品質のレイヤー

データ品質のレイヤー' -> 'Data quality layer

データの問題をどこで、どのように対処するか

Stephen Dawsonによる写真、Unsplash

ジェネレーティブAIやLLMの関心の高まりに伴い、データの品質に対する関心が再燃しました。この領域は大いに助けが必要だったわけではありませんが、Monte Carlo、Soda、Bigeye、Sifflet、Great Expectations、dbt Labsなどの企業が、独自のソリューションからオープンコアまで、さまざまな解決策を開発してきました。これらのソリューションのいくつかは直接の競合他社ですが、すべてが同じ問題に対応しているわけではありません。たとえば、特定の列に一意の値が含まれていることを確認するための明示的なdbtテストを定義することは、メトリックの異常検知(たとえば、通常は5万件のレコードを生成するdim_ordersプロセスがある日に50万件のレコードを生成した場合)とはまったく異なります。データは、壮観で多様な方法で失敗することがあります。

おそらく、データ品質の次元について聞いたことがあるかもしれません。私は特にRichard Farnworthの意見¹が好きですが、クイックなGoogle検索でさまざまな意見が得られます。しかし、本質的には、データはある側面では「正しい」かもしれませんが、他の側面では「間違って」いるという考え方です。データが正確であっても遅ければ価値があるでしょうか?数値が客観的に間違っているとしても、それらが一貫していればどうでしょうか²?これはデータプロダクトの管理と、ステークホルダーの優先事項を特定する重要な側面です。

データの品質の問題のルート原因には、データの形式の不正、欠落、遅延、不完全などがありますが、データの品質問題のルート原因にはあまり注意が払われていません。私たちはデータ自体のテストと観察に非常に多くの時間を費やしており、データを生成、変換、使用するシステムの改善を追求することは少ないです。私は、これらのデータ品質の問題、ソリューション、およびそれらに関連する問題を解決するために関与するべきチームの「レイヤー」を探求したいと思います。

レイヤー1:データの生成

すべてのデータはどこかから来ており、そのソースはデータの品質の問題の根本原因です。ゴミを入れればゴミが出るという原則に従い、低品質なソースシステムのデータから有用なデータプロダクトを作ることはできません。

このレイヤーには、スキーマのドリフト、意味のドリフト、システムの可用性と信頼性という3つの基本的なデータ品質の問題があります。それらはすべて非常に重要ですが、異なるデータ品質の問題を引き起こします。さらに、それらには異なる解決策が必要であり、頻繁に、異なるチームが関与する必要があります…

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

Share:

Was this article helpful?

93 out of 132 found this helpful

Discover more