読者です 読者をやめる 読者になる 読者になる

双六工場日誌

平凡な日常を淡々と綴ります。

1年寝かせたEdisonのWi-Fi接続とFirmware(Yocto Linux)のアップデートにハマったのでメモ

ちょうど1年ぐらい前にIntel Edisonを買ったのですが、使わないまましまいこんだままになっていたので、掘り起こして動かして見ると、Wi-Fiつながらず、解決のために公式サイトの手順でFirmware(Yocto Linux)をアップデートしようとしたところ、素直に落としたYocto Linuxの最新イメージは、2.1、3.0と容量不足で入れられず。。。

ググったところ、2chのEdisonスレに同じような人がいて、そこに書いてある方法でアップデートできて、Wi-Fiまでつながったのでメモ。

参照した情報は以下。

383 :774ワット発電中さん:2015/10/31(土) 14:10:30.62 ID:gzX/MCJu
breakoutボードキットを試してるがWIFIがダメだ 
パスワード認識しIPアドレス取得まではうまくいくがpingが通らない 
edison側からも外からも 
ホストがない場合のunreachableはでずに永遠と沈黙 
WEBも反応しない 
5Gでも2Gでも症状同じ 
iwconfigやwpa_cli statusのメッセージも正常に見える 
無線LAN親機との相性ってあるんだろうか? 

ついでにいうとファームはRelease 2.0 Yocto* complete imageを使用 
2.1だと容量不足になる、フラッシュメモリ1GB搭載バージョンあるんか? 

自作はトラブルを楽しむためにやるもの、と考えれば 
楽しめているとも言える 

393 :774ワット発電中さん:2015/11/27(金) 22:22:52.47 ID:ddDflIs3
>>383 
同じとこでは待ってる奴発見w 
wifiできたぞ!w 
Edisonをまず最新の環境にアップデートするとこではまるよなw 
2.1は単純に容量不足になるw 
でも 
http://downloadcenter.intel.com/download/24910/Intel-Edison-Software-Release-2-1 
ここのFile name: edison-image-ww18-15.zipVersion: 2.1 (Latest) 
ならedisonのRAMでも容量が足りる! 

edisonのRAMを初期化フォーマットしてからにこのファイルを展開してedisonのRAM800Mくらいにコピー 

でedisonnにログインしてreboot ota やればOK 

configure_edison --setup で順に設定していってwifi設定すれば 

edisonのローカルサーバーアドレスが表示されるからブラウザからアクセスでけるようになってる! 

先人の知恵はありがたいです。

スレッドが落ちて、見られなくと困りそうなので、メモ


ここまでできたあとは、以下の手順にしたがって、AWS CLIのインストールまでできました。ここまでできれば、AWSが自由に使えるので、何でもできそうです。

github.com


紹介したスレには、2.1に上げる場合のコメントもあります。以下のサイトを参考にFlash Tool Liteを使えば、2.1にもできるようなので、それはまた今度試してみます。

IoT - The Intel® Edison Board Software Release 2.1 | Intel® Developer Zone

Python製クローラー「Scrapy」の始め方メモ

下書きのまま半年ぐらいほったらかしだったものからサルベージ。内容が古くなっているかもですがご容赦ください。

Python製クローラー「Scrapy」は、さくっとクローラーをつくる際に非常に便利なんですが、フレームワークの全体像を理解するところで時間がかかったので、クローラーをつくる際のとっかかりのところをメモとしてまとめました。

インストール

まずは、依存パッケージのインストール。以下は、「Amazon Linux AMI 2015.09」の場合。

$ sudo yum groupinstall "Development tools" $ sudo yum install python-devel libffi-devel openssl-devel libxml2-devel libxslt-devel

続いて、本体インストール。service_identityは、MITM攻撃を防ぐためのパッケージで、一緒に入れておくのが推奨とのことなので、最初に入れておきます。System Pythonにそのまま追加する手順になっていますが、virtualenv等で環境を分けている場合は、適宜読み替えてください。

