《數學大觀念3數學算什麼?》:2012年摩根大通損失約60億美金,只因交易員動了一個Excel公式

我們想讓你知道的是
在數學犯錯並不可恥,重複錯誤,或是出錯了卻難以修正才是問題所在。在這本關於數學錯誤的小書中,你可以學到如何運用這些經驗避免危險,或是從中獲利。
文:麥特・帕克(Matt Parker)
試算表的終結
把試算表當成資料庫的另一個限制是,試算表最後是會用完的。就跟電腦用三十二位元的二進位數字來記錄時間會遇到麻煩一樣,Excel對於一個試算表裡能夠記錄多少列數,也有一些障礙。
在二○一○年,維基解密網站提供給《衛報》和《紐約時報》九萬兩千份洩漏自阿富汗戰爭的實地報告。網站創辦人阿桑奇親自把檔案送到《衛報》在倫敦的辦公室,報社記者很快確認了那些檔案似乎是真貨,但是出乎他們意料之外的是,報告應該一路延續到二○○九年的年底,但卻在該年四月戛然而止。
是的,你猜對了,Excel用一個十六位元的數字來記算列數,所以可用的列數有最大值,也就是2^16=65,536。因此,當報社記者在Excel裡打開資料,所有在前65,536筆紀錄之後的資料全都消失了。《紐約時報》的記者凱勒描述了發現這件事的那一場祕密會議,他形容阿桑奇「很自然地一秒變身成辦公室技客,解釋說他們已經撞上了Excel的極限」。
Excel從那之後就擴展到最多可使用2^20=1,048,576列,但還是有個極限!在Excel裡向下捲動,感覺起來像是永遠沒有盡頭,但是如果你往下拖動夠久的話,你最終還是會撞上試算表的結尾。如果你想造訪位於橫列末端的那片空無,我可以確認以最高的捲動速度,大概需時十分鐘。
炸開的試算表
整體來說,使用試算表進行任何類型的重要工作都不是個好主意,試算表是讓錯誤可以暗中孳生蔓延的完美環境。歐洲試算表風險利益小組(是的,這世上有個致力於檢驗試算表出錯時刻的真實組織)估計在所有試算表中,有超過百分之九十包含有錯誤。在使用公式的試算表裡,大約百分之二十四在運算過程包含有一個直接的數學錯誤。
他們竟能得到如此明確的百分比數字,這是因為偶爾會有整個公司的全部試算表一次外洩的情況發生。赫曼斯博士是台夫特理工大學的助理教授,她在校內主持學校的試算表實驗室。我很喜歡「試算表實驗室」的概念,在這裡排列整齊的是試算表裡的行列,而不是試管架上的試管;需要設定條件的是判斷式,而不是微生物培養箱。她有過一次機會,能夠分析真實世界中曾被尋獲的一個龐大的試算表語料庫。
在二○○一年安隆醜聞案留下的混亂中,聯邦能源管理委員會發表了他們對安隆公司企業內部和背後證據的調查結果,其中包含該公司內部大約五十萬封的電子郵件。公布和醜聞案無關的員工郵件可能有些疑慮,所以現在有一個顧及員工隱私的「消毒」版本可在網上下載。這讓我們能夠一窺員工在這麼大的一間公司裡如何使用電子郵件的奇景,而他們當然也透過電子郵件的附件寄送了大量的試算表。
赫曼斯和她的同事在電子郵件檔案裡搜尋,最後成功匯集了1萬5770份真實世界的試算表,以及6萬8979封和這些試算表有關的電子郵件。這其中當然有一些選樣偏差的問題,因為這些試算表都來自同一家因為劣質財報而接受調查的公司,實在可惜。但這些資料仍然是一幅令人難以置信的快照,讓我們得以知道試算表在真實世界的實際使用方式,也能知道那些附上試算表的電子郵件是如何評價試算表、如何傳送,以及如何更新。以下就是赫曼斯的發現:
- 試算表的平均檔案大小是113.4 KB。
- 最大的試算表有驚人的41 MB(我打賭那是一封內嵌音效檔和動圖的生日邀請函。光想像就叫我瑟瑟發抖)。
- 平均來說,每一個試算表包含有5.1個工作表。
- 其中一個試算表竟有175個工作表!就連我都覺得太多了,而且這樣會需要SQL。
- 每個試算表平均有6191個不為空的儲存格,其中1286個是公式(所以有20.8%的儲存格使用公式來計算或搬移資料)。
- 有6650個試算表(占總數的42.2%)沒有包含任何一條公式。
拜託,那幹嘛要用試算表?
你愈是鑽研這些試算表出錯的原因,事情就愈來愈有趣。其中那6650個沒有公式的試算表基本上只是美化過的純文字文件,單純用來列出數字而已,所以我就不談它們了。我唯一在乎的試算表,是裡頭會進行一些可能會出錯的數學運算的那一種,也就是剩下的那9120個包含有20,277,835條公式的試算表。
在輸入公式這方面,Excel確實有很良好的防錯設計,它會檢查語法是否都正確。在進行一般的電腦程式設計時,你很容易會把一個多餘的括號留在某處,或者忘了擺上一個逗號,像這種事會讓你在半夜三點對著一個分號大聲咒罵(「你在這裡搞什麼?!」),反正我聽說過類似的故事。Excel至少會大致檢查你的每一個標點符號,看它們是不是都遵守規矩。
但是Excel不能確定你使用的函式是否合理,也不能確定你有沒有指向正確的儲存格、餵送正確的資料給函式。在這些情況下,程式還是會執行指令,只有在數學完全出錯的時候才會回傳錯誤訊息。#NUM!的意思是使用者用了錯誤類型的數字資料,#NULL!指的是輸入資料的範圍沒有被正確定義,還有一個是我的最愛,#DIV/0!,對應的是任何意圖除以零的動作。
赫曼斯發現有2,205個試算表具有至少一個Excel錯誤訊息,也就是說,在所有包含函式的試算表中,有大約24%是有錯誤的。而且這些錯誤並不孤單,每一個有語法錯誤傾向的試算表平均包含585.5個錯誤的運算結果。有755個試算表包含數量驚人的錯誤,超過一百個,而贏得冠軍的那個試算表竟有83,273個錯誤。多到這種程度,我感到的其實只有讚嘆。我大概沒辦法一口氣搞出這麼多錯誤來,除非我另外使用一個獨立的試算表來追蹤它們。
但是在所有試算表會有的錯誤裡,這些顯而易見的錯誤只占很小很小的一部分,還有更多的函式錯誤最後根本無人知曉。如果對建立試算表的人原本的意圖缺乏深刻的理解,是沒有輕鬆的方法能夠掃描試算表、確認每一個函式都指到正確的地方。這大概是試算表最大的問題了吧,使用者很容易不小心選錯行,於是資料的年份突然錯亂,或者在要計算淨利的時候卻算成毛利(還真的很毛!)。
Tags:
雷亞遊戲作品下載破億的秘密,聯手Google Cloud開源又節流

