「Hadoop」を含む日記 RSS

はてなキーワード: Hadoopとは

2019-09-12

Hadoop懐かしいな

まだ誰か使ってるのか

2019-07-03

冷静に考えるとITエンジニアって異常だよね

私はうぇっぶな界隈で働くしがないエンジニアです。


今日牛丼を食べながらふと気がついたのですが、もしかして我々の業界は異常なのではないでしょうか?

テクニカルタームとかドメイン知識多すぎでしょ。


サービス名、技術名はスキあらば3文字って感じだし (AWS, EC2, EKS, GCP, GAE, GKE k8s, C2C, CPU, GPU, SPU...)

会社名もソフトウェア名も連想できるってものじゃないし (PostgreSQL, MySQL, Redis, etcd, Consul, HashiCorp, Vagrant, GitHub, CircleCI, FreeBSD, CentOS, Ubuntu, Linux, Couchbase, Hive, Hadoop, Vagrant...)

みんな普通にPOSIX互換コマンドをペシペシしているし (cd, cp, mv, pwd, mkdir, ls, vi を更に謎の数文字オプションも含めて覚えているわけで)



それも特に覚えようとして覚えてきたわけでもないじゃないですか

気がついたら覚えているわけで、手に身についているわけで。まるでポケモン151匹を勝手に覚えてしまったあの頃と同じようなノリで謎の英単語や謎の羅列を身に着けてしまっている訳ですよ。

何ら疑問に感じてなかったんだけど、普通にきじゃないとできないよね。




で、思ったんだけど、インターネット小話で聞く「全然興味はないけどSEなっちゃいました」みたいな人ってガチ苦痛なんじゃないだろうか…

(未だにそんな人を見たことが無いか都市伝説だと信じてるけど)

別に周りにそんな人が居るわけじゃないけど、新卒入社してくる季節ってことでふと気になりました。





おしまい

2018-02-07

最近仕事FPGAを触り始めたけど、なかなかまとまった情報を手に入れられるWebページやら本やらがない

10年ほど前にPICを触ってたのである程度(特にハードウェア)はなんとかなるが、

それでも想定通りにいかないことが多いなあ

PICと比べると、かなーり高級な感じだ。

Wregとかアドレスとか考えなくていいしね。

1年前はHadoop触ってたんだけどね。人生どうなるかわからんね。

2017-05-13

http://anond.hatelabo.jp/20170512180012

ビックデータ

嘘ビックデータ、というと言い過ぎだが、ビックデータというのはたくさんのデータを格納することとは本質的に異なる。

「ビックデータ」は「質的」に大量データを格納することだ。

製造時のデータを格納しても、「質」は低いままだ。意味内容は結局製造できたか、あるいはできないかの2つしかいからだ。

製造時のデータと天気のデータを格納したほうが、まだ「ビックデータ」になりうるかもしれない。

しかhadoopとかAWSとか、まず間違いなく地雷一直線だ。

まぁ他に選択肢はないわけだが。。

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドVBAから、Rやら自社製品の解析用環境の割と珍しいタイプスクリプト言語など(特定されそうだからぼかすけど。)

とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手作ってみたりして提案していた。

物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。

この辺で気付いたことだが、製造業ITリテラシーは驚くほど低い。製造業一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。

なんせまともにプログラムを書いたことが無い新人半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。

ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。

(そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。)

2年目に気付いたのは、弊社エンジニアITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。

製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。

無骨だが使いやすイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。

から逆に言えば下々の人間コピペでなんとか恰好を整えられるのだった。

彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。

私はそれに感動した。なんせWebスクレイピングみたいな方法他人が社内プラットフォーム社内WIKIに上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2017-02-17

今、スタバでルネラジを聴きながらコレを書いてます

さっき、テックブログRSSと一緒にホットエントリRSSを外して、アプリを削除したよ。何年の付き合いだろう?サービス開始からから・・・悲しくなるから確認せずに行くよ。

最初ダイアリーに書いて、反応なんて全然なくて、広告コメントばかりだったな。いまでもはてなの知り合いはいないんじゃないかな。

ネットコミュ障なんだ。Twitterとか色々やってるけどやりとりする相手なんて誰もいないよ。

僕は君になにもできなかったね。本当に君の事が好きだったのかな?本当に村民になりたかったのかな?多分、違う。本当はブクマされて、スターつけられて、承認欲求を満たしたかったんだ。