$ sudo pip install scrapy service_identity

雛形の作成

ScrapyのProject雛形をつくる

Scrapyを入れたら、続いてクローラーの雛形を作っていきます。まずは、クローラーや各種設定ファイルを入れるは異なる「プロジェクト」を作成します。"scrapy"コマンドが使えるようになっているはずなので、「scrapy startproject <プロジェクト名>」で、カレントディレクトリにプロジェクトの雛形ができます。

$ scrapy startproject example_project

コマンドが成功すると以下のような雛形ができます。

$ tree example_project/
example_project/
├── example_project
│   ├── __init__.py
│   ├── items.py: 収集対象の項目を定義するファイル
│   ├── pipelines.py: データ収集後のアクションを定義するファイル
│   ├── settings.py: アクセス間隔などのクローラーの設定を行うファイル
│   └── spiders
│       └── __init__.py
└── scrapy.cfg: プロジェクト全体の設定ファイル

プロジェクトの中にクローラーの雛形をつくる

続いて、プロジェクトの中にクローラーの雛形を作ります。クローラーをつくるコマンドは「scrapy genspider -t <Template名> <クローラー名> <収集対象サイトドメイン>」です。

<Template名>は、クローラーのひな形の指定。以下の4つのうちのどれかが指定できますが、Webサイトを順に辿って情報を取得する一般的なクローラーをつくる際には、「crawl」オプションを指定します。

  • basic
  • crawl
  • csvfeed
  • xmlfeed

<クローラー名>は、あとでクローラーを走らせる時に指定する名前です。<収集対象サイトドメイン>は、ひな形の中の"allow_domain"、"start_urls"に利用されるドメイン名です。収集したいサイトのドメイン(URLから"http://"を取ったもの)を指定します。

$ cd example_project $ scrapy genspider -t crawl example-crawler www.example.com

ここまでで終わると以下のような雛形ができます。*1

example_project/
├── example_project
│   ├── __init__.py
│   ├── items.py
│   ├── pipelines.py
│   ├── settings.py
│   └── spiders
│       ├── __init__.py
│       └── example_crawler.py: クローラーの定義を行うファイル
└── scrapy.cfg

これで作った雛形のうち、以下の3つに具体的な設定を入れることでクローラー完成です。

  • settings.py
  • items.py
  • example_crawler.py

具体的なクローリング設定

収集間隔の設定(settings.py)

最初にやっておくべきなのは、settings.pyでの収集間隔の設定です。

クローラーを動かす際、適切な収集間隔が設定されておらず、休みなくそのサイトにアクセスしてしまうと、そのサービスに迷惑をかけてしまうことになりかねません。そのため、最初に以下をsettings.pyに書き込んで、1秒程度*2の間隔を空けてアクセスするようにします。

DOWNLOAD_DELAY=1

収集対象項目の定義(items.py)

続いて、収集対象項目を設定します。scrapyでは、"scrapy.Item"を継承したクラスで、出力対象項目を定義します。items.pyの雛形を開くと以下のようになっています。

import scrapy

class ExampleProjectItem(scrapy.Item):
     # define the fields for your item here like:
     # name = scrapy.Field()
     pass

ここでは、"name"のコメントを外し、"body"を追加してみます。ここで急にクラスが出てくるところがわかりにくい点だと思いますが、内容がわからずとも、ここに「<項目名> = scrapy.Field()」を追加しておけば、取得対象項目を増やすことができることがわかっていれば十分です。

import scrapy


class ExampleProjectItem(scrapy.Item):
     # define the fields for your item here like:
     name = scrapy.Field()
     body = scrapy.Field()

クローラーの設定(example_crawler.py)

example_crawler.pyは、以下のような中身になっています。「name」のところがクローラー雛形作成時に指定した<クローラー名>となっています。

