Databricks、大躍進のわけ

投稿日: 2020年6月11日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

Databricksの名前をよく聞くようになりました。たとえば、米調査会社ガートナーが2月に発表したデータサイエンス プラットフォームの企業ランキングでは、DatabricksをLeaders（先頭集団）として位置付けています。ちなみに、MicrosoftやGoogleはLeadersでなく、Visionaries（先見性がある企業）にランクされ、IBMはさらにその下のChallengers（挑戦者）にランクされています。そのことからも、いかにDatabricksの評価が高まっているかがわかります。

Databricksの評価が高まっている理由はいろいろあるようですが、最大の理由は次の2つに絞られると思います。

1つは、Apache Sparkを利用しやすくしたこと。

もともとビッグデータを処理するフレームワークとして、In-Memory（インメモリ）と分散処理による高速化でインタラクティブなデータ分析を可能にしたApache Sparkは、すでに脚光を浴びていました。しかし、その実装が単純ではないという声も強かったのは否めません。そんな中、Databricksを通じて、より簡単にApache Sparkのフレームワークを活用できるようになるという利点が、Databricks躍進の原動力になったのは間違いありません。

2点目は、DatabricksがUnified Analytics Platform（データアナリティクスの統合プラットフォーム）であるということ。

データアナリティクスはデータアナリストの仕事、と思われがちですが（文字通り取れば、そのとおりなのですが）、実際にはさまざまな役割分担が必要です。データエンジニアが、生のデータを処理可能な状態に変換して、それを活用するためのアーキテクチャを設計し、データサイエンティストがそのデータを精製して、そこからビジネスに役立つ分析情報を引き出す方法を考え、機械学習（ML）エンジニアがMLモデルを構築して、データにもとづく予測分析を可能にします。

つまり、ひと口にデータアナリティクスと言っても、多岐にわたる作業がさまざまな専門家によって分担され、それぞれが使用するシステムが異なったりします。システムが異なると、それを橋渡しするための余計な作業とコストが生じます。しかし、Databricksなら、データアナリティクスを分担する全スタッフが同じプラットフォームで作業でき、連携を密にできます。たとえば、データエンジニアはDatabricksでラムダ（Lambda）やデルタ（Delta）アーキテクチャを構築でき、データサイエンティストとMLエンジニアはMLモデルを構築して、MLflowなどでMLライフサイクルを管理できます。

さらに、このようなデータ アーキテクチャを基盤として、データアナリストがBIツールで分析情報を可視化する際、Databricks独自の可視化ツールも利用できるし、データアナリストがすでに使い慣れている他のBIツールに接続することもできます。たとえば、JavaベースのBIツール EspressReport ES（ERES）なら、JDBCドライバを通じてDatabricksに簡単に接続することができます（接続方法の詳細はDatabricksとERESの連携確認を参照）。

このように、データアナリティクス チームの誰もが  —  特に、BIツールを使用するビジネスサイドのスタッフとデータ アーキテクチャを構築するテクニカル サイドのスタッフの双方が  —  共通のプラットフォームで連携して作業できることは、Databricksの大きな強みです。データアナリティクスの標準プラットフォームとして、Databricksのさらなる躍進が見込まれる所以です。

 

 

 

 

関連するトピックス:

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。