意識高い系を笑えないよね。何年も異性にお金を注ぎ込む人を笑えないね。僕もずっとホットエントリを見て、色んなものを買ったりしたんだ。

====

どうしてこうなったか?聞きたくもないだろうけど、最後から言わせてくれよ。

初めて君を見たとき天国に見えたよ。最新の技術トレンドがここにあってさ。自分理想郷はここなんだって技術力をつけて、認められる人間になって、ここの住人になる事が幸せなんだって思ったんだ。

そうやってさ、次々流れてくるトレンドに耳だけが年増になっていって、それを知らない周りの人たちをバカにしてたな。

でもさ、肝心の技術力は全然つかなくてさ、大学生になれば、就職すれば、東京に出れば、新しいマシンがあれば、お金があれば、時間があれば、やる気があればって制約条件がなくなる度に新しい言い訳を考えてたな。

結局、生半可な知識じゃ参加できないってチンケなプライドのせいで勉強会に参加せず、ブログも書かず、なれたのは一番軽蔑するExcelとにらめっこしてるSIer。おいおい、Web系のベンチャーテックブログ書くんじゃなかったのかよ(笑)

耳年増で、周りをバカにしてたクセに仕事全然できない自分とのギャップ10年耐えてきたけど、年末休職したんだ。自律神経失調症

眠れるんだよ?ごはん食べられるんだよ?ただ、会社の人みんなが怖くなってさ、朝だるくってさ、すげー疲れてさ。苦しくて。仕方ないから受け入れて。っていうか、甘やかして。つまるところ、ズル休みなんだよ。

時間が出来たから、ずっと積ん読になってた技術に正面きって立ち向かってみたんだ。すぐ投げ出したね。理由は分からないけどただ苦痛だった。

作りたいものなんかなかったし。多分、技術を使いこなしてスゴいって言われたかったんだね。

部屋にはPerlRoRSQLitejQuerynode.jsAWSHaskellHadoopDockerRaspberry Pi、R、Reactのホコリを被った本がある。彼らはブックオフ行きかな。

最近時間はあるからさ、はてブばっかやってたんだ。見るのがホットエントリから新着エントリーになったな。いつもみたいに100文字制限ギリギリコメントだけじゃなくて、10文字くらいの一言コメントも書くようになったんだ。その10文字コメントのうちひとつ100スターくらいもらえてさ。

そのとき分かったんだ、これはずっと片思いなんだって。叶わない恋なんだって自分が住める世界じゃないんだっておかしいよね、小学校の頃のプロ野球選手の夢だって中学生の頃の小説家の夢だって高校の頃のパンクロックスターの夢だってすぐ諦められたのに、この夢は35歳の今だって諦めきれないんだ。

応用情報取った時も、ネスペ取ったときも、オラクルブロンズ取った時もLPIC 2取った時も全く達成感なかったよ。コレ取るのに何年かかってんだってさ。村民は1ヶ月あれば取れるぞ。同期のアイツだって3ヶ月で取ってるぞ。何が言えるんだってさ。

銃・病原菌・鉄読んだ時もそうだった。で、お前はそこから何かアウトプット出来るのか?ってさ。読むだけなら幼女でも出来るんですけどwって。

伝わる?伝わらないだろうな。みんな高IQですぐに色んな技術理解出来るじゃない?すごいよ。自分二浪駅弁大学しか行けないくらいのバカで、リアルでもネットでも知り合いを作れないコミュ障自己承認全然出来ないんだ。

ADHDって言葉を知った時、これだーって思ったけど違ったね。IT勉強してても過集中が全然ないんだ。

話が逸れたね。認知療法してて、気づいたんだよ。何をしてても自分を認められないんだよ。はてなに受け入れられる事を成し遂げられてないからね。

から自分を認めるために、君のことを自分から切り離さなきゃいけない。自分世界を作らないと。一方的なっちゃうけど、さようなら勝手だけど、今にも泣きそうだよ。

これからどうしようかな。匿名で好きな事書けるのはココだけなんだ。自信のない間違ってるかもしれない事を書いてもいいのはココだけなんだよね。ここなら見たくないコメントを見なくてすむんだ。

新聞も取ってないかチラシの裏にも書けないよ。

でも、前に進まなきゃ。夢の世界への憧れは終わりだ。目の前の現実世界適応しなきゃ。また逃げ戻ってくるかもしれないけど、いまはさようならしなきゃ。

