00:00:06 サプライチェーンのデータ処理の課題とLokadのテラバイトスケーラビリティ。
00:00:38 過去1年間のLokadの処理能力の改善。
00:01:33 Lokadのプラットフォームとスクリプト言語Envisionの説明。
00:03:55 Pythonなどの他のプログラミング言語とEnvisionの比較。
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は、大規模データ処理のためのドメイン固有の言語であるEnvisionを利用して、2017年以来20倍の処理能力を向上させています。Envisionは、一般的なプログラミング言語と比較して、サプライチェーンの文脈で分散コンピューティングを簡素化します。Lokadの進歩により、データ処理時間が数時間から数分に短縮され、サプライチェーンの科学者がより効率的に作業できるようになりました。Vermorelは、成功するサプライチェーンイニシアチブにおいて、アジリティと反復的な最適化の重要性を強調しています。Lokadのテラバイトスケーラビリティは、最適化により包括的なアプローチを可能にし、Envisionスクリプトの表現力を向上させ、現実世界のサプライチェーンの状況により適したものにする計画です。
詳細な概要
このインタビューでは、ホストのKieran Chandlerが、サプライチェーン最適化に特化したソフトウェア企業であるLokadの創設者であるJoannes Vermorelと話し合います。彼らは、サプライチェーン業界における大量のデータの取り扱いの課題とLokadのテラバイトスケーラビリティの開発について話します。
Joannesは、2018年はLokadにとってスケーラビリティの年であり、同社は前年比で処理能力を20倍に向上させました。この改善により、現在の技術の状況を考慮して、Lokadはマルチテラバイトのデータセットを比較的容易に処理できるようになりました。
会社は、量的サプライチェーン最適化のために設計されたSolocatプラットフォームを開発しました。このプラットフォームは、Lokadのドメイン固有のスクリプト言語であるEnvisionを利用しています。Envisionは、サプライチェーンの問題の特定のニーズを解決し、大規模データ処理を容易にするように設計されています。
2018年以前、単一のEnvisionスクリプトは単一のマシンでのみ実行されることができましたが、プラットフォームは複数のテラバイトのデータを保持することができました。会社は、機械学習の計算を複数のマシンに分散することで、ある程度のスケーラビリティを実現していました。しかし、データのソートなどのタスクはまだ1つの大きなマシンに制限されていました。
2018年、LokadはEnvisionスクリプトのバックエンド実行ロジックの完全なアップグレードアーキテクチャを導入しました。新しいアーキテクチャにより、複数のCPUや複数のマシン全体での自動並列化が可能になりました。その結果、データのソートなどのタスクは、数十台のマシンの処理能力を利用することで、より高速に実行することができるようになりました。
Python、Java、C++、C#などの汎用プログラミング言語と比較して、Envisionはサプライチェーンの問題を扱うために特化したドメイン固有の言語であるとJoannesは説明しています。汎用プログラミング言語はほとんど何でもできる能力を提供しますが、分散コンピューティングを実現するためにより複雑な設定と特定のライブラリやフレームワークの深い理解が必要となることがしばしばあります。
一方、Envisionはこれらの技術的な問題を簡素化し、サプライチェーン最適化の文脈で大規模データの処理と分散コンピューティングを容易にすることができます。この特化したアプローチにより、Lokadは汎用プログラミング言語を使用するよりも効果的にスケーラビリティを向上させ、テラバイトのデータを処理することができます。
彼らは会社のソフトウェアであるEnvisionの利点や最近の進歩、サプライチェーン分析の改善について話し合っています。
Envisionは、サプライチェーンの問題に特化したスクリプト言語であり、他の汎用プログラミング言語よりも使用が容易で効率的です。それはいくつかの表現力を犠牲にしていますが、特定のタイプの問題に焦点を当てているため、このトレードオフは受け入れられます。Vermorelは、高度なExcelシートの作成と比較して、Envisionの使用の容易さを説明しています。
1年前、Lokadはビッグデータ分析のための列指向データストレージの実装をすでに行っており、これはリアルタイム処理よりもバッチ分析に適しています。このアプローチではデータを列ごとに保存するため、一部の列にしか影響を及ぼさない操作の処理がより効率的に行えます。ただし、新しい行を追加するにはすべての列で作業する必要があり、リアルタイム処理には効率が低下します。
大量のデータを処理する際のコストについて話し合う際、Vermorelはサプライチェーンサイエンティスト（またはデータサイエンティスト）が最も高価なリソースであると強調し、彼らは希少で特定の知識と広範なトレーニングが必要であると述べています。そのため、Lokadはデータ処理にかかる時間を短縮することで、これらのサイエンティストの時間を最適化しようとしています。
以前は、テラバイトのデータを処理するのに数時間かかっていましたが、最近の進歩によりその時間が数分に短縮されました。これにより、サプライチェーンサイエンティストはタスクに集中し、結果を待つのではなく次のステップにすばやく進むことができます。ただし、それは休憩の機会が少なくなることも意味します。
より大きなデータセットをより速く処理することの突破口には、いくつかの現実世界の利点があります。これにより、企業はサプライチェーンをより効率的かつ効果的に分析し最適化することができ、結果として全体的な業務を改善することができます。
彼らは最適化の課題、アジリティの重要性、および現実世界の偶発的な事態を処理するために必要な反復的なアプローチについて取り上げています。
Vermorelは、数量的なサプライチェーンイニシアチブの実装における主な危険は、システムを完成させるまでにかかる時間であり、すべてのエッジケースを処理して手動の介入を回避することが重要であると指摘しています。かかる時間が長くなるほど、プロジェクトはITやERPのアップグレード、またはビジネスの大幅な変革などのdisruptionsに直面する可能性が高くなり、これにより以前の作業が無効になる可能性があります。
サプライチェーン最適化のイニシアチブを成功させるためには、迅速に本番環境に導入する必要がありますが、これにはアジリティが必要です。Vermorelは、数か月でこれを達成することは多くのように聞こえるかもしれませんが、時間がかかりすぎるとプロジェクトの失敗のリスクが高まると説明しています。彼は最適化のための反復的なアプローチを強調し、これはサプライチェーンや現実世界の偶発的な事態の予測不可能性による必要性です。
反復的な最適化は、サプライチェーン管理に伴う無数の驚きに対処するために不可欠です。Vermorelは、サプライチェーンは複雑であり、複数の市場、国、サプライヤー、製品ラインが関与しているため、事前にすべての潜在的な技術的な課題を考え出しリストアップすることは不可能であり、数値レシピの修正時にアジリティが重要であると説明しています。
次に、KieranはLokadとその将来の展望におけるテラバイトのスケーラビリティの影響についてVermorelに質問します。Vermorelは、同社がスケーラビリティの処理において大幅な改善を遂げており、サプライチェーン最適化の新たな可能性を開いていると述べています。彼は、スケーラビリティは単に大企業との取引に関連するものだけでなく、ネットワークレベルの最適化を達成することも重要であると明確に述べています。
Vermorelは、真の最適化には、各店舗やサプライヤーを個別に最適化するのではなく、ネットワーク全体を1つのエンティティとして考える必要があると強調しています。テラバイトのスケーラビリティにより、Lokadは最適化をより包括的にアプローチすることができ、それにより問題がサプライチェーン全体に広がるのを防ぐことができます。
将来、Lokadはスケーラビリティの利点を活かして、Envisionスクリプトで複雑な現実世界の状況をより流暢かつ直接的に反映する方法を改善する予定です。これにより、現実世界のサプライチェーンの状況に効果的に対処する数値レシピを開発しやすくなります。
インタビューは、Vermorelがアジリティ、反復的最適化、およびサプライチェーン管理における包括的なアプローチの重要性を強調することで締めくくられます。
フルトランスクリプト
Kieran Chandler: 今日はLokad TVで、サプライチェーン内で管理されるデータの膨大な規模を理解し、それに対処するためにLokadがテラバイトのスケーラビリティを開発した方法について話し合います。では、ジョアネスさん、今年の2018年にLokadで取り組んできたことについて少し話しましょう。2018年にはどのような作業を行ってきましたか？
Joannes Vermorel: 2018年は私たちにとってスケーラビリティの年でした。私たちはほぼ連続して1年間、スケーラビリティの向上に取り組んできました。昨年の1月と同じ日付と比較して、私たちは処理能力を20倍に増やしました。これにより、マルチテラバイトのデータセットを比較的容易に処理できるようになりました。現在の技術状況を考えると、テラバイトの処理は簡単なものではありませんが、比較的簡単に行うことができます。
Kieran Chandler: 20倍の改善は非常に大きな進歩ですね。この改善を実現するためにどのような手順を踏んだのですか？
Joannes Vermorel: Lokadはサプライチェーン最適化のためのプラットフォームです。技術的には、私たち独自のスクリプト言語であるEnvisionでアクセスできます。この言語は、サプライチェーン最適化のニーズに特化しているだけでなく、大規模な処理を容易にするために設計されています。昨年までは、クライアントの1つのアカウントには数テラバイトのデータが含まれていることがありましたが、単一のスクリプトやコードは単一のマシンで実行されていました。私たちはすでにスケールアウトを実装しており、機械学習などの特定のコンポーネントについては計算を複数のマシンに分散できるという考え方がありました。しかし、大まかに言えば、データをソートするだけの場合、それは1つの大きなマシンで行われていました。2018年には、Envisionスクリプトのバックエンド実行ロジックの完全にアップグレードされたアーキテクチャを導入しました。現在では、複数のプロセッサやCPUだけでなく、複数のマシンに自動的に並列化されます。つまり、日付、製品、店舗、価格などのデータをソートする単一のスクリプトは、数十台のマシンで実行されるため、はるかに高速になります。
Kieran Chandler: Envisionについて少し話しましょう。Envisionは他のプログラミング言語（Pythonなど）と比較して、これらの改善とスケーラビリティの向上にどのように役立っていますか？
Joannes Vermorel: Envisionはドメイン固有のプログラミング言語であり、Python、Java、C++、C#などの汎用プログラミング言語とは異なります。汎用プログラミング言語では、ほとんど何でもできますが、その代償として、プログラミング環境に技術的なクラスが表面化することがあります。たとえば、Pythonで分散コンピューティングを行うことは可能ですが、特定のライブラリやフレームワークを活用してコードを書く必要があります。また、分散ロジックを実行するためにクラスターを自分で構成する必要があります。同じクラスター上で複数の同時プログラムが実行される場合、異なるスクリプトやユーザーがあるため、より複雑になります。異なるニーズ… まあ、リソースを共有するためにすべての配管を備えている必要があります。帯域幅、ディスク、CPUなどです。そして、それがEnvisionが完全に組み込まれている方法です。失うものは、多くの表現力を失うことですが、それは大丈夫です。Envisionは壊れていません。なぜなら、私たちは特定のタイプの問題、つまりサプライチェーンの問題に特化しているからです。私たちはすべての問題を解決しようとはしません。チェスをプレイするためのエンジンを作ったり、3Dモデリングを行うためのエンジンを作ったりすることはしません。それは非常に特定の問題に向けられています。
Kieran Chandler: つまり、Envisionを使用する方が他のプログラミング言語よりもはるかにシンプルですね。
Joannes Vermorel: まさにその通りです。つまり、数十億行を含むテーブルを処理し、過去3年間の大規模なネットワーク全体での在庫切れのコストと影響を推定するなど、サプライチェーンのコンテキストで期待されるような分析を行うスクリプトを、わずか12行のコードで実行できます。ただし、書きやすいコードです。書きやすいと言っても、コードを書くのはそんなに簡単ではありませんが、高度なExcelシートを作成することと同じくらい難しくはありません。そのExcelシートでは、データに対して高度な平均値、ソート、ルックアップを行います。
Kieran Chandler: なるほど、それではこれらの改善につながった主な洞察や突破口は何でしたか？
Joannes Vermorel: まず、どのような状況から始まったのかを理解するために、1年前にはLokadにはすでに多くのビッグデータの要素がありました。そのうちの1つは、データストレージにコラム指向のアプローチを採用していることです。要するに、従来のSQLデータベースはタブロー形式のストレージを採用しています。つまり、テーブルがある場合、データの行を格納し、行が一緒になっているのが単位です。そのため、タブローデータベースは、小さな更新や行単位の読み書きを効率的に行うことができます。
対照的に、過去数十年にわたってビッグデータ分析を行う際に開発されたのは、コラム指向のアプローチです。つまり、テーブルがある場合、例えば20の列を持つテーブルがあるとします。データは列ごとにパックされて格納されます。では、どういうことでしょうか？たとえば、「単価と数量がある。売上履歴を表すテーブルがあるとします。売上の総額を知りたいので、何をする必要がありますか？価格に数量を掛けて、テーブル全体でその合計を行う必要があります。」という操作を行う場合、私たちが触れるのはたった2つの列だけですが、テーブルには20の列があるかもしれません。したがって、コラム指向のストレージを使用すると、数列に触れるすべての操作は処理され、残りの列は無視されます。タブローフォーマットの場合、他の列は完全に中間にあり、スキップすることはできません。
ただし、欠点としては、追加の行を追加する場合、リアルタイムで作業する場合、コラム指向のアプローチを採用している場合、すべての列で作業する必要があります。
Kieran Chandler: つまり、行を追加する場合、20の列に触れる必要があり、比較的効率が悪いということですね。コラム指向のストレージはバッチ分析に適しており、リアルタイムではなく、サプライチェーンに関連する分析に適しています。1分ごとに更新することはできますが、ミリ秒ごとには更新できません。処理能力と大量のデータを扱うコストについて少し話しましょう。テラバイトのスケーラビリティを実装することで、データの処理にどのような影響がありましたか？
Joannes Vermorel: 実際には、かなりの影響がありました。大規模なサプライチェーンを最適化しようとするとき、最もコストのかかるリソースはサプライチェーンの専門家です。これらの人々は無料ではありませんし、適切な才能を持つ個人を見つけて育成することは難しい課題です。CPU、ディスク、帯域幅はお気に入りのクラウドコンピューティングプラットフォームから安価に構築できるため、希少なリソースはそれらではなく、問題に取り組むために必要な才能を持つ人々です。
テラバイトの処理に入ると、すべてが遅くなります。テラバイトのデータを処理するのにはかなりの時間がかかることがあります、特に確率計算やランダム変数を含む非自明な計算を行う場合は。これには数時間かかることもありますが、今では数分で済みます。サプライチェーンの専門家にとっては、これは彼らがタスクに集中し、結果を得て次のことに進むことができるということを意味します。結果を待つことに時間を費やす必要はありません。したがって、サプライチェーンの専門家にとっては悪いニュースですが、彼らはコーヒーブレイクを少なくすることになります。
Kieran Chandler: この突破口は現実世界にどのような意味を持つのでしょうか？明らかに、より大きなデータセットで作業し、より迅速に作業することができますが、他にも何か利点はありますか？
Joannes Vermorel: はい、量的なサプライチェーンの取り組みの失敗の主な危険または原因の1つは、正確に行うためにかかる時間です。正確に動作し、完全に洗練された状態にするためには、残っているエッジケースがないことが重要です。より大きなデータセットをより速く処理できるようになったことで、これらの問題に効率的に対処できるようになりました。これにより、より良いサプライチェーンの意思決定が可能になります。
Kieran Chandler: あなたのシステムは優れていますが、まだ完全に手動で行われている人が1人います。これには多くの人手が必要で、適切に処理されていないエッジケースを手動で処理する必要があります。これは最適化のための高度な機械学習自動化の目的を果たすことを阻害しています。問題は、すべてのエッジケースを排除し、意思決定の数値レシピを本当に研ぎ澄ませるプロセスに時間がかかりすぎることです。
Joannes Vermorel: はい、その遅延は致命的です。なぜなら、ある時点で、人々はその取り組みの成功に対する信頼を失うからです。もし遅ければ、ITが途中で混乱する可能性があります。例えば、プロジェクトに2年かかる場合、途中でERPのアップグレードが行われる確率は3分の1です。サプライチェーンを最適化し始めると、会社の考え方が大きく変わることがあります。行ったことの多くは、すべてのシステムが変更されるために崩れ落ちます。
待っている時間が長ければ長いほど、プロジェクトに影響を与える要素が増えます。ビジネス自体が劇的な変革を遂げる可能性があり、新しいビジネスの変化に照らして以前の作業が無意味になることがあります。製品をすばやく製造するためには、多くの圧力がかかる要因があります。数ヶ月以内に成功できなければ、取り組みは失敗する可能性があります。そこで、柔軟性が絶対に必要です。
それは多く聞こえるかもしれませんが、数テラバイトのデータに触れ、結果を得るのに数時間かかると、最悪の場合でも数回の数値レシピの微調整になります。物事は非常に遅くなり始めます。
Kieran Chandler: したがって、サプライチェーンを最適化するための一種の反復的なアプローチについて触れているのですが、なぜこのような反復的なアプローチが必要なのでしょうか？なぜボタンを1つ押して、ディープラーニングを使用して良い予測と良い結果を得ることができないのでしょうか？
Joannes Vermorel: 現実はあなたの邪魔をする方法を持っています。サプライチェーンは実際の世界の偶発的な事態に対処することです。現実の織り成すエッジケースは非常に多くあります。例えば、理想的な注文数量を計算し始めると、80個という最適な数量が出てきます。しかし、パレットは0個または100個単位で梱包されているため、80個は選択肢にありません。では、どうすればよいのでしょうか？
このような状況は数十あります。在庫の価値は徐々に減少すると思われるかもしれませんが、実際にはそうではありません。なぜなら、特定の日付の商品の寿命があるからです。寿命の制限に達すると、在庫の価値はゼロまたはマイナスになります。なぜなら、この無価値な在庫を処分するために支払わなければならないからです。
供給チェーンは複雑です。多くの市場で運営し、複数の国で多くのサプライヤーを持ち、潜在的に数十の製品ラインを持つ企業について話している場合、多くの複雑さがあります。イニシアチブに沿って将来に現れる技術的な課題をチームと一緒に部屋で座ってブレストすることができると考えるのは甘い考えです。単に言ってしまうことはできません… 供給チェーンチームと一緒に座って、最適化された供給チェーンの意思決定を生成する数値レシピを狂わせる小さな問題をすべてリストアップしましょうと言うことはできません。現実はいつも驚かせる方法を持っています。たとえば、ある国が何かに奇妙な税金を課しているといった奇妙な事実を発見することになるでしょう。イテレーションアプローチに関する最初の質問に戻ると、この絶え間ない驚きの連続に対処する唯一の方法は、予期せぬものに直面したときに数値レシピを修正することに非常に敏捷であることです。
キーラン・チャンドラー: では、テラバイトのスケーラビリティに焦点を当てて、すべてを統合する方法について考えてみましょう。これはLokadの見通しにどのような変化をもたらすのでしょうか？そして、これは将来にとってどういう意味を持つのでしょうか？
ジョアネス・ヴェルモレル: 私たちはスケーラビリティの処理において非常に大きな改善を遂げました。この開発により、以前は利用できなかった多くの変更が可能になりました。大企業との取引に関してだけでなく、例えば、多くの方法で不正行為を行うこともできます。大規模小売ネットワークの最適化にアプローチする場合、各市場を個別に処理することで、200の市場があれば、市場ごとに1つのマシンが必要であり、スケーリングが可能です。しかし、この方法では求めている供給チェーンの改善は得られません。ネットワークレベルで最適化していません。各店舗を個別に最適化し、ネットワークの他の部分で何が起こっているかを完全に無視しています。
キーラン・チャンドラー: つまり、これらの200台のマシンは互いに通信していないということですか？
ジョアネス・ヴェルモレル: まさにその通りです。独立したサイロがある場合、処理をスケーリングするのは非常に簡単です。しかし、ネットワーク全体を1つのエンティティとして考えるときの課題は異なります。実際には、在庫や資材をネットワーク全体でほぼ任意の方法で出荷することができます。利益を上げないし、意味のない方法もたくさんありますが、可能です。そして、これらの微妙な方法のいくつかは非常に良いアイデアであり、利益を上げるものです。一度にすべてを処理できるシステムが必要です。これが将来にとってどういう意味を持つのでしょうか？それは、より良い、包括的な最適化のための多くの可能性を開くということです。供給チェーン最適化の呪いは、問題を解決するのではなく、問題を移動させることです。ある領域を見て最適化するかもしれませんが、問題はただラインの先に移動するか、サプライヤーに戻るだけです。もう1つの可能性は、スケーラビリティを大幅に向上させた今、表現力に戻ろうとすることです。基本的には、現実世界で起こる複雑な状況をより直接的かつ流暢にEnvisionスクリプトで表現することを目指しています。これにより、現実世界の状況に対応するための適切な数値レシピを提供しやすくなります。
キーラン・チャンドラー: それは素晴らしいですね。ここで話をまとめる必要がありますが、今日はお時間をいただきありがとうございました。今週は以上です。ご視聴いただきありがとうございました。また次回お会いしましょう。それでは、さようなら。
