すのふら

すのふら

日々の備忘録

シシララTVの『センチメンタルグラフティ』実況からの懐かしさよ

人には自身の人生を語る上で必ず言わなきゃいけないゲームがある(と思う)。
それが神ゲーだったり、クソゲーや奇ゲーだったりするんだけど、大体そんな外的なカテゴライズなんて全然どうでもいいわけ。

俺にとってはそれがセンチメンタルグラフティだったりする。

これがなければ俺はきっと元気系が好きということがDNAに刻まれることはなかっただろうし*1

クリスマスに『シスター・プリンセス RePure』の最終回をひとりで見ることもなかっただろうし、

アイマス」「ラブライブ」「プリキュア」「アイカツ」といい感じなおっさんになることもなかったはず。多分。


結果的に自分の子供に『センチメンタルグラフティ』のキャラ名をつけていた、なんてこともなかったはずなんや!


そんな無意識的に刷り込まれているゲームではあるんだけど、つい最近『センチメンタルグラフティ』の実況が最終回を迎えた。


動画

シシララTVというゲーム系のサイトの実況動画。
ニコ生とAbema freshとであるんだが、見てたのがAbema freshだったのでそっち版。

freshlive.tv

freshlive.tv

freshlive.tv

freshlive.tv

freshlive.tv

freshlive.tv

freshlive.tv
最終回はゲームライターのカワチさんのアドリブのキモさを堪能する回。


センチメンタルグラフティ』をざっくり

センチメンタルグラフティ』は1998年1月22日に発売。今年で20周年。

ざっくり内容を説明すると、幼少の頃から転向を繰り返していた主人公。
全国に散らばっている12人のヒロインの誰かから手紙を貰ったので、過去を振り返りながら女の子に会いに行くギャルゲー。

今考えるとぶっ飛んだ設定だよなー。*2


実況のざっくり

この実況は20周年ということで七瀬優役の西口有香さんとプレイする番組なんだけど、生アフレコが聞けるのがかなりレア。

当時の話が聞けたりしてリアルタイムでやっていた俺にとってはかなり感慨深い。

6回目放送では全キャラのアフレコもしてくれるので、ホントありがてえ。


実況は一応七瀬優のベストエンディングを目指すのが目的。
f:id:snofra:20180106202658j:plain
ミステリアスキャラ。主人公と過ごした時間が一番短い。
唯一水着イベントがない!


だけど、この実況には2人の刺客がいて、
1人目が青森の安達妙子。
f:id:snofra:20180106202901j:plain

MCのゲームライター、タタツグさん一押しキャラ。
とても家庭的。「だぞっ」って言うところ、いいよね。

最後の最後まで、優とどちらにするのかネタで揺れに揺れたりそんなやり取りが終始する。


そして2人目。
このゲームといえばというキャラ、仙台の永倉えみる*3

f:id:snofra:20180106202346j:plain

これだけで大体どんなキャラか分かるとは思うけど、彼女が高エンカウントで、あらゆるタイミングで出没。

正直攻略対象の七瀬優よりも登場回数が多い*4

監視されているんじゃないか?


実況を見て

俺もほぼ20年ぶりに見たんだが、あのころから変わらず大阪の森井夏穂推しは変わらなかったので、DNAに完全に刷り込まれていると言っていい。
f:id:snofra:20180106203428j:plain


そして20年経って、ようやく福岡の松岡千恵の魅力に気づきました。
f:id:snofra:20180107000644p:plain

このちょいちょい見せる女の子感すごいいです。

*1:シスプリのせい感もある

*2:しかも続編の2だと前作主人公が死ぬところから始まるという

*3:りゅん (りゅん)とは【ピクシブ百科事典】

*4:最終回のゲームの一番重要なところででてきたのは笑った

ラジカツスターズ!のコーナー正解率を分析する

これはアイカツ! Advent Calendar 2017の8日目の記事です。

アイカツスターズ!』の歌唱担当であるAIKATSU☆STARS!の歌い手さんたちがやっているラジオ『ラジカツスターズ!』について書きます。

『ラジカツスターズ!』はメンバーの中から2~7人(だいたい2人)が交代でパーソナリティをしている番組。
2016年4月からスタートしてもうかれこれ1年8か月。結構長く続いている。

その中でもパーソナルなところが見えるというか、主にるかのポンコツさを見ることができるのが『私達、AIKATSU☆STARS!です!!スターズ!!!』というコーナー。

このコーナーはひとつの質問に対してメンバーが回答を合わせてるという趣旨のもの。

正解すると「スターズポイント」を1ポイントゲットでき、それが貯まると何かご褒美と交換してもらえる。

今回はこの『私達、AIKATSU☆STARS!です!!スターズ!!!』の回答率について分析していこうと思う。


