貌似這算是開博的第一篇文章，居然就從吐槽開篇鳥。雖然先前有寫過幾篇，但也都刪掉了，感覺寫得不好，沒意思。
好吧，正題，今天又是一大班碼農在糾結某個看上去很沒道理的功能，總感覺很沒必要，其實道理也很明顯，就像你永遠不能超越cap，不能讓硬碟跟記憶體的速度一樣快的道理一樣。其實，要改變也不是完全沒有辦法，但要在功能上做一些折中選擇。
下面描述下這個業務場景吧，服務於賣家，要去實時計算賣家的所有商品，即使他有10w個商品也要算（這個做實時計算怎麼可能，雖然是極少可能出現，但作為碼農的思想，極端情況是要考慮的，在**上還真有可能存在這麼多商品的賣家），計算肯定就是需要時間，即使1ms乙個，10w個就100秒了，賣家開啟乙個頁面要100s，他要瘋掉了。文字描述貌似有點無力，還是把流程圖及模組圖畫畫吧。
[img]
現在大概有兩個方案：
乙個是實時的計算，來乙個賣家就實時算一次，這樣的話，商品數多的時候會好慢，做分頁功能得把商品總數算出來—也就是要把全部商品算一次；
另乙個是離線計算好，但是這樣會產生延遲，而且有些賣家不來，你也得算好擺在那裡，好浪費，因為很多賣家都是不來的。延遲上，一般是一天，但是會隨著延遲的時間越短，計算的次數會越多，浪費就越多。
現實中，pd的要求就是要實時，要翻頁，一點都不退讓。
好吧，在這裡只吐槽下這個不可實現的功能，如果大家有好的方案也可以拍磚哦。
離線計算與實時計算的對比
就是在計算開始前已知所有輸入資料，輸入資料不會產生變化，一般計算量級較大，計算時間也較長。例如今天早上一點，把昨天累積的日誌，計算出所需結果。最經典的就是hadoop的mapreduce方式 一般是根據前一日的資料生成報表，雖然統計指標 報表繁多，但是對時效性不敏感。從技術操作的角度，這部分屬於批處...
軟體開發的吐槽與思考
之前一直在做ios開發工程師，現在有機會作為乙個類似軟體經理的位置 職稱仍然是ios工程師，但是實質上我不做開發的 來對專案進行把控，感覺很奇妙。我所在的公司是甲方，請了一些外包公司來做軟體開發，我會核查他們的 和進度，並提出一些意見。總而言之要盡我所能保證ios應用 以及其他部分 的質量和進度。實...
Hadoop（三） 大資料離線計算與實時計算
分享一下我老師大神的人工智慧教程吧。零基礎，通俗易懂！風趣幽默！1 mapreduce是處理hdfs上的資料 2 mapreduce的思想 是pagerank 搜尋排名 原理是進行分布式計算。如上圖，網頁跳轉中，訪問網頁3的次數最多，也就是權重最大的為網頁3。比如京東 中給推薦的商品，就是近期訪問的...