cassandrapython
⑴ python數據分析師需要學什麼
python數據分析師。現在大數據分析可以熱得不要不要的。從發展來看，python數據分析師很有前景的。但也並不是隨便一個公司就可以做大數據分析的。有幾個問題是做大數據要考慮的：大數據來源是否全面，分析什麼，誰來使用等等。當然如果能到能做大數據的公司，那薪水還是可觀的。要做python數據分析師，有一些東西是不得不學的，要不然，做不了分析師的，可能做的程序員，幫別人實現分析的結果而已。第一：統計學知識。（推薦學習：Python視頻教程）
這是很大一部分大數據分析師的短板。當然這里說的不是簡單的一些統計而已。而是包括均值、中位數、標准差、方差、概率、假設檢驗等等具有時間、空間、數據本身。差不多應該是理工科的高等數學的知識，甚至還高一點兒。要能夠建模，要不然你分析出來的結果離實際相差十萬八千里的話，估計要不了幾天，你就會被卷鋪蓋走人了。當然，做個一般的大數據分析師，就不會涉及到很深的高等數學知識了，但要做一個牛B的大數據分析師，還是要學習學習再學習。
第二：很多人想不到的，你還是把EXCEL玩熟悉吧。
當然不需要掌握的高大全，也得要掌握常用的函數，比如重點包括但不限於sum，count，sumif，countif，find，if，left/right，時間轉換，透視表，各種圖表做法等之類的。如果數據量不算是特別大的話，Excel能夠解決很多問題。比如，篩選部分贓數據，排序，挑選滿足條件的數據等等。
第三：分析思維的練習。
比如結構化思維、思維導圖、或網路腦圖、麥肯錫式分析，了解一些smart、5W2H、SWOT等等那就更好了。不一定要掌握多深多全，但一定要了解一些。
第四：資料庫知識。
大數據大數據，就是數據量很多，Excel就解決不了這么大數據量的時候，就得使用資料庫。如果是關系型資料庫，比如Oracle、mysql、sqlserver等等，你還得要學習使用SQL語句，篩選排序，匯總等等。非關系型資料庫也得要學習，比如：Cassandra、Mongodb、CouchDB、Redis、 Riak、Membase、Neo4j 和 HBase等等，起碼常用的了解一兩個，比如Hbase，Mongodb，redis等。
第五：業務學習。
其實對於大數據分析師來說，了解業務比了解數據更重要。對於行業業務是怎麼走的對於數據的分析有著非常重要的作用，不了解業務，可能你分析的結果不是別人想要的。
第六：開發工具及環境。
比如：linux OS、Hadoop（存儲HDFS，計算Yarn）、Spark、或另外一些中間件。目前用得多的開發工具python等等語言工具。
總之，要做一個高級或總監級的大數據分析師那是相當的燒腦的。要學習了解的東西如果只是單純的數據方面的話，那業務和統計知識的學習是必不可少的。如果是實用型的大數據分析師可能只掌握某些部分就可以。大數據開發工程師的話，基本就是掌握開發環境、開發語言以及各種圖表的應用，也是可以滿足的。畢竟，一個公司要團隊協作，一人懂一部分就可以搞出分析產品出來了。認定一項事情就去干！越干越輕松，越干越牛B！
更多Python相關技術文章，請訪問Python教程欄目進行學習！以上就是小編分享的關於python數據分析師需要學什麼的詳細內容希望對大家有所幫助，更多有關python教程請關注環球青藤其它相關文章！
⑵ 為什麼在大數據處理中Cassandra與Spark如此受歡迎
動手實驗Apache Spark的最好方式是使用互動式Shell命令行，Spark目前有Python Shell和Scala Shell兩種互動式命令行。
可以從 這里下載Apache Spark，下載時選擇最近預編譯好的版本以便能夠立即運行shell。
目前最新的Apache Spark版本是1.5.0，發布時間是2015年9月9日。
tar -xvzf ~/spark-1.5.0-bin-hadoop2.4.tgz
運行Python Shell
cd spark-1.5.0-bin-hadoop2.4
./bin/pyspark
在本節中不會使用Python Shell進行演示。
Scala互動式命令行由於運行在JVM上，能夠使用java庫。
運行Scala Shell
cd spark-1.5.0-bin-hadoop2.4
./bin/spark-shell
執行完上述命令行，你可以看到下列輸出：
Scala Shell歡迎信息
Welcome to
____ __
/ __/__ ___ _____/ /__
_\ \/ _ \/ _ `/ __/ '_/
/___/ .__/\_,_/_/ /_/\_\ version 1.5.0
/_/
Using Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25)
Type in expressions to have them evaluated.
Type :help for more information.
15/08/24 21:58:29 INFO SparkContext: Running Spark version 1.5.0
下面是一些簡單的練習以便幫助使用shell。也許你現在不能理解我們做的是什麼，但在後面我們會對此進行詳細分析。在Scala Shell中，執行下列操作：
在Spark中使用README 文件創建textFileRDD
val textFile = sc.textFile("README.md")
獲取textFile RDD的第一個元素
textFile.first()
res3: String = # Apache Spark
對textFile RDD中的數據進行過濾操作，返回所有包含「Spark」關鍵字的行，操作完成後會返回一個新的RDD，操作完成後可以對返回的RDD的行進行計數
篩選出包括Spark關鍵字的RDD然後進行行計數
val linesWithSpark = textFile.filter(line => line.contains("Spark"))
linesWithSpark.count()
res10: Long = 19
要找出RDD linesWithSpark單詞出現最多的行，可以使用下列操作。使用map方法，將RDD中的各行映射成一個數，然後再使用rece方法找出包含單詞數最多的行。
找出RDD textFile 中包含單詞數最多的行
textFile.map(line => line.split(" ").size)
.rece((a, b) => if (a > b) a else b)
res11: Int = 14
返回結果表明第14行單詞數最多。
也可以引入其它java包，例如 Math.max()方法，因為map和rece方法接受scala函數字面量作為參數。
在scala shell中引入Java方法
import java.lang.Math
textFile.map(line => line.split(" ").size)
.rece((a, b) => Math.max(a, b))
res12: Int = 14
我們可以很容易地將數據緩存到內存當中。
將RDD linesWithSpark 緩存，然後進行行計數
linesWithSpark.cache()
res13: linesWithSpark.type =
MapPartitionsRDD[8] at filter at :23
linesWithSpark.count()
res15: Long = 19
上面簡要地給大家演示的了如何使用Spark互動式命令行。
彈性分布式數據集（RDDs）
Spark在集群中可以並行地執行任務，並行度由Spark中的主要組件之一——RDD決定。彈性分布式數據集(Resilient distributed data, RDD)是一種數據表示方式，RDD中的數據被分區存儲在集群中（碎片化的數據存儲方式），正是由於數據的分區存儲使得任務可以並行執行。分區數量越多，並行越高。下圖給出了RDD的表示：
Display- Edit
想像每列均為一個分區（partition ），你可以非常方便地將分區數據分配給集群中的各個節點。
為創建RDD，可以從外部存儲中讀取數據，例如從Cassandra、Amazon簡單存儲服務（Amazon Simple Storage Service）、HDFS或其它Hadoop支持的輸入數據格式中讀取。也可以通過讀取文件、數組或JSON格式的數據來創建RDD。另一方面，如果對於應用來說，數據是本地化的，此時你僅需要使用parallelize方法便可以將Spark的特性作用於相應數據，並通過Apache Spark集群對數據進行並行化分析。為驗證這一點，我們使用Scala Spark Shell進行演示：
-
⑶ Python學哪個資料庫
資料庫得根據業務需要來選擇。
關系型資料庫RDB:MySQL,Oracle,DB2,PGSQL等
非關系型資料庫NoSQL:Redis,Cassandra,Mongodb等
還有最近比較新的NewSQL
⑷ 現在計算機語言這么多有C#、C++、Java什麼VB甚至現在還出現了Python和ruby可我沒那麼的時間學啊
C語言運算快啊，高級語言越來越流行只是因為計算機速度比原來快很多，所以人類可以用運行時的效率為代價來換取開發時的效率。在對運算速度要求高的地方還是需要用C。
另外，Java和.net是強類型的語言，在編譯時、或者甚至在編寫時就能發現錯誤，在開發復雜的大項目的時候這個很有必要，這種情況下用python的話在integration test的時候說不定就要出現只知道有錯卻找不到錯誤在哪兒的情況。
python、ruby、javascript這些都是開發小項目多，之所以這幾年流行，是因為初創企業最開始使用這些很方便。但是當他們長大之後，還是經常要用別的語言重寫的。比如facebook用java寫了他們專門的資料庫cassandra，twitter用java重寫他們原來的ruby on rails寫的伺服器。
所以，編程語言並不是像你想像的那樣容易淘汰的，即使是50年代就出現的fortran，依然是每隔幾年就有新版本，至今仍然在天文學、氣象學、流體力學、生物學、化學、經濟學等等這些需要高強度計算來模擬一個模型的領域里被廣泛使用。
⑸ 大數據分析應該掌握哪些基礎知識呢
前言，學大數據要先換電腦：
保證電腦4核8G內存64位操作系統，盡量有ssd做系統盤，否則卡到你喪失信心。硬碟越大越好。
1，語言要求
java剛入門的時候要求javase。
scala是學習spark要用的基本使用即可。
後期深入要求：
java NIO，netty，多線程，ClassLoader，jvm底層及調優等，rpc。
2，操作系統要求
linux 基本的shell腳本的使用。
crontab的使用，最多。
cpu，內存，網路，磁碟等瓶頸分析及狀態查看的工具。
scp，ssh，hosts的配置使用。
telnet，ping等網路排查命令的使用
3，sql基本使用
sql是基礎，hive，sparksql等都需要用到，況且大部分企業也還是以數據倉庫為中心，少不了sql。
sql統計，排序，join，group等，然後就是sql語句調優，表設計等。
4，大數據基本了解
Zookeeper，hadoop，hbase，hive，sqoop，flume，kafka，spark，storm等這些框架的作用及基本環境的搭建，要熟練，要會運維，瓶頸分析。
5，maprece及相關框架hive，sqoop
深入了解maprece的核心思想。尤其是shuffle，join，文件輸入格式，map數目，rece數目，調優等。
6，hive和hbase等倉庫
hive和hbase基本是大數據倉庫的標配。要回用，懂調優，故障排查。
hbase看浪尖hbase系列文章。hive後期更新。
7，消息隊列的使用
kafka基本概念，使用，瓶頸分析。看浪尖kafka系列文章。
8，實時處理系統
storm和spark Streaming
9，spark core和sparksql
spark用於離線分析的兩個重要功能。
10，最終方向決策
a),運維。（精通整套系統及故障排查，會寫運維腳本啥的。）
b),數據分析。（演算法精通）
c),平台開發。（源碼精通）
自學還是培訓？
無基礎的同學，培訓之前先搞到視頻通學一遍，防止盲目培訓跟不上講師節奏，浪費時間，精力，金錢。
有基礎的盡量搞點視頻學基礎，然後跟群里大牛交流，前提是人家願意，
想辦法跟大牛做朋友才是王道。
⑹ 大家用 Python 做過的規模最大的項目有哪些
目前正在做的，基於深度學習的，汽車年檢類型和使用零件的推薦系統，用的是Python語言和Tensorflow框架，對雲VPN內伺服器，提供API介面，使用kafka消息中間件，預測結果放在cassandra裡面
⑺ Cassandra與HBase的大數據對決 誰是勝者
眾多基於Bigtable技術的開源項目正在通過不同的方式實現高擴展性、高靈活性、分布式及寬列數據存儲等功能，Cassandra和HBase就是其中的代表。
在大數據這一全新的領域里，Bigtable資料庫技術非常值得我們關注，因為這一技術是由谷歌的工程發明的，而谷歌是一家公認的非常擅長管理海量數據的
公司。如果你對此非常了解，那麼你一家知道也熟悉Cassandra和HBase這兩個Apache資料庫項目。
谷歌在2006年的一份研究報告中首次對Bigtable進行了闡述。有意思的是，這份報告當時並沒有將Bigtable作為資料庫技術，而是將其作為一
種「稀疏的分布式多維度」映射技術以存儲拍位元組級數據，並在商用硬體上運行它們。行先是以一種非常獨特的方式被索引，隨後Bigtable利用行鍵對數據
進行分割，將它們分布到集群中。列可以被迅速地定義在行中，讓Bigtable適用於大多數的非模式環境。
Cassandra和HBase都在很大程度上借鑒了早期Bigtable的定義。實際上，Cassandra起源於Bigtable和亞馬遜的
Dynamo技術，HBase將自身定位為「開源Bigtable工具」。就其本身而論，這兩個項目既有許多相同的特點，同時又有許多重大區別。
同為大數據而生
Cassandra與HBase都是NoSQL資料庫。總體上看，這意味著用戶無法使用SQL資料庫。不過，Cassandra使用的是CQL（Cassandra 查詢語言），其語法有明顯模仿SQL的痕跡。
兩者都被設計用於管理非常大的數據集。HBase文件聲稱一個HBase資料庫可以擁有數億個，甚至是數十億個行。此外，用戶還被建議繼續使用關系型資料庫。
兩者都是分布式資料庫，不僅僅是在數據的存儲方式上，在數據訪問方式上亦是如此。客戶端可以與集群中的任意節點相連，並訪問任意的數據。
兩者都宣稱擁有近似於線型的擴展能力。想要管理兩倍規模的數據嗎？用戶只需將集群中的節點擴展兩倍即可。
兩者都是通過復制來防止集群節點故障而導致出現數據損失。被寫入資料庫的行主要由單個集群節點負責（行至節點映射取決於用戶所使用的分區模式）。數據會被
鏡像到稱之為冗餘節點的其他集群成員當中（用戶可配置的復制因子會顯示數量）。如果主要節點出現了故障，那麼數據仍然可以從另外的冗餘節點中被讀取。
兩者都被稱之為列式資料庫。由於它們的名字聽起來像是關系型資料庫，因此用戶在接觸中需要在思想上進行調整，這導致用戶對它們的認知會出現混淆。最容易出
現混淆的地方是，數據在表面上最初是由行進行排列的，表的主要鍵是行鍵。但是與關系型資料庫不同，在列式資料庫中，沒兩個行需要相同的列。正如上面所說的
那樣，在表被創建後，用戶能夠快速在行中加入列。實際上，你能夠向一行中增加許多列。雖然最高上限值難以被准確地計算出來，但是用戶幾乎不可能達到這樣的
上限，即便他們加入大量列的情況下也是如此。
除了這些源於Bigtable定義的特點外，Cassandra和HBase還有一些其他的相似之處。
首先，兩者都使用相似的寫入路徑，即首先將寫入操作記錄在日誌文件中以確保持久性。即便出現寫入失敗的提示，保存在日誌當中的操作記錄可以被重新開始。隨
後，數據被寫入內存緩存中。最後，數據被通過大量的一系列寫入操作寫入到磁碟中（實際上是將內存緩存的副本拷貝至磁碟中）。Cassandra和
HBase所使用的內存和磁碟數據結構在某種程度上都是日誌結構的合並樹。Cassandra的磁碟組件是SSTable，HBase中磁碟組件的是
HFile。
兩者提供JRuby語言的命令行外殼。兩者都通過Java語言被大量寫入，這是訪問它們的主要編程語言，盡管在許多其他的編程語言中都有適合兩者的客戶端包。
當然，Cassandra 和 HBase都是Apache軟體基金會管理的開源項目，兩者都可以通過Apache License version 2.0許可證免費獲取。
相似與差別
盡管兩者有著眾多相似之處，但是它們之間還是存在著許多重大的區別。
盡管Cassandra和HBase中的節點都是對稱的，這意味著客戶端能夠與集群中的任意節點相連，但是這種對稱是不完全的。Cassandra需要用
戶將一些節點作為種子節點，讓它們在集群間通信中扮演集流點的角色。在HBase中，用戶必須讓一些節點充當主節點，它們的功能是監控和協調地區伺服器的
行動。為了確保高可用性，Cassandra採取方式是允許在集群中設置多個種子節點；HBase則是利用備用主節點，如果當前的主節點發生故障，那麼備
份主節點將成為新的主節點。
Cassandra在節點間通信中使用的是Gossip協議。目前Gossip服務已經與Cassandra軟體整合到了一起。HBase則依託完全獨立
的分布式應用Zookeeper來處理相應的任務。盡管HBase與Zookeeper一同出貨，但是用戶常常會使用預置在HBase資料庫中的
Zookeeper。
雖然Cassandra和HBase都不支持實時交易控制，但是兩者都提供了一定程度的一致性控制。HBase向用戶提供記錄級（也就是行級）的一致性。
實際上，HBase在每行都支持ACID級語義。用戶可以在HBase中鎖定一行，但是這種行為並不被鼓勵，因為這不僅影響到並發性，同時行鎖定還會導致
無法進行區域分割操作。此外，HBase還可以執行「檢查與寫入」操作，該操作在單個數據元上提供了「讀取-修改-寫入」的語義。
Cassandra免費的DataStax社區版包含有一個DataStax 操作中心。該中心提供了集群監控與管理功能，它可以檢測資料庫模式，提示鍵空間是否能夠被編輯，以及是否可以增加或刪除列族。
盡管Cassandra被描述為擁有「終極」一致性，但是讀取和寫入一致性可以在級別和區間方面進行調整。也就是說，你不僅可以配置必須成功完成操作的冗餘節點數量，還可以設置參與的冗餘節點是否跨數據中心。
此外，Cassandra還在其計算機指令系統中增加了一些輕量級的交易。Cassandra的輕量級交易採用的是「比較與集合」機制，相當於HBase
的「檢查與寫入」功能。不過，對於HBase的「讀取-修改-寫入」操作功能，Cassandra則缺乏相對應的功能。最終，Cassandra的2.0
版本增加了單獨的行級寫入功能。如果一個客戶端在一行中更新了多個列，那麼其他的客戶端將會看到所有未更新的部分，或所有更新的部分。
在Cassandra和HBase當中，主索引是行鍵，但是數據被存儲在磁碟中，這導致列族成員相互間非常接近。因此仔細規劃列族組織非常重要。為了保持
高查詢性能，有著相同訪問模式的列應該被放在在相同的列族當中。Cassandra允許用戶創建關於列值的額外次索引。這一舉措提升了對那些值具有高重復
性的列（例如存儲客戶電子郵件地址中國家地區的列）的數據訪問。HBase雖然缺乏對次索引的內置支持，但是它們有一些能夠提供次索引功能的機制。這些都
在HBase的在線參考指南和HBase社區博客中被提及。
如前所述，兩個資料庫都有發布數據操作命令的命令行外殼。由於HBase和Cassandra的殼都是以JRuby殼為基礎，因此用戶可以編寫一些腳本，
讓這些腳本能夠調用JRuby殼的所有資源與資料庫所提供的特定API進行交互。此外，Cassandra還定義了模仿自SQL的CQL。與HBase所
使用的查詢語言相比，CQL的功能更加豐富，並且可以在Cassandra的殼內直接執行。
盡管Cassandra仍然支持Thrift
API，但實際上Cassandra一直在推動讓CQL成為資料庫的主要編輯介面。Cassandra的文檔列入了一些針對Java、C#和Python
等使用CQL version
3的驅動。最終，Cassandra將可獲得一個JDBC驅動。該驅動用CQL替代了SQL，將CQL作為數據定義與數據管理語言。
HBase也支持Thrift介面和RESTful Web服務介面，不過HBase原生的Java
API向編程人員提供了豐富的功能。雖然HBase的數據操作命令沒有CQL豐富，但是HBase擁有一個「篩選」功能，該功能可以在會話的伺服器端執
行，大幅提升了掃描（搜索）的吞吐量。
HBase還引入了「協處理器」（coprocessors）這一概念，允許在HBase進程中執行用戶代碼。這基本上與關系型資料庫中的觸發和預存進程相同。目前，Cassandra還沒有類似HBase協處理器的功能。
Cassandra的文檔較HBase的更加醒目，並且擁有更加扁平化的學習曲線。設置一個開發用的Cassandra集群比設置HBase集群要更加簡單。當然，這僅對於開發與測試目的來說非常重要。
棘手之處
在必須為特定應用調整集群時，用戶需要做一些工作。在指定數據集大小、創建與管理多節點集群（通常會跨多個數據中心）的復雜度後，調整工作將變得非常棘手。用戶需要深刻理解集群的內存緩存、磁碟存儲和節點間通信之間相互影響，仔細監控集群的活動。
HBase對Zookeeper的依賴會帶來一些額外的故障點。雖然Cassandra避開了這一問題，但這並不意味著Cassandra集群的調整難度會大幅下降。我們對兩個資料庫的集群調整難點進行了對比（如附表所示）。
需要說明的是，這里並沒有確定誰是勝出者，誰是失敗者。每個資料庫的支持者都會找到一些證據來證明他們的系統優於對方。通常用戶需要對兩個資料庫進行測試，然後才能確定它們執行目標應用的情況。
⑻ python 怎麼玩cassandra
安裝：
[python]view plain
pipinstallpycassa
- 創建一個可操作CF的連接:
importpycassa
pool=pycassa.ConnectionPool(keyspace=ks_name,server_list=server_list,prefill=False)
cf=pycassa.ColumnFamily(pool,cf_name)
cf.insert('rowkey',{'column1':'val'})
cf.get('rowkey')
cf.multiget(['key1','key2'])#查詢多個rowkey
cf.remove('key')
cf.remove('key',columns=['column1'])
rows={'key1':{'column1':'val'},'key2':{'column1':'val2'},'key3':{'column1':'val3'}}
cf.batch_insert(rows)
importcql
connection=cql.connect(host,port,keyspace)
cursor=connection.cursor()
cursor.execute("CQLQUERY",dict(kw='Foo',kw2='Bar',etc...))
forrowincursor:#()calls
doRowMagic(row)
cursor.close()
connection.close()
[python]view plain
幾個核心的方法:
[python]view plain
cassandra 的cql 是用類似sql的語句來操作 cassandra python也提供了 cql的客戶端~
[python]view plain
⑼ cassandra python 怎麼刪除數據
Cassandra通過寫一條「tombstone」來標記一個數據被刪除了。被標記的數據默認要10天(配置文件中的
gc_grace_seconds)後且被compaction或cleanup執行到對應的SSTable時才會被真正從磁碟刪除，因為如果當時這個
delete操作只在3個節點中的2個執行成功，那麼一旦2個有tombstone的節點把數據刪了，集群上只剩下沒tombstone的那個節點，下次
讀這個key的時候就又返回對應的數據，從而導致被刪除的數據復活。Repair操作可以同步所有節點的數據從而保證tombstone在3個節點中都存
在，因此如果想確保刪除100%成功不會復活需要以小於gc_grace_seconds的周期定期執行repair操作(所以官方建
議」weekly」)。
然而在select數據的時候，在每個SSTable遇到的所有符合查詢條件的tombstone要放內存中從而在合並每個SSTable文件的數
據時判斷哪些column數據沒被刪能最終返回，tombstone太多會導致heap被大量佔用需要各種GC從而影響性能，所以cassandra默認
讀到100000個(可配置)tombstone就強製取消這次讀取，因為遇到這種情況一定是你「doing it
wrong」。因此如果經常刪除一個row key下的column key，同時又有一次select一個row key下多個column
key的需求，很容易遇到這種情況，tombstone很多的時候即使不到10w最終成功讀取了，這次讀取也會很慢，並很快導致觸發年輕代GC從而拖慢整
個節點的響應速度。
最好的解決方案肯定是設計的時候就避免。但假如在不修改表結構的情況下，解決方案有兩種：如果不能接受一個column
key被刪又復活，先把gc_grace_seconds改成0，然後刪除的時候用ALL模式，當然只要有1個節點超時/掛掉刪除就會失敗；如果能接受被
刪的數據復活，刪除只為了減少磁碟空間使用，那就直接把gc_grace_seconds設成0，復活就復活吧。