条件

  • 問題数及び正解数は、2017年12月4日放送分の第87回までとする
  • 第64回放送(2017年6月26日)は欠損しているため、問題数正解数0として計算*1
  • コーナー自体やっていない場合(初回やゲスト回など)は問題数正解数0とする
  • この分析は「スターズポイント」ではなく「正解数」の分析とする。(スターズポイントだと第54回(2017年4月17日)でボーナス+2ポイントゲットしている)


全体

100問正解まであともう少し

まず累計正解数が100になるのはいつなのかというところを見てみる。
<放送回数と累計正解数>
f:id:snofra:20171207220021p:plain
○が累計の正解数。☆が100問正解だろうと思われる放送回。

見てみようと思ったらと既に第87回で97問正解してた。ちょっと微妙な予測に……。

線形回帰で多分このくらいには100問できるんじゃないかっていうのを見ると第89回なので、来週か再来週で達成可能だと思う。
欠損している第64回を考慮しても、最低でも2017年中に達成できるんじゃないかと。

今年の残3回がすべて珍回答でメンバーとリスナーの度肝を抜く、るかだった場合は、来年まで持ち越しになるだろうなあ。


累計正解率は30パーセントを維持

次にこのコーナー自体の1回ごとの問題数と正解数、累計正解率を見る。


<累計正解率と各放送回毎問題/正解数>
f:id:snofra:20171207220641p:plain
縦棒グラフの青が問題数。オレンジが正解数。
折れ線が累計正解率。


まずは1回ごとの問題数と正解数。

縦棒グラフで設定がされていないように見えるのはそもそもこのコーナーをやっていない(欠損している第64回)ため。

これをみると0問正解で終了するのが30回までに多いという点。
これは序盤のパーソナリティが3人以上だったからだと思われる。

第23回放送(2016年9月12日)から2人体制になったので、安定――あんましてないっすねw

30回までで正解数0のときのパーソナリティをみると、るかが一番多いのでそれが原因か?


また、正解数の最高が4回なので、簡単な問題または、パーソナリティの周波数があったとしても正解が合うのは4問までということが分かる。


次に累計正解率。

これをみると大体30パーセントあたりを維持していて、直近回の第87回までを見てもこの正解率が大きく変わることはないのかなと。

だいたい1回の放送で問題数が3問程度なので、最低1問は必ず正解できているということが分かる。

これも、るか連投で平気で下がるので、連投した結果どのくらい低下するのかは気になるところw


メンバー別

メンバー別の累計問題数と正解数、正解率を見てみる。


<メンバー別累計問題数/正解数/正解率>
f:id:snofra:20171207224945p:plain
縦棒グラフの青が問題数。オレンジが正解数。
折れ線グラフが正解率。

正解率を見ると圧倒的るかが低いってわかるんだが、ランキングにしてみる。

f:id:snofra:20171207230256p:plain
計算方法は各メンバー別の正解数/問題数。

ランキングトップはみほ。

ラジオではみほの正解率が低い判断されていたりしてたんだけど、俺が見る限り、みほは常に安定して正解できている印象が強いので想定通りの結果。

続いてほぼ同正解率でせなりえが続く。

せなは正解数はメンバーの中でトップなんだけど、問題数もトップなので結果みほより正解率を上げることはできなかった。

最下位はるか

まあこれは約束されてますよねw
るかの回答はちょっとずれているというか、ちょっとどうかしているものが多い。

直近だと「ハロウィンの仮装といえば」という質問に「蜂」と答えたり(第82回)、
「お味噌汁の具の定番といえば」という質問に「味噌」と答えたり(第85回)、
よくある回答にしようと自分から言っておいて「猫によく付ける名前といえば」に「ねこ子」と自分が付けるとしたらという回答をしたりとホントとうかしてるw*2


メンバー個別

るか
f:id:snofra:20171207231641p:plain

みき
f:id:snofra:20171207231651p:plain

かな
f:id:snofra:20171207231709p:plain

みほ
f:id:snofra:20171207231718p:plain

ななせ
f:id:snofra:20171207231727p:plain

せな
f:id:snofra:20171207231742p:plain

りえ
f:id:snofra:20171207231752p:plain

メンバー別問題数/正解数
f:id:snofra:20171207233609p:plain


最後に

pythonでグラフを作成しているんだけど、ソース部分は別のところで書いてます。
snofra-tech.hatenablog.com

*1:完全にメモ取り忘れた

*2:回答もメモっているので遠藤瑠香珍回答集を作りたい

dir(cls)は何をしているんだ

Luigiという公式に某配管工の弟なフロー制御フレームワークの実装を読む日々。つらみ。

そもそもLuigiとはなんぞや?の場合、以下を読むとなんとなくイメージつくかもです。 https://qiita.com/colspan/items/453aeec7f4f420b91241qiita.com


読んでいくときにこれ何やってるんだろ?と思うことしかないんだが、 1点、dir(cls)はなにやってるんだ?ってところを調べたのでメモしておく。



