00:00:06 サプライチェーンにおけるデータ処理の課題とLokadのテラバイト・スケーラビリティ.
00:00:38 過去1年間におけるLokadの処理能力の向上.
00:01:33 Lokadのプラットフォームとスクリプト言語Envisionの解説.
00:03:55 EnvisionとPythonなどその他のプログラミング言語との比較.
00:06:27 Lokadの改善に導いた重要な洞察とブレークスルー.
00:08:00 データベースにおける表形式ストレージと列形式ストレージの比較と効率性.
00:10:36 大量のデータ処理に伴う課題とコスト.
00:12:04 テラバイト規模の処理がサプライチェーンサイエンティストと作業効率に与える影響.
00:14:10 高速な処理と大規模データセットの取り扱いがもたらす実世界での利点.
00:15:30 定量的なサプライチェーン施策におけるエッジケース排除の重要性と長時間プロセスのリスク.
00:17:43 実際の不測事態に対処するための反復的アプローチの重要性.
00:20:47 サプライチェーンの最適化における大規模データ処理の課題と影響.
00:21:10 テラバイトスケーラビリティがLokadの見通しとサプライチェーン最適化の将来に及ぼす影響.
00:24:41 締めくくりの考察とサプライチェーン最適化改善のための今後の可能性.
概要
Kieran Chandlerは、Lokadの創設者Joannes Vermorelに、サプライチェーン最適化および膨大なデータセットの取り扱いについてインタビューしています。Lokadは、2017年以降、そのドメイン固有言語であるEnvisionを活用して大規模データ処理を行い、処理能力を20倍に向上させました。Envisionは、一般的なプログラミング言語と比較してサプライチェーン環境における分散コンピューティングを簡略化します。Lokadの進歩により、データ処理時間は数時間から数分に短縮され、サプライチェーンサイエンティストがより効率的に作業できるようになりました。Vermorelは、サプライチェーン施策を成功させるためのアジリティと反復的最適化の重要性を強調します。Lokadのテラバイトスケーラビリティは、より包括的な最適化アプローチを可能にし、現実のサプライチェーン状況により適切に対処するため、Envisionスクリプトの表現力を強化する計画です.
詳細な概要
このインタビューでは、ホストのKieran Chandlerが、サプライチェーン最適化を専門とするソフトウェア会社Lokadの創設者Joannes Vermorelと対談し、サプライチェーン業界における膨大なデータの取り扱いの課題と、テラバイトスケーラビリティにおけるLokadの進展について語ります.
Joannesは、2018年がLokadにとってスケーラビリティの年であり、前年に比べて処理能力を20倍に増加させたと述べています。この改善により、現行の技術水準を考慮すると、Lokadはマルチテラバイトのデータセットを比較的容易に扱うことが可能となりました.
同社は、量的-供給-チェーン-マニフェスト最適化向けに設計されたSolocatプラットフォームを開発することでこれを実現しました。このプラットフォームは、Lokad独自のドメイン固有スクリプト言語であるEnvisionを活用しています。Envisionは、サプライチェーンの問題に特化したニーズに対応し、大規模なデータ処理を促進するよう設計されています.
2018年以前は、プラットフォームが数テラバイトのデータを保持できたにもかかわらず、単一のEnvisionスクリプトは1台のマシンでのみ実行可能でした。同社は、複数のマシンに機械学習計算を分散させることで、ある程度のスケーラビリティを実現していました。しかし、データのソートなどのタスクは依然として1台の大型マシンに限定されていました.
2018年に、LokadはEnvisionスクリプトのバックエンド実行ロジックの完全なアップグレードを実施しました。この新しいアーキテクチャにより、複数のCPUや全マシン群にわたる自動並列処理が可能となりました。その結果、データのソートなどのタスクは、数十台のマシンの処理能力を活用することで、はるかに速く実行できるようになりました.
Python、Java、C++、C#などの一般的なプログラミング言語とEnvisionを比較した際、Joannesは、Envisionがサプライチェーンの問題に特化したドメイン固有言語であると説明します。一般的なプログラミング言語はほぼ何でも実現可能ですが、分散コンピューティングを達成するためには、より複雑な設定や特定のライブラリ・フレームワークに関する深い理解が必要となることが多いです.
一方でEnvisionは、これらの技術的な複雑さを簡素化し、サプライチェーン最適化の文脈における分散コンピューティングや大規模データ処理を容易にします。この専門的なアプローチにより、Lokadはスケーラビリティを向上させ、一般的なプログラミング言語を使用するよりも効果的にテラバイト規模のデータを扱うことが可能となりました.
彼らは、同社のソフトウェアであるEnvision、その利点、そして最近の進歩がサプライチェーン分析をどのように改善したかについて議論します.
Envisionは、サプライチェーンの問題に特化して設計されたスクリプト言語であり、他の汎用プログラミング言語と比較して、より使いやすく効率的です。表現力の一部を犠牲にしてシンプルさを追求しているものの、特定の問題に焦点を当てているため、このトレードオフは妥当といえます。Vermorelは、Envisionの使いやすさを、高度な平均値、ソート、ルックアップ機能を駆使したエクセルシートの作成に例えています.
1年前、Lokadは既にビッグデータ解析向けのカラムナー（列指向）データ保存方式を実装しており、これはリアルタイム処理よりもバッチ解析に適しています。この方式は、データを行単位ではなく列単位で保存するため、特定の少数の列だけを扱う操作をより効率的に処理できます。しかし、新しい行を追加する際には全ての列を扱う必要があるため、リアルタイム処理にはあまり効率的ではありません.
大量のデータ処理に伴うコストについて議論する際、Vermorelは最も高価なリソースはサプライチェーンサイエンティスト（またはデータサイエンティスト）であると強調します。彼らは希少で、特定の知識が必要であり、広範な研修を受けなければならないからです。その結果、Lokadはデータ処理にかかる時間を短縮することで、これらのサイエンティストの時間の最適化を目指しています.
以前はテラバイト単位のデータ処理に数時間を要しましたが、最近の進歩によりその時間は数分に短縮されました。これにより、サプライチェーンサイエンティストは結果を待つのではなく、作業に集中し、次のステップへ迅速に進むことができます。しかし、その反面、休憩を取る機会も減少します.
より大規模なデータセットを迅速に処理できるという画期的な突破口は、現実世界において多くのメリットをもたらします。これにより、企業はサプライチェーンをより効率的かつ効果的に分析・最適化でき、最終的には全体の業務が向上します.
これらは、最適化の達成における課題、敏捷性の重要性、そして現実の不測事態に対処するために必要な反復的アプローチに取り組むものです.
Vermorelは、定量的なサプライチェーン施策を実施する際の最大の危険は、システムを完璧に仕上げるのに要する時間にあると指摘しています。手動介入を避けるためにあらゆる例外ケースに対処することが極めて重要なためです。時間がかかるほど、プロジェクトは disruptions に直面するリスクが高まり、例えば IT や ERP のアップグレード、あるいは劇的なビジネス変革によって、従来の作業が陳腐化する可能性があります.
成功するためには、サプライチェーン最適化の取り組みを迅速に本番環境へ移行する必要があり、それには敏捷性が求められます。Vermorelは、数ヶ月という短期間で多くのことを達成するのは大変に聞こえるかもしれませんが、時間をかけすぎるとプロジェクトの失敗リスクが増すと説明しています。彼は、予測不可能なサプライチェーンと現実の不測事態により numerical recipes が頓挫しかねないため、反復的な最適化アプローチが不可欠であると強調しています.
サプライチェーン管理に伴う途切れない驚きに対処するためには、反復的な最適化が不可欠です。Vermorelは、サプライチェーンは複数の市場、国、サプライヤー、製品ラインを含む複雑なものであり、あらかじめ全ての潜在的な技術的課題を洗い出すことは不可能であると説明します。したがって、numerical recipes の修正において敏捷性が極めて重要となります.
その後、KieranはLokadにおけるテラバイトスケーラビリティの影響と将来展望についてVermorelに質問します。Vermorelは、同社がスケーラビリティ処理において驚異的な改善を遂げたことで、サプライチェーン最適化の新たな機会が開かれたと述べています。彼は、スケーラビリティは単に大企業への対応だけでなく、ネットワークレベルでの最適化を達成することにもあると明らかにしています.
Vermorelは、本当の最適化を達成するためには、各店舗やサプライヤーを個別に最適化するのではなく、ネットワーク全体を一つのエンティティとして捉える必要があると強調します。テラバイトスケーラビリティにより、Lokadはより包括的に最適化に取り組むことが可能となり、その結果、問題がサプライチェーンの下流に転嫁されるのを防ぐのに役立ちます.
将来的には、Lokadはスケーラビリティ向上の成果を生かして表現力を強化し、複雑な現実の状況をEnvisionスクリプトにより流暢かつ直接的に反映できるようにする計画です。これにより、実際のサプライチェーンの状況に効果的に対処する数値レシピの開発が容易になります.
インタビューは、Vermorelが敏捷性、反復的最適化、そして包括的なサプライチェーン管理アプローチの重要性を強調することで締めくくられます.
完全な書き起こし
Kieran Chandler: 「本日のLokad TVでは、サプライチェーン内で管理されるデータの膨大な規模を理解し、Lokadがどのようにテラバイトスケーラビリティを発展させたかについて議論します。さて、Joannes、今日はLokadで過去1年間に行われた研究開発について少し話をしましょう。2018年には何に取り組んでいたのですか？」
Joannes Vermorel: 「2018年は私たちにとってスケーラビリティの年でした。スケーラビリティ向上に向け、ほぼ連日1年中取り組んできました。昨年1月の状態と比べると、処理能力が基本的に20倍に増加しており、そのおかげでマルチテラバイトのデータセットを比較的容易に処理できる範囲に達しています。現状の技術を考えると、簡単にテラバイトを処理できる方法というのは存在しませんが、それでも比較的シンプルに実現することは可能です。」
Kieran Chandler: 「20倍というのは信じられないほど大きな改善のようですね。この改善を達成するために、どのような手順を踏んだのですか？」
Joannes Vermorel: 「Lokadはサプライチェーン最適化のために設計されたプラットフォームです。技術的には、私たち独自の自家製スクリプト言語 Envision で記述されたスクリプトを通じて利用可能です。この言語は、サプライチェーン最適化のニーズに特化するとともに、大規模処理を容易にするために設計されています。昨年までは、1つのクライアントアカウントが数テラバイトのデータを保持していた一方で、1つのスクリプトやコードは単一のマシン上で実行されていました。すでにスケールアウトを実装していたため、機械学習など特定のコンポーネントに対して計算を複数のマシンへ分散させることが可能でした。しかし、単純にデータをソートする場合は、依然として1台の大きなマシンで行われていたのです。2018年には、Envisionスクリプトのバックエンド実行ロジックのアーキテクチャを完全にアップグレードしました。現在では、複数のプロセッサやCPUだけでなく、多数のマシン群に跨る自動並列処理が可能となっています。つまり、日付、製品、店舗、または価格によるデータの単純なソートなどの操作が、数十台のマシンを使って実行され、格段に高速化されるのです。」
Kieran Chandler: 「では、Envisionについて少し話しましょう。Pythonなどの他のプログラミング言語と比べて、Envisionはどのようにしてこれらの改善やスケーラビリティ向上に寄与しているのでしょうか？」
Joannes Vermorel: 「Envisionはドメイン固有のプログラミング言語であり、Python、Java、C++、C#といった汎用プログラミング言語とは異なります。汎用言語ではほぼ何でも可能ですが、その反面、さまざまな技術的な細部がプログラミング環境に持ち込まれます。例えば、Pythonで分散コンピューティングを行うことは可能ですが、特定のライブラリやフレームワークを活用して計算を多数のマシンに分散させるようにコードを書く必要があります。さらに、この分散ロジックを実行するためのマシンクラスターも自分で設定しなければなりません。異なるスクリプトやユーザーが同じクラスター上で同時にプログラムを実行すると、状況はより複雑になります。つまり、帯域、ディスク、CPUなどのリソースを共有するための全ての配管工事が必要となるのです。そして、これらすべてがEnvisionには完全に組み込まれているのです。結果として、表現力はかなり犠牲になりますが、それで問題はありません。なぜなら、Envisionは基本的にサプライチェーン問題という特定の課題に特化しているため、すべての問題の解決を試みるわけではなく、チェスエンジンや3Dモデリングエンジンを書くことを目的としていないからです。非常に特定の種類の問題に最適化されています。」
Kieran Chandler: 「つまり、Envisionは他のプログラミング言語と比べて、はるかにシンプルに使えるということですね？」
Joannes Vermorel: 「その通りです。例えば、過去3年間にわたって大規模ネットワーク全体でのstockoutsのコストと影響を推定するため、数十億行あるテーブルを処理する分析スクリプトを書くのは、文字通り十数行のコードで実現できます。しかも、そのコードは書きやすいのです。書きやすいと言っても決して簡単というわけではありませんが、高度なExcelシートで複雑な平均値計算、ソート、ルックアップを行うのと同じ程度の難易度です。」
Kieran Chandler: 「では、これらの改善に至った主要な洞察や画期的な発見とは何だったのでしょうか？」
Joannes Vermorel: 単に出発点を理解するために言うと、1年前、Lokad はすでに多くのビッグデータの要素を整えていました。その中の一つは、データ格納に対してカラムナーなアプローチを採用していることです。要するに、従来の SQL データベースはテーブル形式の保存方式を用いています。これは、テーブルが存在する場合、データの各行がひとまとまりとして格納されるということを意味し、その行自体が基本単位となるのです。結果として、テーブル形式のデータベースは、小規模な更新や行単位の読み書きにおいて非常に効率的です。
それに対し、過去何十年もの間、大規模な data analysis を行う際に開発されたのは、カラムナーアプローチです。つまり、例えば20カラムあるテーブルの場合、各カラムごとにデータがまとめて保存されるのです。では、これはどういう意味でしょう？ 例えば、「単価があり、数量がある」という操作を考えてみましょう。sales history を表すテーブルがあるとします。ここで総売上額を知りたい場合、価格と数量を掛け合わせ、その結果をテーブル全体で合計する必要があります。ところが、テーブルに20カラムあっても、この操作で実際に使用されるのは2カラムだけです。したがって、カラムナーなストレージの場合、わずかなカラムにしか作用しない操作はその部分だけが処理され、残りは無視されるのが大きな利点となります。一方、テーブル形式だと、他のカラムもすべて中間に存在し、スキップすることができません。
しかし、欠点として、もし追加の行を入れる場合やリアルタイムで作業する場合、カラムナーアプローチでは、新たな行を追加する際に全てのカラムを処理しなければならない点が挙げられます。
Kieran Chandler: つまり、一行追加する際には20カラムすべてに触れる必要があり、結果として効率が低下します。カラムナーなストレージはバッチ解析、すなわちリアルタイムではなく、サプライチェーンに求められる種類の解析により適しています。更新は毎分行われるものの、ミリ秒単位ではありません。では、処理能力や大量データの扱いに伴うコストについて少し話しましょう。テラバイト規模のスケーラビリティを実現することは、データ処理のコストにどのような影響を与えたのでしょうか？
Joannes Vermorel: 実際、非常に大きな影響があります。大規模なサプライチェーンを最適化しようとする際、最も高価なリソースはサプライチェーンの専門家たちです。彼らは安くはなく、適切な才能を持つ人材を見つけ、育成することは大きな挑戦です。希少なリソースは、お気に入りのクラウドコンピューティングプラットフォームで安価に構築できる CPU、ディスク、または帯域幅ではなく、問題に取り組むための才能ある人々なのです。
テラバイト規模の処理領域に入ると、全てが遅くなります。特に、乱数変数を用いた確率計算などの非自明な計算では、テラバイトのデータ処理にかなりの時間がかかります。以前は何時間もかかっていたものが、今では数分で済む場合もあります。サプライチェーンの専門家にとっては、結果を待つ間に専念でき、次の作業に迅速に移れるという点がメリットですが、その反面、コーヒーブレイクの時間が減るという悪い知らせでもあります。
Kieran Chandler: この突破口は実世界にどのような意味をもたらすのでしょうか？ 明らかに、私たちははるかに大きなデータセットをより迅速に扱えるようになりましたが、他にどんな利点が見えてくるのでしょうか？
Joannes Vermorel: はい、量的サプライチェーン施策が失敗する主要な危険性、あるいは根本原因の一つは、システムが正しく稼働し、完全に仕上がるまでにかかる時間、すなわち残るエッジケースがなくなるまでの期間です。より大きなデータセットを迅速に処理できるようになれば、こうした問題により効率的に対処でき、最終的にはより良いサプライチェーンの意思決定につながります。
Kieran Chandler: システム自体は優れているのに、全く手作業の部分が一つだけ残っている。これは、適切に処理されない全てのエッジケースを手作業で検証するために多大な人手を必要とします。結果、先進的な機械学習による自動化で最適化しようとする目的がある程度損なわれます。全エッジケースを排除し、本当に意思決定の数値レシピを研ぎ澄ますプロセスが、あまりにも長引いてしまう危険性があるのです。
Joannes Vermorel: その通りです。そして、その遅延は致命的です。なぜなら、ある時点で人々はその施策の成功に対する信頼を失ってしまうからです。もし処理が遅ければ、ITシステムが途中で混乱する可能性もあります。例えば、プロジェクトが2年間続く場合、その途中でERPのアップグレードが行われる確率は3分の1にも上ります。サプライチェーンの最適化を進めていても、会社全体の方針が大きく変われば、これまでの成果はすべて崩れてしまうのです。
待てば待つほど、プロジェクトに影響を及ぼす要因は増えます。事業自体が劇的に変化し、以前の成果が新たなビジネス環境の下で陳腐化してしまうのです。製品を迅速に生産に乗せるためのプレッシャーは多く存在し、数ヶ月以内に成功できなければ、その施策は失敗する可能性が高まります。ここに、アジリティが絶対に必要とされる理由があります。
数ヶ月というのは多いように思えるかもしれませんが、テラバイトのデータに手を加え、結果が出るのに数時間かかる場合、数値レシピの調整は最悪でも1日に1～2回程度に留まります。物事は非常に遅くなり始めるのです。
Kieran Chandler: つまり、サプライチェーンを最適化するためには反復的なアプローチが必要ということですね。なぜそのような反復的アプローチが必要なのでしょうか？ 単にボタンを一つ押し、deep learning を使って学習し、優れた予測と結果を得ることができないのでしょうか？
Joannes Vermorel: 現実は必ずしもあなたの思い通りにはいきません。サプライチェーンとは、実世界の不測の事態に対処することなのです。現実の本質から生じる数多くのエッジケースが存在します。例えば、理想的な発注数量として80単位を計算したとします。これが最適な数量であっても、パレットは梱包単位で運ばれるため、実際に存在するのは0単位か100単位のみ。80は選択肢にない、ではどうするのでしょうか？
このような状況は数多く存在します。あなたは在庫の価値が時間とともに徐々に減少すると考えるかもしれませんが、実際はそうではありません。なぜなら、特定の日付が設定されたshelf-lifeが存在するためです。賞味期限や保存期限に達すると、inventory valueはある値からゼロ、さらにはマイナスにまで低下することになるのです。
実際、サプライチェーンは非常に複雑です。もし多くの市場、複数の国、数多くのサプライヤー、そして場合によっては数十の製品ラインを運営する企業の話となれば、複雑さはさらに増します。単に一室に集まって、将来的に発生する全ての技術的課題をチームでブレインストーミングするだけで解決しようとするのは、甘い考えです。サプライチェーンチームと座って、「最適なサプライチェーン意思決定を生む数値レシピを狂わせる小さな要因をすべて洗い出そう」と言っても、問題は解決しません。現実は常に驚きをもたらし、例えばある国で奇妙な税金が課せられているといった予想外の事象に直面するのです。最初の反復的アプローチに関する質問に戻ると、絶え間ないサプライズに対処する唯一の方法は、予期せぬ事態に直面した際に、数値レシピを非常に柔軟に修正することにほかならないのです。
Kieran Chandler: さて、テラバイト規模のスケーラビリティに注目し、全体像をまとめてみましょう。これはLokadの今後の展望にどのような変化をもたらし、将来はどうなるのでしょうか？
Joannes Vermorel: 私たちはスケーラビリティ処理の面で飛躍的な改善を遂げました。この進展により、以前は手が届かなかった多くの変革が実現可能になりました。これは単に大手企業を相手にするということだけでなく、例えば大規模な小売ネットワークの場合にも様々な抜け道が存在するのです。もし、大規模な小売ネットワークの最適化のアプローチが各市場を個別に処理する方法であれば、例えば200の市場があるなら、市場ごとに1台、合計200台のマシンで十分にスケールするでしょう。しかし、その方法ではネットワーク全体での最適化が行われず、求めるサプライチェーンの改善は得られません。各店舗を個別に最適化し、ネットワーク全体で起こることを完全に無視してしまうからです。
Kieran Chandler: つまり、これらの200台のマシンは互いに通信しないということですか？
Joannes Vermorel: その通りです。独立した silos が存在すれば、処理のスケーリングは非常に容易です。しかし、課題はネットワーク全体をひとつのエンティティとして捉え、すべてが連結していると考え始めた場合に現れます。実際、在庫や資材をネットワーク内でほぼ自由に移動させることが可能になります。もちろん、利益が出なかったり意味をなさない方法も多々ありますが、可能性は存在します。そして、その微妙な方法の中には非常に良いアイデアで利益をもたらすものもあるのです。一度にすべてをモノリシックに処理できるシステムが必要です。将来にとってこれは何を意味するのでしょう？ それは、より優れた全体的（ホリスティック）な最適化への多くの道が開かれることを意味します。サプライチェーンの最適化の呪いは、問題を解決するのではなく、単に問題を移動させてしまう点にあります。一部を見て最適化しても、実際には問題を後方やサプライヤに転嫁しているに過ぎないのです。もう一つの可能性として、スケーラビリティが大幅に向上した今、表現力を取り戻す試みが行われるでしょう。基本的には、実世界で起こる複雑な状況を、Envision スクリプト上でより直接的かつ流暢に表現することを目指しています。こうすることで、実世界の状況に適した数値レシピをより容易に提供できるようになるのです。
Kieran Chandler: 素晴らしいですね。ここで締めくくらなければなりませんが、本日はお時間を割いていただきありがとうございました。今週はこれで全てです。ご覧いただき、本当にありがとうございました。それでは、次回またお会いしましょう。さようなら。
