2010年9月20日月曜日

システムエンジニア、ITマネージャの超勉強法

一昔前、IT業界はドックイヤーと言われて、通常の7倍のスピードで環境が変わっていくと
言われていましたが、やっぱりいまでもITは日々かなりのスピードで進化しています。
最近ではクラウドをキーワードとして様々なデータベースやストレージの技術、はたまた
携帯技術を知ることはますます増えています。

そのため、IT関連を仕事をする人はかなり勉強して追いつく必要があります。
ただ、そうは言っても忙しいシステムエンジニア、システムアナリスト、ITマネージャに
とってはなかなか勉強する時間が取れませんし、家族サービスや自分の趣味なども楽しみたいところです。

そこで、不完全ながら、システムエンジニアの超勉強法と称して勉強法について記載したいと思います。

1.大きな書店のコンピュータコーナーに毎週行く
これは私が日々実践していることですが、なるべく大きな書店のコンピュータコーナーに
毎週行きましょう。
そしてまずは平積みされている本なども中心にどんな本が出版されているか確認しましょう。
これをすることによって現在どんなテクノロジーがはやっているかどうかわかります。
また、ここで確認できるのはある程度定評のあるテクノロジと考えていいと思います。
というのは本が出るくらいですが、そのテクノロジについてはある程度需要があるので
知っておくテクノロジと考えてまず間違いありません。
私はこれで特にオープンソースで人気になりつつあるアプリケーションの情報を得ることがあります。
ここで気になったものがあったら、まずはまえがきや最初の章を読んでみることをお勧めします。
そこである程度どのような技術についてすることができます。
興味があったら、本をかって読んでみたり、またネットで追加で調べましょう。

2.最新技術は雑誌で確認
もちろん、最新の技術はWebで日々収集することが基本ですが、そうはいってもなかなか
なれるまでは有益な情報を得ることはできません。
そこでやっぱり最新の動向は雑誌ということになります。
本よりタイムリーな情報が得られますし、簡単に情報がまとめられていますのでお得です。

3.本格な本で勉強
やっぱり最後は本格的な本で勉強する必要があります。
コンピュータ本は高いですがここは投資と思って買って勉強しましょう。
迷ったら、おすすめはオライリー本です。
ただ、オライリー本はレベルが高いし、厚い本が多いのでまずは簡単に書かれている本を
お勧めします。

4.各章のタイトルだけでもスキャニング
もし、忙しくてなかなか時間がとれない人は本の各章のタイトルやサブタイトルだけでも
流しよみすることをお勧めします。
これでなんとなくそのテクノロジについてわかります。
このなんとなく知っているが非常に大事でなんとなく知っていることにより普段入ってこない
情報が目につくようになりますので効果大です。

最後なんといっても継続です。
私もそうですが、なかなか時間は取れませんがとにかく継続して勉強することが
必要です。
日本の技術者は海外と比べるとあまり勉強していないそうです。
特に中堅の技術者は過去の技術しかしらないのにえらそうな態度を取っている人が
おおいですね。
これは自分への胸が痛い言葉ですが。。。。

2010年9月19日日曜日

ソフトウェア企業の競争戦略について考える

昔読んだ本ですが、マイケル・クスマノ氏の「ソフトウェア企業の競争戦略」を読み返しました。
2004年の本なので、内容は結構古いですが、そこに書いてある戦略はいまでも有効だと思います。
ただ、IT業界の状況はものすごいいきよいで変化していますので、こちらを前提にいまの状況に
アップデートする必要がありそうです。

アマゾンで調べたクスマノ氏の最新刊で英語であるそうなのでさっそく読んでみたいと思います。

データマネジメントはあまり関係ないようですが、ソフトウェア企業の製品を利用する以上、
このような戦略の知識もひつようですよね。





書評:Excel 2010&SQL Server 2008 R2による企業データ分析入門

「Excel 2010&SQL Server 2008 R2による企業データ分析入門」を読みました。
SQL Server 2008 R2とPower Pivotの利用方法などがわかるかなと思って読みましたが、
初心者向けに書かれており、基本は企業のデータ分析について中心であり、技術についての
記載はあまりありません。どちらかというと使い方が書いてあるだけなのであまり
利用価値はありませんでした。

個人的にはあまりおすすめしません。


データの戦略性について考える

ハーバードビジネスブレスから出版されている「戦略的データマネジメント 企業利益は真のデータ価値にあり」を
読みました。
本書はデータ品質という観点からデータをいかに会社の資産として使用していくかによって記載されています。

本書を読んで改めてデータの戦略性およびデータの品質の重要性について感じました。
本書を読んで考えたのが、会社のデータ品質および需要性に関する意識です。
データがほしいという声は聞かれるのですが、データ品質について本気で取り組んでいる企業は
やっぱり少ないと思います。
また、データ分析の会社の成熟性という点でも非常に低い会社が多いと思います。

データを戦力的に考えるには会社のデータ分析の成熟性なども合わせて考える必要があると感じました。