端的に言うと、dir(cls)で対象モジュール内の変数とか関数とかの名前(メンバ)を返すことができる。

指定したモジュールやクラス、インスタンスなどの名前空間の名前一覧を返す関数である。
もし引数を省略した場合は現在のスコープの名前一覧を返す。
これを使用すれば、モジュールに含まれたクラスの名前や、クラス内のメンバの名前を調べることができる。
魔術師見習いのノート


上記サイトの例だと

import sys
dir(sys)
['__displayhook__',  '__doc__',  '__excepthook__',  '__interactivehook__',  '__loader__',  '__name__',  '__package__',  '__spec__',  '__stderr__',  '__stdin__',  '__stdout__',  '_clear_type_cache',  '_current_frames',  '_debugmallocstats',  '_getframe',  '_home',  '_mercurial',  '_xoptions',  'api_version',  'argv',  'base_exec_prefix',  'base_prefix',  'builtin_module_names',  'byteorder',  'call_tracing',  'callstats',  'copyright',  'displayhook',  'dllhandle',  'dont_write_bytecode',  'exc_info',  'excepthook',  'exec_prefix',  'executable',  'exit',  'flags',  'float_info',  'float_repr_style',  'get_coroutine_wrapper',  'getallocatedblocks',  'getcheckinterval',  'getdefaultencoding',  'getfilesystemencoding',  'getprofile',  'getrecursionlimit',  'getrefcount',  'getsizeof',  'getswitchinterval',  'gettrace',  'getwindowsversion',  'hash_info',  'hexversion',  'implementation',  'int_info',  'intern',  'is_finalizing',  'last_traceback',  'last_type',  'last_value',  'maxsize',  'maxunicode',  'meta_path',  'modules',  'path',  'path_hooks',  'path_importer_cache',  'platform',  'prefix',  'ps1',  'ps2',  'ps3',  'set_coroutine_wrapper',  'setcheckinterval',  'setprofile',  'setrecursionlimit',  'setswitchinterval',  'settrace',  'stderr',  'stdin',  'stdout',  'thread_info',  'version',  'version_info',  'warnoptions',  'winver'] 

こんな感じでsysの中に存在している名前を見ることができる。



でもって、Luigiの中の該当処理はっていうと、

task.py

from luigi import parameter
from luigi.task_register import Register
・
・
・
Parameter = parameter.Parameter

    @classmethod
    def get_params(cls):
        """
        Returns all of the Parameters for this Task.
        """
        # We want to do this here and not at class instantiation, or else there is no room to extend classes dynamically
        params = []
        for param_name in dir(cls):
            param_obj = getattr(cls, param_name)
            if not isinstance(param_obj, Parameter):
                continue

            params.append((param_name, param_obj))

        # The order the parameters are created matters. See Parameter class
        params.sort(key=lambda t: t[1]._counter)
        return params


for param_name in dir(cls):でcls内のメンバ分ループを実行する。
param_obj = getattr(cls, param_name)でparam_nameの属性を代入する。
f not isinstance(param_obj, Parameter):で属性が、Luigi.Parameterではない場合次行。

ってな感じ。

Redshiftのデータロード方法についてメモ

Redshiftのデータロード方法について、初めて触れるところがあるのでメモする。
データのロード - Amazon Redshift


Insert

COPYコマンドが推奨される。

COPY コマンドは Amazon Redshift の超並列処理 (MPP) アーキテクチャを活用し、Amazon S3 のファイル、DynamoDB テーブル、リモートホストから出力されたテキストのいずれかから並列でデータをロードします。
大量のデータをロードする場合、COPY コマンドを使うことをお勧めします。個々に INSERT ステートメントを使ってテーブルにデータを入力すると著しく時間がかかる場合があります。
または、データがすでに他の Amazon Redshift データベーステーブルに存在する場合、INSERT INTO ... SELECT または CREATE TABLE AS を使用するとパフォーマンスが改善します。
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/t_Loading_tables_with_the_COPY_command.html

普通にInsertすると並列で処理されるから遅いってことかな?
具体的にどのくらい変わるのかっていう点は、計測していないから折見てやってみるか。


Bulk insertを使って、データを一気にインポートする。

その際、テーブルのkey重複等は見ないので、実行すればするほど同じデータが蓄積される。
なので2回実行されないようにするか、実行されたときの設計はしっかり考えなければいけない。


またCOPYコマンドを実行する際、インポート元のS3のcredentials情報を明示的に指定しなければならない?*1ので、
config等に情報を保持するか、CLIで登録されている情報を取得してあげる必要がある。


テーブル生成するときにSORT KEYを定義しておけば、COPYコマンドを実行時初回のみソートが実行される。


Update/Delete

通常通りSQLのupdate/delete文で対応。

