Froglog

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第8章「データ統合と相互運用性」について。 業務で扱っているデータ基盤はデータ統合が不完全であるため、なんとかしたいと考えている。 以降、特に注釈のない引用は DMBOK2 第8章からの引用とする。 データストレージと相互運用性とは データ統合と相互運用性 (DII: Data Integration and Interoperability) は次のように定義されている。 アプリケーションや組織内および相互間におけるデータの移動と統合を管理する データの移動を効率的に管理することがそのビジネス上の意義となる。 ほとんどの組織には数多くのデータストアがあり、組織内・組織間でデータを移動させることは IT 組織の重要な任務となっている。 複雑さとそれに伴うコストを管理するために、全社的な視点からデータ統合を設計しなければならない。 データウェアハウスなどのデータハブによりアプリケーション間のインターフェースの数を削減することができる。 DII のゴールは以下 法令を遵守しながら、必要とするフォーマットと時間枠でデータを安全に提供する。 共有のモデルとインターフェースを開発することでソリューションを管理するコストと複雑さを軽減する。 重要なイベントを特定し、アラートとアクションを自動的に起動する。 ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする。 概念・用語など 抽出、変換、取込 DII の中心にあるのが、抽出 (Extract)、変換 (Transform)、取込 (Load) のいわゆる ETL という基本プロセス。 抽出 ソースから必要なデータを選択し、抽出する 抽出されたデータはディスク上やメモリ上にステージングされる 業務システムで実行される場合は、少ないリソースを利用するように設計する 変換 ソースデータを変換してターゲットデータストアの構造と互換性を持つようにする フォーマット変更、構造の変更、意味的変換、重複排除、並べ替えなどがある 取込 ターゲットシステムに物理的に格納されるか、提供される ELT ターゲットシステムにより多くの変化機能がある場合は、プロセスの順序を ELT にすることができる データレイクへの取込を行うビッグデータ環境では一般的 レイテンシ ソースシステムでデータが生成されてから、ターゲットシステムでそのデータが利用可能になるまでの時間差。 アプローチによってレイテンシの高低が異なる。 バッチ 利用者や自動的な要求に応えて、定期的にアプリケーションや組織間を一定量まとまって移動させる レイテンシは高いが大量データを処理するときのパフォーマンスがいい 低レイテンシを実現するためのマイクロバッチもある 変更データキャプチャ データの変更 (挿入・変更・削除) のデータセットを監視し、その差分をターゲットのシステムに渡す DBMS のアクティビティログをコピーし、処理する形で行われることもある 準リアルタイムとイベント駆動 設定された予定により1日を通して分割された少量のデータセットで処理されたり、データ更新などのイベントが発生したときに処理されたりする 一般的にエンタープライズ・サービス・バスを利用して実装される 非同期 データ提供側は受信側の更新確認を待たずに処理を続行する リアルタイム、同期 次のトランザクションを実行する前に、他のアプリケーションからの確認を受け取るまで実行プロセスが待機する 非同期と比べて状態管理の負担が少ないが、他のトランザクションをブロックしたり遅延させたりすることもある 低レイテンシまたはストリーミング イベントが発生したときにシステムからリアルタイムで連続して流れる リプリケーション 分析やクエリによるパフォーマンス低下を防ぐために、トランザクション処理環境にリプリケーション (複製) を使用することがある。...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データストレージとオペレーション」について。 主にデータベースの運用に関する内容となっており、いわゆるデータベースエンジニアの人には当たり前の話？が書かれている。 以降、特に注釈のない引用は DMBOK2 第6章からの引用とする。 データストレージとオペレーションとは 以下のように定義されている。 データの価値を最大化するために、永続化されるデータを設計し、実装し、サポートすること 主にデータベース管理者 (DBA: Database Administrators) が行うことになる。 次の2つのアクティビティが含まれる。 データベースサポート: データベース環境の初期実装からデータの取得、バックアップ、廃棄までのデータライフサイクル関連アクティビティ データベース技術サポート: 技術要件を決め、技術的なアーキテクチャを定義し、技術を実装・管理する 事業がデータに依存する企業においてはデータストレージとオペレーションのアクティビティは事業の継続性のために必要不可欠である。 ゴールは次のとおり データライフサイクル全体にわたるデータの可用性を管理する データ資産の完全性を保証する データ処理の性能を管理する 概念・用語など データベースアーキテクチャの種類 集中型データベース: 単一システム内で使うデータを一箇所にまとている 分散型データベース: 多数のノードにデータが配置される 連邦型データベース: 自立した複数のデータベースシステムを単一の連邦型データベースに割り当てる 仮想化／クラウドプラットフォーム: クラウド上のデータベースを実装 データベース処理のタイプ ACID: トランザクションの信頼性のための制約 原子性 (Atomicity): 操作はすべて実行されるかまったく実行されないかのどちらか 一貫性 (Consistency): トランザクションはシステムが定義するすべてのルールを常に満たさなければならない 独立性 (Isolation): 各トランザクションは実行中の他のトランザクションの影響を受けない 永続性 (Durability): トランザクションは完了すると元に戻せない BASE: データの量と多様性を受けた、ACID とは異なる考え 基本的に利用可能 (Basically Available): ノードの障害発生時もあるレベル以上の可用性を保証する ソフトステート (Soft State): データは一定の変動状態にある 最終的な一貫性の確保 (Eventual Consistency): データは最終的にすべてのノードで一貫性を保つが、各トランザクションの一貫性が常に確保されているわけではない CAP: 分散システムでは以下のどれか2つしか満たせない 一貫性 (Consistency): システムは常に想定どおり動作できなければならない 可用性 (Availability): システムは要求時に利用可能でなければならに 分断耐性 (Partition Tolerance): システムは部分的な障害の発生時に運用を続行できなければならない データベース構成 上から順により制御された構造であり、かつ古くからあるものとなっている。...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データモデリングとデザイン」について。 第4章でデータモデリングについて言及されていたが、ここで詳しく見ていく。 以降、特に注釈のない引用は DMBOK2 第5章からの引用とする。 データモデリングとは データモデリングとは、データ要件を洗い出し、分析し、取扱スコープを決めるプロセスであり、データ要件を記述し伝えるために、明確に定義されたデータモデルと呼ばれる様式が用いられる。このプロセスは反復的であり、概念、論理、物理モデルが含まれる。 第4章 データアーキテクチャ ではエンタープライズ・データモデルという言葉が登場したが、この第5章ではそのデータモデルがより具体的に解説されている。 データモデルは効果的なデータマネジメントを行うにあたり必要なものとされている。 次のような意義がある。 データに関する共通語彙を提供する 組織のデータや情報システムに関しての明示的な知識を捉え文書化する プロジェクトにおいて主なコミュニケーションツールとして使われる アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる データモデルは組織が把握した現状、またはあるべき姿として組織のデータを記述する。 カテゴリー情報、リソース情報、業務イベント情報、詳細取引情報がその対象となる。 データモデルの構成要素 ほとんどのデータモデルはエンティティ、リレーションシップ、属性、ドメインにより構成される。 エンティティ エンティティとはある組織が情報を収集する対象のこと。 組織が使う名詞。 以下は Marmaid の Entity Relationship Diagrams でエンティティを表現した例。 学校を例にしており、学生、コース、インストラクタがエンティティとして表されている。 --- title: Entity --- erDiagram Student Course Instructor リレーションシップ リレーションシップはエンティティ間の関連性を表す。 以下の例は学生はコースを “履修する”、インストラクタはコースを “教える” ことを表している。 --- title: Relationship --- erDiagram Student }|--|{ Course : take Instructor }|--|{ Course : teach 線の両端の形はリレーションシップの cardinality (多重度) を表している。 この場合ではそれぞれカラスの足状になっているが、それぞれ「1またはそれ以上」という意味で、「学生は1つ以上のコースを履修する」「コースは1人以上の学生に履修される」ということを表している。 リレーションシップの arity (項数) は一般的には二項型 (バイナリリレーションシップ) であることが多く、2つのエンティティ間の関係を表す。...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第4章「データアーキテクチャ」について。 やや抽象度が高い内容となっており、理解が難しいと感じた。 以降、特に注釈のない引用は DMBOK2 第4章からの引用とする。 データアーキテクチャとは データアーキテクチャの定義は以下のとおり。 企業の (組織構造に関係なく) データニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持する。マスターとなる青写真を使ってデータ統合を手引し、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う。 業務戦略と技術実装の間を橋渡しすることがデータアーキテクチャの目的。 以下が成果物、つまり前述の定義の「マスターとなる青写真」となる。 データの保存と処理の要件 企業の現在のデータ要件と長期のデータ要件を満たす構造や計画の立案 これらを記述するためにエンタープライズ・データモデル (EDM) とデータフロー設計が必要となる。(後述) エンタープライズアーキテクチャ データアーキテクチャとビジネス、アプリケーション、テクニカルなど他の領域のアーキテクチャとの違いは下表のようになる。 それぞれが影響を及ぼし合う関係となっており、データアーキテクチャはビジネスアーキテクチャによって決められる。 ドメイン エンタープライズ・ビジネスアーキテクチャ エンタープライズ・データアーキテクチャ エンタープライズ・アプリケーションアーキテクチャ エンタープライズ・テクニカルアーキテクチャ 目的 企業が顧客や他のステークホルダに どのように価値提供しているかを 明らかにする データがどのように整理・管理されるべきか記述する 企業内アプリケーションの 構造と機能を記述する システムを稼働して価値を 提供するために必要な 物理実装技術を記述する 要素 ビジネスモデル、業務プロセス、業務能力、サービス、イベント、戦略、語彙集 データモデル、データ定義、データマッピング仕様、データフロー、構造化データの API ビジネスシステム、ソフトウェアパッケージ、データベース テクニカルプラットフォーム、ネットワーク、セキュリティ、統合ツール 依存関係 他のドメインに対する要件を設定する ビジネスアーキテクチャによって作られ、要求されるデータを管理する ビジネス要件に基づいて特定されたデータに対応する アプリケーションアーキテクチャを提供し実行する 役割 ビジネスアーキテクトとアナリスト、ビジネス・データスチュワード データアーキテクトとモデラー、データスチュワード アプリケーションアーキテクト インフラストラクチャアーキテクト DMBOK2 表6 アーキテクチャ領域 web 系エンジニア的には「アーキテクチャ」という言葉だけ聞くとクラウドサービスのアイコンを使ってアーキテクチャ図をお絵描きするよくあるアレを想像しがちだが、データアーキテクチャはそれではないということ。 (DMBOK2 の分類ではそれはテクニカルアーキテクチャの領域) エンタープライズ・データモデル (EDM) EDM とは 全体的でエンタープライズレベルの実装に依存しない概念または論理モデルであり、企業全体にわたるデータに関して一貫した共通のビューを提供する。 次の図は概念・論理モデルと物理的なデータモデルとの関係を示す。 垂直方向には対象領域ごとに対応する異なるレベルのモデルが関係している。 水平方向には同じレベルのモデルがあり、対象領域をまたいでエンティティが関係し合う。 DMBOK2 図23 エンタープライズ・データモデル...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第15章「データマネジメント成熟度アセスメント」について。 データマネジメントの導入において重要な役割を果たしそうなので早めに確認しておきたかった。 以降、特に注釈のない引用は DMBOK2 第15章からの引用とする。 データマネジメント成熟度アセスメントとは データマネジメント成熟度アセスメント (DMMA: Data Management Maturity Assessment) はその名の通り、組織のデータマネジメントのレベルの評価に基づくプロセス改善の取り組みのこと。 能力成熟度アセスメント (CMA: Capability Maturity Assessment) というものがあり、それのデータマネジメント版が DMMA。 CMA では 成熟度モデルは進化の観点から定義され、それにはプロセスの特性を表すレベルが使用される。組織がプロセスの特性を理解すると、組織は成熟度を測り、その能力を向上させるための計画を立てることができる。(中略) 新しいレベルに上がる度にプロセスの実行はより一貫性を増し、予測可能な状態となり、信頼性が高くなる。 レベルは通常0~5の6段階で表される。 DMMA は 全体的なデータマネジメントを評価するために使用したり、単一の知識領域や、単一のプロセスに焦点を当てて使用したりできる。どのような点に焦点を当てたとしても、DMMA はデータマネジメント業務の健全性と有効性について、業務と IT の視点のギャップを埋めるために役立つ。 組織が DMMA を実施する理由は、規制への対応、データガバナンス、プロセス改善、etc. DMMA の第一のゴールはデータマネジメント活動の現状を評価することであり、それにより改善計画を立てることができるようになる。 アセスメントレベル 以下はアセスメントレベルの概要。 データマネジメントの各知識領域 (ex. データガバナンス、メタデータ管理、etc.) ごとにレベルが評価される。 level 0: 能力が欠如した状態 データマネジメントの取り組みがない level 1: 初期／場当たり的な状態 限られたツールセットを用いた一般的なデータマネジメント ガバナンスは低レベル データ処理は一部の専門家に依存し、役割や責任は部門別に定義されている level 2: 反復可能な状態 組織は一元化された共通ツールを使い始める 役割は明確化されており、一部の専門家のみに依存しない level 3: 定義された状態 拡張可能なプロセスの導入と制度化 組織全体である程度統制されたデータの複製 データ品質全体の総体的な向上 組織的なポリシー定義と統制 level 4: 管理された状態 新しいプロジェクトやタスクから得られる結果が予測され、リスクの管理が始まる データマネジメントに成果に対する評価尺度が含まれる データマネジメント用の標準ツールが集中管理計画とガバナンス機能に組み合わされている level 5: 最適化された状態 活動の成果は十分予測可能に 組織は継続的な改善に重点を置く 十分理解された評価尺度を使ってデータ品質とプロセスが管理・測定される 次のように各知識領域ごとに可視化することができる。...