2017年の振り返りと2018年の目標

2017年の振り返り

全体的な話をまずすると、体調面や仕事面であまりいい年ではなかった。
大きな出来事だと、家を建てたことかなー。家族も増え住んでいたマンションでは手狭になってきたので。

仕事

昇進しなかった

個人的に頑張ったという認識だったし、プロジェクト評価も良かったので、この結果はかなりショックだった。

もはや愚痴しかない。
理由が業務的には問題ないが、採用活動等の社内イベントのお手伝いをしなかったからという、もはやプロジェクト活動外のことがボトルネックになっていて呆気に取られたというか、何言ってるのかよく分からなかった。

そもそもで昇進するかジャッジ決めのメンバーの中で俺のことを良く思っていない人もいるそうで、なんと言うか絶望感凄い。

もうこの会社も抜け時かなって思ったが、懇意にしている上司にもう1年やろうと説得されたので頑張ることにする。

基礎力を鍛える

基礎力が足りてないって思うことが最近増えてきて、それに起因する考慮ミスも出始めてきた。

今まで何となくかわしてきたことのツケを支払わなければならないと数年前から思っていて、思っていただけだったがやっと今年から着手するようになった。

やっぱ俺の今の年で基礎的な、CPU、メモリ、OSっていうハードからって大分恥ずかしいんだけど、知らなかったんだからしょうがない。
応用情報のシラバスに沿うのが一番体系的だったので、取得を目指しながら応用情報よりももう少し深く理解していくように勉強していた。

試験はまあ落ちたんだけど、これで落ちたらしゃーないかなーって思っていたので、次頑張ることにする。

アルハラで揉めた

クソ面倒くさい案件。まさか自分が被害者になるとは思っていなかったので、親しき仲にも礼儀ありやぞと。
そのプロジェクトはちょっと前に離任していて、再オファーもあったんだけどそりゃあ断るよね。

プライベート

「アイカツ！」関連のイベントに参加できた

タイミングよく出張が重なってイベントに参加できることが多かった。

1. 3月25日「アイカツ！ミュージックフェスタ2017」（神奈川）
2. 7月23日『オールアイカツスターズ!DJ LIVE JAPAN TOUR』(東京)
3. 9月30日『オールアイカツスターズ!DJ LIVE JAPAN TOUR』(北海道)

これ以外ではディアステージのイベントにも行ったりして、「アイカツ！」から広がって、面白いこと見つけたなあという感じ。

リターンが乏しいだろう北海道ではなかなかイベントやらないのが悲しい。参加するのでやって！

「アイカツ！」系の分析がやれた

ラジオ番組とCD売り上げの分析だけど6本上げられた。

http://snofra.hatenablog.com/entry/2017/04/15/144333

ラジカツスターズ！のコーナーのメンバー別正解数を図で確認する - すのふら

ラジカツスターズ！のコーナーの未来を予測する - すのふら

ラジカツスターズ！のコーナー正解率を分析する - すのふら

アイカツ!シリーズのCD売上から見えてくるもの - すのふら

本当に『アイカツ!』は『プリパラ』に負けたのか？ - すのふら

python普段使っているけど、俺がやっている仕事とは全然違う分析系なので斬新で面白かった。

分析観点持ってないなーと思うことがやっぱり多いので書籍や他の人の分析手法真似してパターン増やしていく必要がある。

体調が悪かった

1年を通してどこか具合が悪かったり、骨折したりして体調が悪い年だった。
併せて家族の体調も良くなく、子供が入院したり、年の瀬の12月30日に傷が残る程度の怪我をしたりと散々だった。

2018年の抱負

ぶっちゃけ社内評価は絶望的なので、自身の市場評価を確認して、どこに立っているのかを見定めたい。

得た知見は（できれば「アイカツ！」に絡ませて）アウトプットしていきたい。

そのためにはまずPCを買おう。スマホポチポチは結構きつい。

仕事

基礎力を鍛える

これは2017年から引き続きやっていきたい。

応用情報に落ちたというのもあるけど、勉強していることと業務をもっと関連性を持たせながら理解していくことで成長余地を探したい。

