Wendelinプロジェクトは風力タービンの数が増えて、そして処理するアルゴリズムの数が増えてきたときにZabbixやNagiosのような標準的な監視ツールが風力タービンのデータをリアルタイムで収集して処理するのに十分ではないと気がついたあとにWoelfelではじまりました。 Nexedi GmbH (ドイツ), Nexedi SA (フランス), Micromega Dynamics(ベルギー)とWoelfelグループ (ドイツ)とMariaDB (フィンランド) が共同プロジェクトを作り、約3ヶ月で最初の風力発電所の構造健康監視システムの最初の版を完成させました。

このシステムでは、Micromega DynamicsとWoelfelグループが共同で開発したスマート振動センサーがそれぞれの風力タービンに取り付けられます。このスマートセンサーはGNU/Linux OSを内蔵していてトレジャーデータ社の日本人開発者たちが作ったflutnedを動かしています。スマート振動センサーの役割はアナログの振動信号をデジタルデータに変換します。そしてそれをインターネットを経由してデータセンターに送り、そこでさらなるデータ処理が行われます。データ処理の結果はHTML5のUIで表示されてユーザーが地図上にあるそれぞれの風力タービンの健康状態と氷の付着状態を見ることができます。

スマートセンサーとデータセンターのネットワーク接続は普通のIPv4、または、よりよい、復元力のあるIPv6を基にしたNexediのre6st技術で実現できます。re6stは世界のどこで使ってもインターネットの渋滞を迂回できる技術で、中国でも使えて、中国では公式に使用を認められています。

データセンターの運用、そしてセンサーの引当とセンサー群を良いように編成すること、それらはNexediのSlapOSという技術で完全に自動化できます。NexediはSlapOSを2009年に発明しました。SlapOSはオープンソースで、性能が良く、低コストで、少ない計算資源でも動く、エッジコンピューティングソリューションです。これは大きなデータセンターや接続された色々な物を横断してデータ処理ワークフローの編成を劇的に簡単にします。SlapOSはTeralabというフランスの大企業の半数が使っているヨーロッパで最も成功したビッグデータ処理のセンターの中核技術です。

Wendelinはデータ保管、並列データ処理、アウトオブコア処理の全てを行います。Wendelinは様々なPythonプログラミング言語用機械学習ライブラリに頼っています。Wendelinはデータのメタデータ管理ができるので、データごとにいつのどの風力タービンのどのセンサーが使われて収集したものか分かります。さらに、Wendelinはそれぞれのユーザーとデータサイエンティストのアクセスルールを定義できます。それで、それぞれのユーザーは許可された特定のデータと処理アルゴリズムだけを使えるということができます。

WendelinのHTML5UIはオンラインでもオフラインでも動きます。オフラインモードはデータを見るときに早くアプリが応答してほしいときに便利です。オンラインモードはいつでも最新のデータをみたいときに便利です。

初期のWendelinシステムは数個の風力タービンにだけ使われていましたが、いまは8カ国の260個以上の風力タービンを監視するのに使われています。

Woelfel社でのWendelinの最初の成功で、システムは振動監視の新しい応用がはじまりました。Wendelinは今では建設現場の騒音や金融データセンターの振動を監視しています。Jypyterノートブックを基にした自動レポート作成ツールが機能に加わりました。このツールのおかげで顧客に提出する複雑なデータ分析レポートを作成する時間が半分になりました。

次のステップとしてオンデマンドのデータ分析を提供するためにオンライン販売システムも追加します。このサービスではWendelinはセンサーの登録からはじまってデータを分析してレポートを作成して請求書を発行するところまでのビジネス工程全体に統合します。これが可能なのはWendelinがNexediのオープンソースERPであるERP5と同一の基盤を使っているからです。ERP5はキョーリンやサンケイ化学、三菱グループの中などで使われています。

Woelfel社のWendelinプロジェクトで私たちが最初に学んだことはデータバッファリングの大切さです。これはまだ接続する何かを開発する人たちにあまり良く知られていません。

接続する何かの設計をするエンジニアの大半はセンサーから送られてくるデータが少し失なわれてもたいして問題ないと考えがちです。彼らはMQTTのような標準的なプロトコルを頼ります。しかしそういうプロトコルはセンサーからビッグデータセンターに送られたデータが全て届くことを保証しません。よく信じられている、少しデータが欠落しても構わないということ、これが結果的に、異常の発生と関連があるとても重要なデータを取得できないということに繋がります。これはマーフィーの法則と直接因果関係があります：システムやネットワークの異常事態は同時に起きる傾向がある。さらに、データを失なっているということは、つまりデータセンターで収集している信号はもう完全ではないということです。そうなるとデータ処理はもっと複雑になります。なぜならデータサイエンティストは接続が切れていたことによる異常状態を除いて、データの中で意味のある異常状態だけを見つけないといけないからです。

バッファリングの大切さはデータサイエンティストたちがセンサーを再起動したあとに少しデータが欠けたことに文句を言ったことで分かりました。、結局、データが欠けることは許されないのです。

99.999%かそれに以上データ転送が正しく行える簡単な方法はバッファリングです。この図で説明します。

左のシステムはバッファリングを使っていません。

右のシステムはデータを永続的なキューとしてローカルのファイルに書く方法のバッファリングを使っています。このキューはビッグデータセンターがデータを受信したことを確認したときだけ空になります。

