2012/08/01

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

ログファイルをコマンド使って解析するというこの課題。

え。Windows?まさか???cygwin入れたり、vmでやってみたり、開発サーバーで作業すればいいんじゃないっすか(ホジホジ)

いやいやWindowsでシェルと言えばPowerShellでしょう!というわけでやってみました。出力形式に関しては本筋とは関係ないと思うので、PowerShellのデフォルトのままです。

準備
$logs = Import-Csv hoge.log -Header ServerName,UnixTime,UserId,AccessUrl
問1 このファイルを表示しろ
$logs
問2 このファイルからサーバー名とアクセス先だけ表示しろ
$logs|select ServerName,AccessUrl
問3 このファイルからserver4の行だけ表示しろ
$logs|where {$_.ServerName -eq "server4"}
問4 このファイルの行数を表示しろ
$logs|measure
問5 このファイルをサーバー名、ユーザーIDの昇順で5行だけ表示しろ
$logs|sort ServerName,{[int]$_.UserId}|select -First 5
問6 このファイルには重複行がある。重複行はまとめて数え行数を表示しろ
$logs|sort * -Unique|measure
問7 このログのUU(ユニークユーザー)数を表示しろ
$logs|sort UserId -Unique|measure
問8 このログのアクセス先ごとにアクセス数を数え上位1つを表示しろ
$logs|group AccessUrl -NoElement|sort Count -Descending|select -First 1
問9 このログのserverという文字列をxxxという文字列に変え、サーバー毎のアクセス数を表示しろ
$logs|group {$_.ServerName -replace "server","xxx"} -NoElement|sort Count -Descending
問10 このログのユーザーIDが10以上の人のユニークなユーザーIDをユーザーIDでソートして表示しろ
$logs|where {[int]$_.UserId -ge 10}|select -Expand UserId|sort -Unique

PowerShellはテキスト情報をテキストのまま扱うのではなく、オブジェクトとして扱うところが特徴で、CSVファイルもImport-Csvコマンドレットを用いることで、ヘッダ文字列をプロパティ名として各行をオブジェクトとして読み込んでくれます。

あとは各種オブジェクト処理のコマンドレットに、パイプライン経由でオブジェクトを渡していくだけです。コマンドが何をやっているのかも、列番号ではなくプロパティ名を指定してやるので分かりやすいと思います。この課題に寄せられた回答の中では、シェル操作課題 SQLによる解答例が近いかと思います。

今回はCSVから情報を読み込んでいますが、ソースは別になんであってもいいわけです。たとえばGet-EventLogコマンドレットだとイベントログから持ってくることもできますし、XMLなら$xml=[xml](Get-Content file.xml)みたいな感じです。一旦オブジェクトとして取得できてしまえば、あとの処理方法は基本的に同じなので悩む必要がないのが良いところです。

そしてPowerShellの良いところはやはり、外部処理コマンドを使わずとも、シェル言語と組み込みコマンド(コマンドレット)のみで処理が完結するところです。たとえばbashだけでやるとtsekine's miscellaneous thoughts: シェル操作課題への回答のような大変なことになるようです。sortなど基本的なコマンドは使用するにしても、複雑なフィルタ処理などはawkを組みあわせる等しないと、特に後半の処理は辛いでしょう。PowerShellなら異なる処理系を持ち出す必要がなく、PowerShellのみですべて行えます。

もちろん問題点も色々あります。まず第一に、今回の課題のように、ヘッダ文字列がないCSVの場合は例のようにヘッダー文字列(=プロパティ名)を自分で定義してやる必要が出てきます。そのため可読性はともかく、若干、冗長なところがでてきてます。まあ例のように一旦オブジェクトを作って変数に入れてしまえばあとは使いまわせますが、そこはちょっと厳しい点かもしれません。

あとImport-CsvコマンドレットはCSVの各エントリをすべて文字列型のプロパティとしてオブジェクトに格納するところがちょっと微妙な気がしました。数値は数値型で入れてほしいですよね。おかげで何か所か、[int]にキャストせざるを得ない部分が出てきました。

そして処理速度の問題。おそらくログファイルが巨大だとかなりリソースを食って時間もかかると思います。処理を分ける、バックグラウンドジョブやワークフローで動かす、そもそもログファイルを分割保存するようにしておく、等、実運用上では工夫が必要かと思います。

(5:14追記)
既出でした>< [Power Shell] シェル操作課題への回答 - Pastebin.com(by @usamin5885さん)

2009/12/03

TwitterはRESTなAPIを備えているので、httpの通信ができれば基本的にどんな言語でもクライアントを作ることができるのがいいです。そこで私もPSTweetsというPowerShell版Twitterクライアントを作っているのですが、認証周りで問題が発生しています。

Twitterの認証には標準認証とOAuthが使えるのですが、現在はセキュリティ上の理由で標準認証は非推奨です。標準認証がなぜまずいかというと、マッシュアップサービスでTwitterに対して認証が必要な操作をする場合、ユーザーがその第三者のサービスにTwitterのIDとパスワードを送らなければならないためです。そのサービスがユーザーの認証情報を安全に保持してくれる保証はありません。

