2023-10-28

Data Platformについて - その２

Data Platformといっても、人によってOLTP用なのかOLAP用なのかイメージするものが異なってくると思います。私のバックグラウンドはAnalyticsのエリアではなく、ビジネスアプリケーション開発のエリアとなりOLTPの用途をすぐに想像してしまいます。

Data FabricやData meshといった概念は基本的にOLAP用を想定した概念であると最近理解しました。

AWSのサイトにデータメッシュとは何ですか? - データメッシュアーキテクチャの説明 - AWSという記事があり、DataLake、Data Fabric、Data meshの違いが書かれています。

また、IT Leadersの「データファブリック」「データメッシュ」とは何か？データ統合の最前線を専門家に聞く | IT Leadersも参考になります。

少し先のスケジュールにはなりますがAnalytics用のプラットフォームを作る計画もあるのでどのようなアーキテクチャーが良いのか少し考えています。

自分の過去の経験や先人たちの経験を参考にするとDatalakeの概念自体は間違いではなさそうですが、以下のような課題が発生するようです。

データの沼になる (Data Swamp) - どこに何があるかわからない、無駄なデータが存在する
管理するチームがボトルネックになる - 集中管理しているため、人的リソースが共有リソースとなりコンフリクトが発生する
トランザクションのサポートが弱い - 一貫性、独立性のが保障されない場合が多い
データコピーに伴う処理遅延、複雑性があがる - 複数のソリューションを組み合わせるため、データコピーが必要だったり、インテグレーションが増える

これらの一部を解決するためにData Lakehouseというソリューションも出てきています。

Data Warehouse -> Data Lake -> Data Lakehouseといった歴史をたどっていることは理解できたのですが、何が問題で何が解決されるのかもう少し深堀して理解したいところです。

また、このようなソリューションに加え冒頭のData FabricやData meshの概念ももう少し理解・整理が必要です。

テクノロジーは常に進化しており、OLTP, Analyticsのエリアも例外ではありません。

最新テクノロジーを追い続けるだけでなく、本質を見極めてソリューションを考えて行きたいと思う今日この頃です。

2023-10-01

セマンティックバージョニング 2.0.0

コーディング規約

APIやソフトウェアのライブラリを開発する際にバージョン管理をすることが多いと思います。

バージョン番号のルールを決める際に参考にしたいのがセマンティックバージョニングになります。

以下概要です。

　バージョンナンバーは、メジャー.マイナー.パッチとし、バージョンを上げるには、

1. APIの変更に互換性のない場合はメジャーバージョンを、
2. 後方互換性があり機能性を追加した場合はマイナーバージョンを、
3. 後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。

プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの形式を拡張する形で利用することができます。

さらに詳細を見ていくといくつか気になる点があります。

特にバージョン番号を拡張する識別子、ビルドナンバー（ビルドメタデータ）は使った方が問題が発生した際に調査がしやすくなると思います。

セマンティックバージョニングを適用するソフトウェアはパブリックAPIを宣言しなければなりません（MUST）。

これは外部のアプリケーションやライブラリが使用する機能のことと理解ができるようです。パブリックなWEB APIを作る必要があるわけではありません。

メジャーバージョンのゼロ（0.y.z）は初期段階の開発用です。

これは既に本番稼働している場合はバージョン1.0.0以降からつける必要がありそうです。本番リリース前はゼロから始まるバージョンで管理するということだと思います。

プレリリースバージョンは、パッチバージョンの直後にハイフンとドットで区切られた識別子を追加することで表現してもよいです（MAY）。例：1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92。

本番リリース前のalpha版beta版以外にもrc(Release Candidate)といった命名も当てはまるようです。

ビルドメタデータはパッチまたはプレリリースバージョンの直後にプラス記号とドットで区切られた識別子を追加することで表現してもよいです（MAY）。例：1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85。

これはビルド時の識別子のようです。ビルドした日時などを使うのが良さそうですね。

普段なんとなくバージョン管理をしているケースもあると思いますので、その場合は上記を参考にもう少しルールを明確にすると開発時のコミュニケーションが円滑になるかもしれません。

参考リンク：

セマンティックバージョニング 2.0.0 | Semantic Versioning

SemVer（セマンティックバージョニング）：Dev Basics／Keyword - ＠IT

