搞分散式，大數據都寫些什麼代碼，是不是寫不了幾行?

01-27

謝邀。

大數據這個概念有點寬，實際上一般有兩類人會說自己是做大數據的，一類是做大數據分析的，一類是做大數據架構的，

大數據分析（策略）的人主要是來干一些業務層面的東西，例如，分析一下每個用戶的特徵，給他們推薦一些商品、廣告什麼的。這類人主要的工作就是找一些演算法（經常是一些機器學習演算法）來從大數據中挖掘出自己想要的信息，因為數據量比較大，所以這類人經常會使用一些分散式的計算框架來幫助自己更快地完成自己的工作，他們不在乎底下這個分散式框架是怎麼實現的，只要能儘快的完成自己的業務就行了。他們經常需要去寫各種各樣的腳本分析數據，他們經常說自己實際工作中一直都在做兩件事：1. 清洗數據 2. 調整模型參數再跑一遍看看模型效果好不好。他們自黑說自己是調參工程師。他們有時候莫名其妙隨手配一個參數，結果發現模型的效果非常好，於是有人說機器學習是一門玄學。這估計也是題主為什麼會認為他們寫代碼少的原因吧？

不過，實際上，「調參工程師」還是很有技術含量的，把一些機器演算法通過一些神奇的轉化，應用於一些實際的場景中，從而從海量的數據中淘出有用的信息，想想就很excited呀；另外，他們也不是僅僅只來調參，調參完成後，也是需要把模型轉化成成真實可用的線上程序的。

大數據架構的人，主要是為大數據分析的人提供一些大數據分析工具，讓他們只專註於模型的選擇與調參，不再需要過多的去關心代碼實現。這些大數據分析工具有許多很有技術含量，例如Hadoop，Spark，Storm，Flink， Hive，甚至也包括一些分散式機器學習演算法庫的封裝如Mahout，MLlib等。這些工具大多工程量很大，因為分散式本身需要考慮的容錯相關的東西太多，一般這些大數據工具的開發者經常需要考慮，萬一個機器掛了，或者系統運行的其中一個機房斷電了，我們的系統是不是還能及時、正確的算出結果，將來機器恢復時，我們能否及時的把這些機器再重新加入計算集群，以便可以重新使用這些資源。等等，類似的各種問題，導致了做架構的同學的工程代碼量很大。但有時候，做架構的人比較蛋疼的是，許多項目，自己的代碼量極大，而策略的人沒幾行代碼，結果項目通報時，卻只是被策略的同學感謝了一下，主要的功勞是策略方的，因為畢竟自己只是做底層的工具，而對方拿著自己做的工具產生了實際的價值。

綜上，做大數據分析的人代碼量一般小一些，但由於偏向業務，做的事情經常更容易產生實際價值，更容易直觀的看到自己能改變世界。大數據架構的人代碼量很大，工程能力要求高，做的事情也很高端，但相對較難直接產生業務價值，不過這也導致了做架構的人在技術的道路上更加純粹。

關於答主自己，做了快5年架構的，不排除未來哪天開始做策略的可能，因為我感覺那些機器學習演算法還蠻有趣的。

我弄分散式計算平台方面的開發，要寫很多的，可以是茫茫多，比如調度，傳輸，計算，報表，這些流每一部分都有很多大神在寫，都是很牛的系統。比如spark這樣的，引入自己的系統中，適配和處理各種分散式環境的問題就要寫很多代碼了

看你是造輪子還是用輪子咯

如果是做平台運維，寫不了幾行。

如果是應用開發，那就取決於業務本身，分散式、大數據編程不僅僅在某些軟體系統的調度，最主要的工作是把數據在不同種類的軟體間傳遞，最後完成存儲。比如，把結構化、半結構化、非結構化的數據傳遞到hadoop、spark、hpc集群……這裡需要編程，計算時要編寫計算流程、計算腳本，中間結果轉存、最終結果入庫、數據可視化……都需要編程……