ここまではプロジェクトで触ったことでなんとなく知ってる。


insert/update/delete後のデータソートについて

ここからがお初事項。

COPYコマンドで随時コピーすると、2回目以降のCOPYコマンドはソートされないままテーブルに蓄積される。 また、update・deleteを行った後は、テーブルをクリーンアップしないと未ソート領域にデータが蓄積されてクエリ実行時の処理速度が低下する。

データ総数が数百件ならいいけど、数万~億件だとするとこれが致命傷になりかねない。

じゃあどうするかって、クリーンアップするんだが、redshiftだとどうするかというと、VACUUM コマンドを使用する。

一括削除、ロード、一連の増分更新の後にテーブルをクリーンアップするには、データベース全体または個々のテーブルに対して VACUUM コマンドを実行する必要があります。
テーブルのバキューム処理 - Amazon Redshift

ただ、テーブル上での未ソート件数が多い場合はVACUUMコマンドよりもディープコピーがいいよう。

テーブルにソートされていない大規模なリージョンがある場合、ディープコピーの方がバキューム処理より高速です。
欠点としては、ディープコピー処理中は同時更新を実行できません。バキューム処理では実行できます。
ディープコピーを実行する - Amazon Redshift



まだ実際に触ってみたわけではないので、実際に触って癖が分かったらまたメモする。

以下備忘録としてメモ
Redshift設計での個人的知見のまとめ その3 | トロこんぶ
Amazon Redshift DB開発者ガイド – データのロード処理(5).テーブルのバキューム処理 | DevelopersIO
これからAmazon Redshiftを始める技術者が注意すべき22つのポイント | DevelopersIO

*1:調べたかぎりはそうだったので

EMR起動時のインストールコンポーネントについて調べる

前回Sparkについて調べた。

次はSpark、というかhadoopをEMRで立てるので、どういう設定になっているのかを調べる。

インストールされるコンポーネントだけで今は精一杯なので、とりあえずそこだけわかっていることをメモしておく。


インストールされるコンポーネント

f:id:snofra:20171113194630p:plain ざっくりした説明は Amazon EMR 4.x リリースバージョンの詳細 - Amazon EMR を参照

2017年11月13日現在、emr-5.4.0かつSpark2.1.0を入れる。
その場合は、Cluster ManagerはYARNが入るっぽい。


EMRFS(EMR ファイルシステム)

EMRFS は、Amazon S3 にデータを保存する クラスターを可能にする HDFS の実装です。
EMR ファイルシステム (EMRFS) の使用 - Amazon EMR

→S3にデータを保存できるAWSHDFS。おそらくHDFSを併設できる。

Amazon EMR および Hadoop は通常、クラスターを処理するときに以下のうち少なくとも 2 つのファイルシステムを使用します。
ストレージシステムとファイルシステムで作業する - Amazon EMR


emr-goodies

Hadoop エコシステムに役立つ追加のライブラリ 具体的にどのようなライブラリが入っているのかはよくわからず。

EMRのインスタンス上から調べてみると、構成は以下

/etc
└── var
 └── aws
  └── emr
   └── packages
    └── bigtop
     └── emr-goodies
      └── noarch
       ├── emr-goodies-2.4.0-1.amzn1.noarch.rpm
       ├── emr-goodies-hadoop-2.4.0-1.amzn1.noarch.rpm
       └── emr-goodies-hive-2.4.0-1.amzn1.noarch.rpm

これだけ見ると、hadoopとhiveの追加ライブラリがあるってことはわかるけど、emr-goodies-2.4.0-1.amzn1.noarch.rpmは何者なんだろ。


hadoop-client

'hdfs'、'hadoop'、'yarn' などの Hadoop コマンドラインクライアント。


hadoop-hdfs-datanode

ブロックを保存する HDFS ノードレベルのサービス 。
data nodeはHDFSのSlave node内に存在している。
https://oss.nttdata.com/hadoop/hadoop.html
複数マシンへHadoopをインストールする (1/3):CodeZine(コードジン)


hadoop-hdfs-namenode

ファイル名を追跡し、場所をブロックする HDFS サービス。
name nodeはHDFSのMaster node内に存在している。 https://oss.nttdata.com/hadoop/hadoop.html
複数マシンへHadoopをインストールする (1/3):CodeZine(コードジン)


hadoop-hdfs-library

HDFS コマンドラインクライアントとライブラリ。


hadoop-httpfs-server

HDFS オペレーションの HTTP エンドポイント。

httpfsっていうのは、「HDFS over HTTP」のことらしい。
じゃあそれ何なのよってことで調べると

HttpFS can be used to transfer data between clusters running different versions of Hadoop (overcoming RPC versioning issues), for example using Hadoop DistCP.

