python 能處理數(shù)據(jù)庫中百萬行級的數(shù)據(jù)嗎烁兰？
處理大規(guī)模數(shù)據(jù)時有那些常用的python庫耐亏，他們有什么優(yōu)缺點？適用范圍如何沪斟？
王守崑广辰，推薦系統(tǒng)，數(shù)據(jù)挖掘
需要澄清兩點之后才可以比較全面的看這個問題：
1. 百萬行級不算大數(shù)據(jù)量主之，以目前的互聯(lián)網應用來看择吊，大數(shù)據(jù)量的起點是10億條以上。
2. 處理的具體含義槽奕，如果是數(shù)據(jù)載入和分發(fā)几睛，用python是很高效的；如果是求一些常用的統(tǒng)計量和求一些基本算法的結果史翘，python也有現(xiàn)成的高效的庫枉长，C實現(xiàn)的和并行化的冀续；如果是純粹自己寫的算法，沒有任何其他可借鑒的必峰，什么庫也用不上洪唐，用純python寫是自討苦吃。
python的優(yōu)勢不在于運行效率吼蚁，而在于開發(fā)效率和高可維護性凭需。針對特定的問題挑選合適的工具，本身也是一項技術能力肝匆。
Xiaoyu Ma粒蜈，大數(shù)據(jù)平臺碼農
我們公司每天處理數(shù)以P記的數(shù)據(jù)，有個并行grep的平臺就是python做的旗国。當初大概是考慮快速成型而不是極限速度枯怖，但是事實證明現(xiàn)在也跑得杠杠的。大數(shù)據(jù)很多時候并不考慮太多每個節(jié)點上的極限速度能曾，當然速度是越快越好度硝，但是再更高層次做優(yōu)化（比如利用data locality減少傳輸，建索引快速join寿冕，做sample優(yōu)化partition蕊程，用bloomfilter快速測試等等），把python換成C并不能很大程度上提升效率驼唱。
死跑龍?zhí)椎?/a>藻茂，死跑龍?zhí)椎?a target="_blank" rel="nofollow">http://www.sobuhu.com
這要看具體的應用場景，從本質上來說玫恳，我們把問題分解為兩個方面：
1辨赐、CPU密集型操作
即我們要計算的大數(shù)據(jù)，大部分時間都在做一些數(shù)據(jù)計算纽窟，比如求逆矩陣肖油、向量相似度、在內存中分詞等等臂港，這種情況對語言的高效性非常依賴，Python做此類工作的時候必然性能低下视搏。
2审孽、IO密集型操作
假如大數(shù)據(jù)涉及到頻繁的IO操作，比如從數(shù)據(jù)流中每次讀取一行浑娜，然后不做什么復雜的計算佑力，頻繁的輸入輸出到文件系統(tǒng)，由于這些操作都是調用的操作系統(tǒng)接口筋遭，所以用什么語言已經不在重要了打颤。
結論
用Python來做整個流程的框架暴拄，然后核心的CPU密集操作部分調用C函數(shù)，這樣開發(fā)效率和性能都不錯编饺，但缺點是對團隊的要求又高了(尤其涉及到Python+C的多線程操作)...所以...魚與熊掌不可兼得乖篷。如果一定要兼得，必須得自己牛逼透且。
我很喜歡用python撕蔼，用python處理數(shù)據(jù)是家常便飯，從事的工作涉及nlp秽誊，算法鲸沮，推薦，數(shù)據(jù)挖掘锅论，數(shù)據(jù)清洗讼溺，數(shù)據(jù)量級從幾十k到幾T不等，我來說說吧
百萬級別數(shù)據(jù)是小數(shù)據(jù)最易，python處理起來不成問題怒坯，python處理數(shù)據(jù)還是有些問題的
Python處理大數(shù)據(jù)的劣勢：
1. python線程有gil，通俗說就是多線程的時候只能在一個核上跑耘纱，浪費了多核服務器敬肚。在一種常見的場景下是要命的：并發(fā)單元之間有巨大的數(shù)據(jù)共享或者共用（例如大dict），多進程會導致內存吃緊束析，多線程則解決不了數(shù)據(jù)共享的問題艳馒，單獨的寫一個進程之間負責維護讀寫這個數(shù)據(jù)不僅效率不高而且麻煩
2. python執(zhí)行效率不高，在處理大數(shù)據(jù)的時候员寇，效率不高弄慰，這是真的，pypy（一個jit的python解釋器蝶锋，可以理解成腳本語言加速執(zhí)行的東西）能夠提高很大的速度陆爽，但是pypy不支持很多python經典的包，例如numpy（順便給pypy做做廣告扳缕，土豪可以捐贈一下PyPy - Call for donations）
3. 絕大部分的大公司慌闭，用java處理大數(shù)據(jù)不管是環(huán)境也好，積累也好躯舔，都會好很多
Python處理數(shù)據(jù)的優(yōu)勢（不是處理大數(shù)據(jù)）：
1. 異陈刻蓿快捷的開發(fā)速度，代碼量巨少
2. 豐富的數(shù)據(jù)處理包粥庄，不管正則也好丧失，html解析啦，xml解析啦惜互，用起來非常方便
3. 內部類型使用成本巨低布讹，不需要額外怎么操作（java琳拭，c++用個map都很費勁）
4. 公司中，很大量的數(shù)據(jù)處理工作工作是不需要面對非常大的數(shù)據(jù)的
5. 巨大的數(shù)據(jù)不是語言所能解決的描验，需要處理數(shù)據(jù)的框架（hadoop白嘁， mpi。挠乳。权薯。。）雖然小眾睡扬，但是python還是有處理大數(shù)據(jù)的框架的盟蚣，或者一些框架也支持python
6. 編碼問題處理起來太太太方便了
綜上所述：
1. python可以處理大數(shù)據(jù)
2. python處理大數(shù)據(jù)不一定是最優(yōu)的選擇
3. python和其他語言（公司主推的方式）并行使用是非常不錯的選擇
4. 因為開發(fā)速度，你如果經常處理數(shù)據(jù)卖怜，而且喜歡linux終端屎开，而且經常處理不大的數(shù)據(jù)（100m一下），最好還是學一下python
python數(shù)據(jù)處理的包：
1. 自帶正則包马靠， 文本處理足夠了
2. cElementTree, lxml 默認的xml速度在數(shù)據(jù)量過大的情況下不足
3. beautifulsoup 處理html
4. hadoop(可以用python) 并行處理奄抽，支持python寫的map reduce，足夠了甩鳄， 順便說一下阿里巴巴的odps逞度，和hadoop一樣的東西，支持python寫的udf妙啃，嵌入到sql語句中
5. numpy, scipy, scikit-learn 數(shù)值計算档泽，數(shù)據(jù)挖掘
6. dpark(搬樓上的答案）類似hadoop一樣的東西
1，2揖赴，3馆匿，5是處理文本數(shù)據(jù)的利器（python不就處理文本數(shù)據(jù)方便嘛），4燥滑，6是并行計算的框架（大數(shù)據(jù)處理的效率在于良好的分布計算邏輯渐北，而不是什么語言）
暫時就這些，最好說一個方向铭拧，否則不知道處理什么樣的數(shù)據(jù)也不好推薦包赃蛛，所以沒有頭緒從哪里開始介紹這些包
kinglon，信息安全
使用python可以搀菩，但對速度要求較高的關鍵模塊焊虏，還是要用C重寫。
陳木生秕磷，人生苦短我用python:)
大量數(shù)據(jù)處理的瓶頸是在IO澎嚣，而不是在哪個語言疏尿。語言選擇真的是要看個人口味、品味易桃。
可以看看 Douban 的DPark
Vitas Liu褥琐，搜索研發(fā)工程師
碼代碼比程序時間復雜度更cost
Levi.Wang，是的晤郑，我喜歡帥氣的女子亥紙
Hadoop在大數(shù)據(jù)處理領域應用廣泛敌呈，而它官方默認的程序示例是用java寫的，其實大數(shù)據(jù)處理的今天造寝，語言的快慢已經不足以影響到速度了. java跟python的速度跟C沒有可比性磕洪，但他們的高開發(fā)效率和越來越好的解釋器會讓他們在數(shù)據(jù)處理領域大放異彩.
牟小峰，數(shù)據(jù)挖掘
什么叫處理诫龙？ 100萬的數(shù)據(jù)析显，如果只是傳輸?shù)脑挘琾ython和c/c++差不多签赃；如果用來計算話題模型的話谷异，python的速度為c/c++的1/10，內存消耗為10倍多锦聊。
zxskzxsk h歹嘹，太低調了也不好……
使用Python調用vtk庫對100萬行的數(shù)據(jù)進行可視化，結果內存爆滿孔庭，使用C++就沒有問題尺上，Python很占內存，不知道為什么……
yishen chen史飞，我是
很多python庫的實現(xiàn)都是用其他語言寫的(C比較多)尖昏，只是用Python做了個包裝而已。庫的效率本身不低构资。
Python調用vtk庫對面片數(shù)量我測試過是沒有限制的好像抽诉，你所說的100萬多數(shù)據(jù)是不是都是存入了python的list中，list是有上限限制的吐绵。如果不存入list迹淌，應該是沒有渲染上限的。
