大規模データ管理 2022-12-11

大規模データ管理メモ

ただ読むだけでは忘れてしまうので、雑にメモを記録していく試み

1章 データ管理の崩壊

1.1 データ管理

この本では「データ管理」の定義を、「データを管理するために必要なプロセスや手順」のことを指している。
DMBOKをベースにし、データ管理を適切時実行し、データを効率的に利用し、コントロールすることによってデータ管理型の組織を目指すべきである。
やはりデータはあるだけでは意味がないという話。

データ管理のためには様々な方法論・考え方があり、多くの領域にまたがる。

• これは自身の考え
  • ソフトウェアアーキテクチャ
  • データセキュリティ
  • ネットワーク
  • 分散システム
  • データアナリティクス・ビジュアライゼーション

この本ではソフトウェアアーキテクチャと密接に関連するものもあるが、この本で取り上げるのは最新のデータアーキテクチャを管理する上で関連度が高いものを取り上げる。（ここの表現が若干わからなかったので、振り返りたい。）

DMBOKの中でもっとも、多く作業が必要であるとされる領域は、「データ統合と相互運用性」である。
「データ統合」とは、「あるコンテキストから別のコンテキストにデータを効率的に移動させることを目的に、データの移動や、収集、統合、結合、変換などを行うためのすべての考え方・行動」
ここでいうコンテキストとは、データの所在もあれば、データに対するユースケースの違いでもあると思う。

• データの所在
  • S3->Redshiftなど
• データに対するユースケース
  • BIで可視化をするのか
  • 機械学習をするのか
    「相互運用性」とは「アプリケーション間で、アプリケーションの特徴をほとんど知らなくても、通信や、機能の呼び出し、データの転送ができることを指す」
    これはそのままの意味としてとらえられるものの、「特徴をほとんどしらなくても」というのは組織によって知らなくていいレベルが変わってくるので、組織のあり方によりより適切な状態は考えなくてはいけないと思う。（APIが良いのか、直接データベース接続するのが良いかなど）

この「データ統合と相互運用性」はメタデータ管理と十分に結びついていない。と記述がある。
これは本来メタデータも「データ」自体と同様に複数のアプリケーションにおいて、相互に運用される（できる）べきである。なぜならデータの利活用を促進するためにはメタデータの適切な活用が必要であるから。だが、メタデータの取得もとには多くあり（ツール、アプリケーションなど散在）、それらを統一的に管理し運用するすべはおおくは語られていない。

これは実際に非常に痛感している。データを統合するすべは統一的になりつつあるが、各々がもつメタデータ自体はそれぞれのシステムに対して独自の仕組みを現状は用意する必要がある。（必要とされる情報は類似しているにも関わらず）

筆者が懸念していることとして、多くの組織は「セマンティクスを統一し、エンタープライズ規模の一貫性を確保しようとするこころみ」

このセマンティクスに対する意味がいまいち分からなかったが、おそらく「データの意味」みたいな解釈で良いと思う。
要は「データに関しての意味を統一して、どこの箇所で見たとしてもその意味を一貫して見れる状態を確保しようとする試みにたいして懸念がある」のではと考えている。
ただしデータは様々なコンテキストのもと生成される。例えば、集計の目的や、利用の目的によりデータの生成は変わってくる。そのため、ほんとうの意味で一貫性というものは担保できないはず、ということなのか？
ここに関しては次の章で深掘りされるらしいので一旦おいておく。

多くの組織で見られるのはデータを中央集権的な組織・仕組みで管理をするという考え方
これは日本では少なくともほぼすべての企業で行われていると思う。
一方で、中央集権化された仕組みはトレンドの変化に弱い、という問題があるとのこと。
中央集権化=仕組みが巨大になる・ステークホルダーが多くなる
などで、どうしても柔軟な変化が難しいということだろう。
うーん、この本の筆者的にコンテキストが大きく異なったり組織の構造・考え方が大きく異る会社に対して、中央集権的な仕組みはやめようね、ということを促したいのか？
ここもこの後の掘り下げで確認していく。

1.2 分析によるデータランドスケープの細分化

非常にインパクトのあるトレンドは、アドバンストアナリティクス

アドバンストアナリティクスってなんだ？
https://www.sisense.com/glossary/advanced-analytics/
ざっくりいうとデータを可視化・見るだけではなく、ML・AIを利用し、そこから意思決定までを自動化する方法、とのこと。
データを使った意思決定には究極的には意思はいらないだろう、というようなはなし？
意思を入れることにより、どうしても速度が劣ってしまうため、不必要な領域にはアドバンストアナリティクスを利用したより高速で効率的な意思決定が望ましい、と受け取った。

データベースの多様化や進化、アドバンスドアナリティクスの発展に伴い、データの急増とデータ集約という問題が生じている。
アドバンスドアナリティクスなどを達成するためにはDBだけでは実現できない、つまりどこかにデータをエクスポートする必要がある（とくにRDMSは汎用的なDBであるため）。
そうするとデータの所在は多岐にわたり、どのデータがどこから来ているのかなどが不明になる。

1.3ソフトウェアの提供速度の変化

昨今のソフトウェア開発ではDevOpsのような考え方や、1つのアプリケーションであっても複数のサービスに分割するというマイクロサービスのような考え方が広がってきた。
これはそれぞれが、自律的にあかつサービスは小さい方がより柔軟性がまし、ということではある。
しかし一方でデータで考えたときに様々な箇所にデータが点在していたり、整合性の問題など多くの考慮すべき問題が発生する。モノリスのときよりも設計時に考慮する箇所が多くなっている。
これもあとの章でより掘り下げられる。

1.4 ~1.7

• ネットワークの転送速度の高度化

  • これにともない、使いたい場所にデータをデリバリーするという考え方がでてきた
    • BQ, Athena, Snowflakeなどが近い考え方？
    • プラットフォーム的な考え方もあれば3rd partyデータ利用の話もあると思う
  • 使いたいときに使いたいデータをもっていく
    • これまでは使いたい場所にデータを配置する
      • DWHに使いたいデータを取り込む、というような考え方
  • この考え方自体はなるほど、と思いつつも論理的にはあまり変わらないような気もする。
  • 考え方としてもっておきつつ

• データガバナンスの重要性

  • 法規制の強化や、リモートワークの広がりに伴い拡大
  • どこからデータが来て、どこに流れているのかを正しく管理できる必要がある
  • データをどう守るか？という防衛的な視点はあまり語られない
  • また規制というのは開発とは相反してしまう