NoSQL薄弱的安全性會(huì)給企業(yè)帶來(lái)負(fù)面影響 。Imperva公司創(chuàng)始人兼CTO Amichai Shulman如是說(shuō)。在新的一年中，無(wú)疑會(huì)有更多企業(yè)開(kāi)始或籌劃部署NoSQL。方案落實(shí)后就會(huì)逐漸發(fā)現(xiàn)種種安全問(wèn)題，因此早做準(zhǔn)備才是正確的選擇。 作為傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的替代方案，NoSQL在查詢中并不使用SQL語(yǔ)言，而且允許用戶隨時(shí)變更數(shù)據(jù)屬性。此類數(shù)據(jù)庫(kù)以擴(kuò)展性良好著稱，并能夠在需要大量應(yīng)用程序與數(shù)據(jù)庫(kù)本身進(jìn)行實(shí)時(shí)交互的交易處理任務(wù)中發(fā)揮性能優(yōu)勢(shì)，Couchbase創(chuàng)始人兼產(chǎn)品部門高級(jí)副總裁James Phillips解釋稱：NoSQL以交易業(yè)務(wù)為核心。它更注重實(shí)時(shí)處理能力并且擅長(zhǎng)直接對(duì)數(shù)據(jù)進(jìn)行操作，大幅度促進(jìn)了交互型軟件系統(tǒng)的發(fā)展。Phillips指出。其中最大的優(yōu)勢(shì)之一是能夠隨時(shí)改變(在屬性方面)，由于結(jié)構(gòu)性的弱化，修改過(guò)程非常便捷。 NoSQL最大優(yōu)勢(shì)影響其安全性 NoSQL的關(guān)鍵性特色之一是其動(dòng)態(tài)的數(shù)據(jù)模型，Shulman解釋道。我可以在其運(yùn)作過(guò)程中加入新的屬性記錄。因此與這種結(jié)構(gòu)相匹配的安全模型必須具備一定的前瞻性規(guī)劃。也就是說(shuō)，它必須能夠了解數(shù)據(jù)庫(kù)引入的新屬性將引發(fā)哪些改變，以及新加入的屬性擁有哪些權(quán)限。然而這個(gè)層面上的安全概念目前尚不存在，根本沒(méi)有這樣的解決方案。 根據(jù)Phillips的說(shuō)法，某些NoSQL開(kāi)發(fā)商已經(jīng)開(kāi)始著手研發(fā)安全機(jī)制，至少在嘗試保護(hù)數(shù)據(jù)的完整性。在關(guān)系型數(shù)據(jù)庫(kù)領(lǐng)域，如果我們的數(shù)據(jù)組成不正確，那么它將無(wú)法與結(jié)構(gòu)并行運(yùn)作，換言之?dāng)?shù)據(jù)插入操作整體將宣告失敗。目前各種驗(yàn)證規(guī)則與完整性檢查已經(jīng)比較完善，而事實(shí)證明這些驗(yàn)證機(jī)制都能在NoSQL中發(fā)揮作用。我們與其他人所推出的解決方案類似，都會(huì)在插入一條新記錄或是文檔型規(guī)則時(shí)觸發(fā)，并在執(zhí)行過(guò)程中確保插入數(shù)據(jù)的正確性。 Shulman預(yù)計(jì)新用戶很快將在配置方面捅出大婁子，這并非因?yàn)镮T工作人員的玩忽職守，實(shí)際上主要原因是NoSQL作為一項(xiàng)新技術(shù)導(dǎo)致大多數(shù)人對(duì)其缺乏足夠的知識(shí)基礎(chǔ)。Application Security研發(fā)部門TeamSHATTER的經(jīng)理Alex Rothacker對(duì)上述觀點(diǎn)表示贊同。他指出，培訓(xùn)的一大問(wèn)題在于，大多數(shù)NoSQL的從業(yè)者往往屬于新生代IT人士，他們對(duì)于技術(shù)了解較多，但往往缺乏足夠的安全管理經(jīng)驗(yàn)。 如果他們從傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)入手，那么由于強(qiáng)制性安全機(jī)制的完備，他們可以在使用中學(xué)習(xí)。但NoSQL，只有行家才能通過(guò)觀察得出正確結(jié)論，并在大量研究工作后找到一套完備的安全解決方案。因此可能有90%的從業(yè)者由于知識(shí)儲(chǔ)備、安全經(jīng)驗(yàn)或是工作時(shí)間的局限而無(wú)法做到這一點(diǎn)。 NoSQL需在安全性方面進(jìn)行優(yōu)化 盡管Phillips認(rèn)同新技術(shù)與舊經(jīng)驗(yàn)之間存在差異，但企業(yè)在推廣NoSQL時(shí)加大對(duì)安全性的關(guān)注會(huì)起到很大程度的積極作用。他認(rèn)為此類數(shù)據(jù)存儲(chǔ)機(jī)制與傳統(tǒng)關(guān)系類數(shù)據(jù)庫(kù)相比，其中包含著的敏感類信息更少，而且與企業(yè)網(wǎng)絡(luò)內(nèi)部其它應(yīng)用程序的接觸機(jī)會(huì)也小得多。 他們并不把這項(xiàng)新技術(shù)完全當(dāng)成數(shù)據(jù)庫(kù)使用，正如我們?cè)谑占泶罅縼?lái)自其它應(yīng)用程序的業(yè)務(wù)類數(shù)據(jù)時(shí)，往往也會(huì)考慮將其作為企業(yè)數(shù)據(jù)存儲(chǔ)機(jī)制一樣，他補(bǔ)充道。當(dāng)然，如果我打算研發(fā)一套具備某種特定功能的社交網(wǎng)絡(luò)、社交游戲或是某種特殊web應(yīng)用程序，也很可能會(huì)將其部署于防火墻之下。這樣一來(lái)它不僅與應(yīng)用程序緊密結(jié)合，也不會(huì)被企業(yè)中的其它部門所觸及。 但Rothacker同時(shí)表示，這種過(guò)度依賴周邊安全機(jī)制的數(shù)據(jù)庫(kù)系統(tǒng)也存在著極其危險(xiǎn)的漏洞。一旦系統(tǒng)完全依附于周邊安全模型，那么驗(yàn)證機(jī)制就必須相對(duì)薄弱，而且缺乏多用戶管理及數(shù)據(jù)訪問(wèn)方面的安全保護(hù)。只要擁有高權(quán)限賬戶，我們幾乎能訪問(wèn)存儲(chǔ)機(jī)制中的一切數(shù)據(jù)。舉例來(lái)說(shuō)，Brian Sullivan就在去年的黑帽大會(huì)上演示了如何在完全不清楚數(shù)據(jù)具體內(nèi)容的情況下，將其信息羅列出來(lái)甚至導(dǎo)出。 而根據(jù)nCircle公司CTO Tim ‘TK’ Keanini的觀點(diǎn)，即使是與有限的應(yīng)用程序相關(guān)聯(lián)，NoSQL也很有可能被暴露在互聯(lián)網(wǎng)上。在缺少嚴(yán)密網(wǎng)絡(luò)劃分的情況下，它可能成為攻擊者窺探存儲(chǔ)數(shù)據(jù)的薄弱環(huán)節(jié)。因?yàn)镹oSQL在設(shè)計(jì)上主要用于互聯(lián)網(wǎng)規(guī)模的部署，所以它很可能被直接連接到互聯(lián)網(wǎng)中，進(jìn)而面臨大量攻擊行為。 其中發(fā)生機(jī)率最高的攻擊行為就是注入式攻擊，這也是一直以來(lái)肆虐于關(guān)系類數(shù)據(jù)庫(kù)領(lǐng)域的頭號(hào)公敵。盡管NoSQL沒(méi)有將SQL作為查詢語(yǔ)言，也并不代表它能夠免受注入式攻擊的威脅。雖然不少人宣稱SQL注入在NoSQL這邊不起作用，但其中的原理是完全一致的。攻擊者需要做的只是改變自己注入內(nèi)容的語(yǔ)法形式，Rothacker解釋稱。也就是說(shuō)雖然SQL注入不會(huì)出現(xiàn)，但JavaScript注入或者JSON注入同樣能威脅安全。 此外，攻擊者在籌劃對(duì)這類數(shù)據(jù)庫(kù)展開(kāi)侵襲時(shí)，也很可能進(jìn)一步優(yōu)化自己的工具。不成熟的安全技術(shù)往往帶來(lái)這樣的窘境：需要花費(fèi)大量時(shí)間學(xué)習(xí)如何保障其安全，但幾乎每個(gè)IT人士都能迅速掌握攻擊活動(dòng)的組織方法。因此我認(rèn)為攻擊者將會(huì)始終走在安全部署的前面，Shulman說(shuō)道。遺憾的是搞破壞總比防范工作更容易，而我們已經(jīng)看到不少NoSQL技術(shù)方面的公開(kāi)漏洞，尤其是目前引起熱議的、以JSON注入為載體的攻擊方式。 NoSQL安全性并非其阻礙 然而，這一切都不應(yīng)該成為企業(yè)使用NoSQL的阻礙，他總結(jié)道。我認(rèn)為歸根結(jié)底，這應(yīng)該算是企業(yè)的一種商業(yè)決策。只要這種選擇能夠帶來(lái)吸引力巨大的商業(yè)機(jī)遇，就要承擔(dān)一定風(fēng)險(xiǎn)，Shulman解釋道。但應(yīng)該采取一定措施以盡量弱化這種風(fēng)險(xiǎn)。 舉例來(lái)說(shuō)，鑒于數(shù)據(jù)庫(kù)對(duì)外部安全機(jī)制的依賴性，Rothacker建議企業(yè)積極考慮引入加密方案。他警告稱，企業(yè)必須對(duì)與NoSQL相對(duì)接的應(yīng)用程序代碼仔細(xì)檢查。換言之，企業(yè)必須嚴(yán)格挑選負(fù)責(zé)此類項(xiàng)目部署的人選，確保將最好的人才用于這方面事務(wù)，Shulman表示。當(dāng)大家以NoSQL為基礎(chǔ)編寫應(yīng)用程序時(shí)，必須啟用有經(jīng)驗(yàn)的編程人員，因?yàn)榭蛻舳塑浖堑謸醢踩珕?wèn)題的第一道屏障。切實(shí)為額外緩沖區(qū)的部署留出時(shí)間與預(yù)算，這能夠讓員工有閑暇反思自己的工作內(nèi)容并盡量多顧及安全考量多想一點(diǎn)就是進(jìn)步。綜上所述，這可能與部署傳統(tǒng)的關(guān)系類數(shù)據(jù)庫(kù)也沒(méi)什么不同。 具有諷刺意味的是，近年來(lái)數(shù)據(jù)庫(kù)應(yīng)用程序在安全性方面的提升基本都跟數(shù)據(jù)庫(kù)本身沒(méi)什么關(guān)系，nCircle公司安全研究及開(kāi)發(fā)部門總監(jiān)Oliver Lavery如是說(shuō)。
我們擁有十載網(wǎng)頁(yè)設(shè)計(jì)和網(wǎng)站建設(shè)經(jīng)驗(yàn)，從網(wǎng)站策劃到網(wǎng)站制作，我們的網(wǎng)頁(yè)設(shè)計(jì)師為您提供的解決方案。為企業(yè)提供網(wǎng)站設(shè)計(jì)制作、網(wǎng)站設(shè)計(jì)、微信開(kāi)發(fā)、小程序定制開(kāi)發(fā)、手機(jī)網(wǎng)站開(kāi)發(fā)、H5開(kāi)發(fā)、等業(yè)務(wù)。無(wú)論您有什么樣的網(wǎng)站設(shè)計(jì)或者設(shè)計(jì)方案要求，我們都將富于創(chuàng)造性的提供專業(yè)設(shè)計(jì)服務(wù)并滿足您的需求。
大數(shù)據(jù)專業(yè)全稱“大數(shù)據(jù)采集與管理專業(yè)”。
大數(shù)據(jù)采集與管理專業(yè)是從大數(shù)據(jù)應(yīng)用的數(shù)據(jù)管理、系統(tǒng)開(kāi)發(fā)、海量數(shù)據(jù)分析與挖掘等層面系統(tǒng)地幫助企業(yè)掌握大數(shù)據(jù)應(yīng)用中的各種典型問(wèn)題的解決辦法的專業(yè)。
1、行業(yè)現(xiàn)狀：現(xiàn)在越來(lái)越多的行業(yè)對(duì)大數(shù)據(jù)應(yīng)用持樂(lè)觀的態(tài)度，大數(shù)據(jù)或者相關(guān)數(shù)據(jù)分析解決方案的使用在互聯(lián)網(wǎng)行業(yè)，比如百度、騰訊、淘寶、新浪等公司已經(jīng)成為標(biāo)準(zhǔn)。而像電信、金融、能源這些傳統(tǒng)行業(yè)，越來(lái)越多的用戶開(kāi)始嘗試或者考慮怎么樣使用大數(shù)據(jù)解決方案，來(lái)提升自己的業(yè)務(wù)水平。
2、課程設(shè)置：大數(shù)據(jù)專業(yè)將從大數(shù)據(jù)應(yīng)用的三個(gè)主要層面（即數(shù)據(jù)管理、系統(tǒng)開(kāi)發(fā)、海量數(shù)據(jù)分析與挖掘）系統(tǒng)地幫助企業(yè)掌握大數(shù)據(jù)應(yīng)用中的各種典型問(wèn)題的解決辦法，包括實(shí)現(xiàn)和分析協(xié)同過(guò)濾算法、運(yùn)行和學(xué)習(xí)分類算法、分布式Hadoop集群的搭建和基準(zhǔn)測(cè)試、分布式Hbase集群的搭建和基準(zhǔn)測(cè)試、實(shí)現(xiàn)一個(gè)基于、Mapreduce的并行算法、部署Hive并實(shí)現(xiàn)一個(gè)的數(shù)據(jù)操作等等，實(shí)際提升企業(yè)解決實(shí)際問(wèn)題的能力。
3、核心技術(shù)：
（1）大數(shù)據(jù)與Hadoop生態(tài)系統(tǒng)。詳細(xì)介紹分析分布式文件系統(tǒng)HDFS、集群文件系統(tǒng)ClusterFS和NoSQL Database技術(shù)的原理與應(yīng)用；分布式計(jì)算框架Mapreduce、分布式數(shù)據(jù)庫(kù)HBase、分布式數(shù)據(jù)倉(cāng)庫(kù)Hive。
（2）關(guān)系型數(shù)據(jù)庫(kù)技術(shù)。詳細(xì)介紹關(guān)系型數(shù)據(jù)庫(kù)的原理，掌握典型企業(yè)級(jí)數(shù)據(jù)庫(kù)的構(gòu)建、管理、開(kāi)發(fā)及應(yīng)用。
（3）分布式數(shù)據(jù)處理。詳細(xì)介紹分析Map/Reduce計(jì)算模型和Hadoop Map/Reduce技術(shù)的原理與應(yīng)用。
（4）海量數(shù)據(jù)分析與數(shù)據(jù)挖掘。詳細(xì)介紹數(shù)據(jù)挖掘技術(shù)、數(shù)據(jù)挖掘算法–Minhash, Jaccard and Cosine similarity，TF-IDF數(shù)據(jù)挖掘算法–聚類算法；以及數(shù)據(jù)挖掘技術(shù)在行業(yè)中的具體應(yīng)用。
（5）物聯(lián)網(wǎng)與大數(shù)據(jù)。詳細(xì)介紹物聯(lián)網(wǎng)中的大數(shù)據(jù)應(yīng)用、遙感圖像的自動(dòng)解譯、時(shí)間序列數(shù)據(jù)的查詢、分析和挖掘。
（6）文件系統(tǒng)（HDFS）。詳細(xì)介紹HDFS部署，基于HDFS的高性能提供高吞吐量的數(shù)據(jù)訪問(wèn)。
（7）NoSQL。詳細(xì)介紹NoSQL非關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)的原理、架構(gòu)及典型應(yīng)用。
點(diǎn)擊上方 藍(lán)色字體 ，選擇“置頂公眾號(hào)”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
鏈接 | blog.csdn.net/hayre/article/details/80628431
1.MongoDB是什么？用一句話總結(jié)
MongoDB是一款為web應(yīng)用程序和互聯(lián)網(wǎng)基礎(chǔ)設(shè)施設(shè)計(jì)的數(shù)據(jù)庫(kù)管理系統(tǒng)。沒(méi)錯(cuò)MongoDB就是數(shù)據(jù)庫(kù)，是NoSQL類型的數(shù)據(jù)庫(kù)。
（1）MongoDB提出的是文檔、集合的概念，使用BSON（類JSON）作為其數(shù)據(jù)模型結(jié)構(gòu)，其結(jié)構(gòu)是面向?qū)ο蟮亩皇嵌S表，存儲(chǔ)一個(gè)用戶在MongoDB中是這樣子的。
使用這樣的數(shù)據(jù)模型，使得MongoDB能在生產(chǎn)環(huán)境中提供高讀寫的能力，吞吐量較于mysql等SQL數(shù)據(jù)庫(kù)大大增強(qiáng)。
（2）易伸縮，自動(dòng)故障轉(zhuǎn)移。易伸縮指的是提供了分片能力，能對(duì)數(shù)據(jù)集進(jìn)行分片，數(shù)據(jù)的存儲(chǔ)壓力分?jǐn)偨o多臺(tái)服務(wù)器。自動(dòng)故障轉(zhuǎn)移是副本集的概念，MongoDB能檢測(cè)主節(jié)點(diǎn)是否存活，當(dāng)失活時(shí)能自動(dòng)提升從節(jié)點(diǎn)為主節(jié)點(diǎn)，達(dá)到故障轉(zhuǎn)移。
（3）數(shù)據(jù)模型因?yàn)槭敲嫦驅(qū)ο蟮?，所以可以表示豐富的、有層級(jí)的數(shù)據(jù)結(jié)構(gòu)，比如博客系統(tǒng)中能把“評(píng)論”直接懟到“文章“的文檔中，而不必像myqsl一樣創(chuàng)建三張表來(lái)描述這樣的關(guān)系。
3.主要特性
（1）文檔數(shù)據(jù)類型
SQL類型的數(shù)據(jù)庫(kù)是正規(guī)化的，可以通過(guò)主鍵或者外鍵的約束保證數(shù)據(jù)的完整性與唯一性，所以SQL類型的數(shù)據(jù)庫(kù)常用于對(duì)數(shù)據(jù)完整性較高的系統(tǒng)。MongoDB在這一方面是不如SQL類型的數(shù)據(jù)庫(kù)，且MongoDB沒(méi)有固定的Schema，正因?yàn)镸ongoDB少了一些這樣的約束條件，可以讓數(shù)據(jù)的存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)更靈活，存儲(chǔ)速度更加快。 （2）即時(shí)查詢能力
MongoDB保留了關(guān)系型數(shù)據(jù)庫(kù)即時(shí)查詢的能力，保留了索引（底層是基于B tree）的能力。這一點(diǎn)汲取了關(guān)系型數(shù)據(jù)庫(kù)的優(yōu)點(diǎn)，相比于同類型的NoSQL redis 并沒(méi)有上述的能力。 （3）復(fù)制能力
MongoDB自身提供了副本集能將數(shù)據(jù)分布在多臺(tái)機(jī)器上實(shí)現(xiàn)冗余，目的是可以提供自動(dòng)故障轉(zhuǎn)移、擴(kuò)展讀能力。 （4）速度與持久性
MongoDB的驅(qū)動(dòng)實(shí)現(xiàn)一個(gè)寫入語(yǔ)義 fire and forget ，即通過(guò)驅(qū)動(dòng)調(diào)用寫入時(shí)，可以立即得到返回得到成功的結(jié)果（即使是報(bào)錯(cuò)），這樣讓寫入的速度更加快，當(dāng)然會(huì)有一定的不安全性，完全依賴網(wǎng)絡(luò)。
MongoDB提供了Journaling日志的概念，實(shí)際上像mysql的bin-log日志，當(dāng)需要插入的時(shí)候會(huì)先往日志里面寫入記錄，再完成實(shí)際的數(shù)據(jù)操作，這樣如果出現(xiàn)停電，進(jìn)程突然中斷的情況，可以保障數(shù)據(jù)不會(huì)錯(cuò)誤，可以通過(guò)修復(fù)功能讀取Journaling日志進(jìn)行修復(fù)。
（5）數(shù)據(jù)擴(kuò)展
MongoDB使用分片技術(shù)對(duì)數(shù)據(jù)進(jìn)行擴(kuò)展，MongoDB能自動(dòng)分片、自動(dòng)轉(zhuǎn)移分片里面的數(shù)據(jù)塊，讓每一個(gè)服務(wù)器里面存儲(chǔ)的數(shù)據(jù)都是一樣大小。
MongoDB核心服務(wù)器主要是通過(guò)mongod程序啟動(dòng)的，而且在啟動(dòng)時(shí)不需對(duì)MongoDB使用的內(nèi)存進(jìn)行配置，因?yàn)槠湓O(shè)計(jì)哲學(xué)是內(nèi)存管理最好是交給操作系統(tǒng)，缺少內(nèi)存配置是MongoDB的設(shè)計(jì)亮點(diǎn)，另外，還可通過(guò)mongos路由服務(wù)器使用分片功能。
MongoDB的主要客戶端是可以交互的js shell 通過(guò)mongo啟動(dòng)，使用js shell能使用js直接與MongoDB進(jìn)行交流，像使用sql語(yǔ)句查詢mysql數(shù)據(jù)一樣使用js語(yǔ)法查詢MongoDB的數(shù)據(jù)，另外還提供了各種語(yǔ)言的驅(qū)動(dòng)包，方便各種語(yǔ)言的接入。
mongodump和mongorestore,備份和恢復(fù)數(shù)據(jù)庫(kù)的標(biāo)準(zhǔn)工具。輸出BSON格式，遷移數(shù)據(jù)庫(kù)。
mongoexport和mongoimport，用來(lái)導(dǎo)入導(dǎo)出JSON、CSV和TSV數(shù)據(jù)，數(shù)據(jù)需要支持多格式時(shí)有用。mongoimport還能用與大數(shù)據(jù)集的初始導(dǎo)入，但是在導(dǎo)入前順便還要注意一下，為了能充分利用好mongoDB通常需要對(duì)數(shù)據(jù)模型做一些調(diào)整。
mongosniff,網(wǎng)絡(luò)嗅探工具，用來(lái)觀察發(fā)送到數(shù)據(jù)庫(kù)的操作。基本就是把網(wǎng)絡(luò)上傳輸?shù)腂SON轉(zhuǎn)換為易于人們閱讀的shell語(yǔ)句。
因此，可以總結(jié)得到，MongoDB結(jié)合鍵值存儲(chǔ)和關(guān)系數(shù)據(jù)庫(kù)的最好特性。因?yàn)楹?jiǎn)單，所以數(shù)據(jù)極快，而且相對(duì)容易伸縮還提供復(fù)雜查詢機(jī)制的數(shù)據(jù)庫(kù)。MongoDB需要跑在64位的服務(wù)器上面，且最好單獨(dú)部署，因?yàn)槭菙?shù)據(jù)庫(kù)，所以也需要對(duì)其進(jìn)行熱備、冷備處理。
因?yàn)楸酒恼虏皇茿PI手冊(cè)，所有這里對(duì)shell的使用也是基礎(chǔ)的介紹什么功能可以用什么語(yǔ)句，主要是為了展示使用MongoDB shell的方便性，如果需要知道具體的MongoDB shell語(yǔ)法可以查閱官方文檔。
創(chuàng)建數(shù)據(jù)庫(kù)并不是必須的操作，數(shù)據(jù)庫(kù)與集合只有在第一次插入文檔時(shí)才會(huì)被創(chuàng)建，與對(duì)數(shù)據(jù)的動(dòng)態(tài)處理方式是一致的。簡(jiǎn)化并加速開(kāi)發(fā)過(guò)程，而且有利于動(dòng)態(tài)分配命名空間。如果擔(dān)心數(shù)據(jù)庫(kù)或集合被意外創(chuàng)建，可以開(kāi)啟嚴(yán)格模式。
以上的命令只是簡(jiǎn)單實(shí)例，假設(shè)如果你之前沒(méi)有學(xué)習(xí)過(guò)任何數(shù)據(jù)庫(kù)語(yǔ)法，同時(shí)開(kāi)始學(xué)sql查詢語(yǔ)法和MongoDB 查詢語(yǔ)法，你會(huì)發(fā)現(xiàn)哪一個(gè)更簡(jiǎn)單呢？如果你使用的是java驅(qū)動(dòng)去操作MongoDB，你會(huì)發(fā)現(xiàn)任何的查詢都像Hibernate提供出來(lái)的查詢方式一樣，只要構(gòu)建好一個(gè)查詢條件對(duì)象，便能輕松查詢（接下來(lái)會(huì)給出示例），博主之前熟悉ES6，所以入手MongoDB js shell完成沒(méi)問(wèn)題，也正因?yàn)檫@樣簡(jiǎn)潔，完善的查詢機(jī)制，深深的愛(ài)上了MongoDB。
使用java驅(qū)動(dòng)鏈接MongoDB是一件非常簡(jiǎn)單的事情，簡(jiǎn)單的引用，簡(jiǎn)單的做增刪改查。在使用完java驅(qū)動(dòng)后我才發(fā)現(xiàn)spring 對(duì)MongoDB 的封裝還不如官方自身提供出來(lái)的東西好用，下面簡(jiǎn)單的展示一下使用。
這里只舉例了簡(jiǎn)單的鏈接與簡(jiǎn)單的MongoDB操作，可見(jiàn)其操作的容易性。使用驅(qū)動(dòng)時(shí)是基于TCP套接字與MongoDB進(jìn)行通信的，如果查詢結(jié)果較多，恰好無(wú)法全部放進(jìn)第一服務(wù)器中，將會(huì)向服務(wù)器發(fā)送一個(gè)getmore指令獲取下一批查詢結(jié)果。
插入數(shù)據(jù)到服務(wù)器時(shí)間，不會(huì)等待服務(wù)器的響應(yīng)，驅(qū)動(dòng)會(huì)假設(shè)寫入是成功的，實(shí)際是使用客戶端生成對(duì)象id，但是該行為可以通過(guò)配置配置，可以通過(guò)安全模式開(kāi)啟，安全模式可以校驗(yàn)服務(wù)器端插入的錯(cuò)誤。
要清楚了解MongoDB的基本數(shù)據(jù)單元。在關(guān)系型數(shù)據(jù)庫(kù)中有帶列和行的數(shù)據(jù)表。而MongoDB數(shù)據(jù)的基本單元是BSON文檔，在鍵值中有指向不定類型值的鍵，MongoDB擁有即時(shí)查詢，但不支持聯(lián)結(jié)操作，簡(jiǎn)單的鍵值存儲(chǔ)只能根據(jù)單個(gè)鍵來(lái)獲取值，不支持事務(wù)，但支持多種原子更新操作。
如讀寫比是怎樣的，需要何種查詢，數(shù)據(jù)是如何更新的，會(huì)不會(huì)存在什么并發(fā)問(wèn)題，數(shù)據(jù)結(jié)構(gòu)化的程度是要求高還是低。系統(tǒng)本身的需求決定mysql還是MongoDB。
在關(guān)于schema 的設(shè)計(jì)中要注意一些原則，比如：
數(shù)據(jù)庫(kù)是集合的邏輯與物理分組，MongoDB沒(méi)有提供創(chuàng)建數(shù)據(jù)庫(kù)的語(yǔ)法，只有在插入集合時(shí)，數(shù)據(jù)庫(kù)才開(kāi)始建立。創(chuàng)建數(shù)據(jù)庫(kù)后會(huì)在磁盤分配一組數(shù)據(jù)文件，所有集合、索引和數(shù)據(jù)庫(kù)的其他元數(shù)據(jù)都保存在這些文件中，查閱數(shù)據(jù)庫(kù)使用磁盤狀態(tài)可通過(guò)。
集合是結(jié)構(gòu)上或概念上相似得文檔的容器，集合的名稱可以包含數(shù)字、字母或 . 符號(hào)，但必須以字母或數(shù)字開(kāi)頭，完全。
限定集合名不能超過(guò)128個(gè)字符，實(shí)際上 . 符號(hào)在集合中很有用，能提供某種虛擬命名空間，這是一種組織上的原則，和其他集合是一視同仁的。在集合中可以使用。
其次是鍵值，在MongoDB里面所有的字符串都是UTF-8類型。數(shù)字類型包括double、int、long。日期類型都是UTC格式，所以在MongoDB里面看到的時(shí)間會(huì)比北京時(shí)間慢8小時(shí)。整個(gè)文檔大小會(huì)限制在16m以內(nèi)，因?yàn)檫@樣可以防止創(chuàng)建難看的數(shù)據(jù)類型，且小文檔可以提升性能，批量插入文檔理想數(shù)字范圍是10~200，大小不能超過(guò)16MB。
（2）解析查詢時(shí)MongoDB通過(guò)最優(yōu)計(jì)劃選擇一個(gè)索引進(jìn)行查詢，當(dāng)沒(méi)有最適合索引時(shí)，會(huì)先不同的使用各個(gè)索引進(jìn)行查詢，最終選出一個(gè)最優(yōu)索引做查詢
（3）如果有一個(gè)a-b的復(fù)合索引，那么僅針對(duì)a的索引是冗余的
（4）復(fù)合索引里的鍵的順序是很重要的
（2）復(fù)合索引
（3）唯一性索引
（4）稀疏索引
如索引的字段會(huì)出現(xiàn)的值，或是大量文檔都不包含被索引的鍵。
如果數(shù)據(jù)集很大時(shí)，構(gòu)建索引將會(huì)花費(fèi)很長(zhǎng)的時(shí)間，且會(huì)影響程序性能，可通過(guò)
當(dāng)使用 mongorestore 時(shí)會(huì)重新構(gòu)建索引。當(dāng)曾經(jīng)執(zhí)行過(guò)大規(guī)模的刪除時(shí)，可使用
對(duì)索引進(jìn)行壓縮，重建。
（1）查閱慢查詢?nèi)罩?/p>
（2）分析慢查詢
注意新版本的MongoDB 的explain方法是需要參數(shù)的，不然只顯示普通的信息。
本節(jié)同樣主要簡(jiǎn)單呈現(xiàn)MongoDB副本集搭建的簡(jiǎn)易性，與副本集的強(qiáng)壯性，監(jiān)控容易性
提供主從復(fù)制能力，熱備能力，故障轉(zhuǎn)移能力
實(shí)際上MongoDB對(duì)副本集的操作跟mysql主從操作是差不多的，先看一下mysql的主從數(shù)據(jù)流動(dòng)過(guò)程
而MongoDB主要依賴的日志文件是oplog
寫操作先被記錄下來(lái)，添加到主節(jié)點(diǎn)的oplog里。與此同時(shí)，所有從結(jié)點(diǎn)復(fù)制oplog。首先，查看自己oplog里最后一條的時(shí)間戳；其次，查詢主節(jié)點(diǎn)oplog里所有大于此時(shí)間戳的條目;最后，把那些條目添加到自己的oplog里并應(yīng)用到自己的庫(kù)里。從節(jié)點(diǎn)使用長(zhǎng)輪詢立即應(yīng)用來(lái)自主結(jié)點(diǎn)oplog的新條目。
當(dāng)遇到以下情況，從節(jié)點(diǎn)會(huì)停止復(fù)制
local數(shù)據(jù)庫(kù)保存了所有副本集元素?fù)?jù)和oplog日志
可以使用以下命令查看復(fù)制情況
每個(gè)副本集成員每秒鐘ping一次其他所有成員，可以通過(guò)rs.status看到節(jié)點(diǎn)上次的心跳檢測(cè)時(shí)間戳和 健康 狀況。
這個(gè)點(diǎn)沒(méi)必要過(guò)多描述，但是有一個(gè)特殊場(chǎng)景，如果從節(jié)點(diǎn)和仲裁節(jié)點(diǎn)都被殺了，只剩下主節(jié)點(diǎn)，他會(huì)把自己降級(jí)成為從節(jié)點(diǎn)。
如果主節(jié)點(diǎn)的數(shù)據(jù)還沒(méi)有寫到從庫(kù)，那么數(shù)據(jù)不能算提交，當(dāng)該主節(jié)點(diǎn)變成從節(jié)點(diǎn)時(shí)，便會(huì)觸發(fā)回滾，那些沒(méi)寫到從庫(kù)的數(shù)據(jù)將會(huì)被刪除，可以通過(guò)rollback子目錄中的BSON文件恢復(fù)回滾的內(nèi)容。
只能鏈接到主節(jié)點(diǎn)，如果鏈接到從節(jié)點(diǎn)的話，會(huì)被拒絕寫入操作，但是如果沒(méi)有使用安全模式，因?yàn)閙ongo的fire and forget 特性，會(huì)把拒絕寫入的異常給吃掉。
（2）使用副本集方式鏈接
能根據(jù)寫入的情況自動(dòng)進(jìn)行故障轉(zhuǎn)移，但是當(dāng)副本集進(jìn)行新的選舉時(shí)，還是會(huì)出現(xiàn)故障，如果不使用安全模式，依舊會(huì)出現(xiàn)寫不進(jìn)去，但現(xiàn)實(shí)成功的情況。
分片是數(shù)據(jù)庫(kù)切分的一個(gè)概念實(shí)現(xiàn)，這里也是簡(jiǎn)單總結(jié)為什么要使用分片以及分片的原理，操作。
當(dāng)數(shù)據(jù)量過(guò)大，索引和工作數(shù)據(jù)集占用的內(nèi)存就會(huì)越來(lái)越多，所以需要通過(guò)分片負(fù)載來(lái)解決這個(gè)問(wèn)題
（2）分片的核心操作
分片一個(gè)集合：分片是根據(jù)一個(gè)屬性的范圍進(jìn)行劃分的，MongoDB使用所謂的分片鍵讓每個(gè)文檔在這些范圍里找到自己的位置
塊：是位于一個(gè)分片中的一段連續(xù)的分片鍵范圍，可以理解為若干個(gè)塊組成分片，分片組成MongoDB的全部數(shù)據(jù)
（3）拆分與遷移
塊的拆分：初始化時(shí)只有一個(gè)塊，達(dá)到最大塊尺寸64MB或100000個(gè)文檔就會(huì)觸發(fā)塊的拆分。把原來(lái)的范圍一分為二，這樣就有了兩個(gè)塊，每個(gè)塊都有相同數(shù)量的文檔。
遷移：當(dāng)分片中的數(shù)據(jù)大小不一時(shí)會(huì)產(chǎn)生遷移的動(dòng)作，比如分片A的數(shù)據(jù)比較多，會(huì)將分片A里面的一些塊轉(zhuǎn)移到分片B里面去。分片集群通過(guò)在分片中移動(dòng)塊來(lái)實(shí)現(xiàn)均衡，是由名為均衡器的軟件進(jìn)程管理的，任務(wù)是確保數(shù)據(jù)在各個(gè)分片中保持均勻分布，當(dāng)集群中擁有塊最多的分片與擁有塊最少分片的塊差大于8時(shí)，均衡器就會(huì)發(fā)起一次均衡處理。
啟動(dòng)兩個(gè)副本集、三個(gè)配置服務(wù)器、一個(gè)mongos進(jìn)程
配置分片
（2）索引
分片集合只允許在_id字段和分片鍵上添加唯一性索引，其他地方不行，因?yàn)檫@需要在分片間進(jìn)行通信，實(shí)施起來(lái)很復(fù)雜。
當(dāng)創(chuàng)建分片時(shí)，會(huì)根據(jù)分片鍵創(chuàng)建一個(gè)索引。
（2）低效的分片鍵
（3）理想的分片鍵
根據(jù)不同的數(shù)據(jù)中心劃分
（2）最低要求
（3）配置的注意事項(xiàng)
需要估計(jì)集群大小，可使用以下命令對(duì)現(xiàn)有集合進(jìn)行分片處理
（4）備份分片集群
備份分片時(shí)需要停止均衡器
使用64位機(jī)器、32位機(jī)器會(huì)制約mongodb的內(nèi)存，使其最大值為1.5GB
（2）cpu mongodb 只有當(dāng)索引和工作集都可放入內(nèi)存時(shí)，才會(huì)遇到CPU瓶頸，CPU在mongodb使用中的作用是用來(lái)檢索數(shù)據(jù)，如果看到CPU使用飽和的情況，可以通過(guò)查詢慢查詢?nèi)罩?，排查是不是查詢的?wèn)題導(dǎo)致的，如果是可以通過(guò)添加索引來(lái)解決問(wèn)題
mongodb寫入數(shù)據(jù)時(shí)會(huì)使用到CPU，但是mongodb寫入時(shí)間一次只用到一個(gè)核，如果有頻繁的寫入行為，可以通過(guò)分片來(lái)解決這個(gè)問(wèn)題 （3）內(nèi)存
大內(nèi)存是mongodb的保障，如果工作集大小超過(guò)內(nèi)存，將會(huì)導(dǎo)致性能下降，因?yàn)檫@將會(huì)增加數(shù)據(jù)加載入內(nèi)存的動(dòng)作
（4）硬盤
mongodb默認(rèn)每60s會(huì)與磁盤強(qiáng)制同步一次，稱為后臺(tái)刷新，會(huì)產(chǎn)生I/O操作。在重啟時(shí)mongodb會(huì)將磁盤里面的數(shù)據(jù)加載至內(nèi)存，高速磁盤將會(huì)減少同步的時(shí)間
（5）文件系統(tǒng)
使用ext4 和 xfs 文件系統(tǒng)
禁用最后訪問(wèn)時(shí)間
（6）文件描述符
linux 默認(rèn)文件描述符是1024，需要大額度的提升這個(gè)額度
（7）時(shí)鐘
mongodb各個(gè)節(jié)點(diǎn)服務(wù)器之間使用ntp服務(wù)器
啟動(dòng)時(shí)使用 - -bind_ip 命令
（2）身份驗(yàn)證
啟動(dòng)時(shí)使用 - -auth 命令
（3）副本集身份認(rèn)證
使用keyFile，注意keyFile文件的權(quán)限必須是600，不然會(huì)啟動(dòng)不起來(lái)
搭建副本集至少需要兩個(gè)節(jié)點(diǎn)，其中仲裁結(jié)點(diǎn)不需要有自己的服務(wù)器
（2）Journaling日志 寫數(shù)據(jù)時(shí)會(huì)先寫入日志，而此時(shí)的數(shù)據(jù)也不是直接寫入硬盤，而是寫入內(nèi)存
但是Journaling日志會(huì)消耗內(nèi)存，所以可以在主庫(kù)上面關(guān)閉，在從庫(kù)上面啟動(dòng)
可以單獨(dú)為Journaling日志使用一塊固態(tài)硬盤
在插入時(shí)，可以通過(guò)驅(qū)動(dòng)確保Journaling插入后再反饋，但是會(huì)非常影響性能。
-vvvvv 選項(xiàng)（v越多，輸出越詳細(xì)）
db.runCommand({logrotare:1}) 開(kāi)啟滾動(dòng)日志
（2）top
（3）db.currentOp
動(dòng)態(tài)展示mongodb活動(dòng)數(shù)據(jù)
占用當(dāng)前mongodb監(jiān)聽(tīng)端口往上1000號(hào)的端口
把數(shù)據(jù)庫(kù)內(nèi)容導(dǎo)出成BSON文件，而mongorestore能讀取并還原這些文件
（2）mongorestore
把導(dǎo)出的BSON文件還原到數(shù)據(jù)庫(kù)
（3）備份原始數(shù)據(jù)文件 可以這么做，但是，操作之前需要進(jìn)行鎖庫(kù)處理 db.runCommand({fsync:1,lock:true}) db.$cmd.sys.unlock.findOne 請(qǐng)求解鎖操作，但是數(shù)據(jù)庫(kù)不會(huì)立刻解鎖，需要使用 db.currentOp 驗(yàn)證。
db.runCommand({repairDatabase:1}) 修復(fù)單個(gè)數(shù)據(jù)庫(kù)
修復(fù)就是根據(jù)Jourling文件讀取和重寫所有數(shù)據(jù)文件并重建各個(gè)索引 （2）壓緊
壓緊，會(huì)重寫數(shù)據(jù)文件，并重建集合的全部索引，需要停機(jī)或者在從庫(kù)上面運(yùn)行,如果需要在主庫(kù)上面運(yùn)行，需要添加force參數(shù) 保證加寫鎖。
（2）為提升性能檢查索引和查詢
總的來(lái)說(shuō)，掃描盡可能少的文檔。
保證沒(méi)有冗余的索引，冗余的索引會(huì)占用磁盤空間、消耗更多的內(nèi)存，在每次寫入時(shí)還需做更多工作
（3）添加內(nèi)存
dataSize 數(shù)據(jù)大小 和 indexSize 索引大小，如果兩者的和大于內(nèi)存，那么將會(huì)影響性能。
storageSize超過(guò)dataSize 數(shù)據(jù)大小 兩倍以上，就會(huì)因磁盤碎片而影響性能，需要壓縮。
一直想整理一下這塊內(nèi)容，既然是漫談，就想起什么說(shuō)什么吧。我一直是在互聯(lián)網(wǎng)行業(yè)，就以互聯(lián)網(wǎng)行業(yè)來(lái)說(shuō)。
先大概列一下互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)平臺(tái)的用途：
整合公司所有業(yè)務(wù)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)中心；
提供各種報(bào)表，有給高層的，有給各個(gè)業(yè)務(wù)的；
為網(wǎng)站運(yùn)營(yíng)提供運(yùn)營(yíng)上的數(shù)據(jù)支持，就是通過(guò)數(shù)據(jù)，讓運(yùn)營(yíng)及時(shí)了解網(wǎng)站和產(chǎn)品的運(yùn)營(yíng)效果；
為各個(gè)業(yè)務(wù)提供線上或線下的數(shù)據(jù)支持，成為公司統(tǒng)一的數(shù)據(jù)交換與提供平臺(tái)；
分析用戶行為數(shù)據(jù)，通過(guò)數(shù)據(jù)挖掘來(lái)降低投入成本，提高投入效果；比如廣告定向精準(zhǔn)投放、用戶個(gè)性化推薦等；
開(kāi)發(fā)數(shù)據(jù)產(chǎn)品，直接或間接為公司盈利；
建設(shè)開(kāi)放數(shù)據(jù)平臺(tái)，開(kāi)放公司數(shù)據(jù)；
。。。。。。
上面列出的內(nèi)容看上去和傳統(tǒng)行業(yè)數(shù)據(jù)倉(cāng)庫(kù)用途差不多，并且都要求數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)有很好的穩(wěn)定性、可靠性；但在互聯(lián)網(wǎng)行業(yè)，除了數(shù)據(jù)量大之外，越來(lái)越多的業(yè)務(wù)要求時(shí)效性，甚至很多是要求實(shí)時(shí)的 ，另外，互聯(lián)網(wǎng)行業(yè)的業(yè)務(wù)變化非?？欤豢赡芟駛鹘y(tǒng)行業(yè)一樣，可以使用自頂向下的方法建立數(shù)據(jù)倉(cāng)庫(kù)，一勞永逸，它要求新的業(yè)務(wù)很快能融入數(shù)據(jù)倉(cāng)庫(kù)中來(lái)，老的下線的業(yè)務(wù)，能很方便的從現(xiàn)有的數(shù)據(jù)倉(cāng)庫(kù)中下線；
其實(shí)，互聯(lián)網(wǎng)行業(yè)的數(shù)據(jù)倉(cāng)庫(kù)就是所謂的敏捷數(shù)據(jù)倉(cāng)庫(kù)，不但要求能快速的響應(yīng)數(shù)據(jù)，也要求能快速的響應(yīng)業(yè)務(wù)；
建設(shè)敏捷數(shù)據(jù)倉(cāng)庫(kù)，除了對(duì)架構(gòu)技術(shù)上的要求之外，還有一個(gè)很重要的方面，就是數(shù)據(jù)建模，如果一上來(lái)就想著建立一套能兼容所有數(shù)據(jù)和業(yè)務(wù)的數(shù)據(jù)模型，那就又回到傳統(tǒng)數(shù)據(jù)倉(cāng)庫(kù)的建設(shè)上了，很難滿足對(duì)業(yè)務(wù)變化的快速響應(yīng)。應(yīng)對(duì)這種情況，一般是先將核心的持久化的業(yè)務(wù)進(jìn)行深度建模（比如：基于網(wǎng)站日志建立的網(wǎng)站統(tǒng)計(jì)分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數(shù)據(jù)建立的用戶模型），其它的業(yè)務(wù)一般都采用維度+寬表的方式來(lái)建立數(shù)據(jù)模型。這塊是后話。
整體架構(gòu)下面的圖是我們目前使用的數(shù)據(jù)平臺(tái)架構(gòu)圖，其實(shí)大多公司應(yīng)該都差不多：
請(qǐng)點(diǎn)擊輸入圖片描述
邏輯上，一般都有數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層?？赡芙蟹ㄓ兴煌?，本質(zhì)上的角色都大同小異。
我們從下往上看：
數(shù)據(jù)采集數(shù)據(jù)采集層的任務(wù)就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲(chǔ)到數(shù)據(jù)存儲(chǔ)上，期間有可能會(huì)做一些簡(jiǎn)單的清洗。
數(shù)據(jù)源的種類比較多：
網(wǎng)站日志：
作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲(chǔ)在多臺(tái)網(wǎng)站日志服務(wù)器上，
一般是在每臺(tái)網(wǎng)站日志服務(wù)器上部署flume agent，實(shí)時(shí)的收集網(wǎng)站日志并存儲(chǔ)到HDFS上；
業(yè)務(wù)數(shù)據(jù)庫(kù)：
業(yè)務(wù)數(shù)據(jù)庫(kù)的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時(shí)候，我們迫切的需要一種能從各種數(shù)據(jù)庫(kù)中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過(guò)繁重，而且不管數(shù)據(jù)量大小，都需要啟動(dòng)MapReduce來(lái)執(zhí)行，而且需要Hadoop集群的每臺(tái)機(jī)器都能訪問(wèn)業(yè)務(wù)數(shù)據(jù)庫(kù)；應(yīng)對(duì)此場(chǎng)景，淘寶開(kāi)源的DataX，是一個(gè)很好的解決方案（可參考文章 《異構(gòu)數(shù)據(jù)源海量數(shù)據(jù)交換工具-Taobao DataX 下載和使用》），有資源的話，可以基于DataX之上做二次開(kāi)發(fā)，就能非常好的解決，我們目前使用的DataHub也是。
當(dāng)然，F(xiàn)lume通過(guò)配置與開(kāi)發(fā)，也可以實(shí)時(shí)的從數(shù)據(jù)庫(kù)中同步數(shù)據(jù)到HDFS。
來(lái)自于Ftp/Http的數(shù)據(jù)源：
有可能一些合作伙伴提供的數(shù)據(jù)，需要通過(guò)Ftp/Http等定時(shí)獲取，DataX也可以滿足該需求；
其他數(shù)據(jù)源：
比如一些手工錄入的數(shù)據(jù)，只需要提供一個(gè)接口或小程序，即可完成；
數(shù)據(jù)存儲(chǔ)與分析毋庸置疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)最完美的數(shù)據(jù)存儲(chǔ)解決方案。
離線數(shù)據(jù)分析與計(jì)算，也就是對(duì)實(shí)時(shí)性要求不高的部分，在我看來(lái)，Hive還是首當(dāng)其沖的選擇，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù)；壓縮比非常高的ORC文件存儲(chǔ)格式；非常方便的SQL支持，使得Hive在基于結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計(jì)分析遠(yuǎn)遠(yuǎn)比MapReduce要高效的多，一句SQL可以完成的需求，開(kāi)發(fā)MR可能需要上百行代碼；
當(dāng)然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂(lè)意開(kāi)發(fā)Java，或者對(duì)SQL不熟，那么也可以使用MapReduce來(lái)做分析與計(jì)算；Spark是這兩年非?；鸬?，經(jīng)過(guò)實(shí)踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結(jié)合的越來(lái)越好，因此，必須支持使用Spark和SparkSQL來(lái)做分析和計(jì)算。因?yàn)橐呀?jīng)有Hadoop Yarn，使用Spark其實(shí)是非常容易的，不用單獨(dú)部署Spark集群，關(guān)于Spark On Yarn的相關(guān)文章，可參考：《Spark On Yarn系列文章》
實(shí)時(shí)計(jì)算部分，后面單獨(dú)說(shuō)。
數(shù)據(jù)共享這里的數(shù)據(jù)共享，其實(shí)指的是前面數(shù)據(jù)分析與計(jì)算后的結(jié)果存放的地方，其實(shí)就是關(guān)系型數(shù)據(jù)庫(kù)和NOSQL數(shù)據(jù)庫(kù)；
前面使用Hive、MR、Spark、SparkSQL分析和計(jì)算的結(jié)果，還是在HDFS上，但大多業(yè)務(wù)和應(yīng)用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個(gè)數(shù)據(jù)共享的地方，使得各業(yè)務(wù)和產(chǎn)品能方便的獲取數(shù)據(jù)；?和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個(gè)從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，同樣，DataX也可以滿足。
另外，一些實(shí)時(shí)計(jì)算的結(jié)果數(shù)據(jù)可能由實(shí)時(shí)計(jì)算模塊直接寫入數(shù)據(jù)共享。
數(shù)據(jù)應(yīng)用
業(yè)務(wù)產(chǎn)品
業(yè)務(wù)產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層，他們直接從數(shù)據(jù)共享層訪問(wèn)即可；
報(bào)表
同業(yè)務(wù)產(chǎn)品，報(bào)表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計(jì)匯總好的，存放于數(shù)據(jù)共享層；
即席查詢
即席查詢的用戶有很多，有可能是數(shù)據(jù)開(kāi)發(fā)人員、網(wǎng)站和產(chǎn)品運(yùn)營(yíng)人員、數(shù)據(jù)分析人員、甚至是部門老大，他們都有即席查詢數(shù)據(jù)的需求；
這種即席查詢通常是現(xiàn)有的報(bào)表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足他們的需求，需要從數(shù)據(jù)存儲(chǔ)層直接查詢。
即席查詢一般是通過(guò)SQL完成，最大的難度在于響應(yīng)速度上，使用Hive有點(diǎn)慢，目前我的解決方案是SparkSQL，它的響應(yīng)速度較Hive快很多，而且能很好的與Hive兼容。
當(dāng)然，你也可以使用Impala，如果不在乎平臺(tái)中再多一個(gè)框架的話。
OLAP
目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)，都是通過(guò)將需要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫(kù)中做OLAP，但如果數(shù)據(jù)量巨大的話，關(guān)系型數(shù)據(jù)庫(kù)顯然不行；
這時(shí)候，需要做相應(yīng)的開(kāi)發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)，完成OLAP的功能；
比如：根據(jù)用戶在界面上選擇的不定的維度和指標(biāo)，通過(guò)開(kāi)發(fā)接口，從HBase中獲取數(shù)據(jù)來(lái)展示。
其它數(shù)據(jù)接口
這種接口有通用的，有定制的。比如：一個(gè)從Redis中獲取用戶屬性的接口是通用的，所有的業(yè)務(wù)都可以調(diào)用這個(gè)接口來(lái)獲取用戶屬性。
實(shí)時(shí)計(jì)算現(xiàn)在業(yè)務(wù)對(duì)數(shù)據(jù)倉(cāng)庫(kù)實(shí)時(shí)性的需求越來(lái)越多，比如：實(shí)時(shí)的了解網(wǎng)站的整體流量；實(shí)時(shí)的獲取一個(gè)廣告的曝光和點(diǎn)擊；在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫(kù)和傳統(tǒng)實(shí)現(xiàn)方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時(shí)低的、高可靠的實(shí)時(shí)計(jì)算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡(jiǎn)單，不想多引入一個(gè)框架到平臺(tái)中，另外，Spark Streaming比Storm延時(shí)性高那么一點(diǎn)點(diǎn)，那對(duì)于我們的需要可以忽略。
我們目前使用Spark Streaming實(shí)現(xiàn)了實(shí)時(shí)的網(wǎng)站流量統(tǒng)計(jì)、實(shí)時(shí)的廣告效果統(tǒng)計(jì)兩塊功能。
做法也很簡(jiǎn)單，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志，實(shí)時(shí)的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計(jì)，將數(shù)據(jù)存儲(chǔ)至Redis，業(yè)務(wù)通過(guò)訪問(wèn)Redis實(shí)時(shí)獲取。
任務(wù)調(diào)度與監(jiān)控在數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)中，有各種各樣非常多的程序和任務(wù)，比如：數(shù)據(jù)采集任務(wù)、數(shù)據(jù)同步任務(wù)、數(shù)據(jù)分析任務(wù)等；
這些任務(wù)除了定時(shí)調(diào)度，還存在非常復(fù)雜的任務(wù)依賴關(guān)系，比如：數(shù)據(jù)分析任務(wù)必須等相應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能開(kāi)始；數(shù)據(jù)同步任務(wù)需要等數(shù)據(jù)分析任務(wù)完成后才能開(kāi)始；?這就需要一個(gè)非常完善的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)的中樞，負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運(yùn)行。
前面有寫過(guò)文章，《大數(shù)據(jù)平臺(tái)中的任務(wù)調(diào)度與監(jiān)控》,這里不再累贅。
總結(jié)在我看來(lái)架構(gòu)并不是技術(shù)越多越新越好，而是在可以滿足需求的情況下，越簡(jiǎn)單越穩(wěn)定越好。目前在我們的數(shù)據(jù)平臺(tái)中，開(kāi)發(fā)更多的是關(guān)注業(yè)務(wù)，而不是技術(shù)，他們把業(yè)務(wù)和需求搞清楚了，基本上只需要做簡(jiǎn)單的SQL開(kāi)發(fā)，然后配置到調(diào)度系統(tǒng)就可以了，如果任務(wù)異常，會(huì)收到告警。這樣，可以使更多的資源專注于業(yè)務(wù)之上。
重慶分公司
重慶分公司
