-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_BusinessIntelligence
経営・会計・情報処理などの用語で、
-
ビジネス上の意思決定の支援
-
企業などの組織のデータを、収集・蓄積・分析・報告することにより、
経営判断上の過去・現在・未来予測などの視点を提供し意思決定に役立てる。
-
データディスカバリ等、
単純なグラフなどの記述統計的な可視化 - 回帰分析や最小二乗法など推論統計的な推論
- データマイニング
- テキストマイニング
- イメージマイニング
- プロセスマイニング
- 複合イベント処理
- ビジネス業績管理(BPM)
- ベンチマーキング
- 予測分析
- 規範分析
ビッグデータの流れで遡って...。
-
ストアに関連した用語
→ データレイク
→ (データ・クレンジング)
→ データウェアハウス(DWH)
→(特定データ切出)
→ データマート -
分析に関連した用語
データレイク は構造化/非構造化データやバイナリ等の
ファイル含めたローデータを一元的に格納するデータリポジトリ。
(雑に言うと、雑にデータを放り込んでおく入れ物。)
-
特徴
- ⾮常に安価で、優れた耐久性をもつ。
“10 nines”の耐久性。安価。無限のスケーラビリティ。 - 多様な形式の⽣データを蓄積可能。
動画, ⾳声, テキスト, 構造化データ, ⾮構造化データ - オープンで標準のフォーマット。
Parquetフォーマット, 多種多様なツールが対応可能な形式
- ⾮常に安価で、優れた耐久性をもつ。
-
課題
-
データ処理・扱いに関する課題
- データを追加することが難しい。
新しいデータを追加すると正しくない読み取りが⾏われる。 - 既存データの変更が難しい。
GDPRなどの規制対応で既存データの細かな変更が必要。 - ジョブエラー時の対応が難しい。
半分のデータがデータレイクに追加され、残りが消えてしまう。
- データを追加することが難しい。
-
⼀貫性・データ管理に関する課題
- リアルタイム連携が難しい。
ストリーミングとバッチデータを混合すると⼀貫性が保てなくなる。 - データ履歴の管理が難しい。
規制対象システムの場合、再現性、監査、ガバナンスが必要。 - 巨⼤メタデータの扱いが難しい。
⼤規模なデータレイクではメタデータ⾃体が⼤量で管理が難しい。
- リアルタイム連携が難しい。
-
処理性能・データ品質に関する課題
- “膨⼤なファイル”の扱いが難しい。
データレイクは数百万の⼩さなファイルの処理には適していない。 - 最⾼の処理性能担保が難しい。
性能改善のためにデータをパーティション化することなど変更が困難。 - データ品質の担保が難しい。
全てのデータが正確で⾼品質であることを保証することは、常に課題。
- “膨⼤なファイル”の扱いが難しい。
-
(データ・クレンジング)により処理された
データレイクより、より洗練されたデータを格納する。
-
従来のデータウェアハウス(DWH)は、
- 業務データを長期的に蓄積し管理したもの。
- 基幹系システムとは別に構築され、経営的意思決定のための
ビジネス インテリジェンス(BI)やデータマイニング等に利用される。
-
しかし、以下のサポートに課題がある。
- 動画、⾳声、テキスト
- オープンなフォーマットでの格納
- ストリーミング処理
- 機械学習、深層学習
-
昨今のビッグデータのコンテキストで、対応が可能になってきている。
-
従来は、EAI/ETLで行っていた。
-
DWHに保存されたデータの中から、
特定の部門やユーザの使用目的に応じて特定のデータを切り出し、
別のデータベースに整理したもの。 -
従来のデータマートは、多次元データベースとして作成されていた。
-
しかし、昨今のビッグデータのコンテキストでは、
データパイプラインの末端に位置し、- 分析超並列処理(MPP)データベース
- インメモリ・データベース
などが利用されるようになってきている。
-
RDBのデータ構造でも構築可能だが(ROLAP)、
RDBより分析性能の良い独自のデータ構造もある(MOLAP)。 -
多次元データベースは、多次元モデルのスター・スキーマ構造で構成される。
- データ自体を蓄積するファクト・テーブル(非正規化する)
- 分析軸を設定するディメンション・テーブル(高速化のためにキーや集計値以外は追い出す)
- このようにして作成された多次元データを、OLAPキューブと呼ぶ。
-
多次元データを分析する。
- Multidimensional Expressions (MDX)でクエリを行う。
- クエリの結果セットのカラムは、以下の様に分類される。
- ディメンジョン:グループを表示する列
- メジャー:集計値を表示する列
Azure Databricks の該当節を参照。
- 分散処理基盤の発達に伴い誕生
- データレイクとデータウェアハウス(DWH)の特徴を併せ持つ。
- オンデマンドで、データレイク上のデータをデータ・クレンジング
エンドユーザが多次元データベース等のデータマートを自由に検索し、
問題発見・解決するための、分析を主とした利用形態
→ 詳細
-
明示されておらず今まで知られていなかったが、
役立つ可能性があり、かつ、自明でない情報を、
DWHやデータマートのデータから抽出する。 -
通常は想像が及びにくい、ヒューリスティクな
知識獲得が可能であるという期待を含意している。
→ 詳細
-
古くは、OLAP用の多次元データベースをソースとしていたが、
最近は、それ以外のデータベースが利用されるようになってきた。- MPPデータベース
- インメモリ・データベース
-
データディスカバリを行う色々な利用形態
(いずれも データ解析の該当節を参照)- アドホック分析用のツール
- ダッシュボード・ツール
- モニタリング・ツール
1つのデータを多角的に分析する
- 全体を俯瞰
- KPIを一覧
- 対話的に条件を変更
- Tableau
- QlikView
- Power BI
- SAS Visual Analytics
- MotionBoard(国産)
- OLAP (Online Analytical Processing)
- RDBの生みの親でもある E.F.Codd 博士が生み出した言葉
「RDB は、基幹系処理(≒OLTP)を行うために理論化されたものであり、分析処理(≒OLAP)には向かない」
と言って、分析処理に関する「OLAP」を提唱したのが語源
... 参考:https://ja.wikipedia.org/wiki/OLAP
-
データセットの中に存在する属性か、計算した結果取得した派生属性のいずれか。
-
データセットをそれぞれディメンションもしくはメジャーという概念として捉える。
-
これらを組み合わせて使用してデータ集計することで、様々なデータビジュアライゼーションが可能となる。
-
ディメンション
データをグループ化、分離、フィルタリングする、分析の切り口としての属性- データ分析を行う際には、様々な切り口でデータを分割する。
- ディメンションの例として、都道府県別、月別、商品カテゴリ別などが挙げられる。
- 主に属性を使用するが、年代別などの数値範囲を使用することもできる。
-
メジャー
分析の対象とする測定可能な数値属性(単純にディメンションの集計結果など)- 「商品カテゴリ」ディメンションの場合、
- 「売上金額」を集計した「商品カテゴリ別売上金額」。
- 「決済数」を集計した「商品カテゴリ別決済数」。
- 「購買点数」を集計した「商品カテゴリ別購買点数」。
- 主に数値を使用するが、過去データと比較した上昇・維持・低下の評価属性もメジャー
- 「商品カテゴリ」ディメンションの場合、
-
また、得られた二次元表をEXCELなどの表計算ソフトに取り込み、
表計算ソフトの機能を利用して、様々な分析を行うことができる。
リレーショナル データベースなどの外部データ ソースから、
集計したデータを含む多次元構造を設計、作成、および管理できる。
-
統計解析、人工知能(AI)等の技法を適用することで知識を取り出す技術。
-
統計学:
- データの特徴
- 説明変数で分類
- 目的変数と説明変数の関係(集約、予測)
-
人工知能等
- エンリッチメント
- ...
-
-
X マイニング
-
テキスト マイニング(言語処理(AI)の該当節を参照)
- テキストデータから知識を取り出す
- その中でもウェブページを対象にしたものをウェブ マイニングと呼ぶ。
-
イメージ マイニング
大量の画像データから知識を取り出す手法 -
プロセス マイニング
大量のプロセスのデータから知識を取り出す手法
-
- データ分析 > 分析の目的と手法
- データマイニング(DM)- CRISP-DM
- データマイニング(DM)- DataSet
移行メモ: 元ページの「参考」節は見出しのみで本文が無い(書きかけ)。
Tags: 移行, サービス, DX, BI, 開発基盤
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。