医療機器メーカー様向けに、精度管理システムを再構築・機能拡張・保守運用まで一貫してご支援しました。
従来は Java + RDB による構成でしたが、大量データ処理の限界に直面していました。そこで弊社は、HPE Ezmeral Data Fabric – Customer Managed (MapR) を活用した新アーキテクチャを導入。大幅なパフォーマンス改善を実現させました。

特徴・導入効果

• 大規模データ処理基盤の導入
  • MapRとSparkを活用し、精度管理データの集計を高速化。
• リアルタイム処理
  • MapR DB + ojai によるリアルタイム計測を実装。
  • フロント画面には Highcharts を採用し、計測結果のグラフ表示を実現。
• 継続的な進化
  • サーバーサイドからクライアントサイドまで、機能追加・保守運用を継続。
  • 高度なデータ処理からUI/UX改善まで、ワンストップで支援。

技術要素

サーバーサイド

• HPE Ezmeral Data Fabric (MapR) / MySQL
• Java / Spring / Scala / Spark / Kafka / Drill / Elastic Search / R Script

クライアントサイド

• Angular / Angular Material / TypeScript / RxJS / Node.js / Highcharts

成果

本プロジェクトにより、医療機器の精度管理に関わる 大量データを効率的に処理 できるようになりました。
その結果、

• 計測・集計のスピード向上
• データの信頼性確保
• 分析・改善サイクルの短縮化

を実現し、医療現場における品質向上・業務効率化に大きく貢献しました。

Altus-Fiveの強み

• 効率的なフロントエンド開発
  • フロント画面再構築では Angular Material をベースとしたデザインテンプレートを活用し、工数削減と品質担保を両立。
• バックエンド～フロントエンドまで一気通貫対応
  • データ基盤、リアルタイム処理、フロントの可視化までワンストップで提供。
• パフォーマンスと信頼性の両立
  • 医療機器分野において求められる「高精度 × 高速性 × 安定稼働」を実現。

本案件のように 大規模データ処理・可視化システム の開発・運用に強みを持っています。
「パフォーマンス改善したい」「大規模データを効率的に扱いたい」といった課題をお持ちの企業様は、ぜひご相談ください。

The post 03 医療機器メーカー様向け 精度管理システム first appeared on 株式会社Altus-Five.

共有変数

Spark には、データの共有とか、集約するための仕組みが備わっています。
それが、ブロードキャスト（Broadcast）と集約器（Accumulator） です。
http://mogile.web.fc2.com/spark/spark220/rdd-programming-guide.html#shared-variables

ブロードキャスト
参照専用の共有メモリのようなもので、ドライバーで共有したい変数をブロードキャスト変数として登録すると、その変数のラッパーオブジェクトが作成されて、ラッパーオブジェクトが、各エグゼキューターに配信されます。
エグゼキューターからは、ラッパーを通じて、共有変数の実態にアクセスすることができます。 このあたりは、通信のコストを下げるために効果的なブロードキャストアルゴリズムで実装されていると、マニュアルに記載されています。

集約器（Accumulator）
accumulatorは、ドライバーで初期化されて、エグゼキューターからは、加算処理だけが可能で読み取りは出来きません。 読み取りはドライバーからのみ行うことができます。
何かの件数をカウントしたり合計値を求めるような処理に使われます。

クロージャ

PySpark では、ドライバがRDDのメソッドをクロージャとしてシリアライズして、エグゼキューターに配信して、エグゼキューターでデシリアライズされて、処理が実行されます。

Python は “全てがオブジェクト” ということで、関数もオブジェクトなので、関数自体が様々な属性を持っています。
例えば、func()という関数は、func.__code__でコード自体を参照可能だし、func.__globals__で関数内で参照している global な変数がリストされます。他にも、func.__defaults__、func.__dict__などもあります。 https://docs.python.org/ja/3/reference/datamodel.html

クロージャとは、関数と関数内で使用される変数などがセットになったものを指します。 ときどき、クロージャとlambda関数が同じものとして説明されている記事を見ることがありますが、違うものです。lambda関数は、無名関数がクロージャを構成するときの要素の1つというのが、正しいです。

繰り返しになりますが、PySparkは、クロージャをシリアライズして、各エグゼキューターに配信します。

Python のシリアライズモジュールには pickle, marshal, dill, cloudpickle などがあります。（※この記事もあわせて読んでください。https://qiita.com/kojisuganuma/items/e9b29e8e5ef5f5f289b2）
PySpark のシリアライズモジュールは、Python標準の pickle を元にした、独自のものでした。 実際のソースコードは、こちらです。 https://github.com/apache/spark/blob/d48935400ca47275f677b527c636976af09332c8/python/pyspark/cloudpickle.py#L222
A func comprises: code, globals, defaults, closure, and dict.とコメントがあるとおり、 PySparkがエグゼキューターに配信するクロージャは、以下を要素としています。

• コード
• 関数内で使っているグローバル変数
• 引数のデフォルト値
• 引数以外の変数に対してのセル (cell) 群
• 関数属性の名前空間

シリアライズされる変数（グローバル変数など）が持つ値は、”宣言時のスコープ”によって設定された値です。 間違いやすいのは、global変数が宣言されていて、その変数の設定を init() などで、別の関数で初期化してたりすると、たとえ、それが RDD を実行する前だとしても、配信先では、復元されないということです。あくまで、変数宣言時のスコープで行われる処理だけがシリアライズされます。

参考記事

https://qiita.com/Hiroki11x/items/4f5129094da4c91955bc#%E2%85%B3-rdd%E3%81%AE%E6%93%8D%E4%BD%9C
https://www.lifewithpython.com/2014/09/python-use-closures.html

stackoverflow にも興味深い記事がありました。
「PySparkがブロードキャストされなかった変数を参照できるのはなぜですか？」
https://stackoverflow.com/questions/33337446/why-is-pyspark-picking-up-a-variable-that-was-not-broadcast
以下、回答の訳です。

基本的には、クロージャはシリアライズされて各executorとtaskに送られ、 task実行中にアクセスできるようになるので、 RDDのスコープ外のすべての変数をブロードキャストする必要はありません。
ブロードキャスト変数は、ブロードキャストされるデータセットが大きい場合に便利です。

まとめ

ブロードキャストとクロージャの使い分け

グローバル変数の初期値としてセットして、それを RDD や UDF の関数内から、参照するように実装しておけば、クロージャとして、データも一緒にエグゼキューターに配信されるので、小さいデータは、クロージャとして実装して、大きいデータはブロードキャストの機能を使うという使い分けができます。

分散実行されるコードの境界

Javaと違って、Pythonのコードだと、分散先で実行されるコードの境界がわかりづらいのだけど、その答えは、クロージャが実行されるということでした。

ご参考までに。

The post PySparkの分散される処理単位であるクロージャと共有変数の仕組み first appeared on 株式会社Altus-Five.