データ操作の理解（メタデータについて話すときに何について話しているのか）

メタデータについて話すとき、何について話しているのか

メタデータは、テーブルの名前、フィールド、タイプ、および説明です。データ資産の主題はメタデータです。では、メタデータについてどれくらいご存知ですか?

製品の観点から個人的に定義すると、データ管理は主にメタデータ管理の概念に焦点を当てています。データガバナンスとの違いは何ですか?データ管理とデータガバナンスを個人がどのように区別するかについては、後ほど詳しく説明します。

同時に、ここで紹介するメタデータは主に開発プロセスのためのものです。メタデータが資産化され、データ コンシューマー向けになる場合については、後ほどデータ操作セクションでデータ マップを紹介するときに詳しく説明します。

メタデータ、データに関するデータ。この概念に初めて遭遇した場合、標準的な説明方法は混乱を招く可能性があります。野菜市場の例などの例を使用する人もいます。各料理の価格、産地、製造時期などが記載されています。

大まかに言えば、メタデータはスキーマ情報です。さらに進むと、テーブル名、フィールド、タイプ、説明があります。これは理解しやすいですが、もちろん少し大まかです。

ここでもう一歩進んでみましょう。メタデータはデータ資産にアップグレードされる場合もあります。個人的には、本体はやはりメタデータだと理解しています。メタデータに管理属性とビジネス属性が追加されると、データ資産になります。本質的には依然としてメタデータです。

?私はその不確実性を理解したことが一度もありません。それは単純なものを複雑にする能力でしょうか、それとも複雑な問題を単純化する能力でしょうか?

メタデータが概念的にどのように定義されているかに関係なく、ビッグデータ プラットフォームの製品マネージャーは、その概念を実践する必要があります。ビッグデータプラットフォーム全体の観点から、ビッグデータプラットフォームにおけるメタデータの位置づけについてお話しします。一言で言えば、ビッグデータ プラットフォーム全体はメタデータを中心に構築されています。

データ統合の最初から、統合のソース側とターゲット側でメタデータが必要になります。統合後のデータ開発プロセスにはメタデータが必要です。開発後にデータ サービスを作成する場合にもメタデータが必要です。アドホック クエリ分析にはメタデータが必要です。レポートの表示にはメタデータが必要です。メタデータは、ビッグデータ プラットフォーム内のさまざまなモジュールを連結するために使用できます。したがって、ビッグデータプラットフォームはメタデータを中心に構築されていると言えます。

簡単に言えば、メタデータはスキーマであり、メタデータは非常に重要です。では、ビッグデータ プラットフォームではどのようなデータ ソース メタデータを管理する必要があるのでしょうか?

まず、ビッグデータ プラットフォームの主な目的の 1 つはデータ ウェアハウスの構築であるため、データ ウェアハウスに対応するメタデータを管理する必要があります。データ ウェアハウスが HIVE であるか Alibaba のような Maxcomputer であるかに関係なく、ビッグ データ プラットフォーム上で統一的に管理する必要があります。アーキテクチャ内にレイクとウェアハウスの両方がある場合、レイクとウェアハウスのメタデータも統一された方法で管理する必要があります。

その他のタイプについては、ビッグデータプラットフォームの機能が拡大し続けるにつれて、サポートできる開発の種類が増え続け、徐々に他のタイプのデータソースもサポートされるようになります。 MySQL、Oracleなど。テキストやkakfaなどにも製品レベルでスキーマが与えられており、グローバルメタデータ管理という名前が付けられているものもあります。

テキスト、Kafka、スキーマ構造を持たないその他のデータを統合的に管理することで、テーブル構造を持たないデータソースに対するインターフェース操作もサポートできるようになります。

含まれるメタデータ管理タイプが増えるほど、他のモジュールへの影響が大きくなり、プラットフォームがより複雑になります。後述するアドホック クエリの場合、管理されているすべてのメタデータをクエリできる必要がありますか?クエリを実行するときにソース間の関連付けを実行する必要がありますか?これは総合的に考慮する必要があることです。全体の流れがスムーズであれば、良いも悪いもありません。

ほとんどの場合、メタデータは基盤となるデータベースに既に存在するため、同期が必要です。同期には、オフラインとリアルタイムの 2 種類があります。

オフラインとは、定期的に最新のメタデータを取得するためのスケジュールを作成することを意味します。これにより、更新が多少遅れることになります。

リアルタイムとは、データベース上のログを監視することを意味します。変更が発生すると、プラットフォーム上のメタデータも同期的に変更されます。

しかし、どちらの方法を使用したとしても、メタデータの二重スキンの問題は避けられません。

基礎となるレイヤーと深く統合する方法、つまりメタデータが基礎となるカタログを直接読み取る方法があるようです。メタデータはプラットフォーム上に再度保存されることはありません。しかし、これはより低レベルのものであり、これが私が理解したものかどうかはわかりません。また、前述のグローバルメタデータ管理に直面した場合、どのように対処すればよいのでしょうか?これらについては高度な研究を行っていないので、さらに学ぶ必要があります。

メタデータの同期に加えて、ビッグデータ プラットフォーム上でメタデータを直接作成することもできます。作成形式には 2 種類あり、その 1 つがスクリプト形式です。 1つは魔法使いの形をしています。

スクリプト形式

直接書いてSQLを作成できるテキスト編集ボックスです。この形式はほとんどの開発者に好まれます。毎日のフォームに準拠します。ただし、この作成形式は、標準、指標、コード テーブルなどに適切にバインドすることはできません。

ウィザードフォーム

スクリプト フォームに加えて、ウィザード フォームを使用して、テーブルのようなフォームを使用してテーブルを作成することもできます。このフォームでは、テーブルを 1 行ずつ入力したり、タイプを選択したりする必要があります。この操作は非効率的であり、R&D 担当者の日常的なテーブル作成の習慣と一致しません。プロモーションを使えるかどうかですが、個人的にはある程度抵抗があると思います。

ただし、このフォームは、標準、インジケーター、コード テーブルなどに適切にバインドできます。また、このフォームだけがこの情報をテーブルにバインドできるようです。この部分については、次のセクション「データ計画は本当に実現可能か?」でさらに詳しく説明します。

データ操作編では、データ活用の第一歩である「データを探す」という操作のためのメタデータ表示について紹介します。操作プロセス中の表示形式はライブラリの制限を打ち破り、テーブル情報をより柔軟に表示できます。ただし、開発指向のメタデータ用に別のメタデータ表示インターフェイスが作成されます。このインターフェースは、ライブラリとテーブルの階層ツリーの形式になっており、操作指向のメタデータと一緒に使用できます。これも議論の余地のある点です。

上記はすべて、ライター形式のスキーマに基づいています。つまり、データを書き込むときにスキーマ情報が決定されており、日常生活でもよく使用されます。しかし、データ レイクの普及に伴い、スキーマ オン リードがますます頻繁に登場するようになっています。この形式の核となるのは、データの書き込み時にスキーマ情報が指定されず、データの読み取り時にスキーマ情報が割り当てられることです。既存の製品設計でこのタイプのスキーマに遭遇したことがないため、このタイプのスキーマを使用するシナリオについてはやや懐疑的です。連絡が取れたら後ほど更新します。

上記は、データ管理メタデータ部分についての私の個人的な理解です。

この記事はもともと @数据小隶 によって Everyone is a Product Manager に掲載されました。無断転載禁止

タイトル画像はCC0プロトコルに基づいたUnsplashからのものです

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。