コミケ3日目 東“Ｏ”-31b にて『プロジェクト体験ゲーム 進捗どうでしょう？』をリリースします。 #C88
サーバ擬人化ユーザ会ですが、無事に新作を入稿して、データにヘマをしていなければ出せると思うので、取り急ぎブログで告知。余裕があれば、告知ページを作りますが、どこまで頑張れるかわからないので。
頒布日程と場所は以下のとおりです。
【日程】2015年8月16日（日）・コミケ3日目
【スペース】東“Ｏ”-31b （Webカタログへのリンク・要ログイン）
【頒布物】 C88新作・『プロジェクト体験ゲーム 進捗どうでしょう？』（予価500円）、ほか既刊
SELinuxシールがそれなりに残っているので、会場で買ってくれた人にはSELinuxシールもおまけでつけると思います。
また、今回も前回と同様「ちゃんおぷ」との合同サークルになっております。
ゲームとしては、毎ターン進捗を問われ続けながら、虚実交えつつ進んでいかないといけない誰も得しない感じのボードゲームです。（注：「プロジェクト体験ゲーム」と題していますが、現実のプロジェクトとは一切関係ありません）
ストーリーと基本ルールはこんな感じです。
『プロジェクト体験ゲーム 進捗どうでしょう』
ストーリー
20XX年、プロジェクトは炎上の炎に包まれた。
達成不可能と思える要件に、メンバーのやる気は枯れ、予算は割れ、あらゆるエンジニアは絶滅したかに見えた。
しかし、プロジェクトマネージャー（PM）はその失敗を認めていなかった…！
＊ ＊ ＊
ここは、とあるITベンダ。ITバブルに乗って成長したが、最近の業績はパッとしない。先日、それを巻き返そうと無理をおして受注した案件は無理難題ばかり、しかも、顧客との窓口になっているPMは技術音痴で、顧客との調整すらままならない。
そんなある日、PMから緊急ミーティングの招集がかかった。日々悪化するプロジェクトの現状を目の当たりしていたエンジニア達は、誰もがそのミーティングでプロジェクト計画そのものが見直されるものだと思っていた。
しかし、ミーティングでは、PMはそのようなことに全く触れることなく、ただ、次のように言い放った。
「みなさん、ご存知の通り、先日からプロジェクトが全く計画通りに進んでいません。それはひとえにみなさんが計画を持って作業を進めていないからです。これからは、毎日必ず進捗を報告してください。また、念のため言っておきますが、今は会社の危機です。報告の際に、進捗がない場合はどうなるかわかっていますね。みなさんの奮闘を期待しています。私からは以上です」
―誰もが思った。…やばい、これ、アカンやつや……。
これを聞いたエンジニアたちは、みな頭を抱えてしまった。顧客と要件すらまともに話し合えない中、まともに仕事を勧められるはずがない…。
しかし、今のところ目先を食っていくあてもなく、今すぐに仕事がなくなってしまうのは困る。どうせPMは技術のことなんかわかりゃしない、なら、進捗なんて適当にごまかしておけば当面はなんとかなるだろう。とにかく、今はうまく立ちまわって、プロジェクトが終わるまでやり過ごすしかない。
「進捗 or die」
―俺達の闘いが始まる。
■ゲーム内容
◎ゲーム概要
本作は、ブラフゲームの名作「CiaoCiao」をオマージュした、ITプロジェクト体験ゲームです。
プレイヤーは毎ターン、進捗を報告し、その分だけコマを進め、プロジェクトのゴールを目指します。
ただ、プロジェクトマネージャーは技術に関しては全く素人なので、適当な進捗をごまかして先に進むことができます。ただ、周りのエンジニア（他のプレイヤー）からツッコミが入ったら、その時点で嘘がバレて、プロジェクトから追放されてしまいます。
適当に進捗をごまかしつつ、プロジェクト完了まで逃げ切ってください。
◎ゲーム時間の目安とプレイ人数
1ゲームの所要時間（目安）： 30分〜60分
対象年齢： 全年齢（12歳以上推奨）
プレイ人数： 1人〜4人
続きは、紹介ページか現地にて。
追記
MacBook Air（Mid 2012）のSSDを128GBから240GBに換装した。
MacBook Airの容量が足りなくなってきて、つらみが貯まってきたので、連休に合わせてSSDを換装ししました。誰かの参考になればと思い、ブログにメモを残します。
ただ、自分でSSDを換装すると保証外となるので、参考にされる場合は自己責任でお願いします。
SSDの換装を決めた理由
もともとの自分のMBAのSSDは128GBで、去年ぐらいから容量が心もとなくなってきていました。なので、MacBook Airの新モデルが出たら、買い換えようと思っていたのですが、今年の春に発表された新しいMacBookが思いのほか、試される端末*1で、僕自身はその試練を乗り越えられず。。。
それで結局、SSDを換装して乗り切ることにした次第です。
利用したSSD交換キット
ググればすぐ出てきますが、MacBook Air用にTranscendからSSD交換キットが出ていたので、それを購入。240GB、480GB、960GBの3つがありましたが、目先の延命先と割りきって240GBを選択。換装用のSSDに加えて、交換作業用の専用ドライバー、データバックアップ用のSATA/USB変換ケーブルなど、換装に必要なものがひと通り揃ったキットになっています。
実際の作業
届いたものを開けて広げてみると、こんな感じ。
簡単な説明書が付属しているほか、動画でも交換方法が公開されています。
動画を見てもらえばわかりますが、作業はデータをコピーして、付属のドライバーで入れ替えるだけです。
ポイントは、リカバリモードの際、「ソース」と「復元先」を間違えないようにすることでしょうか。これを逆にすると、今のデータをすべて消してしまうので、ここだけは要注意です。ちなみにデータのバックアップには、1時間半ぐらいかかりました。
データを新しいSSDにコピーしたあとは、SSDを換装して、起動すると普通に動きました。思った以上にあっさり交換できたので拍子抜け。ちなみに、OSは「Mavericks」なので、ほかのバージョンだと動きが違うかもしれません。
次がSSD換装後。真ん中のSSDが入れ替わっています。あと、開けたついでに溜まっていたホコリを取りました。
換装後の状況
その後、今まで使ってきて目立った不具合はないですが、以下の問題がありました。
- Dropboxのファイルリストが一旦すべて同期されていない状態の表示になって、再チェックが走った。また、その間に「カメラアップロード」で取り込んだカメラの画像が一部二重に取り込まれた。
- 換装後、Office for Macを起動した際にライセンス認証が求められた。インストール時のライセンスキーを入れたところ、無事に再認証されて利用可能にはなった。
これらのソフトウェアは、HW構成も含めてPCの同一性をチェックしているのかもしれませんねのかもしれませんね。まだすべてのソフトウェアを使ったわけではないので、ほかにも同じようなことはあるかも知れません。
以上、メモまで。
このブログは、ケイオスドラゴンコラボ中のシャッツキステで書かれた*2。お店とは全く関係ないですが、個人的にはシャッツキステに来るエンジニアを常に求めています。
追記：Trim設定について
TwitterでTrimについての質問があったので一点追記。
Jetdriveには、Jetdrive toolkitという管理ツールがあり、ツールからTrimの設定ができます。マニュアルにはそこまで手順が書いてありますが、ここまでやらないとTrimが有効にならず、書き込みが遅くなってきてしまうようなので、そこは注意が必要ですね。また、Trimを有効化すると勝手にMacが再起動してしまうので、作業に影響が出ないようSSD換装後、すぐにTrimを有効化するのがお勧めです。
ツールのダウンロード先は以下です。ただ、Yosemite環境では動かないため、公式Driverの機能を使うという話もあるようです*3。
JetDrive Toolbox - サービス & ダウンロード
Jetdrive toolkitでは、Trimの設定だけではなく、SMARTの情報やSSDの損耗状況も確認できます。
データ分析基盤の「Scheme on Write」から「Scheme on Read」への転換についてのメモ（暫定版）・続き
前の記事の続きです。
前の記事では、分析対象データの加工をできるだけデータ利用に近いフェーズで行うようなアプローチ、「Scheme on Read」に対して、従来のBIシステムと比較して、整理できないか検討しました。
前の記事で、現状の考えを整理したあと、似たような記事を探したところ、以下のような記事もありました。こちらはBIシステムとHadoop中心のシステムを比較するのではなく、DWH/BIシステムを中心にHadoopをETLとして使うシステムとHadoopを中心にするシステムというわけで書いていますが、「データを加工して蓄積するのか、あるいはデータは生のまま蓄積しておくのかという違い」を取り上げているところは共通していると思います。
データを加工して蓄積するのか、あるいはデータは生のまま蓄積しておくのかという違いによって、ビッグデータを分析するための基盤アーキテクチャには大きく２つのタイプに分けることができます。従来からのDWH/BIの流れを汲むものとHadoopを中心にしたものです。データウェアハウス（DWH）中心のアーキテクチャでは、業務データベースからのデータはETLツールによって変換され、DWHに蓄積されます。また、時系列データはCEPエンジンなどにより、そのまま処理されて活用されることもありますが、CEPエンジンによって収集されたデータをDWHに蓄積することもあります。そして、非構造化および半構造化データに対してはHadoopをETLツールのように使って、生のデータから意味付けすることにより構造化してから、DWHに蓄積します。こうすると、すべてのタイプのデータはDWHの中に構造化されて蓄積されるため、OLAPやデータマイニングやテキストマイニングなど従来のBIツール群を使って、データアナリストによる従来通りの分析が可能になります。
一方、Hadoop中心のアーキテクチャでは、業務データベースからのデータはSqoopなどを使って、時系列データはStormやS4などを使って、非構造化データはFlumeやfluentdなどを使って、HDFS（Hadoop分散ファイルシステム）やHBaseなどに、前もって意味付けせずに生のまま蓄積できます。使っているソフトウェアはすべてオープンソースですので経済的なアーキテクチャと言えます。この方式の最大の特長は、生のままのデータが蓄積されているので、データ分析時にいろいろな意味付けを試してみる探索的なデータマイニングができるところにあります。また、従来のBIツールで用意されているアルゴリズムだけではなく、最新の統計理論をベースにゼロからプログラミングできる自由度をもっています。そのため、データアナリストというよりデータサイエンティストに向いたアーキテクチャと言えます。また、必要ならば、HDFSやHBaseから何らかの意味付けをした後のデータをDWHにロードすることによって、従来タイプのBIツール群も使うこともできます。
「Scheme on Read」は、実際のシステムが先行し、それに概念を与えたもの
前の記事では、アーキテクチャやアプローチなどの理論的な面での違いを見てきましたが、この記事と実際のHadoop中心のアーキテクチャを見ていて、その軸での整理は難しいように思えてきました。というのも、データ・ウェアハウスはデータベースに関する理論が先にあり、それをソフトウェアとして実装したのに対し、「Scheme on Read」の概念はHadoopの登場により実装が先行して、それを理解するために概念が形成されたように見えるからです。
私自身はデータ・ウェアハウスが出てきた当初のことを直接知ってはいませんが、BIシステムの成立を見ていると、Wikipediaの「データ・ウェアハウス」の項目には以下のような記述があり、データ・ウェアハウスはデータベースに関する理論的な背景を踏まえて実装されたものとされています。
データウェアの提唱はビル・インモン(William H. Inmon)氏で、1990年の著作によれば、「データウェアハウスは、意志決定(Decision)のため、目的別(Purpose-oriented)に編成され、統合(Integrate)された時系列で、削除(Delete)や更新(Update)しないデータの集合体」とされる。 データウェアハウス - Wikipedia
データ・ウェアハウスベンダのTeradataの解説記事では、ビル・インモン氏がデータ・ウェアハウスが持つべき以下の4つを特徴を著作で主張していたと書かれており、データ・ウェアハウスは当初からあるべき姿が定められていました。
- サブジェクト指向
- 統合すること
- 消さない・更新しない
- 時系列を持つ
BIシステムは基本的にはこの考え方を実装したものと言えるでしょう。
これに対して、「Scheme on Read」は「ビッグデータ分析システム」の実装の集合から共通する考え方を抽出したもののように見えます。
このように最初の時点でアプローチが異なっているため、これを横並びにして比較するよりも、今の段階では実際にあるシステムのケーススタディをまとめ、そこから共通する考え方を抽出していくように考えるのがよさそうです。
一旦、この整理メモはここまで。このアプローチで、アーキテクチャを見ていった結果はまた別の機会に。
だらだら駄文失礼しました。
追記
以下の整理を業務視点と捉えれば、BIシステムもその一つとして整理できそうです。
- 業務視点、業務フローでの整理
- 収集
- 蓄積
- 処理
- 分析・ビジュアライズ
データ分析基盤の「Scheme on Write」から「Scheme on Read」への転換についてのメモ（暫定版）
最近、データ分析基盤を設計するに当たっての考え方を整理する必要があって、要件に応じたデータ分析基盤を設計するに当たっての基本的な考え方は何かを考えています。
近年、データ分析基盤はデータ収集ソフトウェア、データストア、分析処理、分析処理の利用方法などなど、検討すべき項目が多くなり、この辺りの技術の流れを把握している人は当然のように設計を行うことができますが、そうでない人に取っては、どこから検討を始めるべきかわかりにくくなっているように思います。
自分の中でも、これがうまく言語化できておらず人に教えようと思っても、結構詰まってしまうので、ブログで言語化してみる次第です。
最近のデータ分析基盤の基本は「Scheme on Read」型のアーキテクチャ
最近のインターネット上で見るデータ分析のアーキテクチャは、データをデータソースから収集したのち、最低限の加工（ログをフィールドごとに区切るなど）をHDFSやS3、Azure BLOB ストレージなどに置くことが多くになっていると思います。
Hadoopが普及し、分散処理を利用するハードルが下がったことで、一度データを保存してしまえば、あとからデータを分析できる形式に整形することができるようになったことが、このようなアーキテクチャを可能にしていると思います。
保存したデータは、あとでHadoopを使って分析に使いやすい形に加工し、その上で独自の可視化アプリなり、Tableauなどのセルフサービス側のBIツールで読み込んで使うことになります。
最近のデータ分析基盤系のスライドを見ると、このアーキテクチャを前提に以下の4つのコンポーネントに分けて、機能が語られていることが多いようです。最近のデータ分析関連のプロダクトは、このような区分で作られていることが多いので、自分としてもしっくりきます。
データ分析基盤のコンポーネント
参考スライド
- スマートニュースの世界進出を支えるログ解析基盤 #jawsdays #tech - Speaker Deck
- 集める/保存する/処理する/分析する
- Google Cloud Dataflowを理解する - Speaker Deck
- Collect/Store/Process/Visualize
- スマートニュースの世界進出を支えるログ解析基盤 #jawsdays #tech - Speaker Deck
このアーキテクチャは「Scheme on Read」という言葉で呼ばれることがあります。データ加工を出来る限りあとのフェーズにすることで以下のメリットを得ることができます。
- テキストや画像、音声、動画等の非構造化データもそのまま同じ仕組みで保存可能
- データの種類や分析内容が変わっても、「処理」フェーズ以降で必要に応じてデータを加工することで柔軟に対応できる
- データ保存にはファイルをそのまま保存できるようなストレージや分散ファイルシステムを使うことで、データの収集・保存の仕組みをシンプルに保つことができる
分析対象と分析手法が多様化していることから、このような特徴はデータ分析基盤の大きなメリットです。
それでは「Scheme on Write」の基盤とは？
Hadoopが普及する以前は、データ分析基盤と言えば、データ・ウェアハウスを中心とするBIシステムのことを指していました。ただ、BIシステムとHadoopを利用したデータ分析基盤のアーキテクチャの比較は、私が知る限りあまりないように思います。
データ・ウェアハウスのアーキテクチャは「Scheme on Read」と比べると、「Scheme on Write」、つまりデータを保存する際にスキーマを与えるという設計の方法論と考えることができると思います。
BIシステムの構成要素をざっくりまとめると、以下のようになっています。
- BIシステムの構成要素
- ETL
- Extract: 業務システムからのデータ抽出・収集、Transform: データ加工、Load: データ・ウェアハウスへのデータロード
- 蓄積
- データ・ウェアハウスへの蓄積
- 分析・ビジュアライズ
- BIツールでの分析
- ETL
先ほどの最近のコンポーネント分割と比べると、Iシステムではデータ収集とデータ加工が「蓄積」の前に来ており、データ蓄積の時点で分析に必要な前処理がひと通り終わっていることが前提となっていることが大きく異なっています。
データ・ウェアハウスは、単にデータを長期間に渡って蓄積するだけではなく、データ分析の目的に特化したテーブル構造を取ることで、複数の軸でデータの集計・分析を高速に行うことができるようになっています。
データ・ウェアハウスで用いられるテーブル構造は「スタースキーマ」と言われ、各種マスタ情報やデータ集計対象期間等の属性情報を格納した「ディメンション・テーブル」と取引履歴などの履歴データをディメンションテーブルの軸で切って格納した「ファクト・テーブル」からできており、通常は業務システムとは別のテーブル構造を持っています。この構造にしたがってテーブル設計を行い、データを格納することで、BIツールから効率的にデータ分析ができるように工夫がなされています。
そのため、データ・ウェアハウスにデータを蓄積する際には、そのテーブル構造にデータを合わせるためのデータ加工や不正なデータやフォーマットが合わないデータを弾くためのクレンジング処理も必須です。しかし、一旦データを入れてしまえば、後段の分析では前処理が終わった状態でデータを使うことができる、というのがこのアーキテクチャの特徴です。
上で見てきたデータ・ウェアハウスを中心としたBIシステムは、その特徴故にデータ投入時の検討事項が多くなり、かつ、事前のテーブル設計で漏れがあったり、新たに分析対象となる軸が出たりした場合は、またテーブル設計からやり直す必要が出てきます。そのため、最初の要件定義の際に分析軸まで決められるようなデータの種類が増えない業務システムであればいいですが、そうでない場合は設計が困難です。
BIシステムの設計は、企業内部に閉じていることが多く、設計自体が各企業のノウハウを含むので、Web上では概論を超えるような設計内容があまり公開されていないように思います。書籍としては、以下の書籍が参考になりました。
BIシステム構築実践入門 (DB SELECTION)
posted with amazlet at 15.05.02
BIシステム構築実践入門 eコマースデータ活用編 (DB Magazine SELECTION)
posted with amazlet at 15.05.02
「Scheme on Write」は「Scheme on Read」に乗り越えられたと言えるか？
「Scheme on Write」はデータ分析基盤が世の中になかった時に、業務システムとデータ分析を行うシステム（情報系システム）を分割し、業務にしか使われていなかったデータを分析用のデータに転換することでビジネス上の価値を生み出すことを意図して考えだされた仕組みです。
一方、「Scheme on Read」は、上記の背景から生まれた既存のBIシステムが近年のデータ増加のために行き詰まってくる中、Hadoopによる大量データの分散処理が一般的になったことから形作られてきたアーキテクチャだと思います。
ただ、後者が前者を単純に乗り越えて、後者だけですべてが成り立つ世界になったかというとそうでもないかなと思います。どちらにしても、最終的にデータ分析を行うためには、データ分析の目的に応じてデータを整形し、分析する必要があり、また、データの前処理は後に回せば回すほど、余分なデータをあとに持ち越すことになるため、処理のオーバーヘッドは増えてきます。
・・・この関係をうまく整理できればいいのですが、今日の時点ではまだまとまっていません。 連休中に考えがまとめられたらと思いますが、なんとかなるかなー
長くなったので、尻切れですが、今日はここまで。続きはまた考えがまとまり次第ということで。
--
追記
メモの続き書きました。このメモはアプローチの整理までで一旦終了で。
データ分析基盤の「Scheme on Write」から「Scheme on Read」への転換についてのメモ（暫定版）・続き - 双六工場日誌
【まとめ】エンジニアサポートCROSS 2015 に参加してきた #cross2015
すでに会場で書いた分を速報としてブログにもアップしていますが、1/29 に行われた「エンジニアサポートCROSS 2015」に参加してきました。
- 会場前に停泊していた「ASUKA 2」
CROSSは、今年で4回目になるイベントで、様々な分野のエンジニアやコミュニティが一堂に介して交流するイベントです。毎年年明けすぐにやっているので、東京で活動するIT勉強会の合同新年会みたいな面もあったり。
いろいろな人が集まるので、毎年新しい発見があり、また、しばらく会っていなかった人との旧交を温めたり、個人的にはWebエンジニア版のコミケ*1のような位置づけになっています。
去年までは、新宿ベルサールでの開催だったのですが、今年は場所を変えて横浜の「横浜港大さん大ホール」での開催。主催のところをよく見ると、今年は「横浜市経済局」とか「一般社団法人 神奈川県情報サービス産業協会」とか地元とかの地元の団体も後援に入っていました。
参加したセッションのうち、最初の2つは会場にいるうちに速報だけ書いていたので、そちら参照。こういうのは、あとになればなるほど億劫になって、かつ、記憶が薄れて書きにくくなってしまうので、サクッとやってしまうのが大事ですね。
【速報】CROSS2015「女子大生UXデザイン概論」に参加してきたので、偏った視点でメモ - 双六工場日誌
【速報】CROSS2015「Webアプリケーションから機械学習まで ～ PythonとPythonコミュニティの2015年大展望」のメモ - 双六工場日誌
このエントリは、上記のエントリの続き兼参加報告まとめのエントリです。
Twitter の #cross2015 のハッシュタグを追っていると、続々と参加ブログが増えていますが、そちらについては公式のまとめページができるようです。ページができたら、そのURLを追記します。
続きを読む【速報】CROSS2015「Webアプリケーションから機械学習まで ～ PythonとPythonコミュニティの2015年大展望」のメモ
CROSS 2015、ランチセッションのあとは、Webアプリケーションから機械学習まで ～ PythonとPythonコミュニティの2015年大展望に参加してきました。
すでにTogetterがまとめられていたので、ツイートはこちら。
CROSS2015「Webアプリケーションから機械学習まで ～ PythonとPythonコミュニティの2015年大展望」 - Togetter
野球クラスタ（仮）の話だけはすでにスライドが上がっていました。
セッションの内容は、日本国内のPythonコミュニティの網羅的な紹介でした。Pythonを仕事で使っているものの、これまでPythonコミュニティに参加したことがなかったので、それをまとめて聞けたことが個人的には収穫です。
PyLadiesという女性Python使いの国際的なコミュニティがあって、その日本国内のコミュニティの立ちあげを今年新卒で就職したデータサイエンティストの女性がやっているというのが衝撃でした。
登壇者と、それぞれが属しているコミュニティは、セッションページを参照。
ビールの時間が来たので、一旦ここまでで。