そこで考えられたのがOAuthという認証方法です。OAuthはとてもややこしいプロセスを含んでいますが、実質はそんなに難しいものではないです。要は、Twitterというサービス(これをサービスプロバイダという)にアクセスするための権限を、マッシュアップやクライアントを提供する第三者(これをコンシューマという)に委譲する仕組みです。ユーザーが「コンシューマを使いたい!」と思ったら、コンシューマは「じゃあついったーのページに飛ばしますから、あなたのアカウントを私が自由に使うことを許可してね」と言います。それでユーザーがTwitterのOAuth承認ページで「許可」すると、コンシューマはユーザーのアカウント情報を使ってTwitterのAPIを叩けるようになり、ユーザーはコンシューマにTwitterのパスワードを知らせることなくコンシューマの提供するサービスを利用することができるわけです。

さて、このOAuthをコンシューマが利用するには、Twitterにあらかじめ申請する必要があります。といっても登録ページでクライアント/サービス名などを入力するだけです。そうすると、コンシューマキーとコンシューマシークレットという文字列をもらえます。これはクライアントを特定するためのユーザー名とパスワードみたいなものです。ちなみにこの情報はコンシューマを提供する人のTwitterのユーザーアカウントに紐づいています。

コンシューマを通じてユーザーがTwitterのサービスを使うには、コンシューマを通じてTwitterからアクセストークンというものを貰う必要があります。このとき、コンシューマはTwitterに毎回コンシューマキーとコンシューマシークレットを送らなければなりません。

ここでコンシューマが独立したサーバーで運営されているサービスならば何も問題ありません。ユーザーがコンシューマキーとコンシューマシークレットを知る必要もユーザーに知られる危険性もありません。ところが、デスクトップクライアントだとどうなるかというと、コンシューマはデスクトップクライアントそのものです。なので、デスクトップクライアントはコンシューマキーとシークレットを何らかの方法で取得し、Twitterに送る機構が必要になります。

ここで、いくつかの方法があると思います。コンシューマキーとシークレットをデスクトップクライアントに暗号化して埋め込むのも一つの方法でしょう。ですが、結局は復号してTwitterに送らなければならないので、その通信をキャプチャすればユーザーは知ることができます。

なぜコンシューマキーとシークレットをユーザーに知られるとまずいかというと、それらを使うとまったく別のクライアントやサービスを、そのサービス名を詐称して作ることができてしまうからです。これがどうして問題なのかというと、そうなるとOAuthの承認が有名無実化してしまうためです。ユーザーがOAuthの承認ページで承認するサービスが本物かどうか調べるすべがありません。

メール登録制にしてコンシューマキーとシークレットを配布するとか考えましたが、なんだか大昔のシェアウェアのようで、なんとかシリアル集がはびこったように誰かが漏らしてしまう危険性を考えると難しいです。

コンシューマキーとシークレットを自分で取得してもらうというのも考えましたが、それはユーザーにとってかなり敷居が高いうえ、クライアント名がみんなバラバラになってしまいます(Twitterクライアント名はユニークであるため)。

コンシューマキーとシークレットを保持し、ユーザーからのリクエストに応じてアクセストークンを発行するサーバーを立てるというのも考えましたが、それってもうデスクトップTwitterクライアントじゃなくて、Twitterマッシュアップのデスクトップクライアントになってしまいます。

なので、デスクトップクライアントでOAuthを使うのは事実上無理なんじゃないかというのが私の結論です。

標準認証でもいいんですが、現在は標準認証は非推奨であり、そのため今からクライアントを作る場合は標準認証だとクライアント名をTwitterに登録することができなくなっています(タイムラインには「APIで」という表示になってしまう)。昔はメールでクライアント名を申請できたんですが、今はできません(この体制になる前に申請されたクライアントなら、今でも標準認証でもクライアント名を名乗れます)。これから作るクライアントで、クライアント名を名乗るにはOAuth必須です。ボット作者など、コンシューマ=ユーザーの場合はそれでもいいんですが…。これはぜひなんとか改善してもらいたいところですね。といっても、Twitter側からみると、それがコンシューマからのアクセスなのか、ユーザーからのアクセスなのか、区別をするのは難しいでしょうから、デスクトップアプリに限り標準認証でもクライアント名を名乗れるようにする、というのは難しいんじゃないかという気はします。

最近、新しいデスクトップクライアントがあまり登場せず、一方でやたらTwitterのマッシュアップサイトが増えたと思いませんか?中には、それデスクトップアプリでいいじゃないというものもちらほら。もしかして、この制限ができたためなんじゃないかと邪推までしています。うーむ、なんとかならないですかねー?

元記事:http://blogs.wankuma.com/mutaguchi/archive/2009/12/03/183506.aspx


Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー

Twitter

Books