HttpFS can be used to access data in HDFS on a cluster behind of a firewall (the HttpFS server acts as a gateway and is the only system that is allowed to cross the firewall into the cluster). https://hadoop.apache.org/docs/stable/hadoop-hdfs-httpfs/index.html


HttpFSは、Hadoop DistCPなどを使用して、異なるバージョンのHadoopを実行している(RPCバージョン管理の問題を克服する)クラスタ間でデータを転送するために使用できます。

HttpFSは、ファイアウォールの背後にあるクラスタ上のHDFS内のデータにアクセスするために使用できます(HttpFSサーバーはゲートウェイとして機能し、ファイアウォールクラスタに渡すことができる唯一のシステムです)。

以下サイトの分かりやすい絵を見るに
Hoop(httpfs)とwebhdfsの違い - たごもりすメモ

www.slideshare.net

  • httpFS Serverってやつがいる。こいつはクライアント側とHDFS側の間に立っているやつ。
  • クライアントがHDFSからデータを取ってきたいときは、httpFS Serverに対してはhttp REST APIでアクセスする。
  • httpFSサーバ側はクライアントのリクエストを受け取ったらHDFSからデータを取ってきて返す。

こんな感じなんだと思う。

それを踏まえてEMRを見ると、初期状態だとおそらくMaster node内に存在しているんじゃないかなーと推測。

f:id:snofra:20171113201058p:plain

そう思った理由っていうのも、環境設定のshellやxmlの設定を見る限りMaster node内を指定しているように見えたから。

/etc/hadoop-httpfs/conf.empty/httpfs-env.sh

# The hostname HttpFS server runs on
#
# export HTTPFS_HTTP_HOSTNAME=`hostname -f`

/etc/alternatives/hadoop-conf/hdfs-site.xml

  <property>
    <name>dfs.namenode.rpc-address</name>
    <value>ip-xx-xx-xx-xx.ap-northeast-1.compute.internal:8020</value>
  </property>

  <property>
    <name>dfs.namenode.http-address</name>
    <value>ip-xx-xx-xx-xx.ap-northeast-1.compute.internal:50070</value>
  </property>

  <property>
    <name>dfs.namenode.https-address</name>
    <value>ip-xx-xx-xx-xx.ap-northeast-1.compute.internal:50470</value>
  </property>


hadoop-kms-server

Hadoop の KeyProvider API に基づく暗号キー管理サーバー。
EMRのHDFS部の暗号化はデフォルトでhadoop KMSを使用するらしい。

Hadoop KMS – Hadoop Key Management Server (KMS) - Documentation Sets
Apache Hadoop 2.9.1 – Transparent Encryption in HDFS


透過的なデータ暗号化であるそうなんだが、透過的なデータ暗号化って何ぞや?
ググってみるとRDB系の要素で使われるみたい。
透過的データ暗号化の概要

アプリケーション(SQL)側で暗号化/復号処理をしなくても、DBのデータファイルが暗号化される機能です。
データファイルや物理メディア(HDDなど)の窃取・盗難対策に有効です。
一方で、アプリケーション側にSQLインジェクションなどの脆弱性がある場合には、何の保護にもなりません。
MySQL 5.7の透過的データ暗号化


hadoop-yarn-nodemanager

Slave node上に設定。YARN上で各Slave nodeのリソース状況を確認できる。 分散処理技術「Hadoop」とは:NTTデータのHadoopソリューション


hadoop-yarn-resourcemanager

Master node上に設定。YARN上でNodeManagerの管理やアプリ自体の実行状況を確認できる。
分散処理技術「Hadoop」とは:NTTデータのHadoopソリューション


spark-client

Sparkのクライアント


spark-history-server

Sparkのジョブ履歴を格納するサーバー


spark-on-yarn

YARN のメモリ内実行エンジン


spark-yarn-slave

YARN スレーブで必要な Apache Spark ライブラリ



正直全然わからず。
もう少しレベルが上がったらhadoopについてもっと深堀っていきたい。

本当に『アイカツ!』は『プリパラ』に負けたのか?

前回、アイカツ!シリーズのCD売り上げ枚数から現在の状況を見てみたんだけど、やっぱりここははずしちゃダメなんじゃないかという点を分析する。

それは

プリパラにアイカツ!は負けたのか?


対象とするターゲット層やコンテンツ的にもアイカツ!とプリパラはライバル関係と言っていい。

そして、結構よく聞くアイカツ!はプリパラに負けた」
それははたして本当なのかをCD売り上げと検索数から分析する。


前回に引き続き予防線張っとくと、結果的に優劣の話をしますが、アイカツ!やプリパラというコンテンツがダメだとかそういう話ではないので念のため。
そういう感じなんだな程度で抑えてもらえれば

条件

アイカツ!シリーズの分析条件は前回と同様

・プリパラのCDの売り上げ枚数は以下サイトを参考にする
anisonsinger.blogspot.jp

