『壹』 hdfs為什麼能存儲不同類型數據為什麼能存儲pb級的數據
「TB是一個計算機存儲容量的單位，它等於2的40次方，或者接近一萬億個位元組（即，一千千兆位元組）。」
一提到數據量級，人們通常會聯想到美國國會圖書館（見圖）。德勤、麥肯錫、IBM、Gartner和移動廣告公司Adfonic的數據專家向TechTarget記者介紹了PB級數據究竟有多大。
麥肯錫首席分析師Michael Chui指出，美國國會圖書館「在2011年4月前已經收集了235TB的數據，而一個PB相當於它的4倍。」
TechTarget自己的網路網站Whatis有關於PB大小的定義：「PB是數據存儲容量的單位，它等於2的50次方個位元組，或者在數值上大約等於1000個TB。」
未來學家Raymond Kurzweil他的論文中對PB的定義進行延伸：人類功能記憶的容量預計在1.25個TB。這意味著，800個人類記憶才相當於1個PB。
如果這樣還不夠清楚，那麼Adfonic的CTO Wes Biggs給出了下面更直接的計算：
假設手機播放MP3的編碼速度為平均每分鍾1MB，而1首歌曲的平均時長為4分鍾，那麼1PB歌曲可以連續播放2000年。
如果智能手機相機拍攝相片的平均大小為3MB，列印照片的平均大小為8.5英寸，那麼總共1PB的照片的並排排列長度就達到48000英里——大約可以環繞地球2周。
1PB足夠存儲整個美國人口的DNA，而且還能再克隆2倍。
DVD、戰列艦和六國賽
從比特（bit）和位元組（byte）開始，德勤的分析師還將他們的思考向以下方面進一步延伸。（1個比特是1個二進制位，可能是0或1;1個位元組長8個二進制）：
如果以每秒1個位的速度數一下1PB所包含的位數，那麼您需要2.85億年才能數完。
如果每秒數1個位元組，那麼您需要數357萬年。
保存1PB數據需要用掉22.3萬張DVD。
保存1PB數據，需要用掉7.46億張3.5英寸軟盤;這7.46億軟盤重13422噸。這個重量僅僅比2艘Type 45驅逐艦輕一些。
人類身體細胞數據各不相同，但是數量最多的接近100萬億個，如果用1個位來表示1個細胞，那麼1PB足夠記錄90個人的身體細胞，相當於橄欖球六國賽的全部球員。
谷歌、社交媒體和宇宙大爆炸
谷歌在2004年率先進軍數字地圖領域，並在2005年發布了谷歌地圖和谷歌地球。現在，谷歌為用戶提供了超過20PB（215億MB）的地圖影像——包括衛星圖片、航拍照片和360度街景圖片。
即使在2008年，谷歌每天處理的數據已經達到20 PB，一年就是7300 PB。
從那時起，社交媒體網站就開始生成PB級數據，它們逐漸成為所謂的「大數據」。
根據2012年2月1日Facebook向美國證券交易委員會提交的IPO文檔記錄，Facebook在1年前已經存儲了100 PB數據。
在Twitter網站上，每分鍾就有34000條微博出現。IBM非常關注於一個天文項目：「由於20個國家共同出資總計15億歐元建設的平方公里陣列（Square Kilometer Array, SKA）是一個無線電天文望遠鏡，它可以觀測宇宙大爆炸的衰弱信號。」
SKA（計劃在2024年完成）估計整個宇宙每天將生成1376 PB數據，相當於每天傳輸的全球互聯網流量的兩倍。
只能盡量減少，而不能消除，常用減少誤差的
『貳』 圖計算引擎Neo4j和Graphscope有什麼區別
Neo4j是單機系統，主要做圖資料庫。GraphScope是由阿里巴巴達摩院智能計算實驗室研發的圖計算平台，是全球首個一站式超大規模分布式圖計算平台，並且還入選了中 國科學技術協會「科創中 國」平台。Graphscope的代碼在github.com/alibaba/graphscope上開源。SSSP演算法上,GraphScope單機模式下平均要比Neo4j快176.38倍，最快在datagen-9.2_zf數據集上快了292.2倍。
『叄』 有哪些輕型的非關系型資料庫
常見的非關系型資料庫有：1、mongodb；2、cassandra；3、redis；4、hbase；5、neo4j。其中mongodb是非常著名的NoSQL資料庫，它是一個面向文檔的開源資料庫。
常見的幾種非關系型資料庫：
1、MongoDB
MongoDB是最著名的NoSQL資料庫。它是一個面向文檔的開源資料庫。MongoDB是一個可伸縮和可訪問的資料庫。它在c++中。MongoDB同樣可以用作文件系統。在MongoDB中，JavaScript可以作為查詢語言使用。通過使用sharding MongoDB水平伸縮。它在流行的JavaScript框架中非常有用。
人們真的很享受分片、高級文本搜索、gridFS和map-rece功能。驚人的性能和新特性使這個NoSQL資料庫在我們的列表中名列第一。
特點：提供高性能；自動分片；運行在多個伺服器上；支持主從復制；數據以JSON樣式文檔的形式存儲；索引文檔中的任何欄位；由於數據被放置在碎片中，所以它具有自動負載平衡配置；支持正則表達式搜索；在失敗的情況下易於管理。
優點：易於安裝MongoDB；MongoDB Inc.為客戶提供專業支持；支持臨時查詢；高速資料庫；無模式資料庫；橫向擴展資料庫；性能非常高。
缺點：不支持連接；數據量大；嵌套文檔是有限的；增加不必要的內存使用。
2、Cassandra
Cassandra是Facebook為收件箱搜索開發的。Cassandra是一個用於處理大量結構化數據的分布式數據存儲系統。通常，這些數據分布在許多普通伺服器上。您還可以添加數據存儲容量，使您的服務保持在線，您可以輕松地完成這項任務。由於集群中的所有節點都是相同的，因此不需要處理復雜的配置。
Cassandra是用Java編寫的。Cassandra查詢語言(CQL)是查詢Cassandra資料庫的一種類似sql的語言。因此，Cassandra在最佳開源資料庫中排名第二。Facebook、Twitter、思科(Cisco)、Rackspace、eBay、Twitter、Netflix等一些最大的公司都在使用Cassandra。
特點：線性可伸縮；；保持快速響應時間；支持原子性、一致性、隔離性和耐久性(ACID)等屬性；使用Apache Hadoop支持MapRece；分配數據的最大靈活性；高度可伸縮；點對點架構。
優點：高度可伸縮；無單點故障；Multi-DC復制；與其他基於JVM的應用程序緊密集成；更適合多數據中心部署、冗餘、故障轉移和災難恢復。
缺點：對聚合的有限支持；不可預知的性能；不支持特別查詢。
3、Redis
Redis是一個鍵值存儲。此外，它是最著名的鍵值存儲。Redis支持一些c++、PHP、Ruby、Python、Perl、Scala等等。Redis是用C語言編寫的。此外，它是根據BSD授權的。
特點：自動故障轉移；將其資料庫完全保存在內存中；事務；Lua腳本；將數據復制到任意數量的從屬伺服器；鑰匙的壽命有限；LRU驅逐鑰匙；支持發布/訂閱。
優點：支持多種數據類型；很容易安裝；非常快（每秒執行約11萬組，每秒執行約81000次）；操作都是原子的；多用途工具（在許多用例中使用）。
缺點：不支持連接；存儲過程所需的Lua知識；數據集必須很好地適應內存。
4、HBase
HBase是一個分布式的、面向列的開源資料庫，該技術來源於 Fay Chang 所撰寫的Google論文「Bigtable：一個結構化數據的分布式存儲系統」。就像Bigtable利用了Google文件系統（File System）所提供的分布式數據存儲一樣，HBase在Hadoop之上提供了類似於Bigtable的能力。
HBase是Apache的Hadoop項目的子項目。HBase不同於一般的關系資料庫，它是一個適合於非結構化數據存儲的資料庫。另一個不同的是HBase基於列的而不是基於行的模式。
5、neo4j
Neo4j被稱為原生圖資料庫，因為它有效地實現了屬性圖模型，一直到存儲層。這意味著數據完全按照白板的方式存儲，資料庫使用指針導航和遍歷圖。Neo4j有資料庫的社區版和企業版。企業版包括Community Edition必須提供的所有功能，以及額外的企業需求，如備份、集群和故障轉移功能。
特點：它支持唯一的約束；Neo4j支持完整的ACID(原子性、一致性、隔離性和持久性)規則；Java API: Cypher API和本機Java API；使用Apache Lucence索引；簡單查詢語言Neo4j CQL；包含用於執行CQL命令的UI: Neo4j Data Browser。
優點：容易檢索其相鄰節點或關系細節，無需連接或索引；易於學習Neo4j CQL查詢語言命令；不需要復雜的連接來檢索數據；非常容易地表示半結構化數據；大型企業實時應用程序的高可用性；簡化的調優。
缺點：不支持分片
『肆』 資料庫分庫分表（二）Twitter-Snowflake（64位分布式ID演算法）分析與JAVA實現
Twitter-Snowflake演算法產生的背景相當簡單，為了滿足Twitter每秒上萬條消息的請求，每條消息都必須分配一條唯一的id，這些id還需要一些大致的順序（方便客戶端排序），並且在分布式系統中不同機器產生的id必須不同。各種主鍵ID生成策略對比，見 常見分布式主鍵ID生成策略
把 41位的時間前綴 ， 10位的節點標識 ， 12位的sequence 組合在一起。
除了最高位bit標記為不可用以外，其餘三組bit佔位均可浮動，看具體的業務需求而定。 默認情況下41bit的時間戳，1970年算起可以支持該演算法使用到2038年，10bit的工作機器id可以支持1024台機器，序列號支持1毫秒產生4096個自增序列id 。
Snowflake是Twitter在2010年用Scala語言寫的一套主鍵生成策略，用Thrift對外發布主鍵生成服務，其中依賴了Twitter內部的Infrastructure，後來Twitter用 Twitter-server 代替了Snowflake，自2012年起就未更新。見 Twitter-Snowflake項目地址（Tags:snowflake-2010）
之前寫了一個Java的實現，改自網上一個版本: Twitter的分布式自增ID演算法Snowflake實現分析及其Java、Php和Python版 。後來看到當當網的 Sharding-JDBC 分庫分表中間件已實現了此演算法。就直接在其中添加了一些新特性，已merge。( 具體實現 , 說明文檔 )
添加3種IdGenerator實現。
用筆記本（i7-3632QM 2.2GHz 四核八線程）測試了下，每秒生成409萬（理論上的峰值），CPU佔用率18.5%。
『伍』 如何通過python調用新浪微博的API來爬取數據
先上結論，通過公開的api如果想爬到某大v的所有數據，需要滿足以下兩個條件：
1、在你的爬蟲開始運行時，該大v的所有微博發布量沒有超過回溯查詢的上限，新浪是2000，twitter是3200。
2、爬蟲程序必須不間斷運行。
新浪微博的api基本完全照搬twitter，其中介面的參數特性與底層的NoSQL密不可分，建議先看點Nosql資料庫的設計理念有助於更好的理解api設計。
一般來說，如果決定爬某個大v，第一步先試獲取該用戶的基本信息，中間會包含一條最新的status，記下其中的id號作為基準，命名為baseId。
介面中最重要的兩個參數：
since_id：返回ID比since_id大的微博（即比since_id時間晚的微博），默認為0。
max_id：返回ID小於或等於max_id的微博，默認為0。
出於各種原因，獲取statuses的介面，固定為按id降序排列（scan_index_forward=false），即最新的statuses返回在前。假設該微博第一天上線，就一個用戶，發了一百條，id是1到100。而你在該用戶發了第50條的時候開始運行的爬蟲，即baseId=50。
『陸』 怎麼處理大數據，怎麼處理雙11這么多訂單
大數據（巨量數據集合（IT行業術語））
大數據（big data），指無法在可承受的時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力來適應海量、高增長率和多樣化的信息資產。
在維克托·邁爾-舍恩伯格及肯尼斯·庫克耶編寫的《大數據時代》。 中大數據指不用隨機分析法（抽樣調查）這樣的捷徑，而採用所有數據進行分析處理。大數據的5V特點（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（價值）、Veracity（真實性）。
具體操作：
整個處理流程可以概括為四步，分別是採集、導入和預處理、統計和分析，以及挖掘。
採集
大數據的採集是指利用多個資料庫來接收發自客戶端（Web、App或者感測器形式等）的數據，並且用戶可以通過這些資料庫來進行簡單的查詢和處理工作。比如，電商會使用傳統的關系型資料庫MySQL和Oracle等來存儲每一筆事務數據，除此之外，Redis和MongoDB這樣的NoSQL資料庫也常用於數據的採集。
在大數據的採集過程中，其主要特點和挑戰是並發數高，因為同時有可能會有成千上萬的用戶來進行訪問和操作，比如火車票售票網站和淘寶，它們並發的訪問量在峰值時達到上百萬，所以需要在採集端部署大量資料庫才能支撐。並且如何在這些資料庫之間進行負載均衡和分片的確是需要深入的思考和設計。
導入/預處理
雖然採集端本身會有很多資料庫，但是如果要對這些海量數據進行有效的分析，還是應該將這些來自前端的數據導入到一個集中的大型分布式資料庫，或者分布式存儲集群，並且可以在導入基礎上做一些簡單的清洗和預處理工作。也有一些用戶會在導入時使用來自Twitter的Storm來對數據進行流式計算，來滿足部分業務的實時計算需求。
導入與預處理過程的特點和挑戰主要是導入的數據量大，每秒鍾的導入量經常會達到百兆，甚至千兆級別。
統計/分析
統計與分析主要利用分布式資料庫，或者分布式計算集群來對存儲於其內的海量數據進行普通的分析和分類匯總等，以滿足大多數常見的分析需求，在這方面，一些實時性需求會用到EMC 的GreenPlum、Oracle的Exadata，以及基於MySQL的列式存儲Infobright等，而一些批處理，或者基於半結構化數據的需求可以使用Hadoop。
統計與分析這部分的主要特點和挑戰是分析涉及的數據量大，其對系統資源，特別是I/O會有極大的佔用。
挖掘
與前面統計和分析過程不同的是，數據挖掘一般沒有什麼預先設定好的主題，主要是在現有數據上面進行基於各種演算法的計算，從而起到預測（Predict）的效果，從而實現一些高級別數據分析的需求。比較典型演算法有用於聚類的K-Means、用於統計學習的SVM和用於分類的Naive Bayes，主要使用的工具有Hadoop的Mahout等。
-
『柒』 nosql資料庫的幾大類型
1. 鍵值資料庫
相關產品：Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached
應用：內容緩存
優點：擴展性好、靈活性好、大量寫操作時性能高
缺點：無法存儲結構化信息、條件查詢效率較低
使用者：網路雲（Redis）、GitHub（Riak）、BestBuy（Riak）、Twitter（Ridis和Memcached）
2. 列族資料庫
相關產品：BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS
應用：分布式數據存儲與管理
優點：查找速度快、可擴展性強、容易進行分布式擴展、復雜性低
使用者：Ebay（Cassandra）、Instagram（Cassandra）、NASA（Cassandra）、Facebook（HBase）
3. 文檔資料庫
相關產品：MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit
應用：存儲、索引並管理面向文檔的數據或者類似的半結構化數據
優點：性能好、靈活性高、復雜性低、數據結構靈活
缺點：缺乏統一的查詢語言
使用者：網路雲資料庫（MongoDB）、SAP（MongoDB）
4. 圖形資料庫
圖形資料庫-使用圖作為數據模型來存儲數據。
相關產品：Neo4J、OrientDB、InfoGrid、GraphDB
應用：大量復雜、互連接、低結構化的圖結構場合，如社交網路、推薦系統等
優點：靈活性高、支持復雜的圖形演算法、可用於構建復雜的關系圖譜
缺點：復雜性高、只能支持一定的數據規模
使用者：Adobe（Neo4J）、Cisco（Neo4J）、T-Mobile（Neo4J）