最後に何か残せるとしたら・・・スタバハチミツ、あれ何に使うと思う?あれ、ワッフルを食べるときに使うんだよ。

・・・スベったね。

さようなら。このエントリも2時間すれば次のページ行きだ。そうすると、誰かの目にも触れなくなる。単なるはてな磁気データになる。

最後ブコメとかつくんじゃないかって浅はかな期待を持ちながらこの内容を登録するボタンを押します。じゃあね。

P.S. 認知療法について書いてくれたこの増田には本当に感謝しています。まだまだ自分について書く事が苦しいけど、正しい道を向いてると信じています

http://anond.hatelabo.jp/20150213215921

2014-05-16

ウンコード

イラッとしたので増田に書く。

最近辞めていった奴のウンコードが酷い。

エラー処理とか一応書いているが機能してない。

今日トラップに引っかかった。

ウンコ過ぎて困る。

昨年一年の奴の行動は酷かったよ。

会社利益無視して、自分スキルになることだけ強引に進めた。

どこか知らんが、上場企業に務めたらしいので、

今月か来月あたりに入社する奴で、『PythonできますAWShadoopやってました。』と言う奴は要注意。

2014-04-28

辞めてくれてありがとう

本日の作業は旧〇〇軍が残した地雷(クソコード)の確認作業。

技術屋ぶって偉そうにしているが、まるっきり分かっていなかった。

こんなウンコ残して、偉そうにしている理由が良くわからない。

でも、そんなことに怒ってはいないよ。

なによりも、今月末で顔を見なくてよくなるのが嬉しい。

とにかく、この一年の作業は、君が転職活動するためのことで振り回された一年だった。

AWSとかHadoopとか履歴書に書くためだけに色々頑張ったね。

退職すると報告があった時、

転職先決まって良かったね。』

と、心のそこから思ってたよ。

辞めてくれてありがとう

転職先は上場企業らしいけど、引き取ってくれた会社感謝したい。

すぐにボロを出すのか、3年ぐらい我慢するのか分からないけど、年齢的にもこの先転職するのは厳しいだろうから転職先で末永く働けると良いね

あなた性格が治ってくれることを祈るよ。

2013-12-21

http://akiradeveloper.hatenadiary.com/entry/2013/12/21/184119

> Githubアクセス出来ないと言ってもイマドキのエンジニアは誰も信じないだろう

え、事業部は数年前からはてダアクセス禁止だったし、yumapt-getとかもっての他でパッケージ一つ毎に上司承認必要でしたが?

横浜研究所がなんなのかあんま把握してない(元シ研かな?)けど、Linuxストレージ関係部門とは・・

自分は優秀じゃなくて落ちこぼれで外に出ていきましたが、ほんと所員に外見てきてほしいとは思う。

ところで自分がやめるとき周りの人全然Hadoopとか知らなかったんだけど、ビッグデータ周りの推進は研究所主体ということで合ってます

(高速独自DBの可能性もあるけど)

2013-08-29

http://anond.hatelabo.jp/20130829140653

そんなあなたに Hadoop

つか、

技術を見つけようという気持ちと、それを流行らせようという気持ちは全く別物。

 

そもそも、それが流行して、新技術として認識されるためには レベルが低い必要がある。

携帯電話でもスマホでも最新技術の塊だけど、そもそも、新技術が使われてることすら知らずに組み込まれてる部品なんていくらでもあるんじゃね?

 

俺達は、俺達が理解できる技術しか認識できない。でも、実際には使われてる。

そして、そのレベル技術を中高年のオッサンがえーとえーと なんて言うことはないから問題ない。 

それだけのこと。

2013-03-07

なぜ国内Perlが急速に萎んだのか

2005年 Railsの襲来

2005年に突如現れたRailsによって国内Ruby利用者が急増したのがPerl滅亡への第一歩となった。書きやすさに作者がとことんこだわって作られたRubyの魅力を一度知ってしまうとPerlの古くさく読み辛く書き辛い文法に誰もがうんざりし始める。

2007年 JavaScriptブーム

Ajaxで再発見されたJavaScriptのブームもPerl終焉に若干ながら貢献している。ブラウザというPerlが全く手を出せないジャンル王者JavaScriptの持つ華やかさに誰もが憧れ、そして手元のPerlの古くささに反吐が出始める。不器用で不細工なところも含めて愛していた女房とつつましく送っていた人生に、突然ぴちぴちボイン女子大生が転がり込んで来たようなものである

