大數(shù)據(jù)本身做不了什么。我們通過大數(shù)據(jù)主要發(fā)現(xiàn)和處理一些問題！需要學(xué)習(xí)數(shù)理統(tǒng)計(jì)的知識(shí)！如回歸，相關(guān)，建模等！
東源網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站開發(fā)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)建站成立于2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
隨著大數(shù)據(jù)分析市場(chǎng)迅速擴(kuò)展，哪些技術(shù)是最有需求和最有增長潛力的呢？在Forrester Research的一份最新研究報(bào)告中，評(píng)估了22種技術(shù)在整個(gè)數(shù)據(jù)生命周期中的成熟度和軌跡。這些技術(shù)都對(duì)大數(shù)據(jù)的實(shí)時(shí)、預(yù)測(cè)和綜合洞察有著巨大的貢獻(xiàn)。
1. 預(yù)測(cè)分析技術(shù)
這也是大數(shù)據(jù)的主要功能之一。預(yù)測(cè)分析允許公司通過分析大數(shù)據(jù)源來發(fā)現(xiàn)、評(píng)估、優(yōu)化和部署預(yù)測(cè)模型，從而提高業(yè)務(wù)性能或降低風(fēng)險(xiǎn)。同時(shí)，大數(shù)據(jù)的預(yù)測(cè)分析也與我們的生活息息相關(guān)。淘寶會(huì)預(yù)測(cè)你每次購物可能還想買什么，愛奇藝正在預(yù)測(cè)你可能想看什么，百合網(wǎng)和其他約會(huì)網(wǎng)站甚至試圖預(yù)測(cè)你會(huì)愛上誰……
2. NoSQL數(shù)據(jù)庫
NoSQL，Not Only SQL，意思是“不僅僅是SQL”，泛指非關(guān)系型數(shù)據(jù)庫。NoSQL數(shù)據(jù)庫提供了比關(guān)系數(shù)據(jù)庫更靈活、可伸縮和更便宜的替代方案，打破了傳統(tǒng)數(shù)據(jù)庫市場(chǎng)一統(tǒng)江山的格局。并且，NoSQL數(shù)據(jù)庫能夠更好地處理大數(shù)據(jù)應(yīng)用的需求。常見的NoSQL數(shù)據(jù)庫有HBase、Redis、MongoDB、Couchbase、LevelDB等。
3. 搜索和知識(shí)發(fā)現(xiàn)
支持來自于多種數(shù)據(jù)源(如文件系統(tǒng)、數(shù)據(jù)庫、流、api和其他平臺(tái)和應(yīng)用程序)中的大型非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)庫中自助提取信息的工具和技術(shù)。如，數(shù)據(jù)挖掘技術(shù)和各種大數(shù)據(jù)平臺(tái)。
4. 大數(shù)據(jù)流計(jì)算引擎
能夠過濾、聚合、豐富和分析來自多個(gè)完全不同的活動(dòng)數(shù)據(jù)源的數(shù)據(jù)的高吞吐量的框架，可以采用任何數(shù)據(jù)格式?，F(xiàn)今流行的流式計(jì)算引擎有Spark Streaming和Flink。
5. 內(nèi)存數(shù)據(jù)結(jié)構(gòu)
通過在分布式計(jì)算機(jī)系統(tǒng)中動(dòng)態(tài)隨機(jī)訪問內(nèi)存(DRAM)、閃存或SSD上分布數(shù)據(jù)，提供低延遲的訪問和處理大量數(shù)據(jù)。
6. 分布式文件存儲(chǔ)
為了保證文件的可靠性和存取性能，數(shù)據(jù)通常以副本的方式存儲(chǔ)在多個(gè)節(jié)點(diǎn)上的計(jì)算機(jī)網(wǎng)絡(luò)。常見的分布式文件系統(tǒng)有GFS、HDFS、Lustre 、Ceph等。
7. 數(shù)據(jù)虛擬化
數(shù)據(jù)虛擬化是一種數(shù)據(jù)管理方法，它允許應(yīng)用程序檢索和操作數(shù)據(jù)，而不需要關(guān)心有關(guān)數(shù)據(jù)的技術(shù)細(xì)節(jié)，比如數(shù)據(jù)在源文件中是何種格式，或者數(shù)據(jù)存儲(chǔ)的物理位置，并且可以提供單個(gè)客戶用戶視圖。
8. 數(shù)據(jù)集成
用于跨解決方案進(jìn)行數(shù)據(jù)編排的工具，如Amazon Elastic MapReduce (EMR)、Apache Hive、Apache Pig、Apache Spark、MapReduce、Couchbase、Hadoop和MongoDB等。
9. 數(shù)據(jù)準(zhǔn)備
減輕采購、成形、清理和共享各種雜亂數(shù)據(jù)集的負(fù)擔(dān)的軟件，以加速數(shù)據(jù)對(duì)分析的有用性。
10. 數(shù)據(jù)質(zhì)量
使用分布式數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)庫上的并行操作，對(duì)大型高速數(shù)據(jù)集進(jìn)行數(shù)據(jù)清理和充實(shí)的產(chǎn)品。
大數(shù)據(jù)技術(shù)龐大復(fù)雜，基礎(chǔ)的技術(shù)包含數(shù)據(jù)的采集、數(shù)據(jù)預(yù)處理、分布式存儲(chǔ)、NoSQL數(shù)據(jù)庫、數(shù)據(jù)倉庫、機(jī)器學(xué)習(xí)、并行計(jì)算、可視化等范疇
查詢引擎：Phoenix、Shark、Pig、Hive等
流式計(jì)算：storm、Twitter Rainbird等
迭代計(jì)算：Apache Hama、Apache Giraph、HaLoop等
離線計(jì)算：Hadoop MapReduce、Berkeley Spark等
鍵值存儲(chǔ)：LevelDB、RocksDB、HyperDex、Voldemort等
表格存儲(chǔ)：OceanBase、Amazon SimpleDB、Cassandra、HBase等
文件存儲(chǔ)：CouchDB、MongoDB、HDFS等
資源管理：Twitter Mesos、Hadoop Yarn
zookeeper和eureka的區(qū)別：
CAP 原則又稱 CAP 定理，1998年，加州大學(xué)的計(jì)算機(jī)科學(xué)家 Eric Brewer 提出的，指的是在一個(gè)分布式系統(tǒng)中，Consistency（一致性）、?Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可兼得（我們常說的魚和熊掌不可兼得）。CAP 原則也是 NoSQL 數(shù)據(jù)庫的基石。
1、一致性（Consistency，C）：
在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。（等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本）。
2、可用性（Availability，A）：
在一個(gè)分布式系統(tǒng)的集群中一部分節(jié)點(diǎn)故障后，該集群是否還能夠正常響應(yīng)客戶端的讀寫請(qǐng)求。（對(duì)數(shù)據(jù)更新具備高可用性）。
3、分區(qū)容錯(cuò)性（Partition tolerance，P）：
大多數(shù)的分布式系統(tǒng)都分布在多個(gè)子網(wǎng)絡(luò)中，而每個(gè)子網(wǎng)絡(luò)就叫做一個(gè)區(qū)（partition）。分區(qū)容錯(cuò)的意思是，區(qū)間通信可能失敗。
比如阿里巴巴的服務(wù)器，一臺(tái)服務(wù)器放在上海，另一臺(tái)服務(wù)器放在北京，這就是兩個(gè)區(qū)，它們之間可能存在無法通信的情況。在一個(gè)分布式系統(tǒng)中一般分區(qū)容錯(cuò)是無法避免的，因此可以認(rèn)為 CAP 中的 P 總是成立的。CAP 理論告訴我們，在 C 和 A 之間是無法同時(shí)做到。
zookeeper和eureka的區(qū)別：
Spring Cloud Eureka? - AP
Spring Cloud Netflix 在設(shè)計(jì) Eureka 時(shí)就緊遵AP原則。Eureka Server 也可以運(yùn)行多個(gè)實(shí)例來構(gòu)建集群，解決單點(diǎn)問題，但不同于 ZooKeeper 的選舉 leader 的過程，Eureka Server 采用的是Peer to Peer 對(duì)等通信。
這是一種去中心化的架構(gòu)，無 master/slave 之分，每一個(gè) Peer 都是對(duì)等的。在這種架構(gòu)風(fēng)格中，節(jié)點(diǎn)通過彼此互相注冊(cè)來提高可用性，每個(gè)節(jié)點(diǎn)需要添加一個(gè)或多個(gè)有效的 serviceUrl 指向其他節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)都可被視為其他節(jié)點(diǎn)的副本。
在集群環(huán)境中如果某臺(tái) Eureka Server 宕機(jī)，Eureka Client 的請(qǐng)求會(huì)自動(dòng)切換到新的 Eureka Server 節(jié)點(diǎn)上，當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后，Eureka 會(huì)再次將其納入到服務(wù)器集群管理之中。
當(dāng)節(jié)點(diǎn)開始接受客戶端請(qǐng)求時(shí)，所有的操作都會(huì)在節(jié)點(diǎn)間進(jìn)行復(fù)制操作，將請(qǐng)求復(fù)制到該 Eureka Server 當(dāng)前所知的其它所有節(jié)點(diǎn)中。
當(dāng)一個(gè)新的 Eureka Server 節(jié)點(diǎn)啟動(dòng)后，會(huì)首先嘗試從鄰近節(jié)點(diǎn)獲取所有注冊(cè)列表信息，并完成初始化。Eureka Server 通過 getEurekaServiceUrls方法獲取所有的節(jié)點(diǎn)，并且會(huì)通過心跳契約的方式定期更新。
默認(rèn)情況下，如果 Eureka Server 在一定時(shí)間內(nèi)沒有接收到某個(gè)服務(wù)實(shí)例的心跳，Eureka Server 將會(huì)注銷該實(shí)例。當(dāng) Eureka Server 節(jié)點(diǎn)在短時(shí)間內(nèi)丟失過多的心跳時(shí)，那么這個(gè)節(jié)點(diǎn)就會(huì)進(jìn)入自我保護(hù)模式。
Apache Zookeeper - CP
與 Eureka 有所不同，Apache Zookeeper 在設(shè)計(jì)時(shí)就緊遵CP原則，即任何時(shí)候?qū)ookeeper 的訪問請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分割具備容錯(cuò)性，但是 Zookeeper 不能保證每次服務(wù)請(qǐng)求都是可達(dá)的。
從 Zookeeper 的實(shí)際應(yīng)用情況來看，在使用 Zookeeper 獲取服務(wù)列表時(shí)，如果此時(shí)的 Zookeeper 集群中的 Leader 宕機(jī)了，該集群就要進(jìn)行 Leader 的選舉，又或者 Zookeeper 集群中半數(shù)以上服務(wù)器節(jié)點(diǎn)不可用，那么將無法處理該請(qǐng)求。所以說，Zookeeper 不能保證服務(wù)可用性。
當(dāng)然，在大多數(shù)分布式環(huán)境中，尤其是涉及到數(shù)據(jù)存儲(chǔ)的場(chǎng)景，數(shù)據(jù)一致性應(yīng)該是首先被保證的，這也是 Zookeeper 設(shè)計(jì)緊遵CP原則的另一個(gè)原因。
但是對(duì)于服務(wù)發(fā)現(xiàn)來說，情況就不太一樣了，針對(duì)同一個(gè)服務(wù)，即使注冊(cè)中心的不同節(jié)點(diǎn)保存的服務(wù)提供者信息不盡相同，也并不會(huì)造成災(zāi)難性的后果。
因?yàn)閷?duì)于服務(wù)消費(fèi)者來說，能消費(fèi)才是最重要的，消費(fèi)者雖然拿到可能不正確的服務(wù)實(shí)例信息后嘗試消費(fèi)一下，也要?jiǎng)龠^因?yàn)闊o法獲取實(shí)例信息而不去消費(fèi)，導(dǎo)致系統(tǒng)異常要好
重慶分公司
重慶分公司