また、直近でSQL周りでパフォーマンス等求められたりするので、そこもベースの知識をしっかりとつけるために再入門したい。

資格を4つ取得する

これは自分の価値を高めるために必要かなと思っている。転職する予定もあるので。

とりあえず、以下2つは確定なんだけど、他は何にするべきか。
一応バックエンドエンジニアを目指そうとしているので、できればネットワーク系の資格が欲しい。

1. 応用情報
2. AWS 認定ソリューションアーキテクト – アソシエイト

新しい言語を勉強する

直近で書籍を持っていて、業務の幅が広がりそうなscalaかなー。
java未経験者なので、そこのビハインドをどれだけカバーできるかってのがあるかもしれないけどやるだけやってみようかなと。

勉強会に参加する

これも自分の価値をはかるという要素に近いんだけど、自分の会社以外ではどういうことをやっているのか、自分はどの程度の立ち居地にいるのか見ておきたいなあと。

服屋に行く服を探すじゃないけど、まずはPC買うところからっていうね。

プライベート

「アイカツ！」好きの知り合いを増やす

基本ぼっちなんですわ。
イベント開始終了で楽しそうに話しているのを見ていると、まあ悲しいこと。
共有できる人を探したいなあと。

そういうのってどうやって探すもんなんですかね？

体力をつける

体重が増えてきたってのもそうなんだけど、運動していないので体力が凄い落ちてきているのをひしひしと感じる。

仕事していてもここ山場だから頑張ろうって時に頑張れなかったりするので、水泳なりジムなり行って体力をつけたい。

とりあえず最寄のプールに行くところから始める。

「アイカツ！」系の分析をもっとやる

俺が「アイカツ！」にできることはイベントやゲーム、グッズで金を落とすことと、分析して公開していくことなので引き続きやっていきたい。

あまりバズることのないブログだけど、何本かバズるのを目標にする。

ブログへのアウトプット

月1本やればよい、くらいだったので月2本くらいのペースでやっていきたい。

そのためには技術よりの内容とブログ分けないほうがいいのかなって思うし、分析じゃなきゃダメだという観点も変えるべきかなと。

シシララ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回目放送では全キャラのアフレコもしてくれるので、ホントありがてえ。

実況は一応七瀬優のベストエンディングを目指すのが目的。

ミステリアスキャラ。主人公と過ごした時間が一番短い。
唯一水着イベントがない！

だけど、この実況には2人の刺客がいて、
1人目が青森の安達妙子。

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

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

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

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

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

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

実況を見て

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

そして20年経って、ようやく福岡の松岡千恵の魅力に気づきました。

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

*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になるのはいつなのかというところを見てみる。
<放送回数と累計正解数>

○が累計の正解数。☆が100問正解だろうと思われる放送回。

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

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

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

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

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


<累計正解率と各放送回毎問題/正解数>

縦棒グラフの青が問題数。オレンジが正解数。
折れ線が累計正解率。

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

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

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

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

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

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

次に累計正解率。

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

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

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

メンバー別

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


<メンバー別累計問題数/正解数/正解率>

縦棒グラフの青が問題数。オレンジが正解数。
折れ線グラフが正解率。

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

計算方法は各メンバー別の正解数/問題数。

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

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

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

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

最下位はるか

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

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

メンバー個別

るか

みき

かな

みほ

ななせ

せな

りえ

メンバー別問題数/正解数

最後に

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設計での個人的知見のまとめ　その３ | トロこんぶ
Amazon Redshift DB開発者ガイド – データのロード処理(5).テーブルのバキューム処理 ｜ DevelopersIO
これからAmazon Redshiftを始める技術者が注意すべき２２つのポイント ｜ DevelopersIO

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

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

前回Sparkについて調べた。

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

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

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

ざっくりした説明は 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にデータを保存できるAWSのHDFS。おそらく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の違い - たごもりすメモ

Log analysis with Hadoop in livedoor 2013 from SATOSHI TAGOMORI

www.slideshare.net

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

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

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

そう思った理由っていうのも、環境設定の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のトレンド数を比較してみる。

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

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

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

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

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

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

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

それが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週だと推測される。

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

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

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

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

シングル

アルバム

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

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

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

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

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

最後に

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

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

付録

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