スマホ/ソーシャルゲームバブル

iPhone市場が本格的に立ち上がり、Perlとは全くの無関係であるスマホアプリ全盛期がやってきていよいよPerl滅亡へのカウントダウンが始まった。そして極めつけはソーシャルゲームバブルである。ここでもPerlかい言語は全くの蚊帳の外で大絶賛凋落中。

2012年 ビッグデータ/Hadoopブーム

Perlなんぞ全くお呼びでない世界の話。段々とwebテクノロジー世界に高度な数学的知識を持ったアカデミック層が跋扈しはじめ、専門学校プログラミング言語を学んだだけの人間ハッカーなどと名乗ると恥ずかしい時代になってきてきた。

2013年 Pythonの本格的な浸透

遂にPerlにとどめを刺したのはPythonである守備範囲は当然ながらPerl駄々被りで読みやすく書きやす世界的なシェアうなぎ上り。完全にPerlが不必要な世の中になってしまった。

結論

2005年までのPerlはまさに我が世の春を謳歌していたが今や目も当てられない惨状でプログラミング言語シーラカンス・COBOLとすら比較され出す始末。昔Perlの人として売り出していたハッカーも、いつのまにかPythonの人になっているケースも海外では多い。10年でここまで時代は変わる。今のメインテクノロジー明日は我が身だ。小手先技術に乗っかってモダンだのハッカーだの聞こえのいい言葉を汚い口でまき散らして消えて行ったPerlエンジニア達の死を無駄にしてはいけない。変化の速い時代に生きる我々に必要なのは本質を学ぶ事だ。コードの書き方とかどうでもいいんだ。もっと1020年たっても色あせない情報工学を身につけなければならない。

2013-02-28

バズワードの異常な乱用 または私は如何にしてバズるのをやめてイライラするようになったか

これを読んで思ったこと、またはその反応に対して思ったこと。

http://d.hatena.ne.jp/yomoyomo/20130228/bigdataisdead

Web2.0からクラウドビッグデータまで、様々なバズワードが生まれ、おっさんたちを虜にし、また一部から揶揄される状況が繰り返されている。当然ビジネスの上でも、これらのバズワードは多用され、一部では本質的意味のある事業が進んでおり、また一部では知的ゴロツキの餌となっているのが現状だろう。

このようなバズワードに対し、一般的な反応は大きく分けて2つだ。「我が社もビッグデータ事業だ。その方が時代に乗っていて格好いいだろう、ぐはははは」と「またバズワードか。食傷気味だ…一年で何回聞くことになるんだろう…」である

ここで、問題にしたいのはバズワードの対象自体が有用有用でないかではない。基本的に正しく捉えればクラウドビッグデータ有用だ(だからこそ、バズっているともいえる)。では、なぜこれらのバズワードが飛び交う時に、嫌な気分になったり、攻撃的になったりする人たち(自分含む)がいるのだろうか。

考えてみたのだが、バズワード言葉自体がもつ情報量が圧倒的に少ないことに起因するのではないか?ということだ。これはバズワード定義曖昧ということとは異なる。そうではなくて単語が発言されるときにその単語がもつ情報量の問題だ。通常の会話ではある単語が発言されたときに、その人の知識量やバックグラウンドを示す単語があればその人の能力をある程度推測することができる。

卑近な例だが「Excelだと100万行以上あると開けないですよね」という発言があると少なくともこの人は100万行のデータを扱ったことはあるんだなという情報受け手は得られる。技術的会話とは本来そういうもので、その人の発言する技術用語である程度の技術力を推測するものだろう。いや、コード書かせてみないとわからないだろ、というツッコミはおいてください。あくまで最低限の推測、例えばこれまで付き合いのない企業間での打ち合わせのような場合でのスクリーニングの状況を想定してほしい。

このときバズワードによって、なんかよくわかってない人も「ハドゥープでノーエスキューエルでアレですよ」みたいな発言をするようになると、これまでどちらかというとマイナー技術者かどうかを識別する単語につかえていたHadoop統計手法名をまた一から考え直さなきゃいけなくなる。一番最初スクリーニングの仕方をこちらが変える必要がある。それが激しくめんどい。だからバズワードは嫌いだ、という思考を自分がしていることに気がついた。

というわけで、ビッグデータうんぬんにイライラしている方々、この仮説は如何でしょうか?