・プリパラのトレンドについてはgoogleトレンドを使用(検索ワード:プリパラ)
Google トレンド

アイカツ!とプリパラのシリーズ全体の売上推移とgoogleのトレンド数を比較

アイカツ!とプリパラシリーズ全体の売上推移とgoogleのトレンド数を比較してみる。

これで、アイカツ!がプリパラに負けた」瞬間があるのかどうかが見える。

f:id:snofra:20171110204130p:plain

放送時期が分かりやすい用に色づけしてみた。

『プリパラ』は『アイカツ!』と『アイカツスターズ!』を跨ぐように放送されている。
アイドルタイムプリパラ』はまだまだ始まったばかりって感じ。


以下、明記しないけどグラフ上の色はそれぞれ以下を意味してます。
・緑系色:プリパラシリーズ
・赤黄色系:アイカツ!シリーズ


プリパラがアイカツ!を追い抜かした2016年1月

f:id:snofra:20171110204051p:plain

細かい波で示されているのがトレンド数。
どれだけその言葉で検索されたのかってやつ。

それをみると、『プリパラ』が『アイカツ!』を完全に追い抜かした時期がある。

それが2016年1月


アニメは
アイカツ!』が166話「私が見つけた最初の風」(2016年1月7日)
『プリパラ』が77話「対決!ウィンターグランプリ」(2016年1月4日)
が放送された時期。

データカードダス
アイカツ!』が「2016年シリーズ2弾」(2015年11月26日)
『プリパラ』が「5th ライブ 1月 たいけつ!ふゆのグランプリ!」(2015年12月25日)
が稼動している。

この時期、『アイカツ!』は大空あかり編(3期~4期)が終わりに
差し掛かってきている時期。


アイカツ!』の終了のきっかけになっただろう時期

アイカツ!』終了のきっかけになった時期は恐らく、2015年10月第3週だと推測される。


なぜなら、ここで初めてトレンド数が逆転するから。

f:id:snofra:20171111145037p:plain

その前から差自体もかなり縮まってきており、『アイカツ!』の変わる時期がきた瞬間だったのだと思う。


CDアルバムがあまり売れていないプリパラ

次にシングルとアルバムの売り上げ枚数を比較して、どのくらいの差が発生しているのかを見る。

シングル
f:id:snofra:20171110204056p:plain

アルバム
f:id:snofra:20171110204100p:plain

これを見て顕著なのが、トレンド数(人気)はアイカツ!シリーズを超えたプリパラシリーズだが、CDアルバムは売れていないということ。

ここから恐らくプリパラを見たり、ゲームしたりする人はあまりCDにお金を使っていないということが分かる。


また、売り上げ枚数トップ10はほぼi☆Risで占められている。

f:id:snofra:20171111150529p:plain

アルバムは売れていないという点から、購入層はi☆Risが好きな層になるのだろうか。

プリパラ好きでi☆Ris好きであれば、i☆Risの中の人が声をやっているプリパラのアルバムも買うはず。


最後に

前回も書いたけど、
アイカツ!シリーズ好きな人、CD買おう。これ冗談じゃなくマジで。


集計に当たってグラフの作成はpythonで実装している。
ソースコードについては以下に記載したので、気になる人は是非。
snofra-tech.hatenablog.com


付録

例によって使ったデータを置いておく。

f:id:snofra:20171110204543p:plain


f:id:snofra:20171111152005j:plainf:id:snofra:20171111152018p:plainf:id:snofra:20171111152024p:plainf:id:snofra:20171111152029p:plainf:id:snofra:20171111152036p:plainf:id:snofra:20171111152045p:plain

apache Saprkについて最初の調査

仕事でpySparkを使うことになりそうなので、事前学習中。
まずはそもそものSparkについて勉強するために以下あたりで勉強。

初めてのSpark

初めてのSpark

この本、Sparkバージョンが1.4でめちゃくちゃ古い(本日時点で最新バージョン2.1.2)ので、詳細なところというよりは根本を抑える。
併せて、ここにも目を通す。

mogile.web.fc2.com

英語さっぱりな俺にはホンマ神のようなサイトやで……。

更に更に併せてqiita等先人のお力もお借りする。ありがてえありがてえ

めちゃくそ素人なので、間違っていること書いている可能性かなりあるよって予防線張っとく。
自信ニキ指摘オナシャス

Apache Sparkについて

Apache Hadoopという、大きなミドルウェアの中のひとつのフレームワークという考え方でいいのかな?
SparkのほかにMapReduceがいて、MapReduceよりも処理が速いってことで今主流のフレームワーク

f:id:snofra:20171109165423p:plain

YARNってやつがいるが詳細はまだよくわからないので一旦置いておく。
あの日見たYARNのお仕事を僕達はまだ知らない。


Sparkはどのような特徴があるのか

Sparkのサイト翻訳を見ると

