2ヶ月前、Lokadにはリアルタイムデータの探索のための重要な新機能が導入されました。この機能はダッシュボードスライシングというコードネームで、Envisionの低レベルデータ処理バックエンドの完全な改装が必要でした。ダッシュボードスライスでは、各ダッシュボードがリアルタイムで検索バーで探索できるダッシュボードビューの辞書全体になります。

たとえば、_製品検査員_として意図されたダッシュボードをスライスすることで、製品に関するすべての情報(例えば確率的な需要やリードタイムの予測など)を1つの場所に集めることができます。そして、リアルタイムで次の製品に切り替えることができます。

スライスを使用したEnvisionダッシュボード

現在、Lokadは1つのダッシュボードに対して最大200,000のスライス(ダッシュボードビュー)を生成することができます。これらのスライスは、リアルタイムの検索機能を備えたセレクタを介してリアルタイムで表示することができます。これにより、データの探索が容易になります。ビジネスインテリジェンス(BI)ツールとは異なり、これらのスライスには非常に複雑な計算が含まれることがあります。単にスライスアンドダイスではなく、OLAPキューブ上の計算も可能です。

Envisionダッシュボードのスライス用の検索ボックス

データの処理とレポート作成には、通常2つのキャンプがあります。オンライン処理とバッチ処理です。オンライン処理はデータのフィードを受け取り、システムに表示されるすべてのものが常に最新であることが期待されます。システムは現実よりも数分、場合によっては数秒遅れていることはありません。OLAPキューブや多くの「ビジネスインテリジェンス」と呼ばれるツールは、このカテゴリに属しています。リアルタイム1の分析は非常に望ましいですが、ビジネスの観点だけでなく(新鮮なデータは停滞したデータよりも優れています)、エンドユーザーの観点からも重要です(パフォーマンスは機能です)。しかし、リアルタイムでスマートな分析2を提供するのは非常に困難です。そのため、オンライン分析システムは、システムが実行できる分析の種類に厳しい制限があります。

一方、バッチ処理は通常スケジュールされた頻度(例:毎日の実行)で実行され、すべての過去のデータ(またはその一部)が入力されます。結果の新鮮さはスケジュールの頻度によって制限されます。毎日のバッチは常に昨日の状況を反映する結果を提供します。データがすべて利用可能であるため、バッチ処理はオンライン処理を考慮すると到達できないさまざまな計算の最適化を実行するために理想的です。また、ITの観点からも、バッチ処理は実装と運用の両方がはるかに容易です3。バッチ処理の主なデメリットは、バッチ処理の性質によって課せられる遅延です。

ソフトウェアプラットフォームとして、Lokadは明らかに「バッチ処理」のキャンプに属しています。実際、量的サプライチェーンの最適化には高い反応性が必要ですが、追加のパレットを生産するかどうかを決定する、在庫を処分するために価格を下げる時期かどうかを決定するなど、即時の反応性を必要としない多くの意思決定があります。これらの意思決定では、最善の意思決定を行うことが最も重要であり、この意思決定が1つの追加のコンピュータ時間によって計測可能に改善される場合、この1つの追加のコンピュータ時間はほぼ確実に良い投資になります4

したがって、Envisionはバッチ処理の観点に基づいて設計されています。私たちはいくつかのトリックを使って、テラバイトのデータを扱う場合でもEnvisionを非常に高速にすることができますが、このスケールでは結果を数分以内に得ることができますが、1秒未満ではありません。実際、Envisionの計算モデルは非常に分散しているため、Lokadが_任意の_Envisionスクリプトの実行を5秒未満で完了することは困難です。データが関与している場合でも、数メガバイトしかない場合でもです。システムがより_分散_されているほど、すべての部分を同期するための内部の慣性が増えます。スケーラビリティが高いほど、レイテンシが低下します4

数年前、私たちはEnvisionでエントリーフォームの概念を導入しました。これは、ダッシュボードに設定可能なフォームを追加し、それをEnvisionスクリプトからアクセスできる入力にする機能です。例えば、この機能を通じて、指定された製品に関連するすべての関連情報を表示する「製品インスペクター」として意図されたダッシュボードを簡単に設計することができました。ただし、ダッシュボードを新しく入力されたフォームの値に合わせるためには、Envisionスクリプトを再実行する必要があり、リフレッシュされた結果を取得するまで数秒の遅延が発生しました。これはデータの探索には受け入れがたい長さでした。

ダッシュボードスライス(技術ドキュメントをご覧ください)は、オンライン処理とバッチ処理の両方の利点を得るための私たちの試みです。トリックは、Lokadがバッチで非常に多くのスライス(各スライスは製品、場所、シナリオ、またはそれらの組み合わせを反映することができます)を計算し、リアルタイムで別のスライスに切り替えることができるようにすることです。これは、すべてが事前計算されているため可能です。自然に、大量のスライスを事前計算する方が計算上はより高価ですが、思っているほど高価ではありません。通常、Lokadは一度に10,000のスライスを計算する方が、各スライスに専用の実行を行う100の独立した実行よりも安価です。

スライスを通じて、Lokadはステロイドを使用したビジネスインテリジェンスの能力を獲得しています:リアルタイムで多くの異なるビュー(例:製品、場所、時間帯)を探索することができるだけでなく、オンライン処理アーキテクチャの通常の制約はありません。


  1. 分散システムでは、「リアルタイム」というものは存在しません。光速自体が、複数の大陸にまたがるシステムの同期度に厳しい制約を課しています。したがって、この用語はやや乱用されています。ただし、全体のレイテンシが1秒未満であれば、データクランチングアプリを「リアルタイム」として分類することが一般的に受け入れられます。 ↩︎

  2. 自動運転に使用されるような高度なリアルタイムデータ処理システムでも、リアルタイムで動作する場合には学習操作を避けるように注意しています。すべての機械学習モデルは事前計算されて静的です。 ↩︎

  3. バッチプロセスの典型的な実装は、フラットファイルを移動することで構成されており、現在ではほぼすべてのシステムでサポートされている基本的な機能です。その後、運用の観点からは、バッチプロセスの1つのコンポーネントが一時的なダウンタイムを経験した場合、単純な再試行ポリシーで問題を解決することができます。対照的に、オンラインシステムは1つのコンポーネントがダウンした場合にはうまく動作しない傾向があります。 ↩︎

  4. 現在の時点では、主要なクラウドコンピューティングプラットフォームを使用して、モダンなCPU上での1時間の計算コストは通常$0.02未満です。したがって、1つのより良いサプライチェーンの意思決定によって生成される利益が$0.02以上の価値がある限り、この1時間の計算に投資することは合理的です。 ↩︎ ↩︎