2010年9月13日月曜日

インモン、キンボール、データボルトどれにするか、それが問題だ。いや、いや問題ではありません

データウェアハウスの設計において、現在3つのモデルが存在します。
その3つとは下記になります。

1.インモンモデル
データウェアハウスの父といわれるビル・インモンに提唱されている方法論です。
これはいわゆるエンタープライズデータウェアハウスの考え方で、
会社で1つの大きな第3正規形のデータベースを構築し、部門別や必要に応じて
そこからデータマート(スタースキーマ)を構築して分析を行う方法です。
エンドユーザはデータマートにアクセスするのみです。

2.キンボールモデル
スタースキーマを一躍有名にしたラルフ・キンボールの方法論です。
インモンモデルと違うところはキンボールはデータウェアハウスをスタースキーマの
寄せ集めと考える点です。
元データはあくまでデータステージに格納されているという認識です。
エンタープライズデータウェアハウスはデータステージにDBやファイルで保管されている
イメージです。

3.データボルトモデリング
これはダン・リンスデットによって提唱された方法論で、インモンモデルの拡張版と
考えて良さそうです。データボルトモデルはエンタープライズデータウェアハウスを
第3正規形ではなく、データボルトと呼ばれる設計方法で各オペレーションのデータをすべて
そのまま格納する方法です。
データがそのまま保管できるので、データの再加工やトレースに非常に優れています。

では、いったい上の3つの内どれが一番いいのでしょうか。
それは会社の規模やデータウェアハウスに対する成熟性などによることになります。
例えば、とにかくお金がなくてデータマートが欲しいとなったら、2のキンボールモデルで
ボトムアップ式にシステムを増やしていくのがいいでしょう。
また、データすべてをためる予算はないが会社のデータを分析管理した場合は1になると思います。

でも、私は再集計は上の3つのすべてを組み合わせて構築するのが理想だと考えています。

まず、全体のアーキテクチャはインモンモデルを採用して、エンタープライズデータウェアハウスを
構築して、分析は2のキンボールモデルを構築して分析します。
エンタープライズデータウェアハウスは会社のデータをそのまま保管するためにデータボルトモデルを
利用します。
こうすれば、もしキンボールモデルの設計をやりなおしたい場合は過去のデータがそのまま残っていますので
ETLを修正して再構築すれば、過去のデータから再度分析できます。

うーん、いつかこのシステムを構築したいです。

インモン、キンボール、データボルトを網羅したぞうさんのサイト

データボルトモデリングに調べていたら、下記サイトにぶつかりました。
あまり情報量はありませんが、インモン、キンボール、データボルトのすべてに
ついて網羅しています。
非常に優れたサイトなので紹介しておきます。
英語のサイトです。
Sustainable business intelligence

データボルトモデリングの謎を解く!

前回の投稿でデータボルトモデリングについて触れましたが、
本日はちょっとその内容に触れたいと思います。

データボルトモデリングの特徴を一言で言えば、すべてのオペレーションシステムから
来たデータをそのまま保管するモデリングです。
そのままデータを保管するところがポイントです。
そのまま保管する理由はもし後で使用がかわった場合に元データがあるので
それをもとに再構築できるからです。
また、最近のオーディットの対応としてもデータが追えるという点で非常に優れています。

今までとりあえず、万が一のためにローデータをファイルで保管していた会社は多いと思いますが
いざとなったら使わないし、どういうデータ構造になっているかもわからないで有効に活用できて
いなかったので現状です。

そこで、データボルトモデリングです。
これを利用すれば、リレーショナルデータベースに保管できるので、いざというときに利用できます。
確かにすべてを保管するとデータ量が多くなりますが近年ハードは安くなっていますし、データの圧縮技術も
進化しています。
また、データ分散の技術も進化していますので、ある程度大きな会社であれば、これらの問題は解消できると
思います。

では、データボルトモデリングについて説明します。
データボルトモデリングは次の3つのコンポーネントから成り立っています。
それはずばり、
Hubs ハブ
Links リング
Satellites サテライト
の3つです。

それでは1つずつ簡単に説明していきます。

Hubsとはデータの大きな固まりを表したものです。
例えば、顧客とか店舗などになります。
次にLinksです。
リンクはHubsとHubsのリンクを管理するテーブルです。
データボルトモデリングは柔軟性を持たせるために普段はERで定義する
リレーションをリンクテーブルで定義しています。
これにより第3正規形ではテーブルの設計変更が発生する場合でもリンクのデータを
かえることにより柔軟に変更に対応できます。
最後にSatellites.これは通常にデータの属性を保持するテーブルです。
もちろん、ハブとリンクさせるのですが、1つのHubやlinkはサテライトを複数持つことが
できます。

例えば、既存システムで顧客情報をマーケティングシステムおよびセールスシステムのそれぞれで
持っていれば、データボルトモデリングでは名寄せやクレンジングはせずにサテライトをそれぞれ
1つずつ作って、顧客ハブの下にそれぞれもたつことができます。
これですべてのデータをそのまま保持できるのです。