Apache Sparkは高速で汎用的なクラスタコンピュータシステムです。Java, Scale, PythonおよびRの高レベルのAIPを提供し、一般的な実行グラフをサポートする最適化されたエンジンを提供します。SQLおよび構造データのためのSpark SQL機械学習のためのMLlib、グラフ処理のためのGraphX およびSpark Streamingを含む高レベルのツールの充実したセットもサポートします。 概要 - Spark 2.0.0 ドキュメント 日本語訳

要はめちゃ速で汎用的で、いろんな言語に対応しているし、機械学習とかそういうのもできるよってことかな。

なんでめちゃ速なのか?ってSparkのwikipediaにも書いてあるとおり、

フォールトトレラントシステムで管理され、複数マシンのクラスタに分散されたデータ項目の読み取り専用多重集合であるRDD(resilient distributed dataset)と呼ばれるデータ構造を中心とするアプリケーションプログラミングインターフェイスを備えている。
SparkのRDDは、 分散共有メモリの (意図的に)制限された形式で提供する分散プログラムのワーキングセットとして機能する。
Apache Spark - Wikipedia

という2点あるから。


1点目 RDDというデータ構造

と書いておいてアレだが、Sparkのバージョン2.0以降はRDDよりもRDDを基盤としたDataFrameがよく使われるので、RDDベースでの話はやや古すぎるかも。
って前札幌の勉強会で聞いた。

www.slideshare.net

RDDっていう思想はDataFrameになってもあると思うので、詳細よりも考えかたを押さえておく。

RDDはその言葉から障害耐性を持つ並列可能なデータ構造。
「フォールトトレランス *2 で並列処理可能なコレクション」・「コレクションはイミュータブル」とのこと。

RDDのフォールトトレランスは

RDDのいずれかのパーティションが喪失すると、最初にそれを生成した変換を使って自動的に再計算されます。 Spark プログラミング ガイド - Spark 2.0.0 ドキュメント 日本語訳

とあるので、データが壊れたやノードの速度が低下した場合は再実行してデータを再計算するという感じ。

再計算をしても同じ結果が出るようにイミュータブルにしなくてはならない。
前のデータ書き換えることが可能だったら、データがぶっ壊れるので。


2点目 データをキャッシュしておくという考え

MapReduceとの比較になるのが主だけど、それと比べてなぜめちゃ速なのかって、HDFSへのアクセス数を極力抑えるという思考だから。IOのオーバヘッド減らせば速いよね的な。

ここの23p~24pがかなりわかりやすいが、クソ適当な絵で描くと

www.slideshare.net

f:id:snofra:20171109165426p:plain

ジョブが多ければ多いほどHDFSからデータをロードする時間がかかって、その分実行時間がかかってしまう。
その点からSparkはデータをメモリ内に取り込んで(インメモリ内)で処理してしまうので、IOのオーバヘッド時間を減らせるのでより速い。

f:id:snofra:20171109165429p:plain

また、上記Sparkの考え方から何度も使用するRDDは毎度計算すると時間かかるから、RDD自体をメモリに確保しとこうねってことが可能。
これがRDDの永続化ってやつ。

f:id:snofra:20171109165433p:plain


クラスターについて

最初にも書いたけど、Sparkはクラスタコンピューティングフレームワークなので、複数のクラスタで分散する。

Spark公式の概要図 f:id:snofra:20171109170503p:plain


Driver Program

Spark アプリケーションの実行管理や制御を行うもので、main メソッドを含むプロセスとなります。またドライバはSpark アプリケーション毎に1つ存在し、アプリケーションの環境(SparkContext)を作る役割を担っています。 Spark のアーキテクチャ概要

ということなので、マスターノードに該当するところ。こいつから処理が開始する。


実行時にSparkContextってやつで環境の仕込みをする。

そうはいってもこいつがいったい何者なのか、『初めてのSpark』を読んでもよくわからんかったので、sparkのドキュメントを読む。

Main entry point for Spark functionality. A SparkContext represents the connection to a Spark cluster, and can be used to create RDDs, accumulators and broadcast variables on that cluster. SparkContext (Spark 2.0.2 JavaDoc)

google翻訳曰く

Spark機能のメインエントリポイント。SparkContextは、Sparkクラスタへの接続を表し、そのクラスタRDD、アキュムレータ、およびブロードキャスト変数を作成するために使用できます。

とのことなので、多分以下のようなことをやっているんだと思う。
1. マスターノードとスレーブノード間の接続
2. ワーカーノードに、RDDと、アキュムレータ、ブロードキャスト変数を渡す。

ここで、アキュムレータとブロードキャスト変数というものが出てきたので、確認すると

アキュムレータ

CPUで出てくるやつ。Pythonだとitertools.accumulateね。
要は前の値と加算して、その結果を蓄積していくもの。1,2,3,4,5だったら、1,3,6,10,15みたいに前までの計算結果と加算させていく。