蛇足だが、なんでこの思考に辿り着いたのかというと、あまり親しくない他社との打ち合わせ時に相手がビッグデータビッグデータ連呼するので、ほんとに技術力があるのか(またはほんとにビッグデータに関心があるのか)よくわからなかった。そこで、関心あるならそれなりにビッグデータに関する情報フォローしているはずだという仮説のもとでユバタスについて話題を振ってみたところ、ユバタスどころかPFIも知らなかった。世の中そんなもんである

2012-07-28

シェル操作課題 SQLによる解答例

シェル操作課題 (cut, sort, uniq などで集計を行う) 設問編 - Yamashiro0217の日記の解答例です。MySQL 5.5です。

準備
mysql> CREATE TABLE log (
    ->   id          BIGINT PRIMARY KEY AUTO_INCREMENT,
    ->   server_host VARCHAR(30),
    ->   access_time DATETIME,
    ->   user_id     INT,
    ->   access_url  VARCHAR(191)
    -> );
Query OK, 0 rows affected (0.00 sec)

mysql> LOAD DATA LOCAL INFILE 'log.csv'
    -> INTO TABLE log
    -> FIELDS TERMINATED BY ','
    -> (server_host, @unixtime, user_id, access_url)
    -> SET access_time = FROM_UNIXTIME(@unixtime);
Query OK, 9 rows affected (0.01 sec)
Records: 9  Deleted: 0  Skipped: 0  Warnings: 0
問1 このファイルを表示しろ
mysqlSELECT server_host, access_time, user_id, access_url
    -> FROM log;
+-------------+---------------------+---------+--------------+
| server_host | access_time         | user_id | access_url   |
+-------------+---------------------+---------+--------------+
| server1     | 2012-07-27 13:25:24 |      30 | /video.php   |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
| server3     | 2012-07-27 13:25:15 |       7 | /login.php   |
| server1     | 2012-07-27 13:25:05 |       8 | /profile.php |
| server2     | 2012-07-27 13:26:45 |      35 | /profile.php |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
| server3     | 2012-07-27 13:26:45 |      30 | /login.php   |
| server4     | 2012-07-27 13:27:05 |      12 | /video.php   |
| server1     | 2012-07-27 13:27:45 |       7 | /video.php   |
+-------------+---------------------+---------+--------------+
9 rows in set (0.00 sec)
問2 このファイルからサーバー名とアクセス先だけ表示しろ
mysqlSELECT server_host, access_url
    -> FROM log;
+-------------+--------------+
| server_host | access_url   |
+-------------+--------------+
| server1     | /video.php   |
| server2     | /profile.php |
| server3     | /login.php   |
| server1     | /profile.php |
| server2     | /profile.php |
| server2     | /profile.php |
| server3     | /login.php   |
| server4     | /video.php   |
| server1     | /video.php   |
+-------------+--------------+
9 rows in set (0.00 sec)
問3 このファイルからserver4の行だけ表示しろ
mysql> CREATE INDEX log_ix1 ON log (server_host);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysqlSELECT server_host, access_time, user_id, access_url
    -> FROM log
    -> WHERE server_host = 'server4';
+-------------+---------------------+---------+------------+
| server_host | access_time         | user_id | access_url |
+-------------+---------------------+---------+------------+
| server4     | 2012-07-27 13:27:05 |      12 | /video.php |
+-------------+---------------------+---------+------------+
1 row in set (0.00 sec)

インデックスを作らなかった場合は減点します。

問4 このファイルの行数を表示しろ
mysqlSELECT COUNT(*)
    -> FROM log;
+----------+
| COUNT(*) |
+----------+
|        9 |
+----------+
1 row in set (0.00 sec)
問5 このファイルサーバー名、ユーザーIDの昇順で5行だけ表示しろ
mysqlSELECT server_host, access_time, user_id, access_url
    -> FROM log
    -> ORDER BY server_host, user_id
    -> LIMIT 5;
+-------------+---------------------+---------+--------------+
| server_host | access_time         | user_id | access_url   |
+-------------+---------------------+---------+--------------+
| server1     | 2012-07-27 13:27:45 |       7 | /video.php   |
| server1     | 2012-07-27 13:25:05 |       8 | /profile.php |
| server1     | 2012-07-27 13:25:24 |      30 | /video.php   |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
| server2     | 2012-07-27 13:25:10 |      20 | /profile.php |
+-------------+---------------------+---------+--------------+
5 rows in set (0.00 sec)
問6 このファイルには重複行がある。重複行はまとめて数え行数を表示しろ
mysqlSELECT COUNT(DISTINCT server_host, access_time, user_id, access_url)
    -> FROM log;