Semantic Versioning おさらい | DevelopersIO

2023-09-29

Data Platformについて - その１

Data Management

Master Data Management patterns以外にもData Platformそのものを統合型にするのか分散型にするのかを考える必要がありました。

Data Platformといっても人によって定義は異なるかもしれませんが、ひとまず１つの企業でデータを統合管理する想定でその受け皿となる基盤というイメージで考えています。

「クラウドでデータ活用！データ基盤の設計パターン」では以下の３つに定義されています。

	データレイク型	統合型	分散型
柔軟性・拡張性	◎	△	〇
コスト	〇	△	◎
難易度	△（難しい）	◎（簡単）	△（難しい）
サイロ化への対応	◎（簡単）	◎（簡単）	△（難しい
ビッグデータ対応	◎	△	〇

統合型は１つのアナリティクス製品で基盤を統一するということで、分散型は複数のアナリティクス製品が混在するというイメージのようです。統合型・分散型はレガシー的な構成と書いてありますが、選択肢にならないわけではないとのことなので単純にデータレイク的な考え方ではないという意味だと思います。

上記の場合は少し製品依存の考え方？な気がするので、もう少し概念的なところから検討するために「大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス」などを参考にしながら、将来的にはアナリティクス用途以外にも使える基盤の設計をしていく必要があると考えています。

また、Data FabricやData meshといった表現で統合型・分散型について検討されているケースもあり、Data Platformについてはベストプラクティスは無さそうです。

自分たちで試行錯誤しながら世間の動向をみて調整していく必要がありますね。

参考図書：

クラウドでデータ活用！データ基盤の設計パターン

Amazon

大規模データ管理 ―エンタープライズアーキテクチャのベストプラクティス

Amazon

参考リンク：

Data Fabrics for Big Data | Transforming Data with Intelligence

How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh

Data Fabric: How to Architect Your Next-Generation Data Management | Transforming Data with Intelligence

2023-09-26

Master Data Management patterns

Data Management

近々Data Managementの領域に足を踏み込むことになり色々調べている中で、今更ながらMDM (Master Data Management)について少し思ったことを書いておこうと思います。

Gartnerの定義によると

Master data management (MDM) is a technology-enabled discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, semantic consistency and accountability of the enterprise’s official shared master data assets. Master data is the consistent and uniform set of identifiers and extended attributes that describes the core entities of the enterprise including customers, prospects, citizens, suppliers, sites, hierarchies and chart of accounts.

となっています。企業の中で統一されたマスターデータをビジネスとITが一丸となって管理するための規律ということでしょうか。

マスターデータといっても企業によってかなり異なってきますが、顧客、見込み客、商品などは共通のマスターデータになってくるのではないかと思います。

ある程度の企業規模になると、これらのデータが様々なシステムに分散されて管理されており、統合されたマスターがないと顧客に均一的なサービスを提供することが難しくなったり、データの不整合でシステム障害が発生することも考えられます。

ではどのようにデータを統合管理するのかというと、システムが１つしかない場合はそのなかでデータが重複せず品質も均一になるようにすれば良いのでしょうが、多数のシステムにまたがっている場合はいくつかパターンが考えられます。

ガートナーの資料では４つのパターンが挙げられており、様々な企業や個人がこれについて触れています。(例１、例２)

Consolidation
Registry
Coexistence
Centralized

過去に担当したシステムの場合は、元のコンセプトは1. Consolidationだったところ、結局は様々なシステムが相互にデータをやり取りする形になり3. Coexistenceのパターンになっていたように思います。

上記４つの中で単純な1. Consolidationや2. Registryだと、BIツールなど分析用途やレポーティング用途にしか使えないので、長期的には3. Coexistenceか4. Centralizedにすることになると思います。

Coexistenceと4. Centralizedの違いはMaster Data (Golden record)が集中管理されているか、分散管理されているかだけの違いのように見えますが、4. Centralizedにするとかなり強力なコントロールができるようになる半面誰がデータオーナーになるのかや、アプリケーションの実装が複雑になるといった懸念が考えられる気がします。

そうなるとやはり現実的なオプションとしては今の所3. Coexistenceが良いのではないかと考えます。

今後もう少し深堀した際にもっと良いアイデアが出てくるかもしれませんので、その際に別途投稿してみようと思います。