finch+twirlでのhtmlレスポンスの返し方
finchでtwirlのテンプレートの出力を返したかった。
Endpoint[Text.Html]って感じでレスポンスのcontent typeを指定出来そうだが、ドキュメント読んでもText.plainの例はあったのだがText.htmlの例が無く、わからなかった。
結局これで解決はした。
val helloApi: Endpoint[Response] = get("hello") { val content = html.index().toString() val res = Response() res.content = Buf.Utf8("text/html") res.contentType = typ res }
参考
市場への興味
7月に開催された Yahoo! Japan の Hack Day では最優秀賞は「日米為替における予測モデルの提案と評価 – 機械学習による為替予測AIの実装」というテーマのチームが選ばれたという記事を読んだ。どのような結果をだして最優秀賞に選ばれたのかとても気になるところである。
「異例中の異例？ モノをつくらずに受賞」（Hack Day最優秀賞編） - Yahoo! JAPANコーポレートブログ — 「異例中の異例？ モノをつくらずに受賞」（Hack Day最優秀賞編）
最近は市場が面白くて、金融についての書籍を気の赴くままに読んでいたりする。 数字の上下とそれを統一的に説明するような構造の理解には興味をそそられる。 直近読んだ書籍で面白かったのはこちら
- 作者: 松葉育雄
- 出版社/メーカー: シーエーピー出版
- 発売日: 2014/10
- メディア: 単行本
- この商品を含むブログを見る
千葉大工学部の先生の書かれた本で、日経平均の過去データを使いながらそれがどのような統計的性質を持っているかを教科書然として分かりやすく説明している。 例えば、株式市場の値動きは基本的にはほぼランダム・ウォークであるということは広く知られているが、それを実際に確認する。 日経平均や為替やトヨタの株価などの自己相関関数をプロットしてみても、95%の信頼区間の中に収まるという。その程度ではランダムに相場は上下しているのである。
現代のポートフォリオ理論の前提となる考え方に「効率的市場仮説」というものがある。市場は効率的であり、すべての情報は一瞬のうちに価格に織り込まれてしまうという考え方だ。 価格決定モデルとしても有名なブラック・ショールズ・モデルもランダム推移を前提としている。
それでは、株取引における経験則やテクニカル分析などは全てデタラメなのだろうか。 そのような疑問を解消しようというのがこちらの本の目的の一つでもある。
テクニカル分析が成功するのは、データに時間相関があり、その時間相関を引き出せるようなテクニカル指標が利用できる場合に限られる。従来の指標がそのような性質を持ち合わせたものだろうか、この疑問に答えるのが本書の1つの目的である。時間相関があるからこそ、将来がある確率でもって見通せる。 （中略） 本書では、テクニカル分析に利用価値があるのか、どのような場面で価値があるのかを数学的に調べた結果を著した。最も重視したことは、テクニカル分析は金融デーtあに対していったい何をしているのか、売買のタイミングの適切な出し方を算出しているのか、時間相関を通してこれらの疑問に答えることである。
テクニカル分析に用いられる指標には大きく分けて2つあり、本書ではその中でも幾つかの指標について定義を与え、その指標が実際の市場でどの程度有効かを確認している。
まあ、もちろん、これらの指標が完璧にワークして今直ぐ市場で大儲け出来るような話にはならない。 しかし、このように市場がどのような性質をもって動いているのかを数学的に記述する試みは面白く、正に自分が読みたかった本だったというわけだ。
「効率的市場仮説」を前提にしたランダム・ウォークで全ての動きが説明出来るわけもなく、直感的にもそれは分かる。 例えば本書の中では、ランダム・ウォークから外れる動きをイベントやアトラクターなどと呼んで信号処理分野のインパルス応答に見立ててモデル化している。 リーマン・ショック後にブラック・スワンなんて書籍が流行ったのもまさにそのその脱効率的市場仮説的な流れだろう。
冒頭の Hackathon の為替予測みたいに、昨今の機械学習の発展と共に市場の適用も増えていくのだろうか（現状どれほど導入が進んでいるのかは知らない）
一方で、自動取引が加熱しすぎた結果についての批判も生まれていて、これはオンゴーイングな議論の的でもある。
- 作者: マイケルルイス,Michael Lewis,渡会圭子,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2014/10/10
- メディア: 単行本
- この商品を含むブログ (14件) を見る
ねーこ on Twitter: "PTSのアルゴこれだからね。他社を誘因する以外ほかにどんな目的があるの？っていう https://t.co/kHjYv2R6DI"
市場が面白いなと感じるのは、ある手法が一般的になるとそれが陳腐化してしまう所にもある。 例えば今後 Deep Learning を使う手法が有効と見做されて一般化されたとしても、それはいずれ有効で無くなる。
未来には市場の動きやそれで儲けるための手法がどのような結果に行き着いているのだろうか。 それを見られる日が楽しみである。
狭小邸宅を読んだ
不動産クラスタでちょくちょく引き合いに出されるので気になっていた狭小邸宅を読み終えた。 ペンシルハウスを売る消費者向け不動産会社の営業をしている主人公とその業界の話である。
雰囲気は以下のbotを参照
「おい、お前、今人生考えてたろ。何でこんなことしてんだろって思ってたろ、なぁ。なに人生考えてんだよ。てめぇ、人生考えてる暇あったら客みつけてこいよ」
— 狭小邸宅bot (@kyosho_teitaku) September 1, 2016
「いや、お前は思っている。自分は特別な存在だと思っている。自分には大きな可能性が残されていて、いつかは自分は何者かになるとどこかで思っている。俺はお前のことが嫌いでも憎いわけでもない、事実を事実として言う。お前は特別でも何でも無い。何かを成し遂げることはないし、何者にもならない」
— 狭小邸宅bot (@kyosho_teitaku) September 3, 2016
「売るだけだ、売るだけでお前らは認められるんだっ、
— 狭小邸宅bot (@kyosho_teitaku) September 2, 2016
こんなわけのわからねえ世の中でこんなにわかりやすいやり方で
認められるなんて幸せじゃねえかよ。最高に幸せじゃねえかよ」
ほかの人のレビューはこちらの総論と各論が面白かった。
そちらから参照されているように、このコメントはとても共感出来る。
なぜならどこからそうなったのかわからないが、仕事ができるようになった「僕」は終盤の友人たちに会う場面などからわかるように、確実にどこかが狂っているからだ。つまり狂った営業マンだけが「狭小」な家を「邸宅」として売ることができ、その狂気に感染した人間が「狭小邸宅」に住む。そんな怖ろしい日本の現在を鮮やかに描く、実力派のデビュー作だ。
『狭小邸宅』 （新庄耕 著） | 今週の必読 - 週刊文春WEB
探している住宅はその人の人生の投影である。Amazonなどのレビューでは小説の終わり方はあまり評価されていないが、物理的な住宅に投影される「狭小」な自分と「邸宅」な自分の無自覚な自意識を描いたラストシーンは個人的にはとても強烈だった。
スノーボール〜ウォーレン・バフェット伝〜を読んだ
伝説的投資家、ウォーレン・バフェットの伝記を読んだ。文庫で上中下の大作。
スノーボール(改訂新版)〔上〕 ウォーレン・バフェット伝 (日経ビジネス人文庫)
- 作者: アリス・シュローダー,伏見威蕃
- 出版社/メーカー: 日本経済新聞出版社
- 発売日: 2014/06/03
- メディア: 文庫
- この商品を含むブログ (2件) を見る
スノーボールというタイトルが付いている。初めはどういう意味かわからなかったが、これは資本が雪だるま式に膨らんでいく様を表しているらしい。Like a Rolling Stone的な趣がある。
恥ずかしながら投資についての知識はからきしだったので、とても長い書籍だったが全ての出来事が新鮮で終始飽きずに読むことが出来た。バフェットはバークシャー・ハサウェイのCEOだったという事実は知っていたが、会社の起こりが紡績事業を行っていた会社だったということは驚きだった。IT銘柄が嫌いな割にはビル・ゲイツと親交が深く、自分の財団の資産をビル・ゲイツ財団に寄付するくだりなどはなるほどという感じだった。
伝記なのでもちろん彼の人間的な部分にも触れられており、特に妻のスーザンが亡くなったシーンは物語のクライマックス的な趣があった。
この著作をきっかけにバリュー投資についての勉強してみようかなと思うようになった。
世紀の空売りを読んだ
マネー・ショートが映画化されて話題だったので原作の方を読んだ。
- 作者: マイケル・ルイス,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2013/03/08
- メディア: 文庫
- 購入: 1人 クリック: 30回
- この商品を含むブログ (20件) を見る
金融用語の知識があったほうが映画が楽しめると聞いたので、それならばテキストで楽しんだ方が良いなと思ったので書籍を先に楽しんだ。最近はある程度話題になった金融界隈の文庫を読んでいる（リーマン・ショック・コンフィデンシャル、ウォーレン・バフェット伝の二冊だけだけど）。
リーマン・ショック・コンフィデンシャル(上) (ハヤカワ・ノンフィクション文庫)
- 作者: アンドリュー・ロスソーキン,Andrew Ross Sorkin,加賀山卓朗
- 出版社/メーカー: 早川書房
- 発売日: 2014/02/07
- メディア: 文庫
- この商品を含むブログ (6件) を見る
金融界隈の物語はそのスケールの大きさが読んでいてSFのように面白いし、今回読んだ本もこれまで読んだ本の登場人物が出てきて点が線になる感じ、スピンオフ作品的な感じが尚更良い。マネーは誰しもにも関わるテーマだし、その延長線上にあのファンタジーのような世界が広がっていると思うと感慨深い。
また、とは言っても現実の世界の話なので、リーマン・ショックとは何だったのか、いかに債券市場が暴走したのか、その中でウォール・ストリートの投資銀行たちはどう立ちまわったのか、サブプライム・ローンとは、モーゲージ債とは、CDOとは、CDSとはなどなどの知識も得られるのでお得な体験になっている。
M・ルイス氏は同様に金融界隈についての著作をいくつか書いているらしい。ライアーズ・ポーカーと迷ったが、次に読む本はブーメランに決めた（リーマン・ショック後の欧州危機について著作）。フラッシュ・ボーイズ（HFTに関する著作）もOmiさんが面白いって言っていたので早く読みたい（しかしまだ文庫になっていない。ハードカバーは買う気にはならないし、Kindle版を買うのもいまいち好きではないというか文庫という形態が好きすぎるので文庫で読みたい）。
- 作者: マイケルルイス,Michael Lewis,東江一紀
- 出版社/メーカー: 文藝春秋
- 発売日: 2014/09/02
- メディア: 文庫
- この商品を含むブログ (4件) を見る
- 作者: マイケルルイス,Michael Lewis,東江一紀
- 出版社/メーカー: 早川書房
- 発売日: 2013/10/04
- メディア: 新書
- この商品を含むブログ (6件) を見る
作品の中で好きなシーンは、医師から個人投資家に転身した天才マイケル・バーリが、自分がアスペルガー症候群だったと気づき愕然とするシーンです。
embulkでgithubからpluginをインストールする方法
ビルド(Java)
./gradlew gem
ビルド(Ruby)
rake build
pkgの下にgemファイルができるので、
embulk gem install pkg/xxx.gem
する。
@satoshihirose こんにちは、git cloneして、javaなら./gradlew gem ; rubyならrake buildです。pkgの下にgemファイルができるので、embulk gem install pkg/xxx.gemとすれば良いです。
— hiroyuki sato (@hiroysato) April 22, 2016
@hiroysato @satoshihirose 手前味噌ですが、 https://t.co/9qDNGlNQ0O という方法もあります。
— joker1007に宜しく (@joker1007) April 22, 2016
Hadoop / Spark Conference Japan 2016
概要
Hadoop / Spark Conference Japan 2016に参加したチラ裏レポ、感想です。Hadoopカンファレンス初参加でした。途中仕事のメールが入ったためかなり適当にメモったので適当なこと言っていたらすみませんm(__)m
基調講演
Hadoopを取り巻く環境2016
- 濱野 賢一朗 （日本Hadoopユーザー会, NTTデータ）
- Spark Conference 2016初開催！
- Hadoop10周年！このカンファレンスは6回目、7年目。
- 去年1299名→今年1347名。今回は63%が初参加。
- 「Hadoopはひとつのものではなくなった」
- 昔はHDFSとMRだけだった。どこからどこまでがHadoopかわかりにくくなってきた。
- 昔のLinuxも同じことを言われてきた。少しずつ修練されていくと思っている。
- 今どんな変化があるのかを良く知ることが大事。
Hadoopの現在と未来
Yahoo! JAPANのデータプラットフォームの全体像と未来
- 遠藤 禎士（ヤフー）
- マルチビックデータカンパニー。
- Variety。100以上のサービス。
- Volume。649億PV。8300万ユニークブラウザ。
- Velocity。一秒間に5万アクセス。
- 全体像
- これから
- Hadoopに関する技術チャレンジ。
- データ容量が年率四倍になっている。5年後の1024倍は稟議が降りないでしょう（笑）
- 3000台のHadoopクラスタリソースを8ヶ月で使い切る。
- 広告レポートのチャレンジ。毎日13億行が追加される。10万クエリ/hour,、年3.3倍している。
- Hive on Tez。Metastoreがボトルネック。RemoteからLocalへ変更で性能が二倍。
- リソースマネージャー。アプリケーションマネージャのランチャースレッド数を2倍に。
- ハートビート数にRMが耐えられなかったので間隔を伸ばした。結果二倍。
- 他ノードのコンテナ再利用。レプリケーションファクタの増加。ラストアワープロブレム。直近のデータのレプリケーション数を増やした。10万クエリ捌けるようになった。
- NameNode。同時クエリ数を調整する。上げれば良いものでない。
- ジョブ終了時にランダムスリープを入れると良い：ジョブが一斉に終わるとログを書き込む処理がボトルネックになる。
- 今後のYahoo Japanの方向性
- USEからMAKEへ
Hadoopのストレージの現状と展望
- Todd Lipcon（Cloudera）
- HDFSの初期からの開発者。Kudoのリードエンジニア。
- 「エンジニアだからグラフが好きだ」
- 2012年からKudo開発。
- Hadoopには現在800以上のコントリビュータ。コンポネントも2→26へ。
- Basics 2006-2007。Early adapterだけ。Facebook、Yahoo。
- Producion 2008-2011。HDFS HA。HBaseがTLPに。：ランダム・アクセス
- Enterprise 2012-2015。アクセスコントロール。障害復旧。暗号化。SQLonHadoop。HBase1.0。クラウドステレージの対応。
- Next-Gem 2016-2020 RAMが安くなった。ランダム・アクセスが早くて、アナリティクが早くなるようなストレージとしてのKudo。
- Prediction。Kudoのエンプラ対応。HDFSが進化していく。クラウドストレージの重要性が増してくる。
Spark Conference Japanの開催にあたって
- 猿田 浩輔（Apache Sparkコミッタ）
- Spark熱が高まっている。
- 55%以上の人がSparkSQL, Dataframe。MLlibやStreamingも40％に近い結果に。
Spark 2.0: What's Next
- Reynold Xin（Databricks）
- SparkのPMCでTangsutenプロジェクトのリーダー。
- speed, ease of use, sophisticated analytics。オープンソースデータ処理エンジン。
- 2015は1000のコントリビュータ。R。幅広い業界に採用。
- environment, standalone48%, yaron40%, mesos11%, public cloud51%
- BI, DWH, Recommendation、ログ処理、ユーザー向けサービス、不正検出などに使われる。
- Spark2.0
- API Foundation in Spark 2.0はどうなるか。Steraming、DataFrameの成熟。ANSI SQL。
- ストリーム処理が難しい理由は、長期間のアウトプット、遅延処理、障害、分散。これが複雑なオペレーションにわたって機能しないといけない。
- SQL/DF performanceが10倍になる。
- Spark2.0は4、5月にリリース
- [余談] Fortuneのこの記事を日本ローカライズしたネタ笑った。北川景子をXin氏に伝えたの誰だったんだろ。
さくらインターネットが構築した、Apache Sparkによる原価計算システム
- 須藤 武文（さくらインターネット）
- 規模を追求する「持つ経営」なので、資産が増加していく。
- どのくらいコストが掛かっているのか。を知りたい。
- これまでの方法は。手作業に時間がかかる。十分なデータ収集が出来ない。コスト計算の明確なルールが整備不足だった。
- 原価計算の精緻化・迅速化。データ整備と社員の意識向上。分散処理基盤の構築・運用に関する知見を溜める。
- データ量は300GB/day。
- 物理サーバーは30台。総メモリ量は1.6TB。アドホックに増設している。利便性が高くて良い。
各論
YARN: Resource Manager for Analytic Platform
- 小沢 健史（NTT）
- YARNの機能
- 計算機クラスタ内におけるリソース管理
- YARNアプリケーション実行履歴
- 動作中のサービスの場所を知るための仕組み
- なぜYARNを使うのか。
- リソースマネジャー。マスタがクラスタ全体のリソースを管理。
- ノードマネージャー。スレーブが計算機毎のコンテナを管理。
- 課題：割り当てられたコンテナのリソースが全て使い切れているとは限らない。
- 実行履歴の管理。パフォーマンス・チューニング。
- TimelineServer。アプリケーション固有の情報を利用することでリッチな性能解析が可能。例：TezUI
- ServiceRegistory。ある意味サービスディスカバリー。HivemallのMixServerみたいな用途。
- YARN上におけるMR派生の並列分散処理基盤。
- Spark, Tez(Hiveの下で動く）、Flink。汎用的で非循環有向グラフ（DAG）
- MapMapReduceみたいな感じでジョブの数を減らせる。シャッフルが増えると並列性が行かせない。
- Tezは、HivePigといった高水準言語を前提に、シャッフル時のソートがないようなDAGを記述することが可能。
- コンテナの再利用で、コンテナの立ち上げ時間を減らせる。
KuduによるHadoopのトランザクションアクセスと分析パフォーマンスのトレードオフ解消
- Todd Lipcon（Cloudera）
- Why Kudo?
- TimeSeries。ファイナンシャルマーケット。
- Online reporting
- Xiaomiのユースケース。100億/day
- Kafka->Storm->Kudo
- table is horizontally partitioned into tablets. replicas 3 or 5 , Raft consensus. fault tolerance 5 seconds.
- don't need ZK or some module.
- How to work.
- カラムなストレージ。
- データはテーブルに格納する。
Project Tungsten. Bringing Spark Closer to Bare Metal
- Reynold Xin（Databricks）
- 独自のメモリ管理でJVMのオーバヘッド（空間的、GC）を克服する。（四文字のストリングも48バイトになってしまう）
- Janinoコンパイラを使用して、コードの生成時間を減らした。
- アルファソート。キャッシュフレンドリーなソート。プレフィックスを付けることで、短絡化する。
- Spark as a Compilerの話。複雑なIOはコンパイル出来ない。
感想
- Spark、HadoopやKuduのCommiter氏各位の話、分散処理基礎に始まり機能紹介やらコミュニティ今昔やら比較やらが聞けるのでとてもためになる。
- 濱野氏が最初の挨拶で言っていたようにまだまだHadoopコンポーネントは発展していくのだろうし、開発者が良い判断することは暫くは難しいままだろう。
- Maintainable Cloud Architecture of Hadoop聞きたかった😣
- データドリブン企業における、Hadoop基盤とETL ～niconicoでの実践例～も聞きたかった😣
- DynamoDBの話がどこかでされていたようで、聞きたかった😣
現在の弊社にどう活かせるか
S3/Riak上にPlazmaDBを構築して、そこにデータを貯める。HDFSなどをデータ置き場に使わないことで、運用負荷を下げて、更新しやすくなる #hcj2016
— Mr. Fiber (@repeatedly) February 8, 2016
- こう言う意見も全然わかる。
でも、SQLならBigQueryでいいような気もするけど。
— Kazunori Sato (@kazunori_279) 2016, 2月 8
- 「YARNはデータを動かさずに複数のデータ処理基盤を同居させる思想」みたいなものがデータ処理をスケールさせるためには必要であって、そのためにはストレージを中心にデータ処理周りのコンポーネントの開発が活発なHadoopエコシステムにbetするのは長期的に見て間違いない（別にストレージはAWSとかGoogleとかでも良いんだけど）
- Sparkはもちろん銀の弾丸って訳ではないのでって当たり障りのない話になってしまうのだけれど、課題に対してメリット（自分でスケールする分散処理の仕組みを用意するより楽）やデメリット（学習コスト運用コストが増える、cronとかダサい）とかを鑑みて最終的な判断する必要がある。