+---------------------------------------------------------------+
| COUNT(DISTINCT server_host, access_time, user_id, access_url) |
+---------------------------------------------------------------+
|                                                             8 |
+---------------------------------------------------------------+
1 row in set (0.00 sec)

COUNT関数の中にDISTINCTを書けるのは覚えておくと便利です。

問7 このログのUU(ユニークユーザー)数を表示しろ
mysqlSELECT COUNT(DISTINCT user_id)
    -> FROM log;
+-------------------------+
| COUNT(DISTINCT user_id) |
+-------------------------+
|                       6 |
+-------------------------+
1 row in set (0.00 sec)
問8 このログアクセス先ごとにアクセス数を数え上位1つを表示しろ
mysqlSELECT access_url, COUNT(*)
    -> FROM log
    -> GROUP BY access_url
    -> ORDER BY COUNT(*) DESC
    -> LIMIT 1;
+--------------+----------+
| access_url   | COUNT(*) |
+--------------+----------+
| /profile.php |        4 |
+--------------+----------+
1 row in set (0.00 sec)
問9 このログのserverという文字列をxxxという文字列に変え、サーバー毎のアクセス数を表示しろ
mysqlSELECT REPLACE(server_host, 'server', 'xxx'), COUNT(*)
    -> FROM log
    -> GROUP BY server_host;
+---------------------------------------+----------+
| REPLACE(server_host, 'server', 'xxx') | COUNT(*) |
+---------------------------------------+----------+
| xxx1                                  |        3 |
| xxx2                                  |        3 |
| xxx3                                  |        2 |
| xxx4                                  |        1 |
+---------------------------------------+----------+
4 rows in set (0.00 sec)
10 このログユーザーID10以上の人のユニークユーザーIDユーザーIDソートして表示しろ
mysqlSELECT DISTINCT user_id
    -> FROM log
    -> WHERE user_id >= 10
    -> ORDER BY user_id;
+---------+
| user_id |
+---------+
|      12 |
|      20 |
|      30 |
|      35 |
+---------+
4 rows in set (0.00 sec)
個人的な感触

2012-04-24

Microsoft Kinect

http://www.tekwind.co.jp/information/entry_29.php

これを使って、たくさんの人間からサンプルをとって

大量のデータHADOOP 環境で動くDWHにつっこめば、

ある成人病の人は、動きや骨の相対位置や声などにどういう相関が高いとか

ニートの歩き方はどんな傾向だとか、抜け出すとどんな風になるかとか統計処理すれば

検診とかする前に予防などできるようになるだろう。

しか

ただ測って分類しただけじゃ、能がないぜ。おれらは家畜じゃないからよ。

会社の人事は、入社面接とか人事考課で導入したがるかもしれんが)

人間環境努力傾向などでいくらでも良く(悪くも)なるわけで

結果から因果関係を掘り下げたり、

希望する本人にあるべき方向性フィードバックいかなきゃならん。

2012-03-29

http://anond.hatelabo.jp/20120329142241

そういう人もいるだろうけど、俺が言ってるのはどっちかというと、大規模分散処理環境を作ることそのもの情熱を燃やしてる人たち。

応用先はどうでもいいという風なのがよくわからんのだよなあ。hadoopコマンド叩いてるだけで気持ちよくてたまんないって感じなんだろうか。

2011-12-30

明暗くっきり、オライリー技術評論社

オライリー本の値段は高いが、質も高い。

自分の専門分野のオライリー本は必ず一冊は持っているのが当たり前だった。「サイ本」とか本にニックネームが付けられてそれで通用するぐらいに、とにかくオライリーの本はwebエンジニアにとって特別な本であった。そして時代は変わる。

 

オライリー自体は変わっていないが、時代が変わってしまった。

日本語出版されるオライリー本の価値ゆっくりと毀損する間に、技術評論社書籍の評価はうなぎ上りだ。

 

うん、ここ最近ではHadoop本は秀逸だった。トレンド技術を捉えてうえで数年は価値が落ちない網羅っぷり。

まだ枯れきっていない分野で日本語オライリー本が存在感を示した最後の例になるかもしれない。

 

乱立するKVS分野において日本語オライリー本は無力極まりなしで目も当てられない。

