メインコンテンツへジャンプ
<
ページ 9
>

Apache Spark™ と R によるユーザー定義関数の最適化と実用化 —ミネソタ・ツインズにおける投球シナリオのスケーリング–Part 2

序章 Part 1 では 、ミネソタ・ツインズの BOG(Baseball Operations Group)が、選手の成績をより正確に評価するために、過去 1,500 万回の投球ごとに 2 万回、合計 3,000 億回のシミュレーションを実行する必要があったことをお話ししました。BOG のアイディアはシンプルです。 過去 1,500 万回の投球から選手の成績をイメージ化できれば、各選手の分布に従った 3,000 億球のシミュレーションデータからは、より鮮明なイメージと信頼性の高い評価が得られることが想定できます。 このデータは、より多くの勝利を生み出してクラブの収益を上げることを目的とするコーチや人事の決定に影響を与えます。 データを生成・記録するスクリプトと機械学習モデルは全て R...

Delta Engine の概要

本日、Databricks は Delta Engine を発表しました。Delta Engine は、Apache Spark 完全互換のベクトル化クエリエンジンで、最新の CPU アーキテクチャに対応し、Databricks Runtime 7.0 に含まれている Spark 3.0 のクエリオプティマイザおよびキャッシング性能の最適化機能を連携させます。その相乗効果により、データレイク、特に Delta Lake で実現されたデータレイクでのクエリ性能が大幅に高速化され、 レイクハウス アーキテクチャの採用やスケーリングが容易になります。 実行性能のスケーリング...

ミネソタ・ツインズにおける投球シナリオのスケーリング - Part 1

野球の試合における統計分析 メジャーリーグベースボール(MLB)では、投球フォーム、球種や回転数などの投球内容、各選手の打球の動作に至るまで、1 回の投球当たり数十メガバイトのデータが生成されています。1 試合、1 シーズンの間に、これらのデータからいかにして実践可能な気づきを導き出すのでしょうか。2019 年度アメリカン・リーグ中地区優勝チームのミネソタ・ツインズ内の BOG(Baseball Operations Group)は Databricks を導入しています。このブログでは、BOG が Databricks を活用して膨大なセンサーデータを収集し、各投球のシミュレーションを数千回、数万回と実行し、実践可能な気づきを迅速に導き出し、選手の成績の分析やパフォーマンスの改善、競合の偵察、才能評価の改善に役立てる方法を紹介します。ミネソタ・ツインズではさらに、分析サイクルを高速化し、得られた気づきを素速くコーチ陣に伝達することで、試合中の戦略におけるリアルタイム性を高める方法を模索しており、それについても解

Apache Spark 3.0 概要|Python API の強化・PySpark API の拡充など新機能搭載

Apache Spark TM 3.0.0 が Databricks Runtime 7.0 で利用できるようになりました。Spark 3.0.0 はオープンソースコミュニティでの多くのコントリビュートが結実したものです。3,400 以上のパッチが含まれ、Python API および ANSI SQL の機能拡充に加え、開発や調査が行いやすくなるような工夫が施されています。オープンソースプロジェクトとして 10 年目を迎え、多くの参加者の意見と多様なユースケースに応え続けてきた結果が反映されています。 Apache Spark 3.0 の主な新機能...

MLflow モデルレジストリをエンタープライズ機能に拡張

Databricks の MLflow モデルレジストリ にエンタープライズレベルの新機能が追加されました。 Databricks の統合分析プラットフォーム をご利用いただいている場合、MLflow モデルレジストリはデフォルトで有効になります。 このブログでは、モデル管理を一元化するハブとしての MLflow モデルレジストリのメリットをご紹介し、組織内のデータチームによるモデル共有やアクセス制御、モデルレジストリ API を活用した統合や検証について解説します。 MLflow によるハブの一元化が、モデルライフサイクル管理のコラボレーションを可能に MLflow には、実験の一部としての メトリクス 、 パラメータ 、 アーティファクトをトラッキングする機能...

Facebook Prophet と Apache Spark による高精度で大規模な時系列予測・分析とは

Databricks の時系列予測・解析 Notebook を試してみる 時系列予測・分析技術の進展により、小売業における需要予測の信頼性は向上しています。しかし、より正確なインベントリ管理を実現したい企業にとっては、予測の精度とタイミングが課題となっています。従来のソリューションにおいては拡張性や正確性の面で制約がありましたが、 Apache Spark™ と Facebook Prophet の活用によってこれらの課題を克服する企業が増えてきています。 To see this solution for Spark 3.0, please read the post here...