我們想讓你知道的是
2011 年創立的雷亞遊戲(Rayark Inc.),從 2013 年就攜手 Google Cloud 導入相關雲端服務,雙方合作長達十年的關鍵是什麼?
2011年創立的雷亞遊戲(Rayark Inc.),秉持把感動永久留存在玩家心中的信念與堅持,不論是音樂節奏、休閒趣味、科幻動作、又或是策略RPG不同型態的作品,都希望創造出呈現時代回憶的經典製作。每回推出新款遊戲都能叫好又叫座,雷亞遊戲旗下作品的總下載數,全球上看1.3億次。
「我們的優勢,在於故事的呈現及藝術表現,創造出一個讓玩家與故事有聯結的世界觀,」雷亞遊戲技術長Alvin Chung回應。為了精進作品內涵、拓展遊戲更多可能性,雷亞遊戲從2013年就開始積極將開發架構、維運流程搬遷到雲端環境,進而讓團隊養成敏捷的協作文化。

Alvin Chung解釋,「我們希望把更多心力投入設計遊戲本身,同時優化玩家體驗服務,而不是過度分心或花太多資源去顧及底層網路架構,透過雲端工具源創造更大的效益。」若把一款遊戲從無到有,可拆分為企劃、開發、測試、上線等流程,這些不同階段的工作環境,雷亞目前是放在Google Cloud平台上運行。
完善數據治理工程,雷亞遊戲成立數據部門洞悉營運實況
一款遊戲要讓玩家感動,絕對不能只有感性要素,更需要從理性角度洞察玩家行為數據,才能讓用戶的留存保持穩定。尤其現代企業都知道,數據對於公司經營等同石油的價值,於是,雷亞決定成立數據部門,作為輔佐商業決策判斷的後勤核心團隊。
雷亞遊戲產品發行處數據分析部部長Denny Huang表示,「以前只用database,資料的細緻度不夠;打個比方,透過database只能看存摺的結餘,無法回溯歷程資訊;後來成立數據部門,把伺服器的log收進資料倉儲Google BigQuery,等於帳本的每筆明細都會留下記錄,再結合商業智慧與分析軟體Tableau,讓DAU(日活躍用戶)、MAU(月活躍用戶數)、留存率、付費率這些指標以視覺化圖表完整呈現。」