class ExampleCrawlerSpider(CrawlSpider):
    name = 'example-crawler'
    allowed_domains = ['www.example.com']
    start_urls = ['http://www.www.example.com/']

    rules = (
        Rule(LinkExtractor(allow=r'Items/'), callback='parse_item', follow=True),
    )

    def parse_item(self, response):
        i = ExampleProjectItem()
        #i['domain_id'] = response.xpath('//input[@id="sid"]/@value').extract()
        #i['name'] = response.xpath('//div[@id="name"]').extract()
        #i['description'] = response.xpath('//div[@id="description"]').extract()
        return i
  • name: このクローラーの名前。最初につけた名前。
  • allowed_domains: クローリング対象となるドメイン。ここで指定されていないドメインにリンクが貼られていても収集対象にならない。
  • start_urls: クローリングの出発点となるURLのリスト
  • rules: クローリングしたページのうち、リンクを辿るURLとその動作を指定する設定です。
  • parse_item: クローリングしたベージからの情報抽出方法を指定。ページの内容は"response"という変数の中に格納されて渡されるので、その中身を"items.py"で定義したオブジェクトに入れてreturnで返すと、フレームワークがよしなに整形して出力してくれる。*3

こちらの最低限の変更点は、"rules"と"parse_item"メソッドです。

rulesは、ページに含まれるどのリンクを辿るかという設定です。Scrapyは、何も記述せずとも、<a>タグの"href"に書かれているリンク先をすべて取得してきてくれます。その取得したリンクのうち、どれを辿って、どれを辿らないのかを設定するのかをここで決めます。

rules = ( Rule(LinkExtractor(allow=r'Items/'), callback='parse_item', follow=True), )

デフォルトの「(allow=r'Items/')」は、収集対象ドメインの中で「items/」が含まれるURLを取得対象にするという意味になります。ここを対象のサイトに合わせて変更してください。

このような自動的にリンクを集めてきてくれるのは非常に便利なのですが、デフォルト動作を変えたい場合、若干ハードルが高いのが悩ましいところ。

parse_itemは、このrulesで引っかかったページデータの処理内容を書くメソッドです。引数「response」には、取得したページのデータが入っています。この取得したデータをitems.pyで定義した取得項目にマッピングします。items.pyでは、「name」と「body」を定義していたので、それとページの内容の対応付けを書き入れます。取得したページの内容はXPATHもしくはCSSのセレクタでの指定が可能です。取得対象を決める際には、取得対象のサイトの構造をChromeのデベロッパーツール等で確認すると便利です。

たとえば、以下のように変更します。そのほか具体的な指定方法は、公式サイトの例が詳しいので、そちら参照で。

def parse_item(self, response):
    i = ExampleProjectItem()
    i['name'] = response.xpath('//div[@id="name"]').extract()
    i['body'] = response.xpath('//body').extract()
    return i

ここまでで、最低限のクローラー作成は完了です。クセさえ掴んでしまえば、ほとんど自分でコードを書くことなくクローラーをつくることができます。

データ収集

作成したクローラーを動かすコマンドは、「scrapy crawl <クローラー名> -o <出力先ファイル名>」です。<クローラー名>はクローラーの雛形作成時に指定したものです。また、出力形式はCSV、JSON、JSONLinesから選択できますが、どの形式を使うかh<出力先ファイル名>に指定する、ファイルの拡張子から自動的に選択されます。

たとえば、以下のように拡張子「.jl」を使うと、JSONLinesでの出力となり、各ページが1行のJSONに対応する形でファイルにクローリング結果が書き込まれます。

$ scrapy crawl example_crawler -o output.jl

クローラーを作っていく際には、この出力結果と実際のサイトを比較して、items.pyとparse_itemsに必要なフィールドを足し引きしていくことになります。

まとめ

