wyukawa’s blog

データ民主化の負の側面

技術

データの活用が当然のことのようになってエンジニア以外でもSQL書いてデータ抽出するのが一般的になってきました。さらにデータサイエンティストの登場により高度な分析もされるようになってきて、顕在化してきたのがHadoopクラスタの無法地帯化とエンジニアの疲弊なんじゃないかと最近思っております。なおHadoopに限らずElasticsearchでも言えたりします。

これって要はユーザと管理者のバランスの問題で、Hadoopエンジニアを採用するのが難しいというのが背景にあります。

SQL書ける人はそれなりにいるけど、インフラ側の人材不足ですね。この状態でデータの民主化が進むとどうなるかというと、

クエリの数が増える -> なかにも重いクエリも結構ある -> 管理者がそれをチェックするのに疲れて放置するようになる -> クラスタの負荷が増えて障害も出るようになる -> クエリ実行にも時間かかるようになるため、まとめてクエリを投入する人がでてくる -> クエリの数が増える -> ...

というような流れになっていきます。ユーザも多くなっている状況なのでクラスタのアップグレードのようなメンテナンス作業も難しいでしょう。そうして管理者が去り古いインフラを使い続けるユーザだけが残りましたとさ、、、という暗い未来が想像できてしまいます。

まあそうなったらもう外注なり外部のクラウドサービス使った方が良いでしょう。

データの民主化が成立するのって、ユースケースとして重いクエリを投げる必要がないというのと、クエリ投げる人が少数でモラルがある、例えばクエリを投げっぱなしで帰らないとか、自分が投げたクエリをチェックしていて時間かかってそうなら一旦killしてクエリに問題ないか見直すとか、そういう前提が必要なのかなと思っています。

セキュリティ周りとかその辺の基盤がちゃんと整う前になし崩し的にデータの民主化が進むと、クラスタの荒廃化は進みがちです。まあそれでもちゃんとデータサイエンティストの成果が出てそれがエンジニアの給料に反映されるなら問題無いという説もあります。

ただともかくデータにアクセスさせろという人が増えてくると、RDBSからHiveにデータ持ってくる仕事ばかりが増えてきて、そんな仕事モチベーション湧かないよねという。。。なのでエンジニアがツール用意してそれを使って勝手にやってもらうというのが現実的なのかもしれませんが、Spark使いたいとかR使いたいとかいろいろ出てくるとそれ全部対応するのは難しい。

エンジニアを疲弊させるもうひとつの例が、データサイエンティストが書いたクエリ、コードはそのままじゃプロダクションに入れられないから、エンジニアが引き取ってってやつ。や、長い複雑なクエリ渡された人の気持ちを考えると。。。原則としてシンプルなコードじゃない限り人のものなんか読みたくないもんですよ。

このようにエンジニアを疲弊させるものが増えているので、どうしたもんかなと考えています。そういう背景があるので、データくれっていう人に対して感じ悪く塩対応するエンジニアとか、糞クエリを容赦なくkillするhive/presto警察とか、クエリ実行中だろうがメンテナンスして強引にアップグレードするとか、そういったものが必要なのではないかと思ったりしております。

GoogleとかFacebookとかだと充実したインフラがありそうだからそういう問題はないのかもね。

Permalink | コメント(0) | トラックバック(0) | 11:46