わたしたちがマイクロソフトのデータプラットフォームに思うこと

AI の壁、エンジニアが生き残る道は

山本：いま Access が話題になりましたが、SQL Server などもあり。スモールからビッグまで、どう使い分けていますか？

太田：ユースケースの違いだと思います。

長田：ここだから質問したいのですが、RDB と NoSQL 、どう使い分けていますか？いまいち腑に落ちないんですよ。

三宅：データの数や量よりもトランザクション管理ですね。トランザクション管理が厳密ならRDB がいいです。NoSQL でもできなくないですが、ハックレベルなので。

山本：商用データベースならトランザクション管理は当然ですが、OSSのデータベースではトランザクション管理が実装されてない時代があったと聞いて驚きました。

三宅：それなら NoSQL でもいいかもしれませんね（笑）。ブログとかならトランザクション管理は要りませんし。

太田：わたしがよく説明するのは CAP 定理です。一貫性(Consistency) 、可用性 (Availability)、分割耐性(Partition-tolerance)。この3つを同時に保証することは難しいとされています。例えばSQL Serverのようなリレーショナルデータベースは一貫性と可用性の保証を重視しています。一方でNoSQLは可用性と分断耐性、もしくは一貫性と分断耐性を重視しています。つまり、どれを取捨選択するかの違いです。

三宅：それでうちは3～4つのデータソースを組み合わせることも多いです。

山本：CAP 定理は基本に立ち返るという意味で納得しました。最近だと AI が話題で、SQL Server には機械学習サービスが組み込んだりしています。長田さんはどう見ていますか？

長田：最近だと人工知能、AI、ML（マシンラーニング）という言葉が一人歩きしていると感じています。「 AI がなんでもやってくれる」と考えている経営層とか。一方開発者は考え方を変えていく必要があると考えています。　

太田：わたしはAI をブームではなく必然だと思っています。その説明として最近オンライン セミナーで使ったネタを話させてください。

山本：どうぞ。お願いします。

太田：ここではAIは生産性を向上させるためのツールであることをお伝えしています。これまでは人がルールを決めてアルゴリズム（プログラム）を記述していました。これには多くの時間を要していました。しかし今は機械学習を活用することによりデータからアルゴリズム（モデル）をあっという間に導くことができるようになっています。これからのエンジニアはプログラムではなくモデルを管理していくことになるのではないでしょうか。

長田：考え方やアプローチを変えていく必要があるということですね。聞いてて思ったのはデータの質も重要だと思いました。最近聞いた話で、糖尿病研究で検尿のデータを集めて分析しようとしたら、人間のものではないサンプルが混じっていたというのです。

山本：それ、聞いたことあるかも。犬のを持ってきたとかではないですか？

長田：そうなんです。人間の糖尿病検査なのに、自分よりペットの糖尿病が心配でペットの尿を提出した人がいたのです。この1件の混入でデータの集合がおかしくなってしまいます。

山本：データ整備は「マエショリスト（前処理する人の意味）」というデータサイエンティストさんも言っていました。「データ分析をする前に、データにゴミが入らないようにデータを選別する、必要なデータを収集することが大事」と話されていました。

太田：特異なデータについてはプログラムで処置するのも大事ですね。

三宅：前処理は時間がかかります。先日画像でディープラーニングをしたのですが、実際の処理にかけるまで、クリーンなデータを準備するのに数日かかりました。いいところで切り取ったり。「これはまだ AI 処理の手前だ」と思いながら。前処理の機能は充実してほしいですね。

山本：みんなでボーティングしましょう（笑）。

三宅：マイクロソフトの前処理ツールで vott があります。タギングができてすごく便利です。これがなければ GPU がんがん回しても（分析で）意味がない。前処理、すごく重要だと痛感しました。また、今は前処理のノウハウが重要なので、まだエンジニアが活躍できる領域だと思っています。

山本：太田さんの話にも通じますね。AI の台頭でエンジニアが要らなくなると懸念もありますが、モデルの管理と前処理はまだ必要ですから。

三宅：あとモデルのデプロイ。モデルを作ったり、分析自体は AI に任せてもいいのでは。いかにそうしたツールを使うか。

山本：AI のモデルと GPU のドライバセットをコンテナ技術で管理している例もあります。Machine Learning Workbench のコンセプトがこれに該当します。

三宅：AI とコンテナ技術は相性良さそうですね。ディープラーニングは環境構築がすごく大変ですから。SQL Server も Docker が使えるようになったから、元データも管理できるといいですね。コンテナ技術はエンジニアなら覚えておいて絶対に損はないですよ。

太田：リレーショナルデータベースのオプティマイザにもAIが活用されそうです。当初はあらかじめ決めたルールベースで動いていた、今はDB内に蓄積した統計データを頼りにコストベースで動いている、これがさらに進化しモデルベースで動くようになることは自然な流れである気がします。

山本：もう少しで実現できるのではないでしょうか。

三宅：ぼくの SQL Server が好きなところって管理の自動化なんですよ。AI でどんどん便利になるといいですね。

山本：SQL Server のデータならオプティマイザのエンジンを作ったとしても自社製品どうしなので学習効率も良さそうですから。期待したいです。Cosmos DB で最適化したいものはありますか？

三宅：クエリがすでに速いですからね。頑張ってほしいのはグローバル分散での強い整合性ですね。Google Cloud Spanner がありますから。Amazon DynamoDB も Cosmos DB に近づいていますし。他社製品の話ばかりですみません。

山本：いえいえ。満足してしまうと製品の将来はないですから、フィードバックは大事です。Azure Database for MySQL や Azure Database for PostgreSQL も元はフィードバックから製品化にこぎつけたんですよ。今皆さんなら、どんな要望をあげたいですか？

三宅：ぼくなら Cosmos DB のオートスケールです。Amazon DynamoDB ができるので、Cosmos DB で大至急できるようにしないとまずいと思います。Microsoft Azure SQL Database ならバーストが起きてもなんとか頑張ってくれるじゃないですか。

山本：みんなで（フィードバックという形で）声を上げましょう。