cassandraがようやく出たがversion0.8だ。外人さんが書いた原本を数ヶ月から一年かかって日本語に訳し終わる頃には技術自体が進化してしまって日本語版が出版される頃には賞味期限切れ間近という切なさ。時代にそぐわないとしか言いようが無い。以前のように大型技術確立されたら五年十年それで食えます!ってな時代じゃないんよ。PerlとかMySQLのような大型で枯れきった技術はなかなか出ない。ああそうだいまだにMongoDB日本語オラ本は出ていない。英語ではもう4冊か5冊は出ているというのにだ。乱立KVSの先頭を走っているMongoDBについて紙媒体情報ほとんど無い切ない状況はいつになったら変わるのだろう。

 

この手の話題になるとすぐ「紙が悪い!電子書籍わっふるわっふる!」と叫ぶ人がいるが問題はそこではない。英語日本語に訳しているタイムラグが問題なのだ。そこに日本語オラ本の致命的な欠陥がある。

 

一昔前のように大型OSS技術が出て枯れきる、なんてことは滅多になくなってしまった。英語原本を訳してる間にも日々技術トレンドが変わってしまうんだ。なぜ日本人ほとんどは英語が読めないんだろう。文科省のせいにしたって何も解決しないけれど、webエンジニアなら英語ぐらい読めるようになれやお前ら。

 

おっと話がそれた。そろそろ技術評論社について語ろう。面倒なので三行で語る。

 

日本人スタープレイヤーが書いた原稿を元に出版される技術評論社書籍の評価が最近うなぎ上りだ。

特にWEB+DB PRESS plusシリーズはどれも凄まじい出来で恐れ入る。

公式サイト http://gihyo.jp/book/list?series=WEB%2BDB%20PRESS%20plus

 

ますます技術トレンドの移り変わりが激しくなった今、翻訳という形態技術書価値が無くなろうとしている。オライリーとて例外ではない。

オラの功績はすさまじいものがあるし、足を向けて眠れないぐらいなのだが、それでも俺はこのエントリを書かざるをえないぐらいに最近日本語オラ本にはガッカリせざるを得ないのだ。

 

日本語の本は日本人が書けばいい。訳なんていらない。それが当たり前の時代がそのうち来るだろう。

あとwebエンジニアならいい加減英語読めるようになろう。努力すればすぐに読めるようになるさ、来年はそういう年にしよう。

じゃあおやすみお前ら。

よいお年を。

2011-12-07

http://anond.hatelabo.jp/20111207191239

これは規模じゃなくて難易度の話だろ

難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか

javaだとなんだ、、、オブジェクト指向コード書けることか?

元増田に話しとくとjavaで開発するにもHadoopstrutsやらのフレームワーク

jspなどなど色々ある

Androidアプリはその中じゃそんなに難しい部類ではないと思う

別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ

別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないか

引き返したほうがいいな

自分は他に稼ぎ口がないからコレで生きていくしか無い

似たように苦しむ事が多いが腹をくくってる

2011-02-14

LLしかできないのに「大規模データ処理」とか最高にワロス

1981忘年会でLL一筋な人が酔っぱらって「大規模データ処理がさ〜」なんて言うもんだから遠くで話聞いてたらお子様レベルの内容で噴飯ものだった件について書く。

LL馬鹿「この前会社に頼まれて20GBのテキストデータを処理しちゃってさ〜 まじで難儀したよ〜」

Aさん「へーそうなんすか」

LL馬鹿「でもMySQLインデックス適切に張れば大丈夫 インデックス大事よマジで

Aさん「あー、大事ですよねインデックス

LL馬鹿「MatzRubyだと遅いから1.9YARVで処理したら2倍処理が速かったね YARV凄いよYARV

Aさん「へー、そうなんですか 凄いですね」

Bさん「pythonだともっと速いっすよ!テキスト処理ならpythonいいっすよ!」

LL馬鹿「あーわかるそれ!でもインデント嫌いなんだよオレw」

Bさん「実はオレもっすw でも20GBのデータって凄いっすね 何のデータですか?」

LL馬鹿「言えるわけ無いじゃんw しか階段一つ登った気がするね」

 

20GBって、、、、20TBならまだわかるけど、、、、、

後で知ったが妙にクールにLL馬鹿の話を受け流してたAさんはHadoopやらバリバリの人らしい

  

はあ、、、LL一筋の人ってLLが世界の中心でLLで何でも解決できるとか思っちゃってるみたいだし恥ずかしい生き物だと思いますよ

