2月5日(金)、いってきました。
今年は無料！
RDBの話
Actian Vetor
カラムナーデータベース
ベクトル演算する分析向けの超早いデータベース
SQL実行すると、CPUのコア全部使ってうまいこと使って早く処理する
スケールアップあるいはスケールアウトの課題
理論から学ぶデータベース
コストと管理性の問題
スケールアップはコストがかかる、スケールアウトは管理の問題
スケールアウト
スケールアウトは横に並べるからそれぞれ連携させる必要がある
→ボトルネックはInterconect。ソフトウェアアーキテクチャの問題に起因。
どうやって並列に動かすか
スケールアップ
ハードの問題
Sparc M7っていうCPUをOracleが出した
→CPU自体がデータベース処理できるチップを持ってる
暗号化処理→重い
CPUにやらせる
Soralisしか動かない…。
Linux動くようになったら…。
必ずしもハードウェアの問題だけではない
ソフトウェアがリソースを使い切れない
愛用している製品に足りない機能
CHECK制約がない(MySQL)
これがダメすぎるｗ
自動チューニング
気付いたらおかしな事になってる
不要な機能を外す方法がない
→これ難しくね？
新機能とか増えてても気付いてない問題
最近だとクロス集計ROLLUP, CUBEとか使えばいいのに、UNION ALLとかでがんばってるのみると悲しくなる。
SQL標準
2000年くらいまでは騒がれてたけど、最近は若い人は知らない？
SQL標準に入れて欲しい機能
外部キー制約しかない
設計を突き詰めてるとこれだけじゃ足りないかもしれない問題
Window関数とか
PostgreSQLにも入ってる
RDBでは解けない問題
グラフデータベースだとどう？
ハードウェアパワーも上がってきて、RDBでできるんじゃ
結果、グラフデータベース大して使えなかった
RDBの闇
カラム名酷い問題
STOCK_FLAG→在庫フラグ？→実際は在庫取消フラグだった
FROMというカラム名とか…
予約語使うなよ
予備0〜9のカラムはまだ許そう、00〜99で定義したやつは誰だッ！！！
XXフラグというカラム→入ってる値が-100だった
フラグじゃねえｗｗｗ
予備カラムが枯渇してきてそこにXML入れ始める
JSON型どうよ
濫用されるとツラい
通信のために使う
バランス感覚大事
SQLのメリットは手続きを書かなくていいこと、JSONを導入することでいろいろ書かなくちゃいけなくなるならメリットがなくなるんじゃ
ドキュメントDBと同じノリで使い始めると微妙。
JSONの項目のソートとかどうするの問題とか、RDB側の実装が足りていない感はある
RDBじゃなくてもよかった
グルグル系（1行ずつ読み込んで書いて読み込んで書いて）
リファクタリングの話
DBは長生き、DB構造はコピペが当たり前。
プログラムコードのコピペが悪なのは知れ渡ってるのに、DB構造、SQLのコピペは普通にされてるのがイマイチ。
リファクタリングはもっと気軽なものにするべき。
DBだけではできない。プログラム側もやる。
インフラも全部協力してやる必要がある。
大変だけどやらないと先がないぜ。
データベース・リファクタリングを熟読すべし
売ってない。
つながってるところが多すぎてリファクタリング進まない
複数のアプリで1つのデータベースを参照してはいけない
1アプリ・1データベースの構造にしないとリファクタリング
リファクタリングが大変だからと言ってスキーマレスに安易に走ると死ぬ。
今注目してるDB関係のテクノロジ
DB設計はいいツールがないと流行らない
RDBはどう進化するべきか？
変化が激しい現場が増えてきた
汚いから直そうじゃなくて、業務があわないから直す、とか
複数のデータソースを共通のインターフェースで使えるものが増えるといいと思う
Cypher言語の標準化するはず
おうちで学べるデータベースの基本
ランチセッション エンジニアやPMはもっと料理をするべき
メニュー：エンジニアが業務命令で作った焼きそば
PMと料理は通ずるところが多い。
Cooking for Geeks
CTOが現場に言えない本音
公共の場では言えないこともありそうです。
CTOになった経緯
VASILY CTO 今村さん
VASILY創設時最初からCTO
クラウドワークス 大場さん
立ち上げたあとのCTOを引き継いだ
GREEからいきなりCTOとして入った
Wantedly CTO 川崎さん
最初のWantedly使ってWantedlyにジョインした人
エンジニアじゃない人が書いたコードはクソｗ
評価どうしてる？
- みてるところ
- みてないところ
- どう言うミスマッチがあるか
エンジニアの評価は3ヶ月に1回、半年に1回
何してたかはしっかり見てる
よく話す人はよく映る（近い人）
遠い人に対してどうして欲しいか？
アピールして欲しい。
どれだけその人が成長してるかをみてる。
新規サービス作りましたとかのアウトプットはそんなに問題じゃない。
その中に新しい技術入れましたとかが大事。
ケースバイケース
成果と成長を明確に分けてる→大事。
これができました、終わり。だとそこで終わりだから継続が大事。
成長ってどうやって測ってるか？
新しい技術を取り込むのは最低ライン。
発揮されない技術はあんま意味ない。
成果のウェイトが大きい
失敗してる人の方が挑戦してて成長してる、でも成功してる人は成長してない？
失敗して成長してる人はどっかで成功してるはず
成果物の進捗はみてるか、事業の数字があがったかをみてるかどうか
エンジニアのレベルによって観点が違ってくる
極論、成長寄りで評価すると、勉強だけしてればあがってしまう。
自分一人でがんばったからできたってのは、評価低め。
チームでできるようになった＝布教とか色々がんばってるって事だから評価高い
外部に影響を与えられるか
教えたがりの人はどうする
口はうまい。お前が勉強しろよ。
プロダクトにどんだけ貢献できてるかの面も大事。
目標とかしょっちゅう変わる。目標変わるからどうするか。
本人との会話が大事。
毎週話すようにした。
目標のすりあわせだったり、人生相談だったり。
→ちょっとよくなった
3ヶ月でやること決めるとかのコストが非常に高い。
目標以外もやれるようにして、カオス感出す。
仕組み
エンジニアにグレード付けてる
それぞれに求める水準がある
成果と基本給は連動してるのか？
グレードとかランクとか、けっきょくはコミュニケーションのツール。
あくまで補助目的に使ってる
成長について
- 新卒へのメッセージ
- 中堅の成長
- 成長止まっちゃうケース
新卒へのメッセージ
会社の中でうまくやってる人、成果出してるやつのやってることを見て盗め！
言いづらいのは、こいつが成果出てるって言うのを言うこと。
スタートアップ、ベンチャーはキレイな世界じゃないよ。
僕がやらなくてもっていうのもやらないと成長しない、はず。
教育プラン考えるの大変。
企画に行きたいけど、直近はエンジニアでいきたいみたいな人はWebとか向いてないのかもしれん。
技術は手段と考える人。
わかってないうちはそんな感じ。
採用
中途は前職給があるけど、それと仕組みはどう折り合い付けてるか
めっちゃ高い人＝能力高い人
差がありすぎる人はどうするか
1年目は丸ごと払ってる。
採用の軸と評価の軸
面接ではこれが見られてる
地雷ワード
不幸になった例
不幸→お互いが合わなかったとかよくある
採用するときに勉強するかどうかを見てる。
評価の時はそこら辺別に見てない。アウトプット。
チームの癒やし系キャラ
面接時のコーディングについて
アルゴリズム寄りのプログラミングと実際のコードの違いがある
GitHub採用したい
チーム開発になるから、テスト書いてるか、コメント書いてるか、要求されたロジックがどういう風に解釈してるかを見てる
地雷は？
「2年以内にコード書くのを卒業したい」
素直さ、インターネット好きかどうか
本読まない人は人間じゃないｗ
技術がついていくと偏屈になっていく、できる人はいつまで経っても吸収していく姿勢がある。＝素直さ
自分自身が限界になってはいけない
自分より優れてる部分を探してる
キャラ採用も重要ｗ
今いるメンバーを見て足りないところを補えるかとかそういうの。
地頭がいいかを見てる。
地頭がいいかどうかをどうやって見てるか？
最近のすごい技術を説明してもらう
流行ってるからいいとかダメ
エンジニアで一緒に働きたい人ってどんな人？
インターネット好きな人、おもしろいことやりたい人
自分より優秀＝自分にないスキルを持ってる、とんがってるかどうかとか
成果に結びつくかどうかはむずい
自分が詳しくない事についての評価が難しい
変な人
自分なりの指標で行動できる人
退職について
全部オフレコだったので割愛
キャリアについて
エンジニアのキャリアパス
まだ業界的にも確立されてないよね
DeNAとかが型として出したりしてるけど、これしかないわけじゃない
自分で作りたいものを作って提供できるだけの力は身につけよう。
エンジニアの給料の上げ方
本当に何かをやりたかったら自分で何かやるしかない
本当に給料を上げたいなら
業績を上げる→それに自分が必要不可欠な存在になる
どの会社でも身の丈に合った給料しか出せない
CTOになるには
何が評価されてCTOになったのか
どう言うアプローチをしたのか
CTOは単なるロール。
最終的にCTO交代って言うの難しい
自分がCTOでいいのかという葛藤は
自分がやらないとなって言うのがある
CTOは対外的な役割が大きい気がする
CTOの次のキャリア
今のCTOみたいなことやれる人が社内から出て、他にも立ち上げるところにCTOを排出していきたい
次のCTOを育てたい
今やってるのとは違う自分のやりたいことやる事業のCTO
質疑応答
対外的な効果ってどうなの
社員代表として色々伝えてる
経営戦略の中で技術がどう貢献していくのか
利益が出ないと社員に還元できない
経営を技術で支える
答えがない領域に立ち向かってる。
組織的に答えが見つけられるように色々トライしてる
SparkとかHadoop
運用周り
Hadoop
YARNのメリットって享受してる？
あるとき1系、2系に分かれた
2はYARN
YARNのいいとこ
色んなフレームワーク使える
元々HadoopはMapReduceを動かすフレームワーク
YARNになってスケジュールが複雑になった
SPARKはデフォルトの設定だと動かした瞬間に死ぬ
PythonでSpark使ったら顕著
Python RDD毎にPythonプロセスが立ち上がるので、YARNから見るとサクッと仮想メモリの上限に引っかかってしまう
→PythonでSpark使うのはオススメしない。データフレーム使え。
昔のYARNのバージョンだとmasterばっか立ち上がって働くやつがいなかった
FairSchedulerどうよ
YARNになってからプライオリティの設定ができない
デッドロック・内部ロックとか発生する
これまで使ったことない使い方をすると、コードバグが発生しやすい
プロポーザルしてくれると対応する
けっきょくオレオレスケジューラー作りたくなる
声を上げてくれ。
MLに流してくれればおｋ。
バグだったらJIRAに入れてくれたら見ます
コード書く人はドキュメント書くモチベーション沸かないもん？
後回しにしがち
ドキュメンテーションが追いついてない
コミッタ的には全部やるのは大変だからしつこく言われるとやる
Java8はどうなの
Runtimeとして動かすのはOK
Java8でコンパイルするのはムリ。
依存関係の依存関係が超辛い
なんかテストにこけてしまってよくわからんけど今直してるところ
闇が深い
関連ライブラリのソースコードも読んでる。
コミュニティプロジェクト運営
PMCのお仕事
Sparkのコミッタなった時
HBaseのコミュニティはすげーフレンドリーｗ
実装・ソースコード関連
Earthquakeというもんがある
Hadoop3.0のモチベーションは
Hive2.0がまもなく出る
2.0からMapReduceを切り離そうとしてる(Deprecated)
TezかSpark使えって言われるようになるはず。
どっかで移行していく必要がある。
YARNは処理基盤が色々使えるのが良いところ。
MapReduceは長いこと使われてて安定してる
Deprecatedにするのはもったいない。
見てるとTezに依存してるコードが多くて、Hiveの人達がMRでやりたくないんじゃ。
HDFSはファイル置き場として安泰だけど、処理エンジンは移ろいゆく。
そこらへんどうしたらいいのか。
YARNあると下がどういうのでも抽象化してくれるからスイッチしやすい。
だからYARN使うといいかも。
Hiveは最近高速化のために色々入ってる。ぽい。
Configurationクラスツラい問題
これのロードが遅い
大量に入れたら肥大化してジョブサーバーがコケ始めてツラい
Twitterの人とかが直してくれた
ツラいって速度の話？別によくね
多すぎて問題があったときに探すの大変。
Tungstenについて
最近のワークフローだとCPUボトルネックが多い
独自にメモリ構造を管理
ムダな中間オブジェクト、GCを削減
デバッグのしやすさとかはあんまりよくない。
性能を重視してる。