基本上，通過物聯(lián)網，我們試圖與機器、交通、環(huán)境條件或其他任何方面獲得連續(xù)和當前的視圖，然后我們可以利用這些信息去更好地完成某些工作。該操作可能是預測計算機何時會發(fā)生故障，或者更有效地路由通信流，但是對于許多用例，收集數(shù)據(jù)、提供見解和采取行動之間的時間間隔很短。
優(yōu)化移動網絡變得更快了
舉個例子，在紅綠燈改變或者一個人從雜貨店的貨架上走了幾英尺遠之前，對此數(shù)據(jù)進行分析。弄清楚如何分析傳入的數(shù)據(jù)，然后根據(jù)這些數(shù)據(jù)創(chuàng)建一個模型，例如交叉路口或購物者的數(shù)據(jù)，以便計算機能夠對其進行操作，這就是我們討論真相的原因?？肆_斯比的觀點是真理每秒鐘都在變化，所以如果我們試圖建立一個代表機器或模型真相的數(shù)字孿生模型，它需要不斷地改變。這對我們如何看待數(shù)字孿生的計算架構會有很多啟示。
例如，Swim.ai正在與一家美國電信公司合作，實時創(chuàng)建運營商網絡的數(shù)字孿生模型，然后根據(jù)人員的不斷移動和他們正在運行的任何應用程序來優(yōu)化網絡。這家運營商正在追蹤1.5億臺移動設備，這些設備每天總共產生4兆字節(jié)的數(shù)據(jù)。隨著5G技術的出現(xiàn)，設備和基站之間需要追蹤的元素越來越多，運營商預計其需要分析的數(shù)據(jù)量將達到20PB。
在Swim.ai之前，運營商將獲取這些數(shù)據(jù)并將其移動到一個400節(jié)點的Hadoop集群中進行批量分析。它大約花了6個小時，需要很多服務器。在切換到Swim的軟件后，該運營商可以跟蹤這1.5億臺設備和基站，并在100毫秒內開始在其網絡上采取行動。它通過在可用的邊緣處理器上本地處理數(shù)據(jù)，并僅使用確定應采取的任何操作所需的數(shù)據(jù)來實現(xiàn)這一點。
所以網絡優(yōu)化既快又便宜，因為運營商不再需要一個巨大的集群來批量處理巨大的數(shù)據(jù)塊。而且，其蜂窩網絡的數(shù)字孿生體更準確，代表了接近"真相"的東西，并允許運營商立即采取行動解決問題或提供更好的體驗。
在早些時候的談話中，克羅斯比說，他遇到的最大挑戰(zhàn)是想辦法利用Swim軟件賺錢。向郊區(qū)或城市收費25美分一次的API調用，以提供幾乎即時的流量預測或紅燈狀態(tài)不起作用。這個用例很有趣，但經濟性并不存在。沒有足夠的人愿意支付如此高的費用來預測交通流量。
對于這個特殊的運營商，這里發(fā)現(xiàn)了一個客戶有一個高價值的問題，該客戶使用大量數(shù)據(jù)，需要實時洞察，以便采取行動。但是，其中數(shù)字孿生體在幾秒鐘內就代表了實際情況的真相，不確定有多少是值得花費大量金錢的。
例如，雜貨店可能會想弄清楚購物者在哪里，這樣當購物者靠近某一特定產品時，他們可以提供建議。一家物流公司可能想知道，當卡車接近最便宜的汽油時，他們可以命令他們停下來加油。隨著電動汽車和卡車越來越普遍，每秒了解汽車的充電水平和附近充電器的位置將非常重要。
首先，數(shù)字孿生必須在幾秒鐘內提供實時見解和變化。這意味著我們需要標準，而像微軟這樣的公司努力使手工構建辦公室或商店的數(shù)字孿生變得容易，這似乎是錯誤的策略。
第二個觀點是，我們需要重新思考我們如何處理數(shù)據(jù)——我們存儲什么，存儲在哪里，以及如何以比我們今天更靈活的方式將數(shù)據(jù)與計算聯(lián)系起來。