まだ、詳しくは調べていませんが、この設計によりETLの処理もある程度パラレルで処理ができるので
高速で処理ができるようです。

ビックデータを保持する時代この技術は非常に有効だと思います。

2010年9月11日土曜日

データウェアハウスの新モデリング データボルトモデリング(Data vault modeling)

以前、データウェアハウスの設計はインモンモデルとラルフキンボールモデルの2つに分かれると
説明しましたが、どうやらデータウェアハウス業界は日々変化しているようです。

データボルトモデリング(Data vault modeling)なる第3派が存在するようです。
データボルトモデリング(Data vault modeling)とは、インモンモデル、キンボールモデル(スタースキーマ)の
それぞれのデメリットを克服したモデルだそうです。
ということでだいぶまえから提唱されているモデルのようですが、私はさっぱり知りませんでした。。。
やっぱりデータウェアハウス業界も日々進化しているんですね。

ということで、自称スーパーデータエンジニアを目指す私としてはマスターしない分けにはいきません。
こうなったら、日本で一番データボルトモデリングにくわしいというくらいまで勉強したいと思います。
下記にまずは情報があるようなのでこちらで勉強したいと思います。
Data valut modeling article

また、QUIPUというデータボルトモデリングをベースにしたオープンソース製品もあるようです。
こちらもぜひチェックする必要がありそうです。
QUIPU

また、データボルトモデリングはビル・インモンのDW2.0にも組み込まれているようです。
こっちもまだ勉強が進んでいません。

学ぶことはたくさんありますね。

データボルトモデリングについてはこのブログでも紹介していきたいと思います。

2010年9月7日火曜日

アーキテクチャについて勉強する

システムを設計するにはやっぱり全体最適を考えて設計、実装する必要があります。
そこで必要になるのがアーキテクチャという技術です。
データを考える上でも全体のあるべき姿を考えたり、概念モデルを考える必要があります。

ということでアーキテクチャについて勉強しようと思います。
下記書籍を読みました。



非常に情報がよくまとめれており、良書だと思います。

2010年9月6日月曜日

データウェアハウス/BIの読書案内

IT技術者向けの読書案内サイトを作成しました。
下記にデータウェアハウス/BIの読書案内を掲載しています。
データウェアハウス/BI 読書案内

参考にしてください。

2010年9月5日日曜日

スタースキーマ教育普及させたい。。。

最近感じたことですが、データウェアハウスやBIの業務に作成している人で
スタースキーマやデータウェアハウスのアーキテクチャについて一通り知っている人は
少ないようです。。。
どちらかというとデータベースの知識があって、各ETLやBIツールの操作については知っている人が
多いようです。。。しかも、そういう方がデータウェアハウスをデザインすると、
通常に業務DBの延長でデータウェアハウスを設計してしまうため、ユーザの要求については
やってもいいけどお金がかかるやパーフォーマンスが劣化するからできないなどと
理由をつけて使えないシステムを作成してしまうように思います。。。
スタースキーマやSCDなどを深く理解していれば、わりと簡単にできるのにって思ってしまいます。。。

ただ、あまり技術者を避難できないのも事実です。
というのもスタースキーマなどの技術がしっかり勉強できるセミナーや書籍が日本語では少なすぎます。。
ということでこのサイトが少しでも皆様のお役に立つようにがんばりたいと思います。

また、いつかはキンボールなどの名著の翻訳にも挑戦したいと思います。。。。
採算が合いそうにないので翻訳する出版社はなかなかいないかもしれませんが。。。

データウェアハウス:ドリルアクロス(Drill-Across)という技術

データウェアハウスのスタースキーマを設計する際、重要なのはビジネスプロセスごとに
スタースキーマのセットを作成することです。
これは例えば、受注と配送のデータはデータの発生のタイミングが違ったり、配送には
配送者や配送場所などのDimensionが加わったりすのでビジネスプロセスは別考え、別の
スタースキーマにするということです。

ただ、そこで問題になるのが、じゃ、受注と配送を月別で比べたりする場合はどうすれば
いいのでしょうか。
そこで必要になる技術がドリルアクロス(Drill-Across)という技術。
これはドリルダウンやドリルアップとは一切関係ありません。。。

ドリルアクロス(Drill-Across)を簡単に説明すれば、比べたいスタースキーマから
粒度を合わせたサマリーのデータをそれぞれ抽出してからそのデータをマージして
レポートを作るという方法です。比率などもマージの際に計算して出します。

現在、読んでいる「The complete reference: Star schema」には、ドリルアクロスの方法として
下記の3つの方法が紹介されています。
1データベースからそれぞれサマリー情報を出して、レポートシステム側でマージする。

2それぞれのサマリー情報をテンポラリーテーブルに出力してからマージする。

3出力とマージをSQL一本で行う。。。

詳細は「The complete reference: Star schema」の第4章に紹介されています。。。