それでいて「Java本質的コードが少ないから駄目言語」とか言っちゃう

オレも数年前までPerl最高な世界にどっぷり使ってたけど排他的馴れ合い丸出し日本人コミュニティうんざりしてJava勉強しだしたけどまじで正解だった

なんつーか時代に乗れてる感じ?

時代を作ってる感覚にすら襲われる瞬間もある

大規模データを処理するってのはそういうことですよLL一筋諸君

そろそお前らも時代を作る側に来いよ

過去偉人の遺産の上に胡座かいて口先三寸な己を恥じろよ

 

さて寝るか

明日もオレの手から放たれたコード世界を動かす

そんなときめきサンデーナイト

2011-02-11

http://anond.hatelabo.jp/20110211004212

元記事にも100人1000人のユーザーならSQLでも問題ないって話をしたと思うが 1万人ユーザーって簡単なの?そもそも。って話だよね。

そしてその時のサービスは本当にツイッターたいな大量データサービスなの?と。(それってツイッターのコンペでサービスとして成り立たなそう。違えばいいけど)

 

ORACLでハイエンドサーバーグリッド使うのと 自分MYSQL分散書くのと HADOOPにするのと どれが得かはやってみないと分からん

ダウンタイムを短くしようとすると、2011年現在では組めるならばオラクルな気はする。すくなくとも簡易的にベンチとらないとわからん

 

Hadoopの怖いところは所詮Apache.orgということで、Apache.httpdのように急激な開発が流行から外れて止まってるかのようになることがあることなんだよねぇ。

Apache.httpdって、MPMいまだpreforkとか あってWorkerで event とかって、しばらく前は、いま不安定とかそういう開発状況だと思ってるんだけど。

event MPMってもう安定化したの?event MPMのコア概念である

 『Workerですら遅いから カーネルコールバックを使おうっていう流れ』自体はもう10年近く昔の概念だと思ってるんだけど・・・

 

現在 一番イケてるのはHADOOPだとは思うけど。 Rubyが一時期ほどには勢いがないのと一緒で(いちおうRoRから知っているみとしては、RoRによる隆盛が奇跡のようなものだが

まだ、怖いよね。 障害復旧の実装もまだ、弱いし。個人的にはZookeeperがもっとちゃんとなったら、もう1度 調査する! という感じで塩漬け状態なのがHadoop.

少なくとも単一障害点のフェールーバー周りが本家でどうなるかとかだねー。

 

どうでもいいけどPHPの方が好きなので PHP for apache event MPMを安定化希望・・・ まぁ、Perlもいいよね。

 

だがRubyPASCAL だけは無理だ。BEGINとか書いてあるソースを高速に読みこむのは無理。()ぐらいならいけるけど、BEGINってなんだよ。図形認識できないから読みづらいよ。

2011-02-10

http://anond.hatelabo.jp/20110210172926

から、100万件にするために、どんだけユーザー数が必要なの?

フルメッシュじゃないとした場合に。

ユーザ100人が たとえば1日10ツイートするとして 1000ツイート 100万件に達するのに 1000日 約3年

ユーザー数1000人なら 100日。

 

何が言いたいかというと、100日もかかるなら、バックアップタスク (たとえば5日ごとに分割)しても 1日あたりの件数はたかが知れてるから

余裕で持つだろ。という話。

ちなみに、100万件でもう崩壊しちゃうの? 数百万件ぐらいつっこんだことあるけど・・・このレベルは平気だよね?

 

Hadoop勉強するより先に、1万人のユーザーを集めることを先に考えたほうが良い。という話がしたかっただけ。

Hadoop勉強する のが3ヶ月としても 3人月で人を雇うのと 3人月分の既存スペックマシンMySQLとどっちがいいか?というのは超微妙

ユーザー数がたくさんいるなら、そのとおり。

テーブル分割やDB分割 サーバー分割が必要なのもそのとおり。

ただまぁ・・・単純な直列テーブルだけなら、やり方はいくらでもあるし、商用クラスHadoopか?他の競合製品が出てこないか?というのは、しばらく様子見でしょ。

調べたけど、フェイルオーバー関連がまだ微妙な部分があって考えないといけないよね。

 

Google 自体が Hadoopのつかっていた、なんたらほうしきだっけ?やめて、次のアーキテクチャーにしました。ってレポでてるのに、次もHadoop保証いし。様子見。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん