ビッグデータとは
ヘッドライン
いわゆる、何でもありのデータから必要なデータを抜き出し、統計処理や分析・解析を行い、様々な傾向や特筆すべき事項を見つけ出すことの総称のように使われている。
もっと単純にすれば、まずは、どんなデータでもDBに格納しておき、その後プログラム処理で意味のあるデータにしていくことである。
現在有効に活用できているのは上場企業レベルの大企業だろうが、今後中小企業・零細企業にまで落とし込まれてくるだろうことを想定して、自分自身のスキルアップを図ることで今後のビジネスへとつながると考え、練習してみようと思った。
自分が理解できるデータを使ってやってみる。
ビッグデータを分析するには、その分析の目的に従って、開発する人物が【理解していないといけない】。
たとえば、初会議における議事録をDB化してあり、その議事録からビジネスチャンスを探すようなプログラムを開発するとした場合に、まず大事なのは議事内で使われる用語や会議のルールを理解する必要がある。(もちろんその会議のルールに従って会議が進行していることが前提になるが)
会議にはいくつかやり方があるが、国連で採用されているロバート議事法は、一つの例だろう。
同じ質問を2回以上してはいけないや、答えの存在しない質問をしてはいけない、答弁する側は質問に対し逆に質問してはならないなど基本的なルールがある。
しかし、このルールをしっかり守り議事を進行してくれる、また、ロバート議事法に従って議事録を起こしてあるのであれば、分析する際にずいぶん楽になる。
たとえば会議の中で出てくる言葉から重要なキーワードを探す際に、もちろん、その単語をカウントするわけだが、ロバート議事法が存在しない会議であれば、いやがらせで何度も同じ質問をしていた場合、そのキーワードが何度も出てくることになる。
しかし、ロバート議事法を守り会議を進めているのであれば、様々な質問の中で同じキーワードが何度も出てきたことになるので、重要なキーワードといってもいいかもしれない。
そのくらいルールというのは必要だし、開発者がそのルールを理解していれば実は対応が早く終わるかもしれないのだ。
今回、あくまで練習であるということでデータの生成に時間をかけたくないので、既存の存在するデータで練習しようと思い至った。
どうせなら、1円でも収益が上がる可能性を追いかけたい
練習とはいえ、少しでも収益を上げたい。
そう考えた。
現在私ができることの中で、あまり色が変わらないものといえばネットショップ系のものだ。
ネットショップを展開し、私が責任者となり商品販売を行っている。
ノウハウもあるので、できればこの系でビッグデータの練習を行えればもしかしたらネットショップ自体の売れ行きにも影響を及ぼすような重要なヒントが見えるかもしれない。
また、結果として商品が売れれば利益が上がるわけなので、せっかくならこの系で行うことにしたいと思った。
ただし、何らかのミスが起き、現在のものに悪いほうへ影響してほしくないので、商品ラインナップは全く別のものにしようと考えた。
答えがあるデータでやることで勉強する際に問題点がわかりやすいと考えた
答えがあるのであれば、先生がいらないだろうと考えた。
もちろん、なぜその答えになるのか?という根本が理解できないこともあるだろう。
しかし、ビッグデータの活用というもの自体に一定の答えはない。多種多様だ。
なので、ある種の答えがあるデータを活用できればいいのかなと考えた。
APIの存在するものへ
近年プログラマの世界で流行しているAPIが存在するもので行おうと思った。APIは、問い合わせると答えが返ってくるアプリケーションだと思えばいい。
なので、答えが存在することになる。
この種のもので、全データをCSVなどで吐き出し可能なものを使ってみようと考えた。
もしもドロップシッピングのデータで練習
データ件数やAPIの実相、CSVの吐き出し、更新頻度などから考えて、もしもドロップシッピングのデータを展開するのが練習になるのではないかと考えた。
データ件数は約40万件。これだけのデータを一定の処理を行うことでいろいろやれるのではないかと思った。
データの展開から
csvデータは全データを一気に吐き出すことができるので何ら難しいことはない。
その、吐き出したデータをMySQLへ展開すればそれで終わりだ。
MySQLへ展開するプログラムは1時間足らずでできてしまう。
すぐさま展開。
40万レコード近くのDBテーブルが出来上がった。
カテゴリの処理
カテゴリ用のCSVデータはない。APIでカテゴリの展開は容易にできるが、今回はこの一つのテーブルから使われているテーブルを書き出す処理を考えてみようと思った。
既定のままのレコード自体で、すでに大・中・小カテゴリと分けられており、名前が入力されている。
なので、それらを重複しないようにグループ化し、残ったすべてのレコードを別のテーブルに展開すればカテゴリテーブルの出来上がりだ。
これもテーブル構成が理解できれば30分もかからずに処理ができた。
これで、カテゴリわけし、そのカテゴリへ所属している商品リストを出すのは難しくなくなった。
商品詳細ページの制作
データが展開できてしまえば、そのデータのユニークIDなどを使えば個別商品ページは容易に作れてしまう。
情報を吐き出すプログラムは10分もかからなかった。
結局勉強になったのか
残念ながらまったく勉強にならない。
なぜなら、データはすでに整理されており、そのルールに従って作られているので、ルールを知っていれば何ら難しいことはなかった。
ビッグデータとはその種のルールがあいまいなままDB化され、どこに入っているかわからない。どういう書き方がされているかわからないデータを一律で処理し、信頼に足る情報へ昇華させるものだと考える。
そう考えたとき、最初から信頼性が高いデータを使っても勉強にならない。
なぜなら、すでに99%間違いがないデータ(提供された通りの情報)を書き出してしまうので、何ら勉強になるものはなかった。
ただ、まったく進歩がなかったのかというとそうではなく、MySQLに関する知識はより深まった。
今までは、selectを使うようなものはすべてにインデックスをかけていたが、パフォーマンスをよくするためにどうインデックスをかけるのが効率的かインデックスとはそもそもどういうものなのかということを少し勉強した。
また、一時テーブルを使ってよく使うテーブルをいったんメモリに展開し処理を早くする方法や、そもそもメモリに格納する形式でテーブルを作りデータを吐き出すようにしたりしてみた。
メモリテーブルは、MySQLがシャットダウンすると、データが飛ぶので、常駐しなければいけないような商品データのようなものには適していないが、アクセスランキング的な処理や一時データ的なものには適している。頻繁に読み書きするからだ。
そうやってパフォーマンス向上に向けた技術的な知識はかなりついたことで、今回MySQLをフルで利用しているサイトを作ってみたが、MySQLの設定はインストール時のままでもMySQLの処理に1秒はかからない。表示にかかる速度は平均して約0.3秒なので、十分なパフォーマンスだ。
ただ、パフォーマンスのために無駄なフィールド展開などは一切行っていないので、データベース自体もシンプルなものになった。
PHP・MySQLの勉強にはなったがビッグデータというテーマでの勉強にはならなかった。
もう少し雑多な作りのDBを使ってまたいつか勉強してみようと思う。