"Data Science = statistics who uses python and lives in San Francisco"

創(chuàng)新互聯(lián)公司是一家專業(yè)從事做網站、網站制作的網絡公司。作為專業(yè)網絡公司,創(chuàng)新互聯(lián)公司依托的技術實力、以及多年的網站運營經驗,為您提供專業(yè)的成都網站建設、成都營銷網站建設及網站設計開發(fā)服務!
恰好我馬上啟程到Twitter的data science team,而且恰巧懂一點點統(tǒng)計和住在舊金山,所以沖動地沒有邀請就厚臉回答了:D
我認為有幾個大方面
1)學好python。
現(xiàn)在幾乎所以公司的數據都可以api給你,而python的數據處理能力強大且方便。加之在machine learning的很多算法上,python也獨俏一方。另外,它的簡明方便迅速迭代開發(fā),15分鐘寫完個算法就可以看效果了。
除此之外,py還有點酷酷的感覺。任何程序拿matlab和c++都是可以寫的,不過我真沒認識過哪個d愿意自己把自己扔那個不酷的框框里:D
對不規(guī)則輸入的處理也給python一個巨大的優(yōu)勢。通常來說,在我現(xiàn)在日常的工作里,所有的數據都是以純文本但是非格式的形式存儲的(raw text, unstructured data)。問題在于,這些文本不可以直接當作各種算法的輸入,你需要
分詞,分句
提取特征
整理缺失數據
除掉異類(outlier)
在這些時候,python可謂是神器。這里做的1-4都可以直接在scikit-learn里面找到對應的工具,而且,即使是要自己寫一個定制的算法處理某些特殊需求,也就是一百行代碼的事情。
簡而言之,對于數據科學面臨的挑戰(zhàn),python可以讓你短平快地解決手中的問題,而不是擔心太多實現(xiàn)細節(jié)。
2)學好統(tǒng)計學習
略拗口。統(tǒng)計學習的概念就是“統(tǒng)計機器學習方法”。
統(tǒng)計和計算機科學前幾十年互相平行著,互相造出了對方造出的一系列工具,算法。但是直到最近人們開始注意到,計算機科學家所謂的機器學習其實就是統(tǒng)計里面的prediction而已。因此這兩個學科又開始重新融合。
為什么統(tǒng)計學習很重要?
因為,純粹的機器學習講究算法預測能力和實現(xiàn),但是統(tǒng)計一直就強調“可解釋性”。比如說,針對今天微博股票發(fā)行就上升20%,你把你的兩個預測股票上漲還是下跌的model套在新浪的例子上,然后給你的上司看。
Model-1有99%的預測能力,也就是99%的情況下它預測對,但是Model-2有95%,不過它有例外的一個附加屬性——可以告訴你為什么這個股票上漲或者下跌。
試問,你的上司會先哪個?問問你自己會選哪個?
顯然是后者。因為前者雖然有很強的預測力(機器學習),但是沒有解釋能力(統(tǒng)計解釋)。
而作為一個數據科學家,80%的時間你是需要跟客戶,團隊或者上司解釋為什么A可行B不可行。如果你告訴他們,“我現(xiàn)在的神經網絡就是能有那么好的預測力可是我根本就沒法解釋上來”,那么,沒有人會愿意相信你。
具體一些,怎么樣學習統(tǒng)計學習?
先學好基本的概率學。如果大學里的還給老師了(跟我一樣),那么可以從MIT的概率論教材【1】入手。從第1章到第9章看完并做完所有的習題。(p.s.面試Twitter的時候被問到一個拿球后驗概率的問題,從這本書上抓來的)。
了解基本的統(tǒng)計檢驗及它們的假設,什么時候可以用到它們。
快速了解統(tǒng)計學習有哪些術語,用來做什么目的,讀這本【5】。
學習基本的統(tǒng)計思想。有frequentist的統(tǒng)計,也有bayesian的統(tǒng)計。前者的代表作有【2】,后者看【3】。前者是統(tǒng)計學習的圣書,偏frequentist,后者是pattern recognition的圣書,幾乎從純bayesian的角度來講。注意,【2】有免費版,作者把它全放在了網上。而且有一個簡易版,如果感覺力不從心直接看【2】,那么可以先從它的簡易版開始看。簡易版【4】是作者在coursera上開課用的大眾教材,簡單不少(不過仍然有很多閃光點,通俗易懂)。對于【3】,一開始很難直接啃下來,但是啃下來會受益匪淺。
注意,以上的書搜一下幾乎全可以在網上搜到別人傳的pdf。有條件的同學可以買一下紙制版來讀,體驗更好并且可以支持一下作者。所有的書我都買了紙制版,但是我知道在國內要買本書有多不方便(以及原版書多貴)。
讀完以上的書是個長期過程。但是大概讀了一遍之后,我個人覺得是非常值得的。如果你只是知道怎么用一些軟件包,那么你一定成不了一個合格的data scientist。因為只要問題稍加變化,你就不知道怎么解決了。
如果你感覺自己是一個二吊子數據科學家(我也是)那么問一下下面幾個問題,如果有2個答不上來,那么你就跟我一樣,真的還是二吊子而已,繼續(xù)學習吧。
為什么在神經網絡里面feature需要standardize而不是直接扔進去
對Random Forest需要做Cross-Validatation來避免overfitting嗎?
用naive-bayesian來做bagging,是不是一個不好的選擇?為什么?
在用ensembe方法的時候,特別是Gradient Boosting Tree的時候,我需要把樹的結構變得更復雜(high variance, low bias)還是更簡單(low variance, high bias)呢?為什么?
如果你剛開始入門,沒有關系,回答不出來這些問題很正常。如果你是一個二吊子,體會一下,為什么你跟一流的data scientist還有些差距——因為你不了解每個算法是怎么工作,當你想要把你的問題用那個算法解決的時候,面對無數的細節(jié),你就無從下手了。
說個題外話,我很欣賞一個叫Jiro的壽司店,它的店長在(東京?)一個最不起眼的地鐵站開了一家全世界最貴的餐館,預訂要提前3個月。怎么做到的?70年如一日練習如何做壽司。70年!除了喪娶之外的假期,店長每天必到,8個小時工作以外繼續(xù)練習壽司做法。
其實學數據科學也一樣,沉下心來,練習匠藝。
3)學習數據處理
這一步不必獨立于2)來進行。顯然,你在讀這些書的時候會開始碰到各種算法,而且這里的書里也會提到各種數據。但是這個年代最不值錢的就是數據了(拜托,為什么還要用80年代的“加州房價數據”?),值錢的是數據分析過后提供給決策的價值。那么與其糾結在這么悲劇的80年代數據集上,為什么不自己搜集一些呢?
開始寫一個小程序,用API爬下Twitter上隨機的tweets(或者weibo吧。。。)
對這些tweets的text進行分詞,處理噪音(比如廣告)
用一些現(xiàn)成的label作為label,比如tweet里會有這條tweet被轉發(fā)了幾次
嘗試寫一個算法,來預測tweet會被轉發(fā)幾次
在未見的數據集上進行測試
如上的過程不是一日之功,尤其剛剛開始入門的時候。慢慢來,耐心大于進度。
4)變成全能工程師(full stack engineer)
在公司環(huán)境下,作為一個新入職的新手,你不可能有優(yōu)待讓你在需要寫一個數據可視化的時候,找到一個同事來給你做。需要寫把數據存到數據庫的時候,找另一個同事來給你做。
況且即使你有這個條件,這樣頻繁切換上下文會浪費更多時間。比如你讓同事早上給你塞一下數據到數據庫,但是下午他才給你做好。或者你需要很長時間給他解釋,邏輯是什么,存的方式是什么。
最好的變法,是把你自己武裝成一個全能工作師。你不需要成為各方面的專家,但是你一定需要各方面都了解一點,查一下文檔可以上手就用。
會使用NoSQL。尤其是MongoDB
學會基本的visualization,會用基礎的html和javascript,知道d3【6】這個可視化庫,以及highchart【7】
學習基本的算法和算法分析,知道如何分析算法復雜度。平均復雜度,最壞復雜度。每次寫完一個程序,自己預計需要的時間(用算法分析來預測)。推薦普林斯頓的算法課【8】(注意,可以從算法1開始,它有兩個版本)
寫一個基礎的服務器,用flask【9】的基本模板寫一個可以讓你做可視化分析的backbone。
學習使用一個順手的IDE,VIM, pycharm都可以。
看了CNode社區(qū)的一篇文章,非常好,果斷轉,a href=""想看點我/a
NoSQL,泛指非關系型的數據庫。隨著互聯(lián)網web2.0網站的興起,傳統(tǒng)的關系數據庫在應付web2.0網站,特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網站已經顯得力不從心,暴露了很多難以克服的問題,而非關系型的數據庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數據庫的產生就是為了解決大規(guī)模數據集合多重數據種類帶來的挑戰(zhàn),尤其是大數據應用難題。
雖然NoSQL流行語火起來才短短一年的時間,但是不可否認,現(xiàn)在已經開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗,然而現(xiàn)在的系統(tǒng)已經更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個嚴酷的事實:技術越來越成熟——以至于原來很好的NoSQL數據存儲不得不進行重寫,也有少數人認為這就是所謂的2.0版本。這里列出一些比較知名的工具,可以為大數據建立快速、可擴展的存儲庫。
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,是一項全新的數據庫革命性運動,早期就有人提出,發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數據存儲,相對于鋪天蓋地的關系型數據庫運用,這一概念無疑是一種全新的思維的注入。
對于NoSQL并沒有一個明確的范圍和定義,但是他們都普遍存在下面一些共同特征:
不需要預定義模式:不需要事先定義數據模式,預定義表結構。數據中的每條記錄都可能有不同的屬性和格式。當插入數據時,并不需要預先定義它們的模式。
無共享架構:相對于將所有數據存儲的存儲區(qū)域網絡中的全共享架構。NoSQL往往將數據劃分后存儲在各個本地服務器上。因為從本地磁盤讀取數據的性能往往好于通過網絡傳輸讀取數據的性能,從而提高了系統(tǒng)的性能。
彈性可擴展:可以在系統(tǒng)運行的時候,動態(tài)增加或者刪除結點。不需要停機維護,數據可以自動遷移。
分區(qū):相對于將數據存放于同一個節(jié)點,NoSQL數據庫需要將數據進行分區(qū),將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復制。這樣既提高了并行性能,又能保證沒有單點失效的問題。
異步復制:和RAID存儲系統(tǒng)不同的是,NoSQL中的復制,往往是基于日志的異步復制。這樣,數據就可以盡快地寫入一個節(jié)點,而不會被網絡傳輸引起遲延。缺點是并不總是能保證一致性,這樣的方式在出現(xiàn)故障的時候,可能會丟失少量的數據。
BASE:相對于事務嚴格的ACID特性,NoSQL數據庫保證的是BASE特性。BASE是最終一致性和軟事務。
NoSQL數據庫并沒有一個統(tǒng)一的架構,兩種NoSQL數據庫之間的不同,甚至遠遠超過兩種關系型數據庫的不同。可以說,NoSQL各有所長,成功的NoSQL必然特別適用于某些場合或者某些應用,在這些場合中會遠遠勝過關系型數據庫和其他的NoSQL。
什么是NoSQL
大家有沒有聽說過“NoSQL”呢?近年,這個詞極受關注。看到“NoSQL”這個詞,大家可能會誤以為是“No!SQL”的縮寫,并深感憤怒:“SQL怎么會沒有必要了呢?”但實際上,它是“Not Only SQL”的縮寫。它的意義是:適用關系型數據庫的時候就使用關系型數據庫,不適用的時候也沒有必要非使用關系型數據庫不可,可以考慮使用更加合適的數據存儲。
為彌補關系型數據庫的不足,各種各樣的NoSQL數據庫應運而生。
為了更好地了解本書所介紹的NoSQL數據庫,對關系型數據庫的理解是必不可少的。那么,就讓我們先來看一看關系型數據庫的歷史、分類和特征吧。
關系型數據庫簡史
1969年,埃德加?6?1弗蘭克?6?1科德(Edgar Frank Codd)發(fā)表了劃時代的論文,首次提出了關系數據模型的概念。但可惜的是,刊登論文的《IBM Research Report》只是IBM公司的內部刊物,因此論文反響平平。1970年,他再次在刊物《Communication of the ACM》上發(fā)表了題為“A Relational Model of Data for Large Shared Data banks”(大型共享數據庫的關系模型)的論文,終于引起了大家的關注。
科德所提出的關系數據模型的概念成為了現(xiàn)今關系型數據庫的基礎。當時的關系型數據庫由于硬件性能低劣、處理速度過慢而遲遲沒有得到實際應用。但之后隨著硬件性能的提升,加之使用簡單、性能優(yōu)越等優(yōu)點,關系型數據庫得到了廣泛的應用。
通用性及高性能
雖然本書是講解NoSQL數據庫的,但有一個重要的大前提,請大家一定不要誤解。這個大前提就是“關系型數據庫的性能絕對不低,它具有非常好的通用性和非常高的性能”。毫無疑問,對于絕大多數的應用來說它都是最有效的解決方案。
突出的優(yōu)勢
關系型數據庫作為應用廣泛的通用型數據庫,它的突出優(yōu)勢主要有以下幾點:
保持數據的一致性(事務處理)
由于以標準化為前提,數據更新的開銷很小(相同的字段基本上都只有一處)
可以進行JOIN等復雜查詢
存在很多實際成果和專業(yè)技術信息(成熟的技術)
這其中,能夠保持數據的一致性是關系型數據庫的最大優(yōu)勢。在需要嚴格保證數據一致性和處理完整性的情況下,用關系型數據庫是肯定沒有錯的。但是有些情況不需要JOIN,對上述關系型數據庫的優(yōu)點也沒有什么特別需要,這時似乎也就沒有必要拘泥于關系型數據庫了。
關系型數據庫的不足
不擅長的處理
就像之前提到的那樣,關系型數據庫的性能非常高。但是它畢竟是一個通用型的數據庫,并不能完全適應所有的用途。具體來說它并不擅長以下處理:
大量數據的寫入處理
為有數據更新的表做索引或表結構(schema)變更
字段不固定時應用
對簡單查詢需要快速返回結果的處理
。。。。。。
NoSQL數據庫
為了彌補關系型數據庫的不足(特別是最近幾年),NoSQL數據庫出現(xiàn)了。關系型數據庫應用廣泛,能進行事務處理和JOIN等復雜處理。相對地,NoSQL數據庫只應用在特定領域,基本上不進行復雜的處理,但它恰恰彌補了之前所列舉的關系型數據庫的不足之處。
易于數據的分散
如前所述,關系型數據庫并不擅長大量數據的寫入處理。原本關系型數據庫就是以JOIN為前提的,就是說,各個數據之間存在關聯(lián)是關系型數據庫得名的主要原因。為了進行JOIN處理,關系型數據庫不得不把數據存儲在同一個服務器內,這不利于數據的分散。相反,NoSQL數據庫原本就不支持JOIN處理,各個數據都是獨立設計的,很容易把數據分散到多個服務器上。由于數據被分散到了多個服務器上,減少了每個服務器上的數據量,即使要進行大量數據的寫入操作,處理起來也更加容易。同理,數據的讀入操作當然也同樣容易。
提升性能和增大規(guī)模
下面說一點題外話,如果想要使服務器能夠輕松地處理更大量的數據,那么只有兩個選擇:一是提升性能,二是增大規(guī)模。下面我們來整理一下這兩者的不同。
首先,提升性能指的就是通過提升現(xiàn)行服務器自身的性能來提高處理能力。這是非常簡單的方法,程序方面也不需要進行變更,但需要一些費用。若要購買性能翻倍的服務器,需要花費的資金往往不只是原來的2倍,可能需要多達5到10倍。這種方法雖然簡單,但是成本較高。
另一方面,增大規(guī)模指的是使用多臺廉價的服務器來提高處理能力。它需要對程序進行變更,但由于使用廉價的服務器,可以控制成本。另外,以后只要依葫蘆畫瓢增加廉價服務器的數量就可以了。
不對大量數據進行處理的話就沒有使用的必要嗎?
NoSQL數據庫基本上來說為了“使大量數據的寫入處理更加容易(讓增加服務器數量更容易)”而設計的。但如果不是對大量數據進行操作的話,NoSQL數據庫的應用就沒有意義嗎?
答案是否定的。的確,它在處理大量數據方面很有優(yōu)勢。但實際上NoSQL數據庫還有各種各樣的特點,如果能夠恰當地利用這些特點將會是非常有幫助。具體的例子將會在第2章和第3章進行介紹,這些用途將會讓你感受到利用NoSQL的好處。
希望順暢地對數據進行緩存(Cache)處理
希望對數組類型的數據進行高速處理
希望進行全部保存
多樣的NoSQL數據庫
NoSQL數據庫存在著“key-value存儲”、“文檔型數據庫”、“列存儲數據庫”等各種各樣的種類,每種數據庫又包含各自的特點。下一節(jié)讓我們一起來了解一下NoSQL數據庫的種類和特點。
NoSQL數據庫是什么
NoSQL說起來簡單,但實際上到底有多少種呢?我在提筆的時候,到NoSQL的官方網站上確認了一下,竟然已經有122種了。另外官方網站上也介紹了本書沒有涉及到的圖形數據庫和對象數據庫等各個類別。不知不覺間,原來已經出現(xiàn)了這么多的NoSQL數據庫啊。
本節(jié)將為大家介紹具有代表性的NoSQL數據庫。
key-value存儲
這是最常見的NoSQL數據庫,它的數據是以key-value的形式存儲的。雖然它的處理速度非常快,但是基本上只能通過key的完全一致查詢獲取數據。根據數據的保存方式可以分為臨時性、永久性和兩者兼具三種。
臨時性
memcached屬于這種類型。所謂臨時性就是 “數據有可能丟失”的意思。memcached把所有數據都保存在內存中,這樣保存和讀取的速度非常快,但是當memcached停止的時候,數據就不存在了。由于數據保存在內存中,所以無法操作超出內存容量的數據(舊數據會丟失)。
在內存中保存數據
可以進行非常快速的保存和讀取處理
數據有可能丟失
永久性
Tokyo Tyrant、Flare、ROMA等屬于這種類型。和臨時性相反,所謂永久性就是“數據不會丟失”的意思。這里的key-value存儲不像memcached那樣在內存中保存數據,而是把數據保存在硬盤上。與memcached在內存中處理數據比起來,由于必然要發(fā)生對硬盤的IO操作,所以性能上還是有差距的。但數據不會丟失是它最大的優(yōu)勢。
在硬盤上保存數據
可以進行非常快速的保存和讀取處理(但無法與memcached相比)
數據不會丟失
兩者兼具
Redis屬于這種類型。Redis有些特殊,臨時性和永久性兼具,且集合了臨時性key-value存儲和永久性key-value存儲的優(yōu)點。Redis首先把數據保存到內存中,在滿足特定條件(默認是15分鐘一次以上,5分鐘內10個以上,1分鐘內10000個以上的key發(fā)生變更)的時候將數據寫入到硬盤中。這樣既確保了內存中數據的處理速度,又可以通過寫入硬盤來保證數據的永久性。這種類型的數據庫特別適合于處理數組類型的數據。
同時在內存和硬盤上保存數據
可以進行非常快速的保存和讀取處理
保存在硬盤上的數據不會消失(可以恢復)
適合于處理數組類型的數據
面向文檔的數據庫
MongoDB、CouchDB屬于這種類型。它們屬于NoSQL數據庫,但與key-value存儲相異。
不定義表結構
面向文檔的數據庫具有以下特征:即使不定義表結構,也可以像定義了表結構一樣使用。關系型數據庫在變更表結構時比較費事,而且為了保持一致性還需修改程序。然而NoSQL數據庫則可省去這些麻煩(通常程序都是正確的),確實是方便快捷。
可以使用復雜的查詢條件
跟key-value存儲不同的是,面向文檔的數據庫可以通過復雜的查詢條件來獲取數據。雖然不具備事務處理和JOIN這些關系型數據庫所具有的處理能力,但除此以外的其他處理基本上都能實現(xiàn)。這是非常容易使用的NoSQL數據庫。
不需要定義表結構
可以利用復雜的查詢條件
面向列的數據庫
Cassandra、Hbase、HyperTable屬于這種類型。由于近年來數據量出現(xiàn)爆發(fā)性增長,這種類型的NoSQL數據庫尤其引人注目。
面向行的數據庫和面向列的數據庫
普通的關系型數據庫都是以行為單位來存儲數據的,擅長進行以行為單位的讀入處理,比如特定條件數據的獲取。因此,關系型數據庫也被稱為面向行的數據庫。相反,面向列的數據庫是以列為單位來存儲數據的,擅長以列為單位讀入數據。
高擴展性
面向列的數據庫具有高擴展性,即使數據增加也不會降低相應的處理速度(特別是寫入速度),所以它主要應用于需要處理大量數據的情況。另外,利用面向列的數據庫的優(yōu)勢,把它作為批處理程序的存儲器來對大量數據進行更新也是非常有用的。但由于面向列的數據庫跟現(xiàn)行數據庫存儲的思維方式有很大不同,應用起來十分困難。
高擴展性(特別是寫入處理)
應用十分困難
最近,像Twitter和Facebook這樣需要對大量數據進行更新和查詢的網絡服務不斷增加,面向列的數據庫的優(yōu)勢對其中一些服務是非常有用的,但是由于這與本書所要介紹的內容關系不大,就不進行詳細介紹了。
總結:
NoSQL并不是No-SQL,而是指Not Only SQL。
NoSQL的出現(xiàn)是為了彌補SQL數據庫因為事務等機制帶來的對海量數據、高并發(fā)請求的處理的性能上的欠缺。
NoSQL不是為了替代SQL而出現(xiàn)的,它是一種替補方案,而不是解決方案的首選。
絕大多數的NoSQL產品都是基于大內存和高性能隨機讀寫的(比如具有更高性能的固態(tài)硬盤陣列),一般的小型企業(yè)在選擇NoSQL時一定要慎重!不要為了NoSQL而NoSQL,可能會導致花了冤枉錢又耽擱了項目進程。
NoSQL不是萬能的,但在大型項目中,你往往需要它!
文章題目:nosql第一章測試,nosql數據庫入門與實踐第二章
標題來源:http://chinadenli.net/article19/dsggdgh.html
成都網站建設公司_創(chuàng)新互聯(lián),為您提供虛擬主機、網站維護、企業(yè)建站、營銷型網站建設、網頁設計公司、標簽優(yōu)化
聲明:本網站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)