Scrapyでクローリングを始めるに当たって、最低限必要な内容を取り上げました。Scrapyは、非常に機能が豊富で、かつ、拡張性が高いので、これをベースにカスタマイズしていけばWeb上から有用な情報を手軽に収集することができるようになります。

これからWebクローリングを始めようとしている人の手助けになれば幸いです。

*1:*.pycは省略

*2:scrapyはデフォルトで、間隔をランダムにずらす機能が有効になっているため、実際には、ここで設定した数値×0.5〜1.5秒間となります

*3:Ruleの引数の中に「callback='parse_item'」と指定されている

MacにTensorFlowを入れようとしたら、Numpyのエラーが出たのでメモ

自分のMac (Mavericks 10.9.5) を入れようとしたら、Numpyのエラーが出て詰まったのでメモ。

TensorFlowは、公式サイトの以下の手順でインストール

[https://www.tensorflow.org/versions/master/get_started/os_setup.html#pip-installation]

sudo pip install --upgrade https://storage.googleapis.com/tensorflow/mac/tensorflow-0.7.1-cp27-none-any.whl

上記で、問題なくインストールできたものの、以下のエラーが出てimportできず。

$ python
>>> import tensorflow
(中略)
Error: numpy.core.multiarray failed to import

ググッて調べて見ると、System PythonにTensorFlowを入れると、別PATHのNumpyを読んでしまうためにエラーが出るという情報あり。

https://groups.google.com/a/tensorflow.org/forum/#!topic/discuss/O4JQjcyI-9M

In my case (using mac OS) reinstalling numpy version 1.10 with pip was not enough because pip installs in /Library/Python/2.7/site-packages> I had numpy 1.6 simultaneously in a different location /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python When importing tensorflow this was the location first sought for numpy (you can check that with sys.path). Solution: I had to manually remove numpy from this other location not used by pip with "sudo rm .r numpy". Then just restart python.

ここに書かれていた情報を参考に「/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python」以下を見てみたところ、こちらにも過去に入れたと思われるNumpyのファイルがあったので、とりあえずリネームして動作確認

cd /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/
sudo mv numpy/ numpy_old
$ python
>>> import tensorflow

こちらで問題なく動いた様子。


以下はエラーログをググった際に引っ掛けるようのエラーログ全文。

>>> import tensorflow as tf
RuntimeError: module compiled against API version 9 but this version of numpy is 6
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Python/2.7/site-packages/tensorflow/__init__.py", line 23, in <module>
    from tensorflow.python import *
  File "/Library/Python/2.7/site-packages/tensorflow/python/__init__.py", line 49, in <module>
    from tensorflow import contrib
  File "/Library/Python/2.7/site-packages/tensorflow/contrib/__init__.py", line 23, in <module>
    from tensorflow.contrib import layers
  File "/Library/Python/2.7/site-packages/tensorflow/contrib/layers/__init__.py", line 68, in <module>
    from tensorflow.contrib.layers.python.layers import *
  File "/Library/Python/2.7/site-packages/tensorflow/contrib/layers/python/layers/__init__.py", line 22, in <module>
    from tensorflow.contrib.layers.python.layers.initializers import *
  File "/Library/Python/2.7/site-packages/tensorflow/contrib/layers/python/layers/initializers.py", line 24, in <module>
    from tensorflow.python.ops import random_ops
  File "/Library/Python/2.7/site-packages/tensorflow/python/ops/random_ops.py", line 23, in <module>
    from tensorflow.python.framework import ops
  File "/Library/Python/2.7/site-packages/tensorflow/python/framework/ops.py", line 39, in <module>
    from tensorflow.python.framework import versions
  File "/Library/Python/2.7/site-packages/tensorflow/python/framework/versions.py", line 22, in <module>
    from tensorflow.python import pywrap_tensorflow
  File "/Library/Python/2.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 28, in <module>
    _pywrap_tensorflow = swig_import_helper()
  File "/Library/Python/2.7/site-packages/tensorflow/python/pywrap_tensorflow.py", line 24, in swig_import_helper
    _mod = imp.load_module('_pywrap_tensorflow', fp, pathname, description)
ImportError: numpy.core.multiarray failed to import

『プロジェクト体験ゲーム 進捗どうでしょう?』のCOMIC ZIN通販のお知らせと一緒に買いたいおすすめの薄い本たち

f:id:sechiro:20150813174048p:plain:w200:left

C88でリリースした『プロジェクト体験ゲーム 進捗どうでしょう?』は、現在COMIC ZINにて委託をお願いしています。ゲームの内容は、リンク先のブログエントリにも書いていますが、進捗報告のつらみを再現したダウト系ゲームです。

以下のリンクから通販でも購入可能です。だいぶ前から通販できるようになってはいましたが、先日増刷分を納品したので、このタイミングで改めてご紹介を。

COMIC ZIN 通信販売/商品詳細 プロジェクト体験ゲーム 進捗どうでしょう?

とはいえ、さすがにこれだけ通販で買ってもらうはあれなので、自分がC88とコミティア113で買った同人誌のうち、一緒に通販で買えるおすすめの同人誌リストもつけておきます。よろしければ、ご一緒に是非。ちなみにすべて全年齢です。1万800円以上買うと送料無料みたいなので、大人買いもおすすめ。

自分がチェックできた範囲は限られているので、「これが抜けてるぞ!」みたいなものがあれば、コメントいただけるとありがたいです。あとで自分でも足すかもです。

個人的おすすめ同人誌リスト


以上、進捗がいい人もダメな人も是非に。

コミケ3日目 東“O”-31b にて『プロジェクト体験ゲーム 進捗どうでしょう?』をリリースします。 #C88

サーバ擬人化ユーザ会ですが、無事に新作を入稿して、データにヘマをしていなければ出せると思うので、取り急ぎブログで告知。余裕があれば、告知ページを作りますが、どこまで頑張れるかわからないので。

頒布日程と場所は以下のとおりです。

【日程】2015年8月16日(日)・コミケ3日目

【スペース】東“O”-31b (Webカタログへのリンク・要ログイン)

【頒布物】 C88新作・『プロジェクト体験ゲーム 進捗どうでしょう?』(予価500円)、ほか既刊

 SELinuxシールがそれなりに残っているので、会場で買ってくれた人にはSELinuxシールもおまけでつけると思います。

 また、今回も前回と同様「ちゃんおぷ」との合同サークルになっております。

 ゲームとしては、毎ターン進捗を問われ続けながら、虚実交えつつ進んでいかないといけない誰も得しない感じのボードゲームです。(注:「プロジェクト体験ゲーム」と題していますが、現実のプロジェクトとは一切関係ありません)

ストーリーと基本ルールはこんな感じです。

『プロジェクト体験ゲーム 進捗どうでしょう』

f:id:sechiro:20150813174048p:plain:w150:left

ストーリー

 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変換ケーブルなど、換装に必要なものがひと通り揃ったキットになっています。

実際の作業

届いたものを開けて広げてみると、こんな感じ。

f:id:sechiro:20150718175529j:plain

簡単な説明書が付属しているほか、動画でも交換方法が公開されています。

www.youtube.com

動画を見てもらえばわかりますが、作業はデータをコピーして、付属のドライバーで入れ替えるだけです。

ポイントは、リカバリモードの際、「ソース」と「復元先」を間違えないようにすることでしょうか。これを逆にすると、今のデータをすべて消してしまうので、ここだけは要注意です。ちなみにデータのバックアップには、1時間半ぐらいかかりました。

f:id:sechiro:20150718181153j:plain

データを新しいSSDにコピーしたあとは、SSDを換装して、起動すると普通に動きました。思った以上にあっさり交換できたので拍子抜け。ちなみに、OSは「Mavericks」なので、ほかのバージョンだと動きが違うかもしれません。

これがSSD換装前。真ん中にあるがSSDです。

f:id:sechiro:20150718200931j:plain

次がSSD換装後。真ん中のSSDが入れ替わっています。あと、開けたついでに溜まっていたホコリを取りました。

f:id:sechiro:20150718201350j:plain

換装後の状況

その後、今まで使ってきて目立った不具合はないですが、以下の問題がありました。

  • 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」への転換についてのメモ(暫定版)・続き

前の記事の続きです。

sechiro.hatenablog.com

前の記事では、分析対象データの加工をできるだけデータ利用に近いフェーズで行うようなアプローチ、「Scheme on Read」に対して、従来のBIシステムと比較して、整理できないか検討しました。

前の記事で、現状の考えを整理したあと、似たような記事を探したところ、以下のような記事もありました。こちらはBIシステムとHadoop中心のシステムを比較するのではなく、DWH/BIシステムを中心にHadoopをETLとして使うシステムとHadoopを中心にするシステムというわけで書いていますが、「データを加工して蓄積するのか、あるいはデータは生のまま蓄積しておくのかという違い」を取り上げているところは共通していると思います。

データを加工して蓄積するのか、あるいはデータは生のまま蓄積しておくのかという違いによって、ビッグデータを分析するための基盤アーキテクチャには大きく2つのタイプに分けることができます。従来からの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ツール群も使うこともできます。

ビッグデータ分析の意義と、分析のためのシステム基盤 | NTTデータ先端技術株式会社

「Scheme on Read」は、実際のシステムが先行し、それに概念を与えたもの

前の記事では、アーキテクチャやアプローチなどの理論的な面での違いを見てきましたが、この記事と実際のHadoop中心のアーキテクチャを見ていて、その軸での整理は難しいように思えてきました。というのも、データ・ウェアハウスはデータベースに関する理論が先にあり、それをソフトウェアとして実装したのに対し、「Scheme on Read」の概念はHadoopの登場により実装が先行して、それを理解するために概念が形成されたように見えるからです。

私自身はデータ・ウェアハウスが出てきた当初のことを直接知ってはいませんが、BIシステムの成立を見ていると、Wikipediaの「データ・ウェアハウス」の項目には以下のような記述があり、データ・ウェアハウスはデータベースに関する理論的な背景を踏まえて実装されたものとされています。

データウェアの提唱はビル・インモン(William H. Inmon)氏で、1990年の著作によれば、「データウェアハウスは、意志決定(Decision)のため、目的別(Purpose-oriented)に編成され、統合(Integrate)された時系列で、削除(Delete)や更新(Update)しないデータの集合体」とされる。 データウェアハウス - Wikipedia

データ・ウェアハウスベンダのTeradataの解説記事では、ビル・インモン氏がデータ・ウェアハウスが持つべき以下の4つを特徴を著作で主張していたと書かれており、データ・ウェアハウスは当初からあるべき姿が定められていました。

  1. サブジェクト指向
  2. 統合すること
  3. 消さない・更新しない
  4. 時系列を持つ

Teradata|「第2回」データウェアハウスと単なるデータベースの違い

BIシステムは基本的にはこの考え方を実装したものと言えるでしょう。

これに対して、「Scheme on Read」は「ビッグデータ分析システム」の実装の集合から共通する考え方を抽出したもののように見えます。

このように最初の時点でアプローチが異なっているため、これを横並びにして比較するよりも、今の段階では実際にあるシステムのケーススタディをまとめ、そこから共通する考え方を抽出していくように考えるのがよさそうです。

一旦、この整理メモはここまで。このアプローチで、アーキテクチャを見ていった結果はまた別の機会に。

だらだら駄文失礼しました。


追記

以下の整理を業務視点と捉えれば、BIシステムもその一つとして整理できそうです。

  • 業務視点、業務フローでの整理
    • 収集
    • 蓄積
    • 処理
    • 分析・ビジュアライズ