まず第一に、あなたの質問は素晴らしいと思います。精神的なプロセスを明らかにする方法で、あなたはすでに答えを持っていると言えます。
あなたが言及するように
データ レイクの一般的なルールは、取り込み段階で前処理を行わないように思えます。
これは哲学的な結論であり、誇大広告はすべて、この簡単に単純化しすぎたアイデアをめぐって拡大しています。
データレイクとは何かというAWSの定義を確認すると.
データ レイクは、すべての構造化データと非構造化データをあらゆる規模で保存できる集中型リポジトリです。最初にデータを構造化することなく、データをそのまま保存し、ダッシュボードや視覚化からビッグデータ処理、リアルタイム分析、機械学習まで、さまざまな種類の分析を実行して、より良い意思決定を導くことができます。
基本的な定義ですが、「権威へのアピール」として使いましょう。彼らは、データを「そのまま」保存できると明確に言っています。
- 私の最初の質問は、「できる」というのは、厳密には「すべき」という意味ですか? また、「ダッシュボードやビジュアライゼーションからビッグデータ処理まで、さまざまな種類の分析を実行できる」などと述べています。
- 私の2番目の質問は、データが実際に何かに対して故意に不安定である場合...とにかくそこにダンプすることは合法ですか?
同じリンクで、少し下にもあります
データ レイク アーキテクチャの主な課題は、未加工のデータがコンテンツを監視することなく保存されることです。データレイクでデータを使用できるようにするには、データをカタログ化して保護するためのメカニズムを定義する必要があります。これらの要素がなければ、データを見つけることができず、信頼できず、結果として「データの沼地」になります。より幅広いオーディエンスのニーズを満たすには、データ レイクにガバナンス、セマンティックの一貫性、およびアクセス制御が必要です。
一般的に、私の見方では、「前処理なし」というルールに従うためにすべてを投入することは、法王よりもカトリック的であろうとする一般的な試みであるか、またはルールを過度に単純化する一般的な傾向であると考えています。 「現状のまま」の可能性があり、その力は、将来起こりうるすべてのユースケースが本当にわからないことを前提として、データのフィルタリングや変換をインジェクションで行わない方向に向かうため、生データを持つことはしかし、データが破損していることがわかっているからといって、それが良いというわけではありません。
これは次の考えにつながります。非常に繰り返されるアイデアの 1 つは、データ レイクでスキーマ オン リード ( AWS、Intuit、IBM、O'Reilly ) が可能になるというものです。そのため、それを使用する可能性のあるすべての人の生活を過度に複雑にしたくない場合は、何らかのスキーマで可能な限り何かを保持することは理にかなっています。それを使用するオーバーヘッドは落胆する可能性があります。実際、上記の「読み取り時のスキーマの死」と呼ばれる O'Reilly の記事では、ガバナンスの欠如によって追加された複雑さが正確に述べられています。したがって、混沌を取り除くことがデータレイクの成功に役立つと思います。
これまでのところ、私の立場は自分自身にとって非常に明確だと思います-私が応答を書き始めたときはそれほどではありませんでした-しかし、最新の参考文献で締めくくろうとします。それは私が何度か読んだ記事です. 早ければ 2014 年に gartner.com のプレス ルームで公開された、「データ レイクの誤謬に注意してください」と呼ばれています。記事全体は非常に興味深いですが、この部分を強調します
したがって、データレイクにはかなりのリスクが伴います。最も重要なのは、データの品質や、レイク内の同じデータを使用して以前に価値を見出した他のアナリストやユーザーによる調査結果の系列を判断できないことです。その定義によれば、データ レイクは監視やガバナンスなしであらゆるデータを受け入れます。記述的なメタデータとそれを維持するメカニズムがなければ、データ レイクはデータの沼地になる危険性があります。
私はそれに同意します。最初は楽しいです。すべてを保存し、S3 バケットに値が入力されていることを確認し、Athena または Presto でいくつかのクエリを実行したり、多くの gzip ファイルに対していくつかの Spark ジョブを実行したりして、私たちが生きる魔法の時間にいると感じます。しかし、この小さな汚染が発生し、私たちはそれを受け入れ、いつか S3 バケットは 10 ではなく 100 になり、小さな例外は 2 ではなく 20 になり、覚えておくべきことが多すぎて、物事はどんどん混乱していきます。
最終的には、これは意見に基づいています。でも、使えるデータは、未来の自分をもっと幸せにしてくれると思います。
これを言った、私はあなたのオプションに行きます：
Spark ジョブ X 内の破損したレコードを処理します。それは、あなた自身とあなたのチームを憎み、避けることができる仕事をするように彼らをののしることになります.
ETLレイヤーで破損したファイルを修正し、「固定」レイヤーに保存します。あなたはそれを言いました、オーバーヘッドが多すぎます。最初のレイヤーを削除したくなるでしょう。実際、コストを節約するために、古いオブジェクトを自動的に削除するライフサイクル ポリシーを採用することになると思います。
清楚で誠実そうです。「それはおかしい」とは誰も言えません。確認する必要がある唯一のことは、実際に削除するデータがビジネスに関連していないことと、現在把握できない将来の使用の可能性がないことです。この場合でも、安全にプレイするためにいくつかのアプローチに従います。
- Nifi レイヤーで CSV から最初の 2 つの文字列を削除し、読み取り可能なデータを「生」ストレージ レイヤーに保存します。
- 「これが来るとは思わなかった」というケースから身を守るために、これらの 2 行を削除した単純なファイルを保存するメタデータ バケットを保持し、必要に応じて将来それらにアクセスし、返信できるようにします。将来「あなたはそれを削除すべきではなかった」と言うことができる別の意見を持つ人に。しかし、私がこれを言うのは、これらの 2 つの行が何であるか想像できないからです。
個人的には、データ レイクが大好きで、すべてのシステムの背後にある哲学が大好きですが、すべてをケースバイケースで疑問視することも好きです。フラット ファイル、json、csv に大量のデータがあり、それに基づいた大量の運用ワークロードがあります。しかし、私のデータ レイクの最も美しい部分は、実際には純粋に未処理のデータではありません。最初の最小限のクリーンアップを実行することが非常に強力であることがわかりました。スナッピーで圧縮することさえできます。そして、私はそのデータを使用することを本当に楽しんでおり、直接クエリを実行することさえできます。生データはありますが、使用可能です。