双六工場日誌

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

ISUCON 4にチーム「ヤキトリ缶(タレ)」で参加したが、いまいちパッとしない感じだった #isucon

先週開催されたISUCON4に、去年に引き続き参加してきました。

チームメンバーは去年と同じ@と@。チーム名は、去年に引き続きチームミーティングした時に目の前にあった食べ物です。ちなみに去年のチーム名は「勝浦タンタンメン」。

参加日は1日目、仕様言語は去年に引き続いてPython。Goが有利みたいな高度な情報戦も流れていたのですが、去年、Pythonで勝てなかった悔しさから今年もPythonで再挑戦と決めていので、特に言語選択では迷いませんでした。

結果

結果から言うと、タイトルの通りいまいちパッとしない感じで、予選時に提出したスコアは30000弱。予選1日目からベンチマークに見直しがかかったので、更新後のBenchmark v2で、後日確認したスコアはだいたい35000。最終結果の発表は、10/6(月)なのでまだわかりませんが、予選通過ラインには届かなさそうな気配。

今回やったこと

今回やれたこと/やろうとしてやりきれなかったことをざっくり。

  • やれたこと
    • login_logテーブルのインデックス追加: 3000 → 10000ぐらい
    • usersテーブルへのip, last_loginの追加: 10000 → 25000ぐらい
    • index.htmlの静的ファイル化とNginxからの静的配信 → 2000ぐらいアップ?
    • インフラ側はポート枯渇に対応するカーネルパラメータの設定とかNginx-gunicorn間の通信をUnixドメインソケットにするなど、動作に必要な設定のみ。
/etc/sysctl.conf
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 10000 65535
  • やりきれなかったこと
    • lock_user, banned_ipのロジック改善
      • アプリ上では、ログイン失敗数をカウントするところまでできてはいたんですが、初期データの反映が間に合わず、提出は断念。
    • ミドルウェアのチューニング
      • MySQLを5.5 -> 5.6 入れ替えたつもりだったけど、提出AMIはそうなっていなかった。。。そのほか、最後、アプリの実装が間に合わなさそうと見切りをつけて、こっちをやっていればもう1, 2割はなんとかなったかも。

前回のISUCON3の予選では、結果として予選の環境とベンチマークに特化したスコア稼ぎで予選を突破してしまった*1ので、今回は普通のチューニングで着実にスコアを上げていく方向で進めたのですが、いろいろ手間取っているうちにタイムアップ。

飛び道具には手を付けず、とはいえ、超絶アプリ改修もなしの至って普通のチューニングです。

自分たちのチームではこの程度のチューニングができれば予選は通過できると踏んでいたのですが、フタを開けてみると今年は去年以上にレベルが上がっていて、4万以上のハイスコアを出すチームが多数。その勝負の舞台に乗りきれなかった感じです。この辺りの読みと判断も含めてISUCONの勝負なんですよね。。。

当日までの流れ

対策ミーティング

僕たちのチームメンバーは、会社もバラバラで一緒に開発した経験もないため、去年のISUCON本戦ではお互いのやっていることがバッティングしたり、開発方針を共有したりするのに手間取ったので、一旦メンバーで集まって、去年のISUCON予選の問題を題材にして、チーム開発の方法を確認。実質的にはGithubハンズオンで、Mergeリクエストベースで開発することを決めて手順確認。

参加者ブログを見ると、1台のサーバ上のファイルを書き換えたという侠気あふれる報告もありますが、それができるのはいつも一緒に作業してて、阿吽の呼吸があるからだと思うんですよねー

なので、一手間かかりますが、Mergeリクエストを送って、各人が編集内容を確認できるようにしました。

去年のISUCONブログを見ても、役割分担を完全に決めてしまって、それぞれの作業は見ないで進めたって話がほとんどなんですが、即席チームだとなかなかそうも行かず。

本当はもっと対策ミーティングをやったり、ミドルウェア系の秘伝のタレを用意したりしたかったのですが、結局なかなか集まる時間を取ることができず、ISUCONがあった週は自分が毎日終電を逃すスパイラルに陥っていたので、最低限の開発手順と視点の共有ぐらいの準備で本番に臨みました。

当日の流れ