總結，在深度學習沒有解決絕大多數人為干預的各種問題前，處處是程序員的魅影，處處飄著代碼……

贊同張雲聰！實際工作中基本就是這2種情況了。我只回答策略方面。

其中策略RD就是玩數的，所謂策略，就是擇優選擇。如果不需要選擇，直接開發出來就行了；所謂擇優就是比隨機好，比如要出語音搜索的廣告，優先選擇打字不方便的人、普通話好的地域。

數據2種玩法。1）數據分析指明業務方向（在哪裡應該發力，收益空間多大等），確定策略點後，2）機器學習演算法提升業務效率（比隨機的好，比規則的更好）——參見我們組大牛畢然的《大數據分析的道與術》。

回到寫多少代碼的問題上。大數據分析，1）寫mapreduce代碼，這種方式寫的代碼量多，不易維護不便共享思路，還容易出錯，13年時我所在的一個策略組就這麼玩的。2）hiveql（百度版本是queryengine），一個sql搞定輕鬆搞定join、groupby這種寫mapreduce會吐血的分析。3）sparksql（還是sql但飛快，百度版本是pingo），調研迭代起來大大提升效率。大數據挖掘呢，特徵數據整理好後選演算法，1）單機的sklearn、r、libsvm，2）單機搞不定的有集群平台，都是調參即可。

所以，基本不寫代碼。

要寫，那就是sql（數據分析和數據提取）+shellawk（隨手寫簡單處理數據）+python（sql搞不定的session分析，分析上下文有順序，調用sklearn或演算法平台）

大數據框架，平台的目標，就是為了簡化你的各種業務無關的操作內容。

本來很興奮的一件事，被你各種意外異常，各類分散式兼容，為了保障基礎設施的運行，橫添很多邏輯，思路被強行打斷，誰也不會好。

關注核心，關注最優價值，連創業都要搞MVP，你大數據就有很多時間浪費？

大數據要搞什麼？搞數據，搞分析，那才是出成績的地方。

農民主要目標是種出好莊稼，而不是弄出好地，讓別人來種莊稼

如果圍繞著大數據僅僅是玩技術，那應該搞HPC。那才是製作肥沃土壤的人應該乾的事。

謝邀。

總的來說

1.什麼是分散式計算

分散式計算簡單來說，是把一個大計算任務拆分成多個小計算任務分布到若干台機器上去計算，然後再進行結果匯總。目的在於分析計算海量的數據，數據挖掘等。

2.數據處理方式和調度問題

大多數公司的做法是把mysql或sqlserver的數據導入到HDFS，計算完後再導出到常規的資料庫中，這是MapReduce不夠靈活的地方之一。 MapReduce優勢在於提供了比較簡單的分散式計算編程模型。

挺晚了占樓待更

爬蟲做分散式並不困難，做多機器多進程分散式，加幾行即可設計好結構，在目前經驗而言，在採集百度和高德幾個過億級別的數據量時結構一般是如此。

1: 使用redis的隊列作為任務列，將任務。無論多少請求統一從一個雲端隊列中取任務。並發實在大還有優化。

2: 雲主機看情況。因為這時候採集上的時間消耗主要是網路傳輸，比如在採集香港推特數據就會優先用香港的主機。不然每秒幾m的流量還是比較吃延遲的。

3: 存儲放中心db。並發沒問題。一般每個終端一次取多個比如100個網頁網址作為任務，採集完成後再激活資料庫連接然後去批量存儲。這樣效率會比同量任務下效率提高快百倍。

4: 數據解析一律刪繁就簡，比如頁面的源碼能不渲染就最好直接正則匹配。

5: 如果程序中可能有偶爾的意外停止，一方面用進程池一方面用定時任務來重啟整個項目。

6: 這時候就不要糾結是python太慢 java 吃資源，這些問題然後非要用c寫。。

基本網站改版很正常。尤其突然被每秒百千以上並發過去的時候。敏捷開發即可。程序運行的時間遠低於網路流時間。