Sparkでの使い方は主にデバッグ用で、処理実行時のクラスタのイベント数をカウントしておく。


ブロードキャスト変数

要は定数で、Driver Programで作成した定数を各ワーカーノードに渡す。
ブロードキャスト変数がいい理由は、読み取り専用という点と、大きいサイズの定数の場合オーバヘッドが少ないから。逆に小さいサイズの定数はオーバヘッドが大きい可能性がある。
Spark 共有変数


ContextはSparkContext以外にもContext系はHiveContextとSQLContextがある。 *3

SQLContextは

Spark SQLを利用するためには、SparkContextに加えてSQLContextが必要。SQLContextはDataFrameの作成やテーブルとしてDataFrameを登録、テーブルを超えたSQLの実行、キャッシュテーブル、そしてperquetファイルの読み込みに利用される。 Spark SQLサンプルアプリの実行

とのことなので、DataFrameを使用する今のSparkでは必須で準備しておかなくてはいけないものっぽい。

HiveContextはHiveQLを使用するために必要。とさらっと


Cluster Manager

Spark アプリケーションをクラスタ上で実行するためには、クラスタのリソース(メモリやCPU など)の確保を行ったり、スケジューリング管理を行う必要があります。それを行うのがCluster Manager の主な役目となります Spark のアーキテクチャ概要

Cluster Managerには3つのオプションがあって、そのうちひとつを選択するよう。
ジョブスケジューリング - Spark 2.0.0 ドキュメント 日本語訳


スタンドアロンモード

Sparkに組み込まれている標準モード

YARN

YARN上でSparkを起動する。
YARNはHadoopクラスタのリソース管理や、Hadoop上で動作するアプリケーションのスケジューリングを担当するので、そちらに一任する形?
あの日見たYARNのお仕事を僕達はまだ知らない。

Mesos

Apache Mesosで管理されるハードウェアクラスタ上で実行。
利点は、Sparkと他のフレームワークの間の動的なパーティションと、Sparkの複数のインスタンス間のパーティションのスケール
Mesos上でSparkを実行 - Spark 2.0.0 ドキュメント 日本語訳


Worker Node

クラスター。これら(executer)が分散して作業を行う。
処理の最小単位はtask


セキュリティ

共通鍵暗号方式をサポート。
*4 認証はspark.authenticate 設定パラメータを使って設定。
共通鍵暗号方式なので、Spark側と通信側で同一鍵を持っておく必要がある。
セキュリティ - Spark 2.0.0 ドキュメント 日本語訳


Jobの実行状況を覗かれたくない(Cluster Managerを見られたくない)場合、javax servlet filtersで認証等ができるようになるみたい。 Secure Spark


Sparkはコンポーネント間の通信を暗号化することが可能。プロトコルごとでSSL/TLSにできる。
Secure Spark
認証はSASLをサポート。


うーん、SASL認証って何ぞや?

SASLとはSimple Authentication and Security Layer
インターネットプロトコルにおける認証とデータセキュリティのためのフレームワークである。
Simple Authentication and Security Layer - Wikipedia

また、

SASLとはSimple Authentication and Security Layerの略であり,簡単に言ってしまうと認証のためのフレームワークのようなものです。SASLを使用することにより,開発者は既存のライブラリや仕組みを再利用することができ,利用者にはチャレンジ・レスポンス認証などの安全な認証方式を提供することができます。 第18回 OpenLDAPとSASL:そろそろLDAPにしてみないか?|gihyo.jp … 技術評論社

とあるので、どうやらチャレンジ・レスポンス認証 *5で認証する方式っぽい?


うーんなんとなくわかったけど、全体はよくわからないので触ってみて感じつかむしかないかなー。

*1:そもそもクラスタって何ぞや?っていう場合はここで。
http://wa3.i-3-i.info/word12487.html
複数のコンピュータがひとつのコンピュータっぽくふるまうこと。
ということなので、マスターノード(mainがいるところ。基本1つ)とスレーブノード(分散処理するところ。複数)が1つの処理しているってこと。

*2:フォールトトレランスってなんだって人は以下で。要は障害に対してどう備えるか。身近なパターンだと地震起きたときどうする的な?
http://wa3.i-3-i.info/word14813.html

*3:HiveContextとSQLContextの性能比較
SparkSQL - HiveContext/SQLContextの性能比較

*4:共通鍵暗号方式が分からない場合はここで。
http://wa3.i-3-i.info/word1837.html

*5:チャレンジ・レスポンス認証が分からない場合はここ。
http://wa3.i-3-i.info/word12765.html
要は認証サーバ側から要求される毎度異なる値(チャレンジ)とパスワードを合わせた値(レスポンス)とIDを認証サーバに送って、認証サーバ側はレスポンスからパスワード抽出する認証方法。