当日の流れを箇条書きで。

  • まずはAMIを起動して、アプリ確認。銀行アプリかと見せかけたログインするだけのアプリ。
  • ベンチマークを掛けてみる。MySQLの負荷が高い。
  • 開発環境として、メンバーごとにインスタンスを作成。
  • リポジトリの作り方をミスって作り直したりしてて30分ぐらいロス。立ち上がりに時間がかかる。

  • 午後一でアプリを読んだ結果を共有

    • login_logをなめて、ユーザの最終ログイン時間、ロックユーザ、BAN IPを取ってる
    • login_logを最後になめてレポートを作ってて、それがこけるとスコアが登録されない
    • login_logにはINDEXが貼られていない
    • usersテーブルは一切更新されない(初期ユーザのみ)
    • 去年引き続き、1台のサーバにベンチマーク共存しているので、Nginxで返したり、インメモリアプリ化による高速化が効きそうな作り。
    • 自分は一旦、通常のWebアプリとしてのチューニングを実施し、ほかのメンバーがインメモリ化を検討する方向に。
  • 最終ログイン時間とログイン失敗数は、usersテーブルに書いておけばlogin_logを舐める必要はない
  • banned_ipはip管理用のテーブルを追加すればよさそう。(これは最後まで実装間に合わず)
  • 最終的には使わない予定だけど、login_logを舐めるのがヒドいので、とりあえずINDEX貼る
CREATE INDEX id_idx_1 ON login_log (ip, id);
CREATE INDEX id_idx_2 ON login_log (user_id, id);

-> これだけで3000 -> 10000〜までスコアアップ

  • login_logも初期データがあって、最終ログイン時刻とログイン失敗回数はそのデータを反映する必要がありそう。
  • @に、awkワンライナーで最終ログイン時刻一覧を作ってもらって、最終ログイン時刻だけ反映するSQLを作成
  • usersテーブルに最終ログイン時刻とIPを追加して、ログイン時にアップデートするよう変更。
  • 最終ログイン時刻と最終ログインIPの仕様を誤解して、手間取る。
  • ここまでの改修で20000を超えるようになったが、ポート枯渇などのエラーが出るので、カーネルパラメータを変更し、Nginxとgunicorn間の通信をUnixドメインソケットに変更。
  • このタイミングでMySQLを5.6に変更。skip-innodb-doublewrite、innodb_flush_method = O_DIRECT_NO_FSYNC までなら通常の永続化は保たれてセーフだと踏んで設定。これでちょっとスコアアップ。
    • ただ、最終提出AMIへの反映が漏れていたことが、あとで発覚。
  • 続いて、ログイン失敗回数をusersテーブルに書き込むようアプリを改修。
  • @に、awkワンライナーでユーザ・IP別のログイン失敗回数一覧を作ってもらう。
  • ただ時間が迫ってきているのに焦って、ログイン失敗書き込みが漏れてFail。泥罠的な修正を加えたため、バグを埋め込んでしまい手間取る。
  • ベンチマークはFailなしで走るようになったが、初期データの反映ができていないため、レポートで落ちる。。。
  • 結局、安定した時点までのアプリでベンチマークが通ることを確認して時間終了。

以上。

こうしてまとめて見てみると、大したことができてなくてつらい(´;ω;`)

大したことないアプリの改修で、舞台に飲まれてバグを埋め込んで時間を使いすぎました。。。

去年の本戦でも感じましたが、こういった時にすぐに解決策が出てこなかったり、コードを修正するのに手間取ったりするのは、普段からの修行不足。

もう予選も終わり、予選用のリポジトリも公開設定に変更したので、恥ずかしながら、使ったリポジトリのURLを貼っておきます。華々しい結果ではありませんが、ISUCONアンチパターンとして見ていただければ。

予選は双六工場こと、僕の自宅から参加したのですが、うちの周りから上野に掛けてIngressのポータルが多いので、予選後は反省Ingress会をやり、上野の「もつ焼き 大統領」でもつとか馬刺しとか食べて解散。

まとめ

振り返って見ると、いろいろ反省点はありますが、判断ミスややりきれなかったところも含めて、今の自分の実力とも思うので、 予選自体にはそんなに悔いはないです。あとはなにかの奇跡が起こって、運良く本戦に引っかかることを祈るのみ。

ISUCONは、すべての参加者が同じ土俵で戦ってベンチマークスコアのみで勝敗が決まる単純さが面白いですね。非常にわかりやすい。なんとなく、幽遊白書の魔界トーナメントを思い出します。やっぱりこういうお祭りがあると、盛り上がるし、エンジニアの実力がこうやって可視化されるのは、間接的にはIT業界全体にとってもいい影響を与えているのではないかと思います。個人的にも、こういう機会があると普段の仕事の時にも気合が入ります。

最後になりますが、運営のみなさま、出題を引き受けてくれたクックパッドのみなさまに感謝を。貴重な機会をいただき、ありがとうございました。毎年規模が拡大し、参加者にもノウハウが溜まってくる中でISUCONを運営するのは、非常に大変だと思いますが、それが続けられているのも、歴代の運営スタップが真剣に取り組んでくれているからだと思います。予選運営お疲れさまでした。

予選通過は厳しい感じではありますが、いずれにせよ本戦が楽しみです。10/6の最終結果発表を楽しみにしつつ、今日はここまでで。

*1:前回も意図したものじゃなくて、チューニングとして意味がありそうなものを順番に試していったら、うまくいくポイントを見つけてしまったというのが実情なんですが

Hadoop Conference Japan 2014 参加メモ(個別セッション③) #hcj2014

Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014Hadoop Conference Japan 2014 参加メモ(個別セッション②) #hcj2014 の続きです。

メモはここまで。

並列SQLエンジンPresto - 大規模データセットを高速にグラフ化する方法

  • 古橋 貞之(Treasure Data)

f:id:sechiro:20140708172110j:plain

  • 会場でPrestoを使っている人はどれぐらいいますか?

    • 10人ぐらい
      • これは話し甲斐がある
  • HDFS上のデータを可視化したい

    • Hiveは、可視化には遅すぎる
      • ODBC接続が安定しない
        • ただし、Hiveは、巨大なJOINなどでは有効
    • Redshift, PostgreSQLは、コストが高いし、スケーラビリティが低かったり
    • 中間データベースを使うと、余計な手間がかかる
  • Prestoを使うと解決可能

    • PrestoはHiveにもMySQL上にあるデータにもクエリを投げられる
    • Prestoをハブとして解析プラットフォームを作れる
  • 全体アーキテクチャ

    • Coodinator/worker/discovery service
      • Worker -> Connector -> Data sourceとデータを取得
    • クライアントからCoodinatorにクエリ(クライアントは複数ある)
    • SQLメタデータから実行計画を立てる
    • Prestoは、既存のDBに対してクエリを投げるサービス
      • クエリはHTTPとJSONで投げる

f:id:sechiro:20140708174920j:plain

  • Connector

    • Hive
    • Cassandra
    • MySQL(beta)
  • BI tools needs

    • ODBC: Tableau, Cognos, QlickView, Chart.IO
    • JDBC: JasperSoft, Pentaho, MotionBoard
      • しかし、ODBC/JDBCは非常に複雑
  • Prestgres

    • PostgreSQL protocol gateway
      • PostgreSQLODBC/JDBCで接続できる
      • PostgreSQL に見えるんだけど、裏ではPrestoが動く

        • pgpool-Ⅱを改造してクエリを書き換える
        • 書き換えたクエリがPostgreSQLの中でさらに各サービスへのクエリに変換される
      • Tableau/ChartIOからクエリをかけられる

  • Prestoの実行モデル

    • DAG
    • 全タスクが一斉に走るのがMapReduceとの違い
      • MapReduceでは、Task終了待ちができる。
  • Monitoring

    • Web UI
    • JMX HTTP API
      • 運用が考えられていて成熟している
  • Laad map

    • Huge JOIN and Group by
    • Task revovery
    • Create View
    • Plugin repository
    • Native store
  • 情報源

  • QA

    • 想定質問としてあるのが、Impalaと較べてどうなのか
      • 確かにImpalaと比べると遅い
        • アグリゲーションの最適化が図られているので、だんだん早くなっている。開発スピードが早い。
      • impalaよりも、リソース管理がしっかりしており、メトリクスが取りやすい。運用が考慮されている。
        • 拡張性が高く、開発がオープン。
        • プルリクエストが2,3週間でマージされる

内容のメモは以上です。

Hadoop Conference Japan 2014 参加メモ(個別セッション②) #hcj2014

Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014 の続きです。

長くなったので、最後のセッションはさらに分割します。

A Deeper Understanding of Spark Internals

  • Patrick Wendell (Databricks)

f:id:sechiro:20140708144951j:plain

  • Agenda

    • How spark runs, focus on performance

    • Major core components

      • Excecution model
      • The suffule
      • Caching <- not cover in this session
  • Scala example

最初の文字の出現頻度を数える

sc.textFile("hdfs://names")
    .map(name =x> (name.charAt(0), name))
    .groupByKey()
    .mapValues(names => names.toSet.size)
    .collect()
  • Excecution model

    1. Create DAG/RDDs

      • HadoopRDD
        • map()
        • groupby()
        • mapValues()
        • collect()
    2. Create execution plan

      • pipeline as much as possible
      • Split into "stages" based on need to reorganize data
    3. Schedule tasks

      • split each stage into tasks
      • schedule tasks
  • The shuffle

    • Redistribution data
    • Pull-based
    • write intermediate file to disk

      • network bound
    • パーティションごとにHash mapを構築する

      • 一つのキーと値のペアはメモリ上に収まる必要がある
  • What went wrong?

    • Too few partition to get good
    • Large per key groupby()
    • shipped data accross the cluster

    • Ensure enough partitions

      • Minimize memory
      • minimize shuffled
      • Know the standard library
    • too few partitions/too many partitions

      • reasonable number of partitions
  • Fix the problem

    .repartition(6) .distinct()

  • Low level performance

    • jps | grep Executor
    • jstack
    • jmap -histo:live
  • QA

    • Does spark support JOIN?

      • yes
    • Hive, Shark or SparkSQL

      • SparkSQLに統合しようとしている
        • Sharkは新しいプロジェクトでは使うな

LT

LTを見に行きましたが、こちらのメモはカオスなので、一旦割愛で。

Evolution of Impala - Hadoop 上の高速SQLエンジン、最新情報

  • 嶋内 翔(Cloudera)
    • 今日はこのために来たと行ってもいい

f:id:sechiro:20140708154949j:plain

  • Impalaとは、HadoopクラスタのためのMPPクエリエンジン

    • C++/OSS
    • Clouderaが開発
    • Cloudera/MapR/Amazonがサポートを提供
    • 2013/04に1.0リリース
    • スキーマはHiveメタストアに保存
    • SELECTとバルクインサートのみ
    • 相関サブクエリは未実装
  • Impalaのサービス

    • impalad

      • クエリを実行する
      • どのデーモンもクエリを受け付けられる。
      • 受け付けたノードがコーディネータ
    • statestore

      • ネームサービス
      • impaladの簡単な死活監視のみ
      • このサービス自体は死んでいても動作はする
    • catalogd

  • 実行計画

    • シングルノードプランの作成
    • プランフラグメントに分割
  • インメモリの実行

    • 右側にJOINするものは、すべてメモリ上にキャッシュする
    • 左のテーブルはHDFSから読み出す
    • データはストリームで送信され、ディスクには書かれない
    • メタデータは最初だけ読んでキャッシュする
    • クエリが複雑な場合は、デーモン同士が結果を交換する
    • LLVMを使って、クエリのランタイム依存の部分をコンパイルする
      • クエリのカスタムコーディングと同等の内容
  • メタデータ管理

    • catalogd
      • Impala SQLからクラスタ内の全ノードにメタデータの変更をリレーする
      • Hiveで実行したあとにはRefreshが必要だが、基本的に必要ない
  • UDF、UDAF C++Java Python UDFも開発中

  • HBase連携

    • 1行インサート可能
    • 高速にインクリメントするカウンタをHBaseに持つ等のユースケースが可能
  • リソース管理

    • 1.3からアドミッションコントロールが入った
    • リソースの過剰使用を抑える。
    • 設定は以下から
      • Cloudera Manager
      • fair-scheduler.xml/llama-site.xml
    • ソフトリミットなので、高頻度でクエリが来ると場合によってはリソース上限を超えうることに注意
  • Llama

    • 低レイテンシ用のアプリケーションマスタ
      • YARNのスケジューリングを細かくするためのサービス
      • YARNのリソース配分をキャッシュ
      • 1.4でプロダクションレディ
  • Sentry

    • データベース、テーブル、ビュー、列、行の単位でアクセス制御
    • エコシステム全体で利用可能
  • パフォーマンスと最適化

    • HDFSショートサーキットリード

    • HDFSキャッシング

    • Parquet

      • パーケと読む
      • カラムナー
        • ストレージ効率が高い
        • スキャン効率が高い
    • Compute stats

      • ETL処理の終わりに必ずやるべき
        • データの統計情報を取ることで高速化する
    • 並列性

      • マルチユーザ、並列に強い
        • Prestoと比較して早い
          • I/Oを削減するアプローチではなく、CPU時間が重要
          • PrestoはCPU時間が長い
  • スケーラビリティ

    • Impalaはリニアスケーラビリティがある。

    • HWを倍

      • クエリによるがおおよそ倍の性能
    • 倍のクラスタで、倍のユーザ
      • 同じか良くなる傾向
  • ロードマップ

    • 1.4

f:id:sechiro:20140708170622j:plain

  • 下半期に2.0を出す

    • LAG
    • LEAD
    • 相関サブクエリ
    • Nested Data(JSONとか)を入れる
  • Impala本からPDFが無償公開されているので読むと良い

  • QA

    • Impalaバージョン同士の比較は?

      • バージョンの差異はすぐにはデータがない
    • UDTFは?

      • 望んでいるというのは認識している。プライオリティが高いがまだロードマップに載ってきていない。

Hadoop Conference Japan 2014 参加メモ(個別セッション①) #hcj2014

Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014 の続きです。

続いて、個別セッションの前半。先は長い。。。

個別セッション

BigQuery and the world after MapReduce

  • Speaker: 佐藤一憲 (Google

    • GCPサポート
    • GCP solutions design
    • Docker/GCP meet up
  • Google I/O で、GoogleMapReduceを使っていないという話があった

  • We use Dremel ≒ Google BigQuery(MPP)

    • 68B records in ~20 secs
    • 120億行フルスキャンで10秒ぐらい
    • コスト
      • Storage 0.026/GB per manth
      • Query: $5/TB
    • Column Oriented Storage
  • HDFSの元となったGoogle File Systemも現在は使っていない

    • Colossus The next generation Google File System
      • Tail Latency が低い -> レスポンスが遅いノードに引きずられない
  • Google BigQuery

    • Scanning 1 TB in 1 sec takes 5000 disks

    • 処理

      • Mixer -> Shards -> Mixer
    • JOINの方式

      • Small JOIN: Broadcast JOIN
      • Big JOIN: JOIN EACH, GROUP EACH -> Shuffle
        • 608M x 38M records -> 90s
    • BigQuery streaming

      • 1M rows/s を格納可能
      • Fluentd Plugin bigquery がこれに対応していて、データを流し込める
  • Google I/Oで発表された今後実装予定の機能

    • Connectors for Hadoop

      • GCS Connector
      • BigQuery Connector
      • Datastore(BigTable) Conector
    • BigQuery UDF

      • Input/Output as JSON
      • JS in SQL
      • →簡単な処理はBigQuery単体でできてしまう
    • Google Cloud Dataflow

      • Cloud Pub/Sub
        • Hadoop/Sparkとの連携を予定
        • 1 vs 1M の pub/subも作れる
      • Batch/Streamingを一つのコードでやってしまう
        • Google Flume + MillWheel On GCE
          • -> Paperが出ている
        • PipelineをJavaの数珠つなぎで書く
          • 内部で最適化される
  • QA

    • Fluentdで今後チャンクにIDをつけるようにする。インターネット経由だと重複は結構ある。Googleへのデータ送信時に、そういう重複排除の仕組みは提供されるか。

      • 現状はない。インポートしてもらって、Group BYで重複を排除してもらう等が必要。
      • Exactly Onceに関しては、Google I/Oでも質問があって、Dataflowの中ではできている。
    • BIツールから直でつないで使うのか、スプレッドシートに書きだすのか、どちらの使い方を想定しているか

    • 大きなデータでクエリが走らないのは?

      • おそらくソフト的なクォータ設定で止まっている。
      • サポートを購入してもらうと制限を外せる
      • Reserved Capacityというメニューがある
    • クエリの結果の整合性は?

      • トランザクションはサポートしていないし、スナップショットとしての整合性も保証していない

Hivemall: Apache Hiveを用いたスケーラブルな機械学習基盤

f:id:sechiro:20140708140255j:plain

  • Hivemallは、Hive上で動くOSS機械学習ライブラリ

    • HiveのUDF、UDTFで実装されており、Hiveに慣れていれば、追加の学習コストが少ない
    • 学術研究の結果をいち早く取り込んでいる
    • イテレーションを回すとHadoopは遅くなるので、イテレーション減らす実装としている

    • 既存ツールはプログラムが必要

      • すべてのステップがHiveQLで実行可能
        • add jar
        • source のみで実行可能
    • 特徴数の削減をサポートしている

      • 学習時やテスト時に予測モデルをメモリに収める必要がない。
    • EMRに自動構築するBootstrapを提供している

    • 最新のオンライン学習アルゴリズムをサポート

      • CW、SCW、AROWをサポート
      • 学習の収束が高速
      • 10イテレーション→2, 3イテレーション
      • オンライン学習で精度がよい

        • confidence weighted
          • 重みと確信度を更新する
          • 確信度が十分な重みについては、小さな更新。学習初期は大きな更新。
      • UDAF(集約関数)での機会学習

      • 反復学習は、HDFSを介するのがボトルネック

        • Sparkは担当領域を各ノードでキャッシュするので今後のバージョンで高速化する可能性がある
        • SparkのMLlib はサンプリングを利用したMini-batch勾配降下法
      • Hivemall

        • amplify UDTFでデータを増幅してShuffle
        • rand_amplify UDTFでデータを増幅してMap Only Shuffle
      • KDD Cup 2012 Track2データセットベンチマーク

        • VM, Bismarck, Spark MLlib 1.0と比較して学習時間が短く、予測精度がよい。
      • Apache incubator化の打診がある。Hortonworksから打診を受けている。

  • QA

Hadoop Conference Japan 2014 参加メモ(キーノート) #hcj2014

久々にブログを更新しようと思ったら、この数カ月で記事らしい記事は「一人遊園地」しか書いていないことに軽い絶望を覚えたせちろーです。

今日は、Hadoop Conference Japan 2014に参加してきたので、その時に取ったメモを整理してアップ。長くなるので、まずはキーノートから。間違いがあってもご容赦ください。

当日の資料は、以下のページにアップされると思うので、詳しい情報は以下を見てください。

http://www.eventbrite.com/e/hadoop-conference-japan-2014-tickets-12016613013

それぞれ別の立場から話しているのに、Hadoopの用途が大量データの保存と単純な集計から、汎用的な分散処理基盤かつMPPまで包含するような方向で進化しているという観点が共通しているところが面白いですね。

キーノート

開会挨拶

f:id:sechiro:20140708101830j:plain

  • 参加登録者
    • 1296名 -> 最終的には1299名
    • 約65%が初めて参加する人
  • データ

    • 利用経験のアンケートでは、44%以上の人が半年以上の経験。始める人も増えている。
    • エコシステムでは、Hiveが半数使っている、2位がHBaseで意外、新しいプロダクトとして、Impala、Sparkが入っている。
    • NTT/NTTデータが第9位のソースコードコミットで日本からの貢献も多い
  • Hadoopのこれまで

    • はじめて普及した並列分散処理
    • データの読み込みのスループットの最大化
    • シンプルなモデル(MapReduce
  • だんだんYARNが中心に座ってきている

    • MRの経験をもとに複数の分散処理エンジンを使い分ける時代に

『The Future of Data』

  • Speaker: Doug Cutting (Hadoop生みの親, Apache Software Foundation, Cloudera)

f:id:sechiro:20140708104221j:plain

  • 未来は予測できないが、いくつかの事実が真実を予測

    • HWの性能が上がり、安くなっている。
    • データの価値はさらに高まり 
      • 競争力を維持するためには、データ活用が必須
    • OSSが勝ち残る
    • Hadoop機能はさらに向上
    • Hadoopが当たり前に   * Hive: SQLができる人が、アフォーダブルなスケーラブルな基盤を支える

    • Hadoopビッグデータ界を席巻

  • Hadoopが「エンタープライズデータハブ」となる

『The Future of Spark』

  • Speaker: Patrick Wendell (Apache Spark主要開発者, Databricks)

f:id:sechiro:20140708105920j:plain

  • 今日のスライドは、自分で日本語に翻訳した

  • Spark開発者の一週間

    • 500 Patch
    • 200 update issue
    • 140 Mail thread
    • ...
  • Spark開発目標

    • Data scientist, engineerの能力拡張
    • CleanなAPI
    • 多様な環境に適用
    • 強力な標準ライブラリ
  • API互換性を維持

    • 標準APIと試験的APIがある
    • 互換性を維持した安定したプロダクト
    • マイナーリリースは3ヶ月毎に
    • 必要に応じてメンテナンスリリース
    • パッチリリースは慎重に
  • Spark Stack

    • Spark SQL
    • MLlib
    • Graph X
    • Spark Streaming
  • Sparkの未来は「ライブラリ」

    • パッケージ化してどこでも使えるように
  • Spark SQL

    • 急速に成長
    • SQL 92を目指している
    • Hadoop、NoSQL、RDBMSを統合
      • Sharkから直接アップグレードできる
  • DatabricksではクラウドでSparkを提供している

Hadoopエコシステムの変遷と、見えてきた使いどころ』

  • Speaker: 太田 一樹 (Treasure Data CTO)

f:id:sechiro:20140708112953j:plain

  • Hadoopの本質的な価値とは
    • Collect any types of Data
    • Store any types of Data Economically
    • Faster use of Data
    • Better use of Data
  • ここまで使うことでHadoopの価値が出る

  • Collect any types of Data

    • Fluentd
    • Apache Flume
    • Kafka
    • Sqoop
  • Store any types of Data Economically

    • どんなタイプのデータも格納可能
      • ファイルフォーマットに注目が集まっている 
  • Faster use of Data

    • DAG型
    • External DSL
      • Hive,Pig
    • Internal DSL
  • Better use of Data

    • Impala, Presto, Drill
    • Mahout, Hivemall
  • データベースの進化

    • クエリプランナ、オプティマイザからHadoopにクエリが生成される
    • Vertica Zonemapで準構造化データも扱えるようになっている
  • スキーマ管理がもたらす問題

    • 一部のレポートしか作れない
    • データの整合性はとれるが、出てくるころには使えない
  • 現在のトレンド

    • Hadoopにとにかく生データを集約。スキーマも意識しない。
    • 集約した結果をMPPに入れる
  • 今後、Hadoopは構造化データとの境界線に突入

    • HadoopだけでMPPができるように
    • トレンドを読みながら技術を利用すべき

キーノートのメモはここまで。

溜まってきた大量の名刺やシャッツキステのポイントカードをしまうのにちょうどいい道具を調べた

最近、名刺やらシャッツキステのポイントカードが貯まってきて、カード状のものを保存するのに使えそうな道具を調べたので、その時の内容の備忘録を書いてみました。*1

自分で探せていない範囲がまだありそうなので、この用途でもっといいものがあれば、教えていただけるとありがたいです。

調べるにあたっての前提

以前は、名刺はきちんと名刺ファイルにファイリングしていました。しかし最近は、ものぐさでファイリングしなくなってしまっていて、その管理方法も限界に…。また、電子化しておいて、実物は廃棄してしまうという方法もあると思うのですが、収集癖があるから現物を捨てるのは忍びないので、それも今回は除外。

上記の前提なので、今回は入れるのに手間がかからない箱状のものをターゲットとしました。

どうやって見つけるか

箱状のものを使うと決めたものの、最初にカード状のものをしまう箱をどういう単語で検索すべきかという問題に引っかかりました。いろいろ試行錯誤して検索してみた結果は以下の通り。

  • カードホルダー → ハズレ
    • 主に社員証をぶら下げるものや財布上のカード入れが引っかかる。
  • カードケース → ハズレ
    • 主に財布上のカード入れが引っかかる
  • カードボックス → 当たり!
    • 主に名刺を1000枚単位で収納できる箱やカードゲーム用カードを入れる箱が引っかかる
    • 「ネームカードボックス」とすると、名刺をしまう箱に絞り込める。
  • 名刺箱、名刺ケース → 当たり!
    • 名刺を買った時に入っているような箱が引っかかる。
  • ネームカードケース → 微妙
    • 主に社員証をぶら下げるものが引っかかる。ただし、あとで取り上げる今回買った製品がたまたま「ネームカードケース」という製品名だったため、それだけ例外的に引っかかった。

「名刺箱」というのは、見つけてしまえば当たり前の検索ワードなのですが、当初は「カードケース」で検索していたので、なかなか見つけられずに苦労しました。。。

500枚以上のカードを入れるのに使えるもの

今回探したものの中で、500枚以上のカードがある場合に使えると思ったのは「カードボックス」系のものです。このジャンルのものは、今回初めて知りました。探してみるとあるもんなんですねー

自分で買ったのは以下の「ネームカードケース」。選んだ決め手は、下の箱の高さが名刺の縦幅よりも低く、名刺が取り出しやすい点。この製品はフタがパカっと完全に外れるタイプなので、フタに蝶番がついている方がお好みであれば、そちらもよいかも。

また、今回はファイルはなしということで除外しましたが、カードボックスの類似製品として、このジャンルだと下の商品のような円形に名刺をパタパタ入れていくものも見つけました。

「ローロデックス」という製品なんですね。どこかで見た気がしますが、名前を知るのは初めて。名前を知らないと全然見つけられない。。。

数百枚程度のカードを入れるのに使えるもの

数百枚程度のカードを入れる場合は、今見つけられているものの中では「名刺箱」が良さそうという結論です。名刺を買った時の箱が残っていれば、それを使うのが一番リーズナブルですが、単体で買うこともできました。

ただ、安い名刺箱はネットでは5個単位、10個単位ものが多くて、1個だけ買う方法がなさそうなのがネック。余った分は、小物の整理にも使えるので、まとめて買っても使うところはあるように思いますが。

透明なものがいいか、中は見えない方がいいかは好みの問題ですが、以下のようなものがありました。*2

高級感が欲しい場合

今回自分では買っていませんが、「名刺箱」で調べてみると、凝ったものも見つかりました。千代紙のものは、値段も手頃なので個人名刺入れとかによいかも。ほかにも、漆器で1万円超えみたいなものも見つかりましたが、さすがに使う機会なさそう…。

以上、どこにニーズがあるかわかりませんが、調査メモでした。

今日はこの辺で。

*1:商品紹介は、Amazon楽天へのアフィリエイトリンクになっているので、その点はご了解ください

*2:自分では透明な方を買いました。

一人遊園地に行ってみた

今日は、花やしきに行ってきました。行った理由は、花やしきのローラーコースターに乗ってみたかったから。

全然下調べせずにいったので、花やしきのローラーコースターがまだやっているか不安でしたが、行ってみたところ、まだまだ現役で稼働していました!

なんと去年還暦! そして、還暦の人は無料で乗り放題!!

楽しい!!! ✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌.

f:id:sechiro:20140503172820j:plain

f:id:sechiro:20140503173300j:plain

ただ、周りはカップルか子供連ればっかりで、一人で行くとその人の心が試されます。人の迷惑にならない限り、どんなところでも行きたかったら行くべきだとは思いますが、周りがキャッキャウフフしている中に一人でいると精神が徐々に蝕まれていくので、基本的には一人で遊園地に行くのはおすすめできませんね。

ちなみに、一時期Twitterで回っていたぼっち検定では、一人遊園地は上から2つ目のレベルになっています。ただ、神レベルのラブホテルは、旅行で使えば割と簡単に達成できるし、千葉のネズミの国はパスポート持ってソロで行ってる人が結構いるので、上位の方が割と簡単に達成できるような気もします。

【ぼっち検定】
初級 一人で牛丼
5級 一人でラーメン
3級 一人でファミレス
1級 一人で居酒屋
初段 一人で温泉
ニ段 一人で回転寿司
三段 一人で海水浴
五段 一人で焼肉
名人 一人で公園の手漕ぎボート
独聖 一人で遊園地
神 一人でラブホテル 

今日はこんなところで。