Ⅰ 想從事大數據方面有關的工作，要學什麼我大學學的是網路工程，擺脫講詳細點！
首先從大數據本身看，大數據從採集存儲計算分析可視共享等處理過程，價值在於對業務理解基礎上關聯預測，需要技術演算法架構等能力支撐，同時注重數據安全隱私保護。大數據是個團隊工作，不是一個人能完成的。
其次從所學專業看，你的網路工程偏向於網路組網，橫向的數據來龍去脈比較清楚，可以結合自己的興趣向大數據處理過程的一些環節發展，比如數據安全性考慮。數學功底好的可以考慮建模演算法研究應用。
最後從職業規劃看，要有一定的應用意識，抓住一點突破縱深發展為專家後再考慮面的擴展。學什麼取決於你以後工作的需求，不是為了學而學。
希望能幫到你一些。
Ⅱ 大數據行業的數據精準嗎
第一，用戶行為與特徵分析。顯然，只要積累足夠的用戶數據，就能分析出用戶的喜好與購買習慣，甚至做到「比用戶更了解用戶自己」。有了這一點，才是許多大數據營銷的前提與出發點。無論如何，那些過去將「一切以客戶為中心」作為口號的企業可以想想，過去你們真的能及時全面地了解客戶的需求與所想嗎？或許只有大數據時代這個問題的答案才更明確。
第二，精準營銷信息推送支撐。過去多少年了，精準營銷總在被許多公司提及，但是真正做到的少之又少，反而是垃圾信息泛濫。究其原因，主要就是過去名義上的精準營銷並不怎麼精準，因為其缺少用戶特徵數據支撐及詳細准確的分析。相對而言，現在的RTB廣告等應用則向我們展示了比以前更好的精準性，而其背後靠的即是大數據支撐。
第三，引導產品及營銷活動投用戶所好。如果能在產品生產之前了解潛在用戶的主要特徵，以及他們對產品的期待，那麼你的產品生產即可投其所好。例如，Netflix在近投拍《紙牌屋》之前，即通過大數據分析知道了潛在觀眾最喜歡的導演與演員，結果果然捕獲了觀眾的心。又比如，《小時代》在預告片投放後，即從微博上通過大數據分析得知其電影的主要觀眾群為90後女性，因此後續的營銷活動則主要針對這些人群展開。
第四，競爭對手監測與品牌傳播。競爭對手在干什麼是許多企業想了解的，即使對方不會告訴你，但你卻可以通過大數據監測分析得知。品牌傳播的有效性亦可通過大數據分析找准方向。例如，可以進行傳播趨勢分析、內容特徵分析、互動用戶分析、正負情緒分類、口碑品類分析、產品屬性分布等，可以通過監測掌握競爭對手傳播態勢，並可以參考行業標桿用戶策劃，根據用戶聲音策劃內容，甚至可以評估微博矩陣運營效果。
第五，品牌危機監測及管理支持。新媒體時代，品牌危機使許多企業談虎色變，然而大數據可以讓企業提前有所洞悉。在危機爆發過程中，最需要的是跟蹤危機傳播趨勢，識別重要參與人員，方便快速應對。大數據可以採集負面定義內容，及時啟動危機跟蹤和報警，按照人群社會屬性分析，聚類事件過程中的觀點，識別關鍵人物及傳播路徑，進而可以保護企業、產品的聲譽，抓住源頭和關鍵節點，快速有效地處理危機。
第六，企業重點客戶篩選。許多企業家糾結的事是：在企業的用戶、好友與粉絲中，哪些是最有價值的用戶？有了大數據，或許這一切都可以更加有事實支撐。從用戶訪問的各種網站可判斷其最近關心的東西是否與你的企業相關；從用戶在社會化媒體上所發布的各類內容及與他人互動的內容中，可以找出千絲萬縷的信息，利用某種規則關聯及綜合起來，就可以幫助企業篩選重點的目標用戶。
第七，大數據用於改善用戶體驗。要改善用戶體驗，關鍵在於真正了解用戶及他們所使用的你的產品的狀況，做最適時的提醒。例如，在大數據時代或許你正駕駛的汽車可提前救你一命。只要通過遍布全車的感測器收集車輛運行信息，在你的汽車關鍵部件發生問題之前，就會提前向你或4S店預警，這決不僅僅是節省金錢，而且對保護生命大有裨益。事實上，美國的UPS快遞公司早在2000年就利用這種基於大數據的預測性分析系統來檢測全美60000輛車輛的實時車況，以便及時地進行防禦性修理
第八，SCRM中的客戶分級管理支持。面對日新月異的新媒體，許多企業想通過對粉絲的公開內容和互動記錄分析，將粉絲轉化為潛在用戶，激活社會化資產價值，並對潛在用戶進行多個維度的畫像。大數據可以分析活躍粉絲的互動內容，設定消費者畫像各種規則，關聯潛在用戶與會員數據，關聯潛在用戶與客服數據，篩選目標群體做精準營銷，進而可以使傳統客戶關系管理結合社會化數據，豐富用戶不同維度的標簽，並可動態更新消費者生命周期數據，保持信息新鮮有效。
第九，發現新市場與新趨勢。基於大數據的分析與預測，對於企業家提供洞察新市場與把握經濟走向都是極大的支持。例如，阿里巴巴從大量交易數據中更早地發現了國際金融危機的到來。又如，在2012年美國總統選舉中，微軟研究院的David Rothschild就曾使用大數據模型，准確預測了美國50個州和哥倫比亞特區共計51個選區中50個地區的選舉結果，准確性高於98%。之後，他又通過大數據分析，對第85屆屆奧斯卡各獎項的歸屬進行了預測，除最佳導演外，其它各項獎預測全部命中。
第十，市場預測與決策分析支持。對於數據對市場預測及決策分析的支持，過去早就在數據分析與數據挖掘盛行的年代被提出過。沃爾瑪著名的「啤酒與尿布」案例即是那時的傑作。只是由於大數據時代上述Volume（規模大）及Variety（類型多）對數據分析與數據挖掘提出了新要求。更全面、速度更及時的大數據，必然對市場預測及決策分析進一步上台階提供更好的支撐。要知道，似是而非或錯誤的、過時的數據對決策者而言簡直就是災難。
Ⅲ 如何用Solr搭建大數據查詢平台
0×00 開頭照例扯淡
自從各種脫褲門事件開始層出不窮，在下就學乖了，各個地方的密碼全都改成不一樣的，重要帳號的密碼定期更換，生怕被人社出祖宗十八代的我，甚至開始用起了假名字，我給自己起一新網名」興才」，這個看起來還不錯的名字，其實是我們家鄉罵人土話，意思是腦殘人士…. -_-|||額好吧，反正是假的，不要在意這些細節。
這只是名，至於姓氏么，每個帳號的注冊資料那裡，照著百家姓上趙錢孫李周吳鄭王的依次往下排，什麼張興才、李興才、王興才……於是也不知道我這樣」興才」了多久，終於有一天，我接到一個陌生電話：您好，請問是馬興才先生嗎?
好么，該來的終於還是來了，於是按名索驥，得知某某網站我用了這個名字，然後通過各種途徑找，果然，那破站被脫褲子了。
果斷Down了那個褲子，然後就一發不可收拾，走上了收藏褲子的不歸路，直到有一天，我發現收藏已經非常豐富了，粗略估計得好幾十億條數據，拍腦袋一想，這不能光收藏啊，我也搭個社工庫用吧……
0×01 介紹
社工庫怎麼搭呢，這種海量數據的東西，並不是簡單的用mysql建個庫，然後做個php查詢select * from sgk where username like 『%xxxxx%』這樣就能完事的，也不是某些幼稚騷年想的隨便找個4g內存，amd雙核的破電腦就可以帶起來的，上面這樣的語句和系統配置，真要用於社工庫查詢，查一條記錄恐怕得半小時。好在這個問題早就被一種叫做全文搜索引擎的東西解決了，更好的消息是，全文搜索引擎大部分都是開源的，不需要花錢。
目前網上已經搭建好的社工庫，大部分是mysql+coreseek+php架構，coreseek基於sphinx，是一款優秀的全文搜索引擎，但缺點是比較輕量級，一旦數據量過數億，就會有些力不從心，並且搭建集群做分布式性能並不理想，如果要考慮以後數據量越來越大的情況，還是得用其他方案，為此我使用了solr。
Solr的基礎是著名的Lucene框架，基於java，通過jdbc介面可以導入各種資料庫和各種格式的數據，非常適合開發企業級的海量數據搜索平台，並且提供完善的solr cloud集群功能，更重要的是，solr的數據查詢完全基於http，可以通過簡單的post參數，返回json,xml,php,python,ruby,csv等多種格式。
以前的solr，本質上是一組servlet，必須放進Tomcat才能運行，從solr5開始，它已經自帶了jetty，配置的好，完全可以獨立使用，並且應付大量並發請求，具體的架構我們後面會講到，現在先來進行solr的安裝配置。
0×02 安裝和配置
以下是我整個搭建和測試過程所用的硬體和軟體平台，本文所有內容均在此平台上完成：
軟體配置: solr5.5,mysql5.7,jdk8,Tomcat8 Windows10/Ubuntu14.04 LTS
硬體配置: i7 4770k,16G DDR3,2T西數黑盤
2.1 mysql資料庫
Mysql資料庫的安裝和配置我這里不再贅述，只提一點，對於社工庫這種查詢任務遠遠多於插入和更新的應用來說，最好還是使用MyISAM引擎。
搭建好資料庫後，新建一個庫，名為newsgk，然後創建一個表命名為b41sgk,結構如下：
id bigint 主鍵 自動增長
username varchar 用戶名
email varchar 郵箱
password varchar 密碼
salt varchar 密碼中的鹽或者第二密碼
ip varchar ip、住址、電話等其他資料
site varchar 資料庫的來源站點
接下來就是把收集的各種褲子全部導入這個表了，這里推薦使用navicat，它可以支持各種格式的導入，具體過程相當的枯燥乏味,需要很多的耐心，這里就不再廢話了，列位看官自己去搞就是了，目前我初步導入的數據量大約是10億條。
2.2 Solr的搭建和配置
首先下載solr：
$ wget http://mirrors.hust.e.cn/apache/lucene/solr/5.5.0/solr-5.5.0.tgz
解壓縮：
$ tar zxvf solr-5.5.0.tgz
安裝jdk8：
$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update
$ sudo apt-get install oracle-java8-installer
$ sudo apt-get install oracle-java8-set-default
因為是java跨平台的，Windows下和linux下solr是同一個壓縮包，windows下jdk的安裝這里不再說明。
進入解壓縮後的solr文件夾的bin目錄，solr.cmd和solr分別是windows和linux下的啟動腳本：
因為社工庫是海量大數據，而jvm默認只使用512m的內存，這遠遠不夠，所以我們需要修改，打開solr.in.sh文件，找到這一行：
SOLR_HEAP=」512m」
依據你的數據量，把它修改成更高，我這里改成4G，改完保存. 在windows下略有不同，需要修改solr.in.cmd文件中的這一行：
set SOLR_JAVA_MEM=-Xms512m -Xmx512m
同樣把兩個512m都修改成4G。
Solr的啟動，重啟和停止命令分別是：
$ ./solr start
$ ./solr restart –p 8983
$ ./solr stop –all
在linux下還可以通過install_solr_service.sh腳本把solr安裝為服務，開機後台自動運行。
Solr安裝完成，現在我們需要從mysql導入數據，導入前，我們需要先創建一個core，core是solr的特有概念，每個core是一個查詢、數據,、索引等的集合體，你可以把它想像成一個獨立資料庫，我們創建一個新core：
在solr-5.5.0/server/solr子目錄下面建立一個新文件夾，命名為solr_mysql，這個是core的名稱，在下面創建兩個子目錄conf和data，把solr-5.5.0/solr-5.5.0/example/example-DIH/solr/db/conf下面的所有文件全部拷貝到我們創建的conf目錄中.接下來的配置主要涉及到三個文件， solrconfig.xml， schema.xml和db-data-config.xml。
首先打開db-data-config.xml，修改為以下內容：
<dataConfig>
<dataSource name="sgk" type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://127.0.0.1:3306/newsgk" user="root" password="password" batchSize="-1" />
<document name="mysgk">
<entity name="b41sgk" pk="id" query="select * from b41sgk">
<field column="id" name="id"/>
<field column="username" name="username"/>
<field column="email" name="email"/>
<field column="password" name="password"/>
<field column="salt" name="salt"/>
<field column="ip" name="ip"/>
<field column="site" name="site"/>
</entity>
</document>
</dataConfig>
這個文件是負責配置導入數據源的，請按照mysql實際的設置修改datasource的內容，下面entity的內容必須嚴格按照mysql中社工庫表的結構填寫，列名要和資料庫中的完全一樣。
然後打開solrconfig.xml，先找到這一段：
<schemaFactory class="ManagedIndexSchemaFactory">
<bool name="mutable">true</bool>
<str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>
把它全部注釋掉，加上一行，改成這樣：
<!-- <schemaFactory class="ManagedIndexSchemaFactory">
<bool name="mutable">true</bool>
<str name="managedSchemaResourceName">managed-schema</str>
</schemaFactory>-->
<schemaFactory class="ClassicIndexSchemaFactory"/>
這是因為solr5 以上默認使用managed-schema管理schema，需要更改為可以手動修改。
然後我們還需要關閉suggest，它提供搜索智能提示，在社工庫中我們用不到這樣的功能，重要的是，suggest會嚴重的拖慢solr的啟動速度,在十幾億數據的情況下，開啟suggest可能會導致solr啟動載入core長達幾個小時!
同樣在solrconfig.xml中，找到這一段：
<searchComponent name="suggest" class="solr.SuggestComponent">
<lst name="suggester">
<str name="name">mySuggester</str>
<str name="lookupImpl">FuzzyLookupFactory</str> <!-- org.apache.solr.spelling.suggest.fst -->
<str name="dictionaryImpl">DocumentDictionaryFactory</str> <!-- org.apache.solr.spelling.suggest. -->
<str name="field">cat</str>
<str name="weightField">price</str>
<str name="suggestAnalyzerFieldType">string</str>
</lst>
</searchComponent>
<requestHandler name="/suggest" class="solr.SearchHandler" startup="lazy">
<lst name="defaults">
<str name="suggest">true</str>
<str name="suggest.count">10</str>
</lst>
<arr name="components">
<str>suggest</str>
</arr>
</requestHandler>
把這些全部刪除，然後保存solrconfig.xml文件。
接下來把managed-schema拷貝一份，重命名為schema.xml (原文件不要刪除)，打開並找到以下位置：
只保留_version_和_root_節點，然後把所有的field，dynamicField和Field全部刪除，添加以下的部分：
<field name="id" type="int" indexed="true" stored="true" required="true" multiValued="false" />
<field name="username" type="text_ik" indexed="true" stored="true"/>
<field name="email" type="text_ik" indexed="true" stored="true"/>
<field name="password" type="text_general" indexed="true" stored="true"/>
<field name="salt" type="text_general" indexed="true" stored="true"/>
<field name="ip" type="text_general" indexed="true" stored="true"/>
<field name="site" type="text_general" indexed="true" stored="true"/>
<field name="keyword" type="text_ik" indexed="true" stored="false" multiValued="true"/>
<Field source="username" dest="keyword"/>
<Field source="email" dest="keyword"/>
<uniqueKey>id</uniqueKey>
這里的uniqueKey是配置文件中原有的，用來指定索引欄位，必須保留。新建了一個欄位名為keyword，它的用途是聯合查詢，即當需要同時以多個欄位做關鍵字查詢時，可以用這一個欄位名代替，增加查詢效率，下面的Field即用來指定復制哪些欄位到keyword。注意keyword這樣的欄位，後面的multiValued屬性必須為true。
username和email以及keyword這三個欄位，用來檢索查詢關鍵字，它們的類型我們指定為text_ik，這是一個我們創造的類型，因為solr雖然內置中文分詞，但效果並不好，我們需要添加IKAnalyzer中文分詞引擎來查詢中文。在https://github.com/EugenePig/ik-analyzer-solr5下載IKAnalyzer for solr5的源碼包，然後使用Maven編譯，得到一個文件IKAnalyzer-5.0.jar，把它放入solr-5.5.0/server/solr-webapp/webapp/WEB-INF/lib目錄中，然後在solrconfig.xml的fieldType部分加入以下內容：
<fieldType name="text_ik" class="solr.TextField">
<analyzer type="index" useSmart="false" class="org.wltea.analyzer.lucene.IKAnalyzer"/>
<analyzer type="query" useSmart="true" class="org.wltea.analyzer.lucene.IKAnalyzer"/>
</fieldType>
保存後，core的配置就算完成了，不過要導入mysql數據，我們還需要在mysql網站上下載mysql-connector-java-bin.jar庫文件，連同solr-5.5.0/dist目錄下面的solr-dataimporthandler-5.5.0.jar，solr-dataimporthandler-extras-5.5.0.jar兩個文件，全部拷貝到solr-5.5.0/server/solr-webapp/webapp/WEB-INF/lib目錄中，然後重啟solr，就可以開始數據導入工作了。
Ⅳ 大數據三大核心技術：拿數據、算數據、賣數據！
大數據的由來
對於「大數據」（Big data）研究機構Gartner給出了這樣的定義。「大數據」是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力來適應海量、高增長率和多樣化的信息資產。
1
麥肯錫全球研究所給出的定義是：一種規模大到在獲取、存儲、管理、分析方面大大超出了傳統資料庫軟體工具能力范圍的數據集合，具有海量的數據規模、快速的數據流轉、多樣的數據類型和價值密度低四大特徵。
大數據技術的戰略意義不在於掌握龐大的數據信息，而在於對這些含有意義的數據進行專業化處理。換而言之，如果把大數據比作一種產業，那麼這種產業實現盈利的關鍵，在於提高對數據的「加工能力」，通過「加工」實現數據的「增值」。
從技術上看，大數據與雲計算的關系就像一枚硬幣的正反面一樣密不可分。大數據必然無法用單台的計算機進行處理，必須採用分布式架構。它的特色在於對海量數據進行分布式數據挖掘。但它必須依託雲計算的分布式處理、分布式資料庫和雲存儲、虛擬化技術。
大數據需要特殊的技術，以有效地處理大量的容忍經過時間內的數據。適用於大數據的技術，包括大規模並行處理（MPP）資料庫、數據挖掘、分布式文件系統、分布式資料庫、雲計算平台、互聯網和可擴展的存儲系統。
最小的基本單位是bit，按順序給出所有單位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB。
大數據的應用領域
大數據無處不在，大數據應用於各個行業，包括金融、 汽車 、餐飲、電信、能源、體能和 娛樂 等在內的 社會 各行各業都已經融入了大數據的印跡。
製造業，利用工業大數據提升製造業水平，包括產品故障診斷與預測、分析工藝流程、改進生產工藝，優化生產過程能耗、工業供應鏈分析與優化、生產計劃與排程。
金融行業，大數據在高頻交易、社交情緒分析和信貸風險分析三大金融創新領域發揮重大作用。
汽車 行業，利用大數據和物聯網技術的無人駕駛 汽車 ，在不遠的未來將走入我們的日常生活。
互聯網行業，藉助於大數據技術，可以分析客戶行為，進行商品推薦和針對性廣告投放。
電信行業，利用大數據技術實現客戶離網分析，及時掌握客戶離網傾向，出台客戶挽留措施。
能源行業，隨著智能電網的發展，電力公司可以掌握海量的用戶用電信息，利用大數據技術分析用戶用電模式，可以改進電網運行，合理設計電力需求響應系統，確保電網運行安全。
物流行業，利用大數據優化物流網路，提高物流效率，降低物流成本。
城市管理，可以利用大數據實現智能交通、環保監測、城市規劃和智能安防。
體育 娛樂 ，大數據可以幫助我們訓練球隊，決定投拍哪種 題財的 影視作品，以及預測比賽結果。
安全領域，政府可以利用大數據技術構建起強大的國家安全保障體系，企業可以利用大數據抵禦網路攻擊，警察可以藉助大數據來預防犯罪。
個人生活， 大數據還可以應用於個人生活，利用與每個人相關聯的「個人大數據」，分析個人生活行為習慣，為其提供更加周到的個性化服務。
大數據的價值，遠遠不止於此，大數據對各行各業的滲透，大大推動了 社會 生產和生活，未來必將產生重大而深遠的影響。
大數據方面核心技術有哪些？
大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、NoSQL資料庫、數據倉庫、機器學習、並行計算、可視化等各種技術范疇和不同的技術層面。首先給出一個通用化的大數據處理框架，主要分為下面幾個方面：數據採集與預處理、數據存儲、數據清洗、數據查詢分析和數據可視化。
數據採集與預處理
對於各種來源的數據，包括移動互聯網數據、社交網路的數據等，這些結構化和非結構化的海量數據是零散的，也就是所謂的數據孤島，此時的這些數據並沒有什麼意義，數據採集就是將這些數據寫入數據倉庫中，把零散的數據整合在一起，對這些數據綜合起來進行分析。數據採集包括文件日誌的採集、資料庫日誌的採集、關系型資料庫的接入和應用程序的接入等。在數據量比較小的時候，可以寫個定時的腳本將日誌寫入存儲系統，但隨著數據量的增長，這些方法無法提供數據安全保障，並且運維困難，需要更強壯的解決方案。
Flume NG
Flume NG作為實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據，同時，對數據進行簡單處理，並寫到各種數據接收方(比如文本，HDFS，Hbase等)。Flume NG採用的是三層架構：Agent層，Collector層和Store層，每一層均可水平拓展。其中Agent包含Source，Channel和 Sink，source用來消費(收集)數據源到channel組件中，channel作為中間臨時存儲，保存所有source的組件信息，sink從channel中讀取數據，讀取成功之後會刪除channel中的信息。
NDC
Logstash
Logstash是開源的伺服器端數據處理管道，能夠同時從多個來源採集數據、轉換數據，然後將數據發送到您最喜歡的 「存儲庫」 中。一般常用的存儲庫是Elasticsearch。Logstash 支持各種輸入選擇，可以在同一時間從眾多常用的數據來源捕捉事件，能夠以連續的流式傳輸方式，輕松地從您的日誌、指標、Web 應用、數據存儲以及各種 AWS 服務採集數據。
Sqoop
Sqoop，用來將關系型資料庫和Hadoop中的數據進行相互轉移的工具，可以將一個關系型資料庫(例如Mysql、Oracle)中的數據導入到Hadoop(例如HDFS、Hive、Hbase)中，也可以將Hadoop(例如HDFS、Hive、Hbase)中的數據導入到關系型資料庫(例如Mysql、Oracle)中。Sqoop 啟用了一個 MapRece 作業(極其容錯的分布式並行計算)來執行任務。Sqoop 的另一大優勢是其傳輸大量結構化或半結構化數據的過程是完全自動化的。
流式計算
流式計算是行業研究的一個熱點，流式計算對多個高吞吐量的數據源進行實時的清洗、聚合和分析，可以對存在於社交網站、新聞等的數據信息流進行快速的處理並反饋，目前大數據流分析工具有很多，比如開源的strom，spark streaming等。
Strom集群結構是有一個主節點(nimbus)和多個工作節點(supervisor)組成的主從結構，主節點通過配置靜態指定或者在運行時動態選舉，nimbus與supervisor都是Storm提供的後台守護進程，之間的通信是結合Zookeeper的狀態變更通知和監控通知來處理。nimbus進程的主要職責是管理、協調和監控集群上運行的topology(包括topology的發布、任務指派、事件處理時重新指派任務等)。supervisor進程等待nimbus分配任務後生成並監控worker(jvm進程)執行任務。supervisor與worker運行在不同的jvm上，如果由supervisor啟動的某個worker因為錯誤異常退出(或被kill掉)，supervisor會嘗試重新生成新的worker進程。
Zookeeper
Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。它的作用主要有配置管理、名字服務、分布式鎖和集群管理。配置管理指的是在一個地方修改了配置，那麼對這個地方的配置感興趣的所有的都可以獲得變更，省去了手動拷貝配置的繁瑣，還很好的保證了數據的可靠和一致性，同時它可以通過名字來獲取資源或者服務的地址等信息，可以監控集群中機器的變化，實現了類似於心跳機制的功能。
數據存儲
Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。
HBase
HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。HBase是一種Key/Value系統，部署在hdfs上，克服了hdfs在隨機讀寫這個方面的缺點，與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用伺服器，來增加計算和存儲能力。
Phoenix
Phoenix，相當於一個Java中間件，幫助開發工程師能夠像使用JDBC訪問關系型資料庫一樣訪問NoSQL資料庫HBase。
Yarn
Yarn是一種Hadoop資源管理器，可為上層應用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。Yarn由下面的幾大組件構成：一個全局的資源管理器ResourceManager、ResourceManager的每個節點代理NodeManager、表示每個應用的Application以及每一個ApplicationMaster擁有多個Container在NodeManager上運行。
Mesos
Mesos是一款開源的集群管理軟體，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應用架構。
Redis
Redis是一種速度非常快的非關系資料庫，可以存儲鍵與5種不同類型的值之間的映射，可以將存儲在內存的鍵值對數據持久化到硬碟中，使用復制特性來擴展性能，還可以使用客戶端分片來擴展寫性能。
Atlas
Atlas是一個位於應用程序與MySQL之間的中間件。在後端DB看來，Atlas相當於連接它的客戶端，在前端應用看來，Atlas相當於一個DB。Atlas作為服務端與應用程序通訊，它實現了MySQL的客戶端和服務端協議，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。Atlas啟動後會創建多個線程，其中一個為主線程，其餘為工作線程。主線程負責監聽所有的客戶端連接請求，工作線程只監聽主線程的命令請求。
Ku
Ku是圍繞Hadoop生態圈建立的存儲引擎，Ku擁有和Hadoop生態圈共同的設計理念，它運行在普通的伺服器上、可分布式規模化部署、並且滿足工業界的高可用要求。其設計理念為fast analytics on fast data。作為一個開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Ku不但提供了行級的插入、更新、刪除API，同時也提供了接近Parquet性能的批量掃描操作。使用同一份存儲，既可以進行隨機讀寫，也可以滿足數據分析的要求。Ku的應用場景很廣泛，比如可以進行實時的數據分析，用於數據可能會存在變化的時序數據應用等。
在數據存儲過程中，涉及到的數據表都是成千上百列，包含各種復雜的Query，推薦使用列式存儲方法，比如parquent,ORC等對數據進行壓縮。Parquet 可以支持靈活的壓縮選項，顯著減少磁碟上的存儲。
數據清洗
MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，」Map(映射)」和」Rece(歸約)」，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。
隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。
Oozie
Oozie是用於Hadoop平台的一種工作流調度引擎，提供了RESTful API介面來接受用戶的提交請求(提交工作流作業)，當提交了workflow後，由工作流引擎負責workflow的執行以及狀態的轉換。用戶在HDFS上部署好作業(MR作業)，然後向Oozie提交Workflow，Oozie以非同步方式將作業(MR作業)提交給Hadoop。這也是為什麼當調用Oozie 的RESTful介面提交作業之後能立即返回一個JobId的原因，用戶程序不必等待作業執行完成(因為有些大作業可能會執行很久(幾個小時甚至幾天))。Oozie在後台以非同步方式，再將workflow對應的Action提交給hadoop執行。
Azkaban
Azkaban也是一種工作流的控制引擎，可以用來解決有多個hadoop或者spark等離線計算任務之間的依賴關系問題。azkaban主要是由三部分構成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban將大多數的狀態信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、認證、調度以及對工作流執行過程中的監控等;Azkaban Executor Server用來調度工作流和任務，記錄工作流或者任務的日誌。
流計算任務的處理平台Sloth，是網易首個自研流計算平台，旨在解決公司內各產品日益增長的流計算需求。作為一個計算服務平台，其特點是易用、實時、可靠，為用戶節省技術方面(開發、運維)的投入，幫助用戶專注於解決產品本身的流計算需求
數據查詢分析
Hive
Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。Hive本身不存儲和計算數據，它完全依賴於HDFS和MapRece。可以將Hive理解為一個客戶端工具，將SQL操作轉換為相應的MapRece jobs，然後在hadoop上面運行。Hive支持標準的SQL語法，免去了用戶編寫MapRece程序的過程，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece 、編程能力較弱與不擅長Java語言的用戶能夠在HDFS大規模數據集上很方便地利用SQL 語言查詢、匯總、分析數據。
Hive是為大數據批量處理而生的，Hive的出現解決了傳統的關系型資料庫(MySql、Oracle)在大數據處理上的瓶頸 。Hive 將執行計劃分成map->shuffle->rece->map->shuffle->rece…的模型。如果一個Query會被編譯成多輪MapRece，則會有更多的寫中間結果。由於MapRece執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。在Hive的運行過程中，用戶只需要創建表，導入數據，編寫SQL分析語句即可。剩下的過程由Hive框架自動的完成。
Impala
Impala是對Hive的一個補充，可以實現高效的SQL查詢。使用Impala來實現SQL on Hadoop，用來進行大數據實時查詢分析。通過熟悉的傳統關系型資料庫的SQL風格來操作大數據，同時數據也是可以存儲到HDFS和HBase中的。Impala沒有再使用緩慢的Hive+MapRece批處理，而是通過使用與商用並行關系資料庫中類似的分布式查詢引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分組成)，可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。Impala將整個查詢分成一執行計劃樹，而不是一連串的MapRece任務，相比Hive沒了MapRece啟動時間。
Hive 適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢，Impala給數據人員提供了快速實驗，驗證想法的大數據分析工具，可以先使用Hive進行數據轉換處理，之後使用Impala在Hive處理好後的數據集上進行快速的數據分析。總的來說：Impala把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的map->rece模式，以此保證Impala有更好的並發性和避免不必要的中間sort與shuffle。但是Impala不支持UDF，能處理的問題有一定的限制。
Spark
Spark擁有Hadoop MapRece所具有的特點，它將Job中間輸出結果保存在內存中，從而不需要讀取HDFS。Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。Spark 是在 Scala 語言中實現的，它將 Scala 用作其應用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。
Nutch
Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬蟲。
Solr
Solr用Java編寫、運行在Servlet容器(如Apache Tomcat或Jetty)的一個獨立的企業級搜索應用的全文搜索伺服器。它對外提供類似於Web-service的API介面，用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML文件，生成索引;也可以通過Http Get操作提出查找請求，並得到XML格式的返回結果。
Elasticsearch
Elasticsearch是一個開源的全文搜索引擎，基於Lucene的搜索伺服器，可以快速的儲存、搜索和分析海量的數據。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。
還涉及到一些機器學習語言，比如，Mahout主要目標是創建一些可伸縮的機器學習演算法，供開發人員在Apache的許可下免費使用;深度學習框架Caffe以及使用數據流圖進行數值計算的開源軟體庫TensorFlow等，常用的機器學習演算法比如，貝葉斯、邏輯回歸、決策樹、神經網路、協同過濾等。
數據可視化
對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。主流的BI平台比如，國外的敏捷BI Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數等。
在上面的每一個階段，保障數據的安全是不可忽視的問題。
基於網路身份認證的協議Kerberos，用來在非安全網路中，對個人通信以安全的手段進行身份認證，它允許某實體在非安全網路環境下通信，向另一個實體以一種安全的方式證明自己的身份。
控制許可權的ranger是一個Hadoop集群許可權框架，提供操作、監控、管理復雜的數據許可權，它提供一個集中的管理機制，管理基於yarn的Hadoop生態圈的所有數據許可權。可以對Hadoop生態的組件如Hive，Hbase進行細粒度的數據訪問控制。通過操作Ranger控制台，管理員可以輕松的通過配置策略來控制用戶訪問HDFS文件夾、HDFS文件、資料庫、表、欄位許可權。這些策略可以為不同的用戶和組來設置，同時許可權可與hadoop無縫對接。
簡單說有三大核心技術：拿數據，算數據，賣數據。
Ⅳ elasticsearch 在大數據中能實現哪些功能
由於需要提升項目的搜索質量，最近研究了一下Elasticsearch，一款非常優秀的分布式搜索程序。最開始的一些筆記放到github，這里只是歸納總結一下。
首先，為什麼要使用Elasticsearch？最開始的時候，我們的項目僅僅使用MySQL進行簡單的搜索，然後一個不能索引的like語句，直接拉低MySQL的性能。後來，我們曾考慮過sphinx，並且sphinx也在之前的項目中成功實施過，但想想現在的數據量級，多台MySQL，以及搜索服務本身HA，還有後續擴容的問題，我們覺得sphinx並不是一個最優的選擇。於是自然將目光放到了Elasticsearch上面。
根據官網自己的介紹，Elasticsearch是一個分布式搜索服務，提供Restful API，底層基於Lucene，採用多shard的方式保證數據安全，並且提供自動resharding的功能，加之github等大型的站點也採用 Elasticsearch作為其搜索服務，我們決定在項目中使用Elasticsearch。
對於Elasticsearch，如果要在項目中使用，需要解決如下問題：
索引，對於需要搜索的數據，如何建立合適的索引，還需要根據特定的語言使用不同的analyzer等。
搜索，Elasticsearch提供了非常強大的搜索功能，如何寫出高效的搜索語句？
數據源，我們所有的數據是存放到MySQL的，MySQL是唯一數據源，如何將MySQL的數據導入到Elasticsearch？
對於1和2，因為我們的數據都是從MySQL生成，index的field是固定的，主要做的工作就是根據業務場景設計好對應的mapping以及search語句就可以了，當然實際不可能這么簡單，需要我們不斷的調優。
而對於3，則是需要一個工具將MySQL的數據導入Elasticsearch，因為我們對搜索實時性要求很高，所以需要將MySQL的增量數據實時導入，筆者唯一能想到的就是通過row based binlog來完成。而近段時間的工作，也就是實現一個MySQL增量同步到Elasticsearch的服務。
Lucene
Elasticsearch底層是基於Lucene的，Lucene是一款優秀的搜索lib，當然，筆者以前仍然沒有接觸使用過。:-)
Lucene關鍵概念：
Document：用來索引和搜索的主要數據源，包含一個或者多個Field，而這些Field則包含我們跟Lucene交互的數據。
Field：Document的一個組成部分，有兩個部分組成，name和value。
Term：不可分割的單詞，搜索最小單元。
Token：一個Term呈現方式，包含這個Term的內容，在文檔中的起始位置，以及類型。
Lucene使用Inverted index來存儲term在document中位置的映射關系。
譬如如下文檔：
Elasticsearch Server 1.0 （document 1）
Mastring Elasticsearch （document 2）
Apache Solr 4 Cookbook （document 3）
使用inverted index存儲，一個簡單地映射關系：
Term
Count
Docuemnt
1.0 1 <1>
4 1 <3>
Apache 1 <3>
Cookbook 1 <3>
Elasticsearch 2 <1>.<2>
Mastering 1 <2>
Server 1 <1>
Solr 1 <3>
對於上面例子，我們首先通過分詞演算法將一個文檔切分成一個一個的token，再得到該token與document的映射關系，並記錄token出現的總次數。這樣就得到了一個簡單的inverted index。
Elasticsearch關鍵概念
要使用Elasticsearch，筆者認為，只需要理解幾個基本概念就可以了。
在數據層面，主要有：
Index：Elasticsearch用來存儲數據的邏輯區域，它類似於關系型資料庫中的db概念。一個index可以在一個或者多個shard上面，同時一個shard也可能會有多個replicas。
Document：Elasticsearch裡面存儲的實體數據，類似於關系數據中一個table裡面的一行數據。
document由多個field組成，不同的document裡面同名的field一定具有相同的類型。document裡面field可以重復出現，也就是一個field會有多個值，即multivalued。
Document type：為了查詢需要，一個index可能會有多種document，也就是document type，但需要注意，不同document裡面同名的field一定要是相同類型的。
Mapping：存儲field的相關映射信息，不同document type會有不同的mapping。
對於熟悉MySQL的童鞋，我們只需要大概認為Index就是一個db，document就是一行數據，field就是table的column，mapping就是table的定義，而document type就是一個table就可以了。
Document type這個概念其實最開始也把筆者給弄糊塗了，其實它就是為了更好的查詢，舉個簡單的例子，一個index，可能一部分數據我們想使用一種查詢方式，而另一部分數據我們想使用另一種查詢方式，於是就有了兩種type了。不過這種情況應該在我們的項目中不會出現，所以通常一個index下面僅會有一個 type。
在服務層面，主要有：
Node: 一個server實例。
Cluster：多個node組成cluster。
Shard：數據分片，一個index可能會存在於多個shards，不同shards可能在不同nodes。
Replica：shard的備份，有一個primary shard，其餘的叫做replica shards。
Elasticsearch之所以能動態resharding，主要在於它最開始就預先分配了多個shards（貌似是1024），然後以shard為單位進行數據遷移。這個做法其實在分布式領域非常的普遍，codis就是使用了1024個slot來進行數據遷移。
因為任意一個index都可配置多個replica，通過冗餘備份的方式保證了數據的安全性，同時replica也能分擔讀壓力，類似於MySQL中的slave。
Restful API
Elasticsearch提供了Restful API，使用json格式，這使得它非常利於與外部交互，雖然Elasticsearch的客戶端很多，但筆者仍然很容易的就寫出了一個簡易客戶端用於項目中，再次印證了Elasticsearch的使用真心很容易。
Restful的介面很簡單，一個url表示一個特定的資源，譬如/blog/article/1，就表示一個index為blog，type為aritcle，id為1的document。
而我們使用http標准method來操作這些資源，POST新增，PUT更新，GET獲取，DELETE刪除，HEAD判斷是否存在。
這里，友情推薦httpie，一個非常強大的http工具，個人感覺比curl還用，幾乎是命令行調試Elasticsearch的絕配。
一些使用httpie的例子:
# create
http POST :9200/blog/article/1 title="hello elasticsearch" tags:='["elasticsearch"]'
# get
http GET :9200/blog/article/1
# update
http PUT :9200/blog/article/1 title="hello elasticsearch" tags:='["elasticsearch", "hello"]'
# delete
http DELETE :9200/blog/article/1
# exists
http HEAD :9200/blog/article/1
索引和搜索
雖然Elasticsearch能自動判斷field類型並建立合適的索引，但筆者仍然推薦自己設置相關索引規則，這樣才能更好為後續的搜索服務。
我們通過定製mapping的方式來設置不同field的索引規則。
而對於搜索，Elasticsearch提供了太多的搜索選項，就不一一概述了。
索引和搜索是Elasticsearch非常重要的兩個方面，直接關繫到產品的搜索體驗，但筆者現階段也僅僅是大概了解了一點，後續在詳細介紹。
同步MySQL數據
Elasticsearch是很強大，但要建立在有足量數據情況下面。我們的數據都在MySQL上面，所以如何將MySQL的數據導入Elasticsearch就是筆者最近研究的東西了。
雖然現在有一些實現，譬如elasticsearch-river-jdbc，或者elasticsearch-river-mysql，但筆者並不打算使用。
elasticsearch-river-jdbc的功能是很強大，但並沒有很好的支持增量數據更新的問題，它需要對應的表只增不減，而這個幾乎在項目中是不可能辦到的。
elasticsearch-river-mysql倒是做的很不錯，採用了python-mysql-replication來通過binlog獲取變更的數據，進行增量更新，但它貌似處理MySQL mp數據導入的問題，不過這個筆者真的好好確認一下？話說，python-mysql-replication筆者還提交過pull解決了minimal row image的問題，所以對elasticsearch-river-mysql這個項目很有好感。只是筆者決定自己寫一個出來。
為什麼筆者決定自己寫一個，不是因為筆者喜歡造輪子，主要原因在於對於這種MySQL syncer服務（增量獲取MySQL數據更新到相關系統），我們不光可以用到Elasticsearch上面，而且還能用到其他服務，譬如cache上面。所以筆者其實想實現的是一個通用MySQL syncer組件，只是現在主要關注Elasticsearch罷了。
項目代碼在這里go-mysql-elasticsearch，現已完成第一階段開發，內部對接測試中。
go-mysql-elasticsearch的原理很簡單，首先使用mysqlmp獲取當前MySQL的數據，然後在通過此時binlog的name和position獲取增量數據。
一些限制：
binlog一定要變成row-based format格式，其實我們並不需要擔心這種格式的binlog佔用太多的硬碟空間，MySQL 5.6之後GTID模式都推薦使用row-based format了，而且通常我們都會把控SQL語句質量，不允許一次性更改過多行數據的。
需要同步的table最好是innodb引擎，這樣mysqlmp的時候才不會阻礙寫操作。
需要同步的table一定要有主鍵，好吧，如果一個table沒有主鍵，筆者真心會懷疑設計這個table的同學編程水平了。多列主鍵也是不推薦的，筆者現階段不打算支持。
一定別動態更改需要同步的table結構，Elasticsearch只能支持動態增加field，並不支持動態刪除和更改field。通常來說，如果涉及到alter table，很多時候已經證明前期設計的不合理以及對於未來擴展的預估不足了。
更詳細的說明，等到筆者完成了go-mysql-elasticsearch的開發，並通過生產環境中測試了，再進行補充。
總結
最近一周，筆者花了不少時間在Elasticsearch上面，現在算是基本入門了。其實筆者覺得，對於一門不懂的技術，找一份靠譜的資料（官方文檔或者入門書籍），蛋疼的對著資料敲一遍代碼，不懂的再問google，最後在將其用到實際項目，這門技術就算是初步掌握了，當然精通還得在下點功夫。
現在筆者只是覺得Elasticsearch很美好，上線之後鐵定會有坑的，那時候只能慢慢填了。話說，筆者是不是要學習下java了，省的到時候看不懂代碼就慘了。:-)