所謂的熱點圖，是圖1）構建一張灰度圖，圖2）在每個熱點的位置上繪製併疊加形成灰色的熱點圖，圖3）根據顏色表生成熱點圖。不難看出，最核心的是圖2的過程。詳情參考《視覺化之熱點圖》。
圖1
圖2&圖3
1強調兩處細節
這種思路效率高，缺點就是不夠靈活，每個點都是同一個樣式，沒有考慮該點的半徑和權重。建立大小不一的模版(章)，每個熱點根據自己的半徑值選擇對應的章就可以，實現思路如下：
半徑&模版
權重的不同，是通過蓋章的“力度”，權重越大，不透明度越大，這樣疊加時也越能體現權重大的效果。是否發現，這個方式會產生覆蓋情況，並不嚴謹。
權重&透明度(力度)
2大資料渲染
我們看看在不同資料量下的效能分析。7759個熱點，每個點有經緯度和權重三個float值，生成一張2000*1400左右的熱點圖。採用pa7/heatmap.js，在Chrome下測試1w(1倍)，5w（5倍），10w（15倍），60w(75倍)，100w(150倍)，600w(750)六個級別，千萬級別會崩潰。
備註：只測試了一次，誤差估計不小，僅供參考。
資料轉換消耗（毫秒）
純渲染時間(毫秒)
在這種方式下渲染時間依次為：68，100，194，894，2918，63817(ms)。資料量在100w以內的還好，渲染時間將近3s。但再往上就不給力了。千萬級別下讀取會崩潰，記憶體達到1.2G以上。渲染就算可用，從時間消耗上也不實用。
在渲染效能方面，之前我們通過模版，蓋章的思路已經優化了，沿著這個思路提升空間不大。而且，因為渲染上存在疊加依賴，很難並行。
CPU並行
自己實現渲染演算法，以並行的方式實現數值計算部分。思路如下：對熱點圖這個目標圖片，遍歷每一個畫素，以畫素半徑做一個緩衝區分析，獲取對應的熱點資料（資料支援範圍查詢）。如果沒有熱點，則該畫素為空；如果存在N個熱點，則計算該點的熱點值。乍看上去，這不是又倒退到逐點計算的思路上。
坦白說，我很不喜歡這個思路，就好比老師出了一道1+2+3……+100的題目，本來是想讓你發現規律和資料模型，。可是你真的在一個個累加。但全班同學合作，把這100個數分解成10組，每人分別計算一部分，同樣也能很快得出結果，這就是另一個角度的智慧。
因為每個點的計算是獨立的，可以通過並行來優化“渲染”時間。但這種思路是以放棄渲染技術為代價的，也要藉助於空間索引，平行計算，在JS上很難實現。
另外，這個思路讓我認為（不知道對不對），點差值和熱點圖並無本質區別。
GPU並行
下圖是OpenGL的思路：每一個熱點構造成一個正方形，對角線將其分為兩個三角形，有四個頂點和6個頂點索引。採用批次渲染的方式，每個批次下渲染1w個熱點（對應4w個頂點），將資料分解為多個批次，實現大資料的渲染，GPU中實現混合效果。具體的shader程式碼可以參考pyalot。
我在WebGL下實現了這個思路，還是剛才那個7759個熱點的資料，我放到一個渲染批次，對這一個批次渲染多次， 1s內完成千萬級別的渲染。
3問題
資料解析是瓶頸，比如經緯度點最終要轉換到畫素單。如果效能還不夠，就“偷工減料”，建立向量金字塔，本質就是把N個點合併成一個，減少渲染過程的計算量。
二維對應的策略是，渲染效能不夠，就把渲染問題轉為for迴圈下的簡單計算，然後通過CPU並行優化；對於三維，需要點轉三角形，建立buffer，然後通過GPU實現渲染過程。
從渲染的角度來看，無論二維還是三維，在十萬級別下的效能都不錯，百萬級別也能接受，差別不大，但十萬以上，兩者的渲染差距則體現出來，前者像打狗棒，強調的是心法和招式，後者則是降龍十八掌，靠的是內力。兩點區別，二維是因為渲染效能不行，只好採用最簡單的數值計算，以這樣的代價實現核心計算的並行；三維本身就是並行策略，就是通過shader，通過頂點和片元實現GPU的並行。第二，GPU的並行能力顯然不是CPU可以媲美的，換句話說，GPU能夠承擔更多的併發計算量，儘可能少的對原始資料做預處理，理論上，只要記憶體夠用或讀取資料合理，視訊記憶體上通過批次渲染，可以渲染任意大的資料量，而且時間和批次應該是線性的。
v最後，再強調一下資料。簡單計算了一下，假如是一個二進位制流的方式，一個熱點佔12個位元組，這樣1kw個點要佔120M，即使壓縮後也得20M，這還沒有考慮資料轉換上的消耗。對於Web端，基於原始資料，需要有一種機制，能夠快速的完成資料傳輸和處理。
有一個不一定對的思路，建一個GeoHash，大範圍的預先生成熱點圖，更新頻率可以不高；區域性範圍則通過GeoHash獲取對應的熱點，實現本地渲染。GeoHsh貌似是一種很不錯的大資料設計方式，我也不太瞭解，有時間z再研究研究。
還有一個收穫，當複雜度達到一定程度，原先行得通的演算法和方案不一定滿足要求了。更精彩的是，因為效能低，以前認為比較差的思路，因為思路簡單，容易實現並行改造，竟然可行了。