pandazx's blog

Hadoop, データ分析など雑多な技術ブログ

Ubuntu16.04でCUDAなどのインストールでログインできなくなった場合の対処

NVIDIAグラフィックカードディープラーニングGPUとして使う場合、 グラフィックカードのドライバ、cuDNN、CUDAをインストールするが、 インストール後に再起動すると画面が正しく表示されず、ログインできなくなる場合がある。

場合があるというか、よくある。

Ubuntuでこの現象が起きた場合に画面が起動中の紫色一色になったままことがある。 この場合、放置、電源長押しのシャットダウン、再起動を何回か繰り返して 20-30分ぐらい経過して、諦めの境地に達した時に 急に画面を正しく認識し、ログイン画面が表示されるようになるので、すぐに諦めてはいけない。 後はディスプレイの画面表示をフルスクリーンにしたり、他のにしたりしてみたり。

以下の方法も有効だと思われる。

Ubuntu14.04にNVIDIAドライバーをインストールしたらGUIログインできなくなったときの話

メモ: 話が分かりにくい人の条件

@sogitani_baigie のツイート。

https://twitter.com/sogitani_baigie/status/1022282283997310977?s=21

話が分かりにくい人の条件

・前提の説明がない

・結論を先に言ってない

・質問に答えてない

・全体→部分という構造になってない

・抽象的な言葉が多い

・相手に合わせて使う言葉を選んでない

・言葉を省略しすぎてる

・事実と解釈がごちゃまぜ

・話が拡散したり脱線したりする

 

教材として使えそう。

戦わずして勝つファシリテーション

開発プロジェクトでお客様または企画と打合せする際に打合せ資料を作成し、打合せの流れを考えてアジェンダを作成する。

打合せの目的が進捗報告の場合がある。その場合、プロジェクトを進めるにあたって見つかった課題を議論する。

課題はプロジェクト関係者全員にとって解決すべきことだが、その解決方法は様々である。解決方法によっては、誰かにしわ寄せが行くこともある。開発を請け負う側としては、開発がスムーズに行くようにしたいと思うのは当然である。

 

おそらく、多くの場合、課題は開発から報告される。打合せで課題をそのまま報告するのは悪手である。開発側としては、その課題の落とし所を考えておき、打合せで解決方法が意図したところに落ち着いて欲しい。

これの可能性を高めるには打合せ準備が大事だ。そして、「戦わずして勝つ」、つまり、打合せでハードな議論をせずに意図したところに話の流れを持っていく。

それは話の出発点を相手が重視するところからスタートさせること。例えば、企画があって開発があるので、当然、出発点は企画の立場にたったものになる。最初に開発の話からスタートさせてはいけない。それでは、企画からしたら、自分たちのロジックではないものをぶつけられるので、話を聞くスタンスが守りから入ってしまう。それではお互いがぶつかってしまう。

相手が納得しているロジックからスタートして、意図した解決方法に至るまでのロジックを展開する。この時にすべてを話すのではなく、一部は相手に考えてもらい、自然と意図したところに話がいくようにファシリテーションする。

 

どうやっても、どちらかが泣くしかない場合は戦うしかない。ただ、その場合、最終的に責任者が決断することになるので、それこそ、打合せが始まる前に勝負は決まっていると言えなくもない。

プロジェクトを壊す人

とある記事からの引用だが、

古参メンバーに何から何まですべて聞く
進捗が良くないことをごまかす
理解できていない部分をごまかす
よく分からないけど、なにかやばい

 

この中のどれか1つ該当ではなく、複数持ちの人はプロジェクトキラーと言える。

Openstack Swiftコマンドメモ

Swiftをコマンドラインから操作する方法メモ

コンテナ操作

# リスト表示
openstack container list
# 作成
openstack container create {container_name}
# 削除
openstack container delete {contaier_name}
# オブジェクトが残っていてコンテナが削除できない場合は以下のコマンドで削除
openstack container delete -r {contaier_name}

オブジェクト操作

# リスト表示
openstack object list
# 登録
openstack object create {contaier_name} {filepath}
# 削除
openstack object delete {contaier_name} {filepath}
# 取得
swift download {contaier_name} {filepath} -o {output path}

メルカリ CRE Server Side Tech Talk vol.2に行ってきた

mercari.connpass.com

に行ってきた。以下はメモ

CREチームの紹介

  • CREとは、お客様からの信頼性向上を目指すエンジニア
  • 元々はCXIで、カスタマーセンターCSのサポートがメインだった
  • これをメルカリのユーザーにまで対象を広げた

メルカリの商品監視を支える技術

機械学習によるマーケット健全化を支える技術

  • LovemachineというML基盤を独自開発しており、OSS公開予定だが、人手が足りなくて、あまり進んでいない

機械学習によるマーケット健全化の施策

  • スピーカーの自己紹介
    • Solarのクエリチューニング
    • 近所検索を開発
  • CSには偽ブランドを見分ける鑑定士がいる
  • 質問
    • 商品監視の機械学習モデルは複数ある?複数の結果をどう解釈してる?
    • 監視目的別にモデルがある

「アプリケーションエンジニアのためのApache Spark入門」出版記念セミナーに行ってきた

connpass.com

に行ってきた。以下はメモ

Apache Spark入門書籍の紹介

  • 理論よりも使い方に重きを置いた入門書
  • サンプルのプログラミング言語Python
  • データ分析基盤に使われるOSS紹介
  • データ収集はfluentd, kafka
  • データ蓄積はhdfs, cassandra
  • ストリーム処理、簡易な集計分析はSpark structured streaming
  • バッチ処理はSpark SQL
  • データ分析はSpark MLlib, Jupyter
  • Sparkが注目されている理由はデータ分析プラットフォームの主要な機能があるため

Fluentd, Kafkaの紹介

  • 残念ながらスピーカーが私用のため、欠席

Spark Streamingについて

  • ストリーム処理はデータが無限
  • バッチ処理はデータが有限
  • ただ、Spark Streamingはマイクロバッチなので、データを有限として扱う
  • Spark2.3.0から継続実行方式が可能になる
  • ストリーム処理で発生する問題
  • データが発生した順に到着しない。out of order. ネットワーク遅延やサーバ間の時刻ズレなどが原因
  • データのグルーピングの概念
  • タンブリングウィンドウは固定長で区切る方式
  • スライディングウィンドウは固定長だが、スライド幅が異なる方式
  • セッションウィンドウは特定キー、特定時間内のデータを同一ウィンドウにまとめて処理する方式
  • 実際に到着が遅れて困る例。データが大幅に遅れると、どこまで、その遅れを待てばいいのか検討が必要
  • 対応方法としては、データ発生時刻とデータ処理時間を分けて管理する。加えてDBへの投入時間を管理する場合もある
  • どこまで処理したかの管理はwater markで管理
  • データ発生時刻が一定時間以上古い場合は除外する
  • 出力する値や集計方式として、処理完了したもの、追加部分のみ、更新部分のみを選択可能
  • これらのサンプルプログラムが書籍に記載されている

データの蓄積

  • Spark SQLとCassandraの紹介
  • Spark処理結果を出力先として、Cassandraがオススメ

データ分析について

  • データ分析プロセスCRISP-DM
  • 他にKDD,SEMMAがある
  • 資料は後日、公開

プロダクション投入に向けて

  • Sparkは計算資源といえる。そのため、ステートレス化できる。今風に言えばサーバレスにできる
  • AWS Glueを使うとHdoopクラスタなしにSparkを使える。GlueにHive metastoreを置いて、実データはS3に置く構成