Delta Lake でのスキーマ(schema)DB の適用・展開とは

September 24, 2019 Burak YavuzBrenner Heintz による投稿 in Databricks ブログ
データブリックスの Notebook シリーズを試す データは常に進化し、蓄積されていきます。私たち人間の日々の経験と似ているかもしれません。私たちは、自身の周りの世界の変化についていくために、常に新しいデータを取り込み、認識し、ときにはその中から新たな概念や解釈を得ます。このような認識モデルは、まさにテーブルのスキーマそのものです。どちらも、新しく得る情報の分類と処理のしかたを決める役割を持っています。 データベースにおけるスキーマとは : そもそも「スキーマ(schema)」とは、日本人にとっても馴染みのある「スキーム(scheme)」という言葉の派生語です。計画や図などの意味を持ち、データベース関連だけでなく、哲学や心理学で使われている言葉でもあります。この記事で説明するデータベーススキーマ(DBスキーマ)とは、簡単に言えばデータベースの構造や整理の仕方のことです。細かな定義は、データベースの種類や会社によって異なりますので、今回は Databricks の次世代型データレイク・データウェアハウスである、D

Delta Lake を深堀り:トランザクションログの解析

August 21, 2019 Burak YavuzMichael ArmbrustBrenner Heintz による投稿 in Databricks ブログ
トランザクションログは、ACIDトランザクション、スケーラブルなメタデータ処理、タイムトラベルなど、Delta Lake の最も重要な機能の多くに共通する要素であるため、Delta Lake を理解するうえで重要な鍵となります。この記事では、Delta Lake のトランザクションログとは何か、ファイルレベルでどのように動作するのか、そして、複数の同時読み取りと書き込みの問題に対してどのようにエレガントなソリューションを提供するのかを探ります。 Delta Lake のトランザクションログとは Delta Lakeトランザクションログ(DeltaLog とも呼ばれる)は、Delta Lake テーブルで実行された全てのトランザクションの記録で、その開始以来、順番に記録されています。 トランザクションログの目的 シングルソースオブトゥルース Delta Lake は Apache Spark™ 上に構築されており、あるテーブルの複数のリーダーやライターが同時にテーブル上で作業することを可能にしています。ユーザーに常

Databricks Connect:ホスト型 Apache Spark™ をアプリ、マイクロサービスに

June 14, 2019 Eric Liang による投稿 in Databricks ブログ
Databricks Connect は、ネイティブな Apache Spark API を任意の Notebook、IDE、カスタムアプリから利用可能にするための新たなライブラリです。今回はその概要をご説明します。 概要 ここ数年、Apache Spark 向けにさまざまなカスタムアプリケーションコネクタが開発されています。spark-submit、REST ジョブサーバー、Notebook ゲートウェイなどのツールなどが含まれます。しかし、これらのツールには多くの制限があります。以下はその一部です。 汎用的でなく、特定の IDE や Notebook でのみ動作するものが多い。 アプリケーションを Spark クラスタ内でホストして実行することが必要な場合がある。 Spark...

機械学習モデル、決定木(ディシジョン・ツリー)による分析を活用した金融詐欺検知の大規模展開

Databricks の Notebook を試してみる 人工知能(AI)を活用した金融不正行為検知の大規模展開は、いかなるユースケースにおいても容易なことではありません。膨大の履歴データの取捨選択、絶えず進化する機械学習と深層学習技術の複雑さ、不正行為の実例の少なさなどが、不正行為パターンの検知を困難にしています。金融サービス業界においては、セキュリティに対する懸念の高まりや、不正行為がどのように特定されたかを説明することの重要性が加わり、複雑さがさらに増大しています。 一般的に、検知パターンを作成するために、まずはドメインエキスパートが不正行為者が行うであろう行為を想定して一連のルールを作成します。ワークフローに金融詐欺検知の専門家を含めて、特定の動作に関する要件をまとめる場合もあります。その後、データサイエンティストは、利用可能なデータのサブサンプルを取得し、これらの要件と、場合によっては既存の金融不正事例を参照して、深層学習または機械学習アルゴリズムのセットを選択します。そして、データエンジニアが、この検