作者 |Ben Schmidt
譯者 |彎月
出品 | CSDN（ID：CSDNnews）
以下為譯文：
最近，我做了許多有關數據編程未來發展方面的探索。在日常工作中，我使用Python 的 pandas 和 R 的 dplyr。但我注意到了一些非常有趣的現象。最近我從事的一個項目需要進行大規模的散點圖可視化，最多需要在瀏覽器上繪制10億個點。在實現這個功能時，我意識到一些問題：
1. 在過去的幾十年內，計算機的速度大幅提升；
javascript ide，2. 數據分析使用的語言開始掉隊了；
3. 新的數據格式的出現，導致 Python、R和 JavaScript 之間的區別不是那么重要了；
4. 原本用于前端的JavaScript語言開始越來越多地用在后端，處理Python和R所從事的數據任務；
5. 這些趨勢的確有點奇怪，但也許不是壞事。
java和javascript哪個難，我嘗試過使用一種二進制的序列化格式代替JSON，我發現：
隨著webgpu和新的二進制序列化格式（如Arrow）的出現，geojson蝸牛般的速度越來越難以忍受。越來越多的R和Python庫變成了JS或WASM的封裝。就像 2000 年前后它們封裝 Java 一樣，這個趨勢很奇怪。
這里，我主要談談Python和R，因為這兩種語言在數據編程領域中占據絕對優勢。（“數據編程”指的是數據科學；由于我并不是數據科學家，我不確定用這個詞來描述我的工作是否準確。）一些經濟學界的老古董們依然在使用Stata，而激進的人使用Julia，但如果你想從事數據工作，那必然會用到Python或R。 在我們的工作中，數據處理程序最大的問題就在于，它們在CPU上運行，而且絕大多數僅能使用一個核心。因此速度永遠是最頭疼的問題。2011年，我第一次嘗試Python，當時為了尋找GIL（全局解釋器鎖）的解決方案而抓狂，由于GIL的存在，程序無法在多核心上運行，甚至連多線程都不行。最近情況好了一些，至少線性代數方面的程序可以使用計算機的全部資源了。
所有程序的圖形界面都不約而同地轉向了Web。如果晚幾年才開始從事現在的工作，我甚至都不會意識到曾經還存在另一種解決方案。我從未真正使用過R的tcl/tk界面，但我知道它們存在。大約在2008年，JB Michel編寫的第一版Google Ngram瀏覽器就是使用某個Python庫編寫的。當時這種用法非常正常。但在過去十年，凡是需要編寫用戶界面元素，比如“按鈕”或“鼠標滑過事件”，那么毫無疑問，最容易的做法就是使用HTML的概念，而不是使用操作系統本身的概念。Martin Camacho在編寫第一版Bookworm UI的時候就意識到需要一款JavaScript的圖表庫。現在，JavaScript的集成在數據編程領域越來越緊密了。我的許多同事和學生，都采用HTML/JS把他們的R包裝成了漂亮的應用，給Google colab notebook添加了文本框、滑塊等裝飾，或者將R和Python代碼發布到在線圖書。
javascript編程、Jupyter notebook和RStudio IDE自身也在轉變：它們只不過是一堆由看不見的JavaScript連在一起的Python代碼。同樣，這些平臺或多或少都顛覆了過去的模型。我剛開始學習R時，還需要把代碼從文本編輯器中復制粘貼到core R GUI中；我還嘗試過emacs的ESS模式。但在今天，如果你需要反復檢查某個數據框中的隨機樣本，重復運行某段代碼，或者檢查正則表達式是否能準確清理數據，你會選擇notebook界面，就算你最終需要把代碼打包成一個庫，也會在開發中選擇notebook。
而可視化方面也逐漸被JavaScript滲透。包括我在內的許多人都認為，在可視化pandas的數據框時，Altair要比matplotlib容易得多；而對于希望實現鼠標懸停提示功能的學生們，我也不再推薦ggplotly。沒錯，ggplot和matplotlib依然是在發表論文時的首選，但一旦涉及到Web上的交互式、響應式圖表，我們希望圖表能實現同樣的功能。就像notebook界面中HTML的選擇菜單和按鈕擔當的角色一樣，在圖表界面中，JS的圖表庫擔當了此角色。
首先聲明，這一節的觀點不保證完全正確。對于這些內容我并不是專家。但是這個領域的確不穩定，我相信有人和我有同樣的經歷。
近年來，GPU開始取代CPU。R/Python在GPU方面的接口很弱。Numba某種程度上可以使用；我也一直在研究gnumpy；我沒有在R中特意使用過GPU，雖然有可能無意中用到過。在Python和R中，最簡單的使用GPU的方法就是使用TensorFlow或Torch，即使不需要神經網絡也可以。例如，在訓練UMAP模型時，我會選擇神經網絡接口，盡管我更傾向于CPU接口。
原生javascript，大多數接口都依賴于CUDA來訪問GPU。（我不確定的就是這里。）如果你要在這些平臺上編程，就需要啟動一臺云服務器運行模型。CUDA的配置很繁瑣，而且有可能你的機器上沒有GPU。如果你想在云中運行一切也沒問題，Google可以免費提供TPU。但僅僅是在幾百萬行數據上執行group-by、apply或summarize，使用TPU就是殺雞用牛刀了。再說，盡管云計算比自己的筆記本便宜，但是云存儲非常昂貴。為了運行RateMyProfessor的數據框，我每年都需要向Digital Ocean支付大約100美元；而為了保存HathiTrust所需的幾個T的數據，我只能選擇學校的集群和家里的一塊12TB硬盤，否則就付不起賬單了。
?
我第一次在JavaScript中繪制圖表時就被震驚了。ggplot僅僅繪制幾千個點就要等很久，我早已習慣了。geopandas中的多邊形操作很慢很昂貴，我也習慣了。而且我習慣了一邊喝茶，一邊等待加載geojson文件。
然而使用JavaScript，利用三角形生成隨機多邊形，然后繪制幾百萬個點，幾乎一眨眼的功夫就能完成；接著甚至可以用regl實現動畫，實現平滑縮放。例如，下面這個例子中，每張選票需要繪制5個點，你可以隨意加載每個州。
javascript技術，隨著我制作的這種可視化越來越多，我終于發現了原因。Apache Arrow能夠暴露非常底層的數據模型，鼓勵你從數據定義和底層的類型兩方面進行思考。我在使用R的numpy時就習慣了這種思維范式，但在R中只做過一點點。但在現代JS中，二進制數組緩沖區是語言內置的。剛開始使用JS的時候，我以為它會很慢，但與其他動態強類型語言相比，Web開發者對于速度有更高的要求。Chrome內置的性能測試工具非常強大，而且Google在提高JS運行速度方面下了很大力氣，因為他們的收益就來自于更好的Web體驗。當然，許多網站依然很慢，因為他們使用了大量的React和沒有任何用處的代碼；而且DOM也確實很慢。但JavaScript本身非常快。
在剛開始教數字化人性課程時，我最不喜歡的一項工作就是幫助學生安裝本地的Java環境，以運行主題模型最好的實現——Mallet。現在，我們通常使用gensim中更慢的實現，或者結構化主題模型等。但負責維護Mallet的David Mimno卻說，JavaScript非常快。
盡管JavaScript作為語言的名聲不太好，但從ES2015版本之后，使用JavaScript寫程序的難度降低了很多。Map、集合、for...of...結構，所有這些語法都能正常使用（不會像我最初進行可視化時，由于單詞統計程序的詞匯表中包含了constructor一詞，而不得不調試了好幾個小時）；而且還支持許多語法，如類、數組解構、箭頭函數等，都比Python更好用。
?
JavaScript前景，既然JavaScript很快，那么WebGL就可以自由發揮了。想象一下，只需幾毫秒就能繪制peano曲線中的兩百萬個點。你甚至可以重新生成每一幀。
而且WebGL與Apache Arrow一樣都使用浮點數緩存，所以數據是從磁盤（或Web）直接復制到渲染器中，而不需要做JavaScript計算。這個操作很難，而且很容易出錯。（我認為regl已經做了非常好的抽象，但我仍然會在本應創建一個緩沖區的時候，不小心為每一幀分配數千個緩沖區）。
至于在線制圖方面，mapbox.gl或deck.gl中基于protobuffer的向量文件能夠實現相似的功能。在處理制圖數據時，一旦嘗試過二進制數據的速度和壓縮率，就很難再忍受基于JSON的格式的額外開銷了。
?
python編程、我見識過了WebGL的速度。對于數組平滑、對每個點執行數值過濾、分組求和等任務，針對數據框中的每個元素并行執行關系代數操作，是完全可行的。
但除了在非常適合的情況下，否則我仍然不愿意使用WebGL，因為WebGL非常不擅長數值計算。除非非常有必要，否則我不會建議別人學習WebGL。屬性緩沖區只能是浮點類型，因此你需要把所有整型轉換成浮點類型才能傳送數據。許多情況下，數據可以降低成半精度浮點，但雙精度浮點數非常困難，以至于WebGL采用了一整套莫名其妙的結構，花費了巨大的代價來支持它。材質的支持在不同設備上的支持也不同（蘋果的設備似乎有特殊的問題），所以據我所知，許多人都想出了各種退而求其次的方法。而一些數據編程必需的操作，如列表的索引查找、在數組上執行for循環等，是幾乎做不到的。在WebGL中編寫復雜的渲染器很有意思，但這樣做就違背了整個系統的初衷。
最后這兩個關鍵技術遲遲不見任何進展。Web Assembly（WASM）是一項優秀的技術。若干Rust的項目可以編譯成WASM，在瀏覽器中實現更快的計算。（如果我晚幾年學習一門新語言，那肯定是Rust，因為在編寫webgl程序的過程中，我經常需要自己編寫垃圾收集器，但作為一名使用高級語言的人，我學習的C語言還不夠，并沒有掌握足夠的基礎知識。）2000年前后，許多Python和R軟件包都依賴于Java虛擬機；到了2010年，許多軟件包開始依賴于C/C++。我認為，很快Python和R軟件包就會開始依賴于JavaScript虛擬機。
最后一項技術一直沒有任何進展，但可能是最重要的。WebGL正在逐漸死去，但大公司都在合力將WebGPU打造成在瀏覽器中使用GPU的下一代標準。它構建在已有設備的GPU接口上（如Vulkan和Metal），而這些已有接口都是我不愿意學習的。
編程？WebGPU將會取代WebGL，在瀏覽器中快速渲染圖形。但是，在WebGL中進行繁重計算的能力非常誘人，以至于一些激進的人已經開始這樣做了。
我并沒有仔細閱讀過WebGPU的規格，但它的確支持采用更強壯的方式來處理任務。已經出現了一些使用WebGPU來處理線性代數的庫（如BLAS）。可以想象，有了更多的數據類型支持，許多簡單的group-by-filter-apply函數可以完全移到GPU上進行。
我于2004年開始學習R時，花費了許多時間嘗試用SQL來保存在當時看來很多的數據——根據種族、學校、性別等分類的、幾十年來的上百萬條學生數據。現在已經完全可能將全部數據都放進GPU內存中進行處理了。一般而言，GPU內存（0.5~4GB）和通用內存（2~16GB）的差異并不是那么大，因此我們并不會發送過多的數據。數據分析和處理一般都可以并行化。
?
一旦這個組合可以成功運行，就會比Python/R更快、更方便，·而且在許多情況下不需要配置就可以使用。去年出現的Arquero庫已經在Observable中實現了dplyr以及PandasAPI中最重要的部分，而且速度與python/R不相上下。如果使用集成更緊密的二進制文件，或使用不同的后端，它（或者類似的庫）很容易成為所有學校數據科學課程的首選平臺。即使做不到這一點，JavaScript在可視化速度（GPU集成）和界面（HTML5）方面的優勢也意味著，我們可以將數據放在網站上進行探索。
一旦這些快速操作可以實現，解析CSV或JSON的額外開銷，以及沒有嚴格類型定義等缺點將會變得更明顯。屆時一定會出現一種更標準的二進制交換格式，就像現在的arrow、HDF5、ORC或profobuffer。
?
使用R或Python的數據編程語言將會依賴于JavaScript。就像Python/R封裝Altair、封裝HTML點擊事件，越來越多的包和模塊將會在JS虛擬機上運行。人們也會關注有關V8引擎版本的問題。還會出現本應在任何地方都能運行的python代碼，卻無法在某些低端筆記本上運行的問題。
自2003年左右以來，我一直在從事某些編程工作，而且自2010年以來，我的大部分時間都在從事編程。在這期間內，我看到我們完全可以在開放式數據上編輯或運行數據分析。有些人只需要靜態圖表，而有些人想隱藏他們的數據。大多數人都不想調整設置。很多人都不太喜歡Javascript。但這是因為互聯網創建于90年代，目的是共享學術作品，并允許讀者對其進行編輯。大多數學術界和許多媒體都致力于單向信息流，而媒體喜歡追捧互聯網，但看到如今這些變化，我感到特別興奮，因為它們代表了一種可能性，也許Web真的能夠兌現自己的諾言：用更簡單的方式思考問題。
原文鏈接：http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/
?入侵微博服務器刷流量，開發者獲刑 5 年；馬化騰重回中國首富；支持 M1 芯片，VS Code 1.54 發布 | 極客頭條?“無語！只因姓True，蘋果封了我的iCloud賬戶”
?如何成為一名更出色的開發者？
?TIOBE 3 月編程語言：Swift 一路低走，Java 份額大跌
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