この図は3つの状態を表しています。ネットワークに接続している状態。ネットワークが切断している状態。ネットワークが再接続している状態。

左側で受信した信号が不完全で右側で信号が完全なのが分かります。

左側で不完全な部分の信号は平均的な値で埋められます。これはセンサーから届く異常な信号を検知する妨げになります。右側では正しく表示されています。

Wendelinの仕組みではバッファリングはトレジャーデータ社が作ったfluentdプロトコルで行います。fluentdの実装にはRubyとCがあります。Nexediは最近QUICプロトコルをfluentdに加える仕事をしています。QUICはTCPとHTTPとTLSのオーバーヘッドをほとんど取り除いてよりよいパフォーマンスと同等のプライバシーを確保するプロトコルです。

完璧にきれいなデータであるために、バッファリングだけでなくビッグデータセンター側でトランザクション管理も必要です。トランザクション管理で一度データセンター側で受けとったデータは完全に保存されてセンサーバッファからは削除していいことを保証します。トランザクション管理はWendelinとリレーショナルデータベースの標準機能です。しかし大抵のデータベース技術やFTPやSFTPのようなファイル転送プロトコルにはその機能はありません。

二つ目にWoelfel社のWendelinプロジェクトで学んだことはPython言語とそのデータサイエンス用ライブラリ群の価値です。

1995年にNumPyライブラリが作られて、22年が経ちます。NumPyはPythonの世界に高性能線形代数とFORTRAN言語で1979年以来開発されているBLASとLAPACKのような科学計算ライブラリをもたらします。明らかに古代のライブラリに頼ることでPythonとNumPyはFORTRANコードの最適化の40年をてこにでき、OpenMPライブラリを通して並列計算のあらゆる形を可能にします。今までBLASやLAPACKを越える線形代数と科学計算の実装はありません。

PythonはFORTRANのの太古世界を現代的な文法、オブジェクト指向、そしてスクリプトのおかげで対話的にします。そしてさらにPython言語の上位セットのCythonによって強力な型付けができ、CやC++に近い性能を簡単な例外処理と自動メモリ管理の利点と共に実現できます。

それなので、どうしてたくさんのデータサイエンティストがPythonに移行しているのかがとてもよく分かります。例えば、最も人気がある機械学習ライブラリがCythonを使っていて、たくさんの機械学習アルゴリズムを簡単な行列操作として実装しています。scikit-imageは画像処理用です。pyopencvはビデオ処理用です。scipyは汎用的な信号処理と科学計算ライブラリです。statmodelsは統計モデル用です。Pandasは例えば金融用アプリケーションなどで時系列と構造化データの管理を簡単にします。

さらに最近では、Pythonはディープラーニングの主要な道具になりました。PyTorch(Facebook)やKeras(Google)などがあります。

全てのライブラリにはJupyterのおかげでWebベースのノートブックを使って簡単に使えます。データサイエンティストのチームはデータと処理能力を一つのJupyterノートブックをCPUコアとメモリがたくさんある強力なサーバーにインストールすることで共有できます。そして、もしそれでも足りなかったら、JupyterはRや別のプログラミング言語(Julia、Scala)の統計ライブラリと組み合わせられます。

ですから、データサイエンティストがデータ分析にPython以外の言語を使う理由を想像するのは難しいです。

データサイエンスに加えて、PythonはIoTデバイスの高速開発用に使えます。micropythonフレームワークはESP32マイクロコントローラーでたった520kbのRAMで動きます。

レッスン2をきちんと聴いていた人は分かるとおり、私たちはデータサイエンスという言葉を使いました。しかし、完全に実用のビッグデータ処理IoTシステムにはサイエンス以上のものが必要です。エンジニアリングが必要です。

Woelfel社のWendelinプロジェクトで学んだ3つ目のことはデータサイエンスではなく、むしろデータエンジニアリングといえる事柄です。

データエンジニアリングはセンサーの数が数個から数百、数千になったときに発生します。センサーの数が増えると、途端にそれぞれのセンサーに関連するメタデータの管理が必要になります。メタデータは初期登情報、データ取得ユニット、センサーの交換についての事柄などがあります。これはセンサーの種類が増えるとさらに重要になってきます。センサーの種類は同目的の新型センサーが登場することで増えていきます。

データエンジニアリングは一つのビッグデータ処理IoTシステムが複数の独立したアプリケーションで使われるようになったり、顧客ごとにデータ参照権限を制限したり許可したりするようになるときに発生します。

データエンジニアリングは複数のデータサイエンティスト達が同じシステム上で働いて古いアルゴリズムから新しいアルゴリズムを作らないといけないときに必要です。古い機能を部分的に再利用して新しいものを作るのは簡単であるべきです。異なる種類のデータには異なるデータ処理ワークフローが明白な作法で、バッチかストリームで、使われるべきです。

以上のものに加えて、データエンジニアリングはデータサイエンティストたちが分析するデータよりももっと大きいデータを処理するシステムを作るという意味です。これにはアウトオブコアと呼ばれる技術が必要です。アウトオブコアはRAMよりも大きい巨大な行列をいつでも読み込んで処理できることを保証します。

Pythonの世界ではwendelin.coreだけが本当にアウトオブコア処理ができる技術です。Wendelinはデータエンジニアリングをするのに必要な全てのものを提供します。Wendelinはさらにあらゆる形のデータ分析サービスビジネスの販売やレポート作成の自動化もできます。