為了貼近玩家的需求、打造出更符合市場想法的作品,雷亞的營運團隊也希望藉由數據深入鞏固與玩家的黏著度,進而排除不利玩家留存的情境,就能事先透過BigQuery搭配Firebase實現A/B Testing。Alvin Chung舉例,遊戲業相當重視玩家前10分鐘的留存率,如果發現新手歷程在某一區卡關過久,他們就會調閱BigQuery內的玩家行為資料,找出用戶成長停滯的原因,進而修正遊戲的設計機制。透藉由此檢視及驗證方法,促使玩家加入遊戲的前10分鐘留存率提升50%。
盤點目前雷亞數據部門使用BigQuery的數據狀況,每天處理報表容量達9TB、單日300G流量,以及儲存操作紀錄超過300TB。如此龐大的資料量,雷亞也透過BigQuery搭配Tableau,落實更細緻的商業邏輯判斷。
Denny Huang分享其中一個情境:他們想知道玩家在特定戰場,怎麼運用卡牌的排列組合,這時候就能借助BigQuery及機器學習的運算,掌握某個關卡的通關率是否落在合理範圍。後續透過數據分析,找到禮包購買率的最佳時機點,並微調設定禮包內容物,以強化玩家購買誘因,讓特定產品付費率增加17%、 單一活動營收增加16%。
把關伺服器預算有效節流,借助BigQuery從每月縮短到每日掌握報表
如果說提升禮包購買率、留存時間拉長,對於遊戲開發商是「開源」策略,那麼透過Google Cloud來檢視整體服務的運作效率,則屬於「節流」手段。雷亞遊戲就提到,他們所部署的伺服器牽涉相當龐大的機器種類,內容涵蓋資料倉儲單元、資料庫單元、以及運算單元,運行過程勢必就會有所花費,這也是遊戲商的成本之一。
雷亞遊戲網站可靠性工程(SRE)工程師Gene Liu表示,「洞察伺服器維運數據,可以知道我們的後端服務是否有效率?服務品質如何?又或是有沒有讓玩家收到錯誤訊息狀況?透過監控整體後端服務的健康程度以及資源用量,讓我們知道研發資源需優先最佳化哪些項目。」
從上述情境可觀察到,SRE的主要工作就是要確保確保遊戲對內和對外服務的穩定,並且維持一定品質的玩家遊玩體驗。以對內服務來說,遊戲伺服器傳數據給BigQuery的過程,不但要保持通暢,而且也盡可能不會掉失任何資料。不過也因為遊戲玩家來自全球不同時區,等於系統的流量高低峰是24小時在變動;甚至若有特殊行銷檔期,玩家在同一時間大量湧入領獎勵,SRE團隊就要花更多時間在監測伺服器的運作狀態。

Gene Liu對此提到,「我們的後端服務部署於Google Kubernetes Engine之上,後端服務向BigQuery寫入資料是透過Pub/Sub,而Pub/Sub與BigQuery都是全代管的服務,可以大幅度减輕我們的工作負擔,不用手動擴展或縮減設定雲端服務所使用的資源,跟以前的維運工具相比,現在的管理模式可以節省非常多時間。」
另一方面,Gene Liu接著說,雷亞也在雲端環境架設資料視覺化網路應用程式平台Grafana,Grafana可以在網路瀏覽器內顯示資料圖表,並提供警告功能。因此一旦監測到數據峰值異常,就能立刻行動來最佳化産品的效能,或是有效排除伺服器原本不應浪費的成本。
「現在雲端服務的費用以raw data傳到BigQuery後,能透過Grafana即時檢視哪個專案的伺服器以及流量花多少錢,或發現花費異常時候,可以找到是哪個專案開的運算資源。以前要每個月收到帳單才知道費用,現在則是可以即時得知系統數據,並在數小時內掌握各項雲端服務的費用。」Gene Liu補充道。
期待以敏捷方式迭代產品,提供玩家即時又彈性服務
雷亞與Google Cloud的合作,除了上述相關應用,其他還包含Cloud Load Balancing、Compute Engine、Dataflow、Cloud Monitoring、Cloud Logging以及Google Workspace等解決方案,在其他業務及跨部門協作過程有廣泛運用。

Alvin Chung最後回應,「我們多年來觀察Google Cloud持續發布新功能,讓雷亞在做數據分析、維運上更穩定,也希望借力於雲端讓我們越來越省心,專注在遊戲的開發或加速迭代新的産品,更即時觀察市場的回應,進而縮短time to market的腳步。」
由此可見,雷亞遊戲在實現打造具時代回憶的偉大作品之際,藝術也要融合技術,除了讓玩家在遊戲過程感到幸福,同時也基於雲端應用,提供玩家快速又彈性的滿意服務。