hbase去中心化
❶ 如何建立一個完整可用的安全大數據平台
「
要建立一個大數據系統，我們需要從數據流的源頭跟蹤到最後有價值的輸出，並在現有的Hadoop和大數據生態圈內根據實際需求挑選並整合各部分合適的組件來構建一個能夠支撐多種查詢和分析功能的系統平台。這其中既包括了對數據存儲的選擇，也涵蓋了數據線上和線下處理分離等方面的思考和權衡。此外，沒有任何一個引入大數據解決方案的商業應用在生產環境上承擔的起安全隱患。
1
計算框架篇
大數據的價值
只有在能指導人們做出有價值的決定時，數據才能體現其自身的價值。因此，大數據技術要服務於實際的用途，才是有意義的。一般來說，大數據可以從以下三個方面指導人們做出有價值的決定：
報表生成（比如根據用戶歷史點擊行為的跟蹤和綜合分析、 應用程序活躍程度和用戶粘性計算等）；
診斷分析（例如分析為何用戶粘性下降、根據日誌分析系統為何性能下降、垃圾郵件以及病毒的特徵檢測等）；
決策（例如個性化新聞閱讀或歌曲推薦、預測增加哪些功能能增加用戶粘性、幫助廣告主進行廣告精準投放、設定垃圾郵件和病毒攔截策略等）。
圖 1
進一步來看，大數據技術從以下三個方面解決了傳統技術難以達成的目標（如圖1）：
在歷史數據上的低延遲（互動式）查詢，目標是加快決策過程和時間， 例如分析一個站點為何變緩慢並嘗試修復它；
在實時數據上的低延遲查詢，目的是幫助用戶和應用程序在實時數據上做出決策， 例如實時檢測並阻攔病毒蠕蟲（一個病毒蠕蟲可以在1.3秒內攻擊1百萬台主機）；
更加精細高級的數據處理演算法，這可以幫助用戶做出「更好」的決策， 例如圖數據處理、異常點檢測、趨勢分析及其他機器學習演算法。
蛋糕模式
從將數據轉換成價值的角度來說，在Hadoop生態圈十年蓬勃成長的過程中，YARN和Spark這二者可以算得上是里程碑事件。Yarn的出現使得集群資源管理和數據處理流水線分離，大大革新並推動了大數據應用層面各種框架的發展（SQL on Hadoop框架, 流數據，圖數據，機器學習）。
它使得用戶不再受到MapRece開發模式的約束，而是可以創建種類更為豐富的分布式應用程序，並讓各類應用程序運行在統一的架構上，消除了為其他框架維護獨有資源的開銷。就好比一個多層蛋糕，下面兩層是HDFS和Yarn, 而MapRece就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。
在這一架構體系中，總體數據處理分析作業分三塊（圖2），在HBase上做互動式查詢（Apache Phoenix, Cloudera Impala等）， 在歷史數據集上編寫MapRece程序抑或利用Hive等做批處理業務， 另外對於實時流數據分析Apache Storm則會是一種標准選擇方案。
雖然Yarn的出現極大地豐富了Hadoop生態圈的應用場景，但仍存有兩個顯而易見的挑戰：一是在一個平台上需要維護三個開發堆棧；二是在不同框架內很難共享數據，比如很難在一個框架內對流數據做互動式查詢。這也意味著我們需要一個更為統一和支持更好抽象的計算框架的出現。
圖 2
一統江湖
Spark的出現使得批處理任務，互動式查詢，實時流數據處理被整合到一個統一的框架內（圖3），同時Spark和現有的開源生態系統也能夠很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。 通過啟用內存分布數據集，優化迭代工作負載， 用戶能夠更簡單地操作數據，並在此基礎上開發更為精細的演算法，如機器學習和圖演算法等。
有三個最主要的原因促使Spark目前成為了時下最火的大數據開源社區（擁有超過來自200多個公司的800多個contributors）：
Spark可以擴展部署到超過8000節點並處理PB級別的數據，同時也提供了很多不錯的工具供應用開發者進行管理和部署；
Spark提供了一個互動式shell供開發者可以用Scala或者Python即時性試驗不同的功能；
Spark提供了很多內置函數使得開發者能夠比較容易地寫出低耦合的並且能夠並發執行的代碼，這樣開發人員就更能集中精力地為用戶提供更多的業務功能而不是花費時間在優化並行化代碼之上。
當然Spark也和當年的MapRece一樣不是萬靈葯，比如對實時性要求很高的流數據處理上Apache Storm還是被作為主流選擇， 因為Spark Streaming實際上是microbatch（將一個流數據按時間片切成batch,每個batch提交一個job）而不是事件觸發實時系統，所以雖然支持者們認為microbatch在系統延時性上貢獻並不多，但在生產環境中和Apache Storm相比還不是特別能滿足對低延時要求很高的應用場景。
比如在實踐過程中， 如果統計每條消息的平均處理時間，很容易達到毫秒級別，但一旦統計類似service assurance（確保某條消息在毫秒基本能被處理完成）的指標， 系統的瓶頸有時還是不能避免。
但同時我們不能不注意到，在許多用例當中，與流數據的交互以及和靜態數據集的結合是很有必要的, 例如我們需要在靜態數據集上進行分類器的模型計算，並在已有分類器模型的基礎上，對實時進入系統的流數據進行交互計算來判定類別。
由於Spark的系統設計對各類工作（批處理、流處理以及互動式工作）進行了一個共有抽象，並且生態圈內延伸出了許多豐富的庫（MLlib機器學習庫、SQL語言API、GraphX）, 使得用戶可以在每一批流數據上進行靈活的Spark相關操作，在開發上提供了許多便利。
Spark的成熟使得Hadoop生態圈在短短一年之間發生了翻天覆地的變化， Cloudera和Hortonworks紛紛加入了Spark陣營，而Hadoop項目群中除了Yarn之外已經沒有項目是必須的了（雖然Mesos已在一些場合替代了Yarn）, 因為就連HDFS，Spark都可以不依賴。但很多時候我們仍然需要像Impala這樣的依賴分布式文件系統的MPP解決方案並利用Hive管理文件到表的映射，因此Hadoop傳統生態圈依然有很強的生命力。
另外在這里簡要對比一下互動式分析任務中各類SQL on Hadoop框架，因為這也是我們在實際項目實施中經常遇到的問題。我們主要將注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中歷史最短的，論文發表在15年的SIGMOD會議上， 原文對比了數據倉庫上不同類型的查詢在Shark（Spark最早對SQL介面提供的支持）、Spark SQL和Impala上的性能比較。
也就是說， 雖然Spark SQL在Shark的基礎上利用Catalyst optimizer在代碼生成上做了很多優化，但總體性能還是比不上Impala, 尤其是當做join操作的時候， Impala可以利用「predicate pushdown」更早對表進行選擇操作從而提高性能。
不過Spark SQL的Catalyst optimizer一直在持續優化中，相信未來會有更多更好的進展。Cloudera的Benchmark評測中Impala一直比其他SQL on Hadoop框架性能更加優越，但同時Hortonworks評測則指出雖然單個數據倉庫查詢Impala可以在很短的時間內完成，但是一旦並發多個查詢Hive on Tez的優勢就展示出來。另外Hive on Tez在SQL表達能力也要比Impala更強（主要是因為Impala的嵌套存儲模型導致的）， 因此根據不同的場景選取不同的解決方案是很有必要的。
圖 3
各領風騷抑或代有才人出？
近一年比較吸引人眼球的Apache Flink（與Spark一樣已有5年歷史，前身已經是柏林理工大學一個研究性項目，被其擁躉推崇為繼MapRece, Yarn，Spark之後第四代大數據分析處理框架）。 與Spark相反，Flink是一個真正的實時流數據處理系統，它將批處理看作是流數據的特例，同Spark一樣它也在嘗試建立一個統一的平台運行批量，流數據，互動式作業以及機器學習，圖演算法等應用。
Flink有一些設計思路是明顯區別於Spark的，一個典型的例子是內存管理，Flink從一開始就堅持自己精確的控制內存使用並且直接操作二進制數據，而Spark一直到1.5版本都還是試用java的內存管理來做數據緩存，這也導致了Spark很容易遭受OOM以及JVM GC帶來的性能損失。
但是從另外一個角度來說, Spark中的RDD在運行時被存成java objects的設計模式也大大降低了用戶編程設計門檻， 同時隨著Tungsten項目的引入，Spark現在也逐漸轉向自身的內存管理， 具體表現為Spark生態圈內從傳統的圍繞RDD（分布式java對象集合）為核心的開發逐漸轉向以DataFrame(分布式行對象集合)為核心。
總的來說，這兩個生態圈目前都在互相學習，Flink的設計基因更為超前一些，但Spark社區活躍度大很多，發展到目前毫無疑問是更為成熟的選擇，比如對數據源的支持（HBase, Cassandra, Parquet, JSON, ORC）更為豐富以及更為統一簡潔的計算表示。另一方面，Apache Flink作為一個由歐洲大陸發起的項目，目前已經擁有來自北美、歐洲以及亞洲的許多貢獻者，這是否能夠一改歐洲在開源世界中一貫的被動角色，我們將在未來拭目以待。
2
NoSQL資料庫篇
NoSQL資料庫在主流選擇上依舊集中在MongoDB, HBase和Cassandra這三者之間。在所有的NoSQL選擇中，用C 編寫的MongoDB幾乎應該是開發者最快也最易部署的選擇。MongoDB是一個面向文檔的資料庫，每個文檔／記錄／數據（包括爬取的網頁數據及其他大型對象如視頻等）是以一種BSON（Binary JSON）的二進制數據格式存儲, 這使得MongoDB並不需要事先定義任何模式, 也就是模式自由（可以把完全不同結構的記錄放在同一個資料庫里）。
MongoDB對於完全索引的支持在應用上是很方便的，同時也具備一般NoSQL分布式資料庫中可擴展，支持復制和故障恢復等功能。 MongoDB一般應用於高度伸縮性的緩存及大尺寸的JSON數據存儲業務中，但不能執行「JOIN」操作，而且數據佔用空間也比較大，最被用戶詬病的就是由於MongoDB提供的是資料庫級鎖粒度導致在一些情況下建索引操作會引發整個資料庫阻塞。一般來說，MongoDB完全可以滿足一些快速迭代的中小型項目的需求。
下面來主要談談Cassandra和HBase之間的比較選擇。Cassandra和HBase有著截然不同的基因血統。HBase和其底層依賴的系統架構源自於著名的Google FileSystem（發表於2003年）和Google BigTable設計（發表於2006年）， 其克服了HDFS注重吞吐量卻犧牲I/O的缺點，提供了一個存儲中間層使得用戶或者應用程序可以隨機讀寫數據。
具體來說，HBase的更新和刪除操作實際上是先發生在內存MemStore中， 當MemStore滿了以後會Flush到StoreFile, 之後當StoreFile文件數量增長到一定閾值後會觸發Compact合並操作，因此HBase的更新操作其實是不斷追加的操作，而最終所有更新和刪除數據的持久化操作都是在之後Compact過程中進行的。
這使得應用程序在向內存MemStore寫入數據後，所做的修改馬上就能得到反映，用戶讀到的數據絕不會是陳舊的數據，保證了I/O高性能和數據完全一致性； 另一方面來說， HBase基於Hadoop生態系統的基因就已經決定了他自身的高度可擴展性、容錯性。
在數據模型上，Cassandra和HBase類似實現了一個key-value提供面向列式存儲服務，其系統設計參考了 Amazon Dynamo (發表於2007年) 分布式哈希（DHT）的P2P結構（實際上大部分Cassandra的初始工作都是由兩位從Amazon的Dynamo組跳槽到Facebook的工程師完成)，同樣具有很高的可擴展性和容錯性等特點。
除此之外， 相對HBase的主從結構，Cassandra去中心化的P2P結構能夠更簡單地部署和維護，比如增加一台機器只需告知Cassandra系統新節點在哪，剩下的交給系統完成就行了。同時，Cassandra對多數據中心的支持也更好，如果需要在多個數據中心進行數據遷移Cassandra會是一個更優的選擇。
Eric Brewer教授提出的經典CAP理論認為任何基於網路的數據共享系統，最多隻能滿足數據一致性、可用性、分區容忍性三要素中的兩個要素。實際分布式系統的設計過程往往都是在一致性與可用性上進行取捨，相比於HBase數據完全一致性的系統設計，Cassandra選擇了在優先考慮數據可用性的基礎上讓用戶自己根據應用程序需求決定系統一致性級別。
比如：用戶可以配置QUONUM參數來決定系統需要幾個節點返回數據才能向客戶端做出響應，ONE指只要有一個節點返回數據就可以對客戶端做出響應，ALL指等於數據復制份數的所有節點都返回結果才能向客戶端做出響應，對於數據一致性要求不是特別高的可以選擇ONE，它是最快的一種方式。
從基因和發展歷史上來說，HBase更適合用做數據倉庫和大規模數據處理與分析（比如對網頁數據建立索引）， 而Cassandra則更適合用作實時事務和互動式查詢服務。Cassandra在國外市場佔有比例和發展要遠比國內紅火， 在不少權威測評網站上排名都已經超過了HBase。目前Apache Cassandra的商業化版本主要由軟體公司DataStax進行開發和銷售推廣。另外還有一些NoSQL分布式資料庫如Riak, CouchDB也都在各自支持的廠商推動下取得了不錯的發展。
雖然我們也考慮到了HBase在實際應用中的不便之處比如對二級索引的支持程度不夠（只支持通過單個行鍵訪問，通過行鍵的范圍查詢，全表掃描），不過在明略的大數據基礎平台上，目前整合的是依然是HBase。
理由也很簡單，HBase出身就與Hadoop的生態系統緊密集成，其能夠很容易與其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）進行整合，而不需要重新部署一套分布式資料庫系統，而且可以很方便地將同樣的數據內容在同一個生態系統中根據不同框架需要來變換存儲格式（比如存儲成Hive表或者Parquet格式）。
我們在很多項目中都有需要用到多種SQL on Hadoop框架，來應對不同應用場景的情況，也體會到了在同一生態系統下部署多種框架的簡便性。 但同時我們也遇到了一些問題， 因為HBase項目本身與HDFS和Zookeeper系統分別是由不同開源團隊進行維護的，所以在系統整合時我們需要先對HBase所依賴的其他模塊進行設置再對HBase進行配置，在一定程度上降低了系統維護的友好性。
目前我們也已經在考慮將Cassandra應用到一些新的客戶項目中，因為很多企業級的應用都需要將線上線下資料庫進行分離，HBase更適合存儲離線處理的結果和數據倉庫，而更適合用作實時事務和並發交互性能更好的Cassandra作為線上服務資料庫會是一種很好的選擇。
3
大數據安全篇
隨著越來越多各式各樣的數據被存儲在大數據系統中，任何對企業級數據的破壞都是災難性的，從侵犯隱私到監管違規，甚至會造成公司品牌的破壞並最終影響到股東收益。給大數據系統提供全面且有效的安全解決方案的需求已經十分迫切：
大數據系統存儲著許多重要且敏感的數據，這些數據是企業長久以來的財富
與大數據系統互動的外部系統是動態變化的，這會給系統引入新的安全隱患
在一個企業的內部，不同Business Units會用不同的方式與大數據系統進行交互，比如線上的系統會實時給集群推送數據、數據科學家團隊則需要分析存儲在數據倉庫內的歷史數據、運維團隊則會需要對大數據系統擁有管理許可權。
因此為了保護公司業務、客戶、財務和名譽免於被侵害，大數據系統運維團隊必須將系統安全高度提高到和其他遺留系統一樣的級別。同時大數據系統並不意味著引入大的安全隱患，通過精細完整的設計，仍然能夠把一些傳統的系統安全解決方案對接到最新的大數據集群系統中。
一般來說，一個完整的企業級安全框架包括五個部分：
Administration: 大數據集群系統的集中式管理，設定全局一致的安全策略
Authentication: 對用戶和系統的認證
Authorization：授權個人用戶和組對數據的訪問許可權
Audit：維護數據訪問的日誌記錄
Data Protection：數據脫敏和加密以達到保護數據的目的
系統管理員要能夠提供覆蓋以上五個部分的企業級安全基礎設施，否則任何一環的缺失都可能給整個系統引入安全性風險。
在大數據系統安全集中式管理平台這塊，由Hortonworks推出的開源項目Apache Ranger就可以十分全面地為用戶提供Hadoop生態圈的集中安全策略的管理，並解決授權(Authorization)和審計(Audit)。例如，運維管理員可以輕松地為個人用戶和組對文件、數據等的訪問策略，然後審計對數據源的訪問。
與Ranger提供相似功能的還有Cloudera推出的Apache Sentry項目，相比較而言Ranger的功能會更全面一些。
而在認證（Authentication）方面, 一種普遍採用的解決方案是將基於Kerberos的認證方案對接到企業內部的LDAP環境中， Kerberos也是唯一為Hadoop全面實施的驗證技術。
另外值得一提的是Apache Knox Gateway項目，與Ranger提高集群內部組件以及用戶互相訪問的安全不同，Knox提供的是Hadoop集群與外界的唯一交互介面，也就是說所有與集群交互的REST API都通過Knox處理。這樣，Knox就給大數據系統提供了一個很好的基於邊緣的安全（perimeter-based security）。
基於以上提到的五個安全指標和Hadoop生態圈安全相關的開源項目， 已經足已證明基於Hadoop的大數據平台我們是能夠構建一個集中、一致、全面且有效的安全解決方案。
我市再ITjob管網上面找的
❷ 大數據主要學什麼內容
一般來說，在一線城市，以BAT來說它們企業給應屆畢業生的起薪並不高，但只要工作拚命、能力出眾，事實上入職後的2、3年裡就很容易拿到15萬元以上的年薪。而在三線互聯網公司，同等條件下，普通技術員工的年薪一般能達到15萬元左右。而准二線的互聯網公司的普通員工薪水基本也能達到或超過20萬元，與許多傳統行業相比，這樣的收入水平絕對令人艷羨。工作經驗超過5年後，互聯網企業中的收入差距就會拉大。
如此誘人的薪資，肯定是人人都想加入的。但加入的條件就在於需要掌握一定的技能，綜合很多大數據公司的要求統計如下：
1、熟練使用SQL語言；
2、熟練使用Hadoop、M/R、Hive、Storm等開發工具；
3、熟悉Linux命令及Shell編程；
4、對數據敏感，良好的邏輯分析能力，良好溝通能力和團隊精神；
5、熟悉Impala、Druid、Mdrill、ElasticSearch等大數據工具者優先；
根據企業對大數據工程師的要求，你需要學習的技術如下：
階段一、大數據基礎——java語言基礎方面
（1）Java語言基礎
（2） HTML、CSS與JavaScript
（3）JavaWeb和資料庫
階段二、 Linux&Hadoop生態體系
Linux體系、Hadoop離線計算大綱、分布式資料庫Hbase、數據倉庫Hive、數據遷移工具Sqoop、Flume分布式日誌框架
階段三、 分布式計算框架和Spark&Strom生態體系
（1）分布式計算框架
Python編程語言、Scala編程語言、Spark大數據處理、Spark—Streaming大數據處理、Spark—Mlib機器學習、Spark—GraphX 圖計算、實戰一：基於Spark的推薦系統（某一線公司真實項目）、實戰二：新浪網（www.sina.com.cn）
（2）storm技術架構體系
Storm原理與基礎、消息隊列kafka、Redis工具、zookeeper詳解、實戰一：日誌告警系統項目、實戰二：猜你喜歡推薦系統實戰
階段四、 大數據項目實戰（一線公司真實項目）
數據獲取、數據處理、數據分析、數據展現、數據應用
階段五、 大數據分析 —AI（人工智慧）
Data Analyze工作環境准備&數據分析基礎、數據可視化、Python機器學習
1、Python機器學習2、圖像識別&神經網路、自然語言處理&社交網路處理、實戰項目：戶外設備識別分析
❸ 大數據工程師學哪些核心技術是什麼
【導讀】提起大數據大家都不陌生，是高薪的代名詞。因此吸引了不少零基礎和跨行業的的小夥伴想要進入到此行業，那麼大數據工程師學哪些?核心技術是什麼呢?為了幫助大家更好的融入到工作中，小編整理了以下幾點，希望對大家有所幫助。
一、大數據採集
大數據採集，即對各種來源的結構化和非結構化海量數據，所進行的採集。
資料庫採集：流行的有Sqoop和ETL，傳統的關系型資料庫MySQL和Oracle
也依然充當著許多企業的數據存儲方式。當然了，目前對於開源的Kettle和Talend本身，也集成了大數據集成內容，可實現hdfs，hbase和主流Nosq資料庫之間的數據同步和集成。
網路數據採集：一種藉助網路爬蟲或網站公開API，從網頁獲取非結構化或半結構化數據，並將其統一結構化為本地數據的數據採集方式。
文件採集：包括實時文件採集和處理技術flume、基於ELK的日誌採集和增量採集等等。
二、大數據預處理
大數據預處理，指的是在進行數據分析之前，先對採集到的原始數據所進行的諸如「清洗、填補、平滑、合並、規格化、一致性檢驗」等一系列操作，旨在提高數據質量，為後期分析工作奠定基礎。數據預處理主要包括四個部分：數據清理、數據集成、數據轉換、數據規約。
三、大數據儲存
大數據每年都在激增龐大的信息量,加上已有的歷史數據信息,對整個業界的數據存儲、處理帶來了很大的機遇與挑戰.為了滿足快速增長的存儲需求,雲存儲需要具備高擴展性、高可靠性、高可用性、低成本、自動容錯和去中心化等特點.常見的雲存儲形式可以分為分布式文件系統和分布式資料庫。其中,分布式文件系統採用大規模的分布式存儲節點來滿足存儲大量文件的需求,而分布式的NoSQL資料庫則為大規模非結構化數據的處理和分析提供支持。
四、大數據清洗
MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，」Map(映射)」和」Rece(歸約)」，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。
五、大數據查詢分析
Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive
SQL)查詢功能。Hive本身不存儲和計算數據，它完全依賴於HDFS和MapRece。可以將Hive理解為一個客戶端工具，將SQL操作轉換為相應的MapRece
jobs，然後在hadoop上面運行。Hive支持標準的SQL語法，免去了用戶編寫MapRece程序的過程，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece
、編程能力較弱與不擅長Java語言的用戶能夠在HDFS大規模數據集上很方便地利用SQL 語言查詢、匯總、分析數據。
六、大數據可視化
大規模數據的可視化主要是基於並行演算法設計的技術，合理利用有限的計算資源，高效地處理和分析特定數據集的特性。通常情況下，大規模數據可視化的技術會結合多解析度表示等方法，以獲得足夠的互動性能。
在科學大規模數據的並行可視化工作中，主要涉及數據流線化、任務並行化、管道並行化和數據並行化4 種基本技術。
以上就是小編今天給大家整理發送的關於「大數據工程師學哪些?核心技術是什麼?」的相關內容，希望對大家有所幫助。想了解更多關於數據分析及人工智慧就業崗位分析，關注小編持續更新。
❹ Hadoop如何處理非結構化數據
非結構化資料庫是指其欄位長度可變，並且每個欄位的記錄又可以由可重復或不可重復的子欄位構成的資料庫，用它不僅可以處理結構化數據（如數字、符號等信息）而且更適合處理非結構化數據（全文文本、圖像、聲音、影視、超媒體等信息）。
面對海量非結構數據存儲，杉岩海量對象存儲MOS，提供完整解決方案，採用去中心化、分布式技術架構，支持百億級文件及EB級容量存儲，具備高效的數據檢索、智能化標簽和分析能力，輕松應對大數據和雲時代的存儲挑戰，為企業發展提供智能決策。
❺ 大數據工程師需要學哪些技術
一、大數據採集
大數據採集，即對各種來源的結構化和非結構化海量數據，所進行的採集。
資料庫採集：流行的有Sqoop和ETL，傳統的關系型資料庫MySQL和Oracle 也依然充當著許多企業的數據存儲方式。當然了，目前對於開源的Kettle和Talend本身，也集成了大數據集成內容，可實現hdfs，hbase和主流Nosq資料庫之間的數據同步和集成。
網路數據採集：一種藉助網路爬蟲或網站公開API，從網頁獲取非結構化或半結構化數據，並將其統一結構化為本地數據的數據採集方式。
文件採集：包括實時文件採集和處理技術flume、基於ELK的日誌採集和增量採集等等。
二、大數據預處理
大數據預處理，指的是在進行數據分析之前，先對採集到的原始數據所進行的諸如“清洗、填補、平滑、合並、規格化、一致性檢驗”等一系列操作，旨在提高數據質量，為後期分析工作奠定基礎。數據預處理主要包括四個部分：數據清理、數據集成、數據轉換、數據規約。
三、大數據儲存
大數據每年都在激增龐大的信息量,加上已有的歷史數據信息,對整個業界的數據存儲、處理帶來了很大的機遇與挑戰.為了滿足快速增長的存儲需求,雲存儲需要具備高擴展性、高可靠性、高可用性、低成本、自動容錯和去中心化等特點.常見的雲存儲形式可以分為分布式文件系統和分布式資料庫。其中,分布式文件系統採用大規模的分布式存儲節點來滿足存儲大量文件的需求,而分布式的NoSQL資料庫則為大規模非結構化數據的處理和分析提供支持。
四、大數據清洗
MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，”Map(映射)”和”Rece(歸約)”，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。
關於大數據工程師需要學哪些技術，青藤小編就和您分享到這里了。如果您對大數據工程有濃厚的興趣，希望這篇文章可以為您提供幫助。如果您還想了解更多關於數據分析師、大數據工程師的技巧及素材等內容，可以點擊本站的其他文章進行學習。
❻ 淘寶為什麼使用HBase及如何優化的
1 前言
hbase是從hadoop中 分離出來的apache頂級開源項目。由於它很好地用java實現了google的bigtable系統大部分特性，因此在數據量猛增的今天非常受到歡 迎。對於淘寶而言，隨著市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效插入和讀取變得越來越重要。由於淘寶擁有也許是國內最大 的單一hadoop集群(雲梯)，因此對hadoop系列的產品有比較深入的了解，也就自然希望使用hbase來做這樣一種海量數據讀寫服務。本篇文章將 對淘寶最近一年來在online應用上使用和優化hbase的情況做一次小結。
2 原因
為什麼要使用hbase？
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。
但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：
a) 數據量變得越來越多，事實上現在淘寶幾乎任何一個與用戶相關的在線業務的數據量都在億級別，每日系統調用次數從億到百億都有，且歷史數據不能輕易刪除。這需要有一個海量分布式文件系統，能對TB級甚至PB級別的數據提供在線服務
b) 數據量的增長很快且不一定能准確預計，大多數應用系統從上線起在一段時間內數據量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴展能力有比較強烈的需求，且不希望存在單點制約
c) 只需要簡單的kv讀取，沒有復雜的join等需求。但對系統的並發能力以及吞吐量、響應延時有非常高的需求，並且希望系統能夠保持強一致性
d) 通常系統的寫入非常頻繁，尤其是大量系統依賴於實時的日誌分析
e) 希望能夠快速讀取批量數據
f ) schema靈活多變，可能經常更新列屬性或新增列
g) 希望能夠方便使用，有良好且語義清晰的java介面
以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。首先它的數據由hdfs天然地做了數據冗餘，雲梯三年的穩定運行，數據100%可靠 己經證明了hdfs集群的安全性，以及服務於海量數據的能力。其次hbase本身的數據讀寫服務沒有單點的限制，服務能力可以隨伺服器的增長而線性增長， 達到幾十上百台的規模。LSM-Tree模式的設計讓hbase的寫入性能非常良好，單次寫入通常在1-3ms內即可響應完成，且性能不隨數據量的增長而 下降。
region（相當於資料庫的分表）可以ms級動態的切分和移動，保證了負載均衡性。由於hbase上的數據模型是按rowkey排序存儲的，而讀 取時會一次讀取連續的整塊數據做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要1次io就能獲取幾十上百條用戶想要的 數據。最後，淘寶大部分工程師是java背景的同學，因此hbase的api對於他們來說非常容易上手，培訓成本相對較低。
當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是 單點的，單台機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。
3 應用情況
我們從2011年3月開始研究hbase如何用於在線服務。盡管之前在一淘搜索中己經有了幾十節點的離線服務。這是因為hbase早期版本的目標就 是一個海量數據中的離線服務。2009年9月發布的0.20.0版本是一個里程碑，online應用正式成為了hbase的目標，為此hbase引入了 zookeeper來做為backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一個里程碑，基本上我們今天 看到的各大網站，如facebook/ebay/yahoo內所使用於生產的hbase都是基於這一個版本(fb所採用的0.89版本結構與0.90.x 相近)。bloomfilter等諸多屬性加入了進來，性能也有極大提升。基於此，淘寶也選用了0.90.x分支作為線上版本的基礎。
第一個上線的應用是數據魔方中的prom。prom原先是基於redis構建的，因為數據量持續增大以及需求的變化，因此我們用hbase重構了它 的存儲層。准確的說prom更適合0.92版本的hbase，因為它不僅需要高速的在線讀寫，更需要count/group by等復雜應用。但由於當時0.92版本尚未成熟，因此我們自己單獨實現了coprocessor。prom的數據導入是來源於雲梯，因此我們每天晚上花 半個小時將數據從雲梯上寫入hbase所在的hdfs，然後在web層做了一個client轉發。經過一個月的數據比對，確認了速度比之redis並未有 明顯下降，以及數據的准確性，因此得以順利上線。
第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數據傳輸平台，廣泛應用於實時日誌收集、數據實 時監控、廣告效果實時反饋、資料庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態的數據增加使hbase上compact/balance /split/recovery等諸多特性受到了極大的挑戰。TT的寫入量大約一天20TB，讀的量約為此的1.5倍，我們為此准備了20台 regionserver的集群，當然底層的hdfs是公用的，數量更為龐大（下文會提到）。每天TT會為不同的業務在hbase上建不同的表，然後往該 表上寫入數據，即使我們將region的大小上限設為1GB，最大的幾個業務也會達到數千個region這樣的規模，可以說每一分鍾都會有數次 split。在TT的上線過程中，我們修復了hbase很多關於split方面的bug，有好幾個commit到了hbase社區，同時也將社區一些最新 的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數據丟失最大的風險之一，這一點對於每個想使用hbase的開發者來 說必須牢記。hbase由於採用了LSM-Tree模型，從架構原理上來說數據幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因後面會 單獨強調。TT在預發過程中我們分別因為Meta表損壞以及split方面的bug曾經丟失過數據，因此也單獨寫了meta表恢復工具，確保今後不發生類 似問題(hbase-0.90.5以後的版本都增加了類似工具)。另外，由於我們存放TT的機房並不穩定，發生過很多次宕機事故，甚至發生過假死現象。因 此我們也著手修改了一些patch，以提高宕機恢復時間，以及增強了監控的強度。
CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現在一般歸 納為四類原因：網路原因、gc問題、命中率以及client的反序列化問題。我們現在對它們做了一些解決方案(後面會有介紹)，以更好地對慢響應有控制 力。
和Facebook類似，我們也使用了hbase做為實時計算類項目的存儲層。目前對內部己經上線了部分實時項目，比如實時頁面點擊系 統，galaxy實時交易推薦以及直播間等內部項目，用戶則是散布到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式 做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數據，同時關聯商品表等維度表計算排行(TopN)，而實時頁面點擊系統則是 基於twitter開源的storm進行開發，後台通過TT獲取實時的日誌數據，計算流將中間結果以及動態維表持久化到hbase上，比如我們將 rowkey設計為url+userid，並讀出實時的數據，從而實現實時計算各個維度上的uv。
最後要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由於它關繫到 己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數據丟失以及服務中斷是零容忍。它對compact做了優化，避免大數據量的compact在 服務時間內發生。新增了定製的filter來實現分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗餘數據的傳輸以及90%以上的讀轉化成了順序 讀。目前該集群存儲了超過百億的訂單數據以及數千億的索引數據，線上故障率為0。
隨著業務的發展，目前我們定製的hbase集群己經應用到了線上超過二十個應用，數百台伺服器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。
4 部署、運維和監控
Facebook之前曾經透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集群按用戶分為數 個集群，每個集群100台伺服器，擁有一台namenode以及分為5個機架，每個機架上一台zookeeper。可以說對於大數據量的服務這是一種優良 的架構。對於淘寶來說，由於數據量遠沒有那麼大，應用也沒有那麼核心，因此我們採用公用hdfs以及zookeeper集群的架構。每個hdfs集群盡量 不超過100台規模（這是為了盡量限制namenode單點問題）。在其上架設數個hbase集群，每個集群一個master以及一個 backupmaster。公用hdfs的好處是可以盡量減少compact的影響，以及均攤掉硬碟的成本，因為總有集群對磁碟空間要求高，也總有集群對 磁碟空間要求低，混合在一起用從成本上是比較合算的。zookeeper集群公用，每個hbase集群在zk上分屬不同的根節點。通過zk的許可權機制來保 證hbase集群的相互獨立。zk的公用原因則僅僅是為了運維方便。
由於是在線應用，運維和監控就變得更加重要，由於之前的經驗接近0，因此很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養。以下講一些我們的運維和監控經驗。
我們定製的hbase很重要的一部分功能就是增加監控。hbase本身可以發送ganglia監控數據，只是監控項遠遠不夠，並且ganglia的 展示方式並不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監控點，比如compact/split/balance/flush隊列以及各個階 段的耗時、讀寫各個階段的響應時間、讀寫次數、region的open/close，以及具體到表和region級別的讀寫次數等等。仍然將它們通過 socket的方式發送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數據的精度會越來越低，因此我們自己編寫 程序從rrd中讀出相應的數據並持久化到其它地方，然後自己用js實現了一套監控界面，將我們關心的數據以趨勢圖、餅圖等各種方式重點匯總和顯示出來，並 且可以無精度損失地查看任意歷史數據。在顯示的同時會把部分非常重要的數據，如讀寫次數、響應時間等寫入資料庫，實現波動報警等自定義的報警。經過以上措 施，保證了我們總是能先於用戶發現集群的問題並及時修復。我們利用redis高效的排序演算法實時地將每個region的讀寫次數進行排序，能夠在高負載的 情況下找到具體請求次數排名較高的那些region，並把它們移到空閑的regionserver上去。在高峰期我們能對上百台機器的數十萬個 region進行實時排序。
為了隔離應用的影響，我們在代碼層面實現了可以檢查不同client過來的連接，並且切斷某些client的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。maprece的應用也會控制在低峰期運行，比如在白天我們會關閉jobtracker等。
此外，為了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重 的工操作，因此盡量減少hbck的調用次數，盡量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外為了確保 hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。
我們會每天根蹤所有線上伺服器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低為0。另外 每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。盡管並不是每一次error都會引發問題，甚至大部分error都只是分布式系統中的正常現 象，但明白它們問題的原因是非常重要的。
5 測試與發布
因為是未知的系統，我們從一開始就非常注重測試。測試從一開始就分為性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀 寫比例，不同k/v大小，不同列族數，不同命中率，是否做presharding等等。每次運行都會持續數小時以得到准確的結果。因此我們寫了一套自動化 系統，從web上選擇不同的場景，後台會自動將測試參數傳到各台伺服器上去執行。由於是測試分布式系統，因此client也必須是分布式的。
我們判斷測試是否准確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來 的事實證明它非常有意義。因為我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被准確捕捉到，又比如某次代碼修改 使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。
功能測試上則主要是介面測試和異常測試。介面測試一般作用不是很明顯，因為hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要， 我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受 到了重視和commit。分布式系統設計的難點和復雜度都在異常處理上，我們必須認為系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查 看代碼大體定位到問題以後，在代碼層面強行拋出異常來復現它。事實證明這非常有用。
為了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每台伺服器上抓取相應的日誌並按一定規律匯總。這非常重要，避免浪費大量的時間到登錄不同的伺服器以尋找一個bug的線索。
由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發布模式。它既要避免頻繁的發布引起的不穩定，又要 避免長期不發布導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩周從內部trunk上release一個版本，該版本必須通過所有 的測試包括回歸測試，並且在release後在一個小型的集群上24小時不受甘擾不停地運行。每個月會有一次發布，發布時採用最新release的版本， 並且將現有的集群按重要性分級發布，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發布機制後，由發布帶來的不穩定因素大大下降 了，並且線上版本也能保持不落後太多。
6 改進和優化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公布了對hbase的所有改造，並且將他們內部實際使用的版本開源到了社區。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐 大，並且由於應用類型非常豐富，我們並們並沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們並不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也為社 區提交了10數個穩定性相關的patch，比較重要的有以下幾個：
https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899
還有其它一些，我們主要將patch提交到0.92版本，社區會有commitor幫助我們backport回0.90版本。所以社區從 0.90.2一直到0.90.6一共發布了5個bugfix版本後，0.90.6版本其實己經比較穩定了。建議生產環境可以考慮這個版本。
split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta 表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之後region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region 被兩個以上的regionserver所服務，那麼就可能出現這一個region所服務的數據會隨機分別寫到多台rs上，讀取的時候也會分別讀取，導致數 據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。
前面說到慢響應的問題歸納為網路原因、gc問題、命中率以及client的反序列化問題。網路原因一般是網路不穩定引起的，不過也有可能是tcp參 數設置問題，必須保證盡量減少包的延遲，如nodelay需要設置為true等，這些問題我們通過tcpmp等一系列工具專門定位過，證明tcp參數 對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將 version數設為1以增加緩存的容量，良好的balance也能幫助充分應用好每台機器的命中率。我們為此設計了表級別的balance。
由於hbase服務是單點的，即宕機一台，則該台機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。為此主要做了幾點優 化。首先是將zk的宕機發現時間盡量縮短到1分鍾，其次改進了master恢復日誌為並行恢復，大大提高了master恢復日誌的速度，然後我們修改了 openhandler中可能出現的一些超時異常，以及死鎖，去掉了日誌中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鍾甚至半小時無法重啟的問題己經被修復掉了。另外，hdfs層面我們將 socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。
hbase本身讀寫層面的優化我們目前並沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因為由於hbase本身 良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數並應用於生產環境後，都基本滿足需求。不過這是我們接下來的重要工作。
7 將來計劃
我們目前維護著淘寶內基於社區0.90.x而定製的hbase版本。接下來除繼續fix它的bug外，會維護基於0.92.x修改的版本。之所以這 樣，是因為0.92.x和0.90.x的兼容性並不是非常好，而且0.92.x修改掉的代碼非常多，粗略統計會超過30%。0.92中有我們非常看重的一 些特性。
0.92版本改進了hfile為hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文 件。現有的HFile在文件大到一定程度時，index會佔用大量的內存，並且載入文件的速度會因此下降非常多。而如果HFile不增大的 話，region就無法擴大，從而導致region數量非常多。這是我們想盡量避免的事。
0.92版本改進了通訊層協議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成為影響client性能的地方。
0.92版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
還有其它很多優化，比如改進了balance演算法、改進了compact演算法、改進了scan演算法、compact變為CF級別、動態做ddl等等特性。
除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯的特性，0.94是一個性能優化版本。它做了很多革命性工作，比如去掉root表，比如HLog進行壓縮，replication上支持多個slave集群，等等。
我們自己也有一些優化，比如自行實現的二級索引、backup策略等都會在內部版本上實現。
另外值得一提的是hdfs層面的優化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化 讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優秀的hdfs團隊來支持我們的 hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數的建議，以及幫助實現namenode的HA等。最新的測試 表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監控和調整regionserver的負載，能夠動態地將負載不足的集群上的伺服器挪到負載較高的集群中，而整個過程對用戶完全透明。
總的來說，我們的策略是盡量和社區合作，以推動hbase在整個apache生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。
❼ solr怎麼給hbase建立索引原理
以下資料整理自網路,以及查看solr幫助文檔。主要分為兩部分，第一部分是對《db-data-config.xml》的配置內容的講解（屬於高級內容），第二部分是DataImportHandler（屬於基礎）,第三部分是對db-data-config.xml的進階
第一部分是對《db-data-config.xml》
query是獲取全部數據的SQL
deltaImportQuery是獲取增量數據時使用的SQL
deltaQuery是獲取pk的SQL
parentDeltaQuery是獲取父Entity的pk的SQLFull
Import工作原理：
執行本Entity的Query，獲取所有數據；
針對每個行數據Row，獲取pk，組裝子Entity的Query；
執行子Entity的Query，獲取子Entity的數據。Delta
Import工作原理：
查找子Entity，直到沒有為止；
執行Entity的deltaQuery，獲取變化數據的pk；
合並子Entity
parentDeltaQuery得到的pk；
針對每一個pk
Row，組裝父Entity的parentDeltaQuery；
執行parentDeltaQuery，獲取父Entity的pk；
執行deltaImportQuery，獲取自身的數據；
如果沒有deltaImportQuery，就組裝Query限制：
子Entity的query必須引用父Entity的pk
子Entity的parentDeltaQuery必須引用自己的pk
子Entity的parentDeltaQuery必須返回父Entity的pk
deltaImportQuery引用的必須是自己的pk第二部分是DataImportHandler
關於DataImportHandler的具體使用方法，詳見下文，如果你英文超級好，那看這個鏈接吧：http://wiki.apache.org/solr/DataImportHandler大多數的應用程序將數據存儲在關系資料庫、xml文件中。對這樣的數據進行搜索是很常見的應用。所謂的DataImportHandler提供一種可配置的方式向solr導入數據，可以一次全部導入，也可以增量導入。
概覽
目標
能夠讀取關系資料庫中的數據。
通過可配置的方式，能夠將資料庫中多列、多表的數據生成solr文檔
能夠通過solr文檔更新solr
提供 通過配置文件就能夠導入所有數據的能力
能夠發現並處理
由insert、update帶來的變化（我們假定在表中有一個叫做「last-modified的列」）
能夠配置 「完全導入」和「增量導入」的時間
讓讀取xml文件，並建立索引成為可配置。
能夠將
其他的數據源（例如：ftp，scp，etc）或者其他格式的文檔（Json，csv）以插件的形式集成到項目中。
設計思路
這個Handler首先要在solrconfig.xml文件中配置下，如下所示。
<requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
<lst name="defaults">
<str name="config">/home/username/data-config.xml</str>
</lst>
</requestHandler>從它的名字上，我們或許也可以猜到，
DataImportHandler正是requestHandler的實現。我們一共需要在兩個地方配置文件中進行一些配置。
solrconfig.xml 。
data-config.xml必須在這個文件中配置，datasource也可以。不過，一般將datasource放在data-config.xml文件中。
data-config.xml怎樣獲取數據？（查詢語句、url等等）
要讀什麼樣的數據（關系資料庫中的列、或者xml的域）
做什麼樣的處理（修改/添加/刪除）
跟關系資料庫一起使用
下面幾個步驟是必要的.
定義一個data-config.xml 文件，並這個它的路徑配置到solrconfig.xml
中關於DataImportHandler的配置中。
給出Connection的信息（假設你選擇在solrconfig中配置datasource）
打開DataImportHandler頁面去驗證，是否該配置的都配置好了。http://localhost:8983/solr/dataimport
使用「完全導入」命令將數據從資料庫中導出，並提交給solr建立索引
使用「增量導入」命令對資料庫發生的變化的數據導出，並提交給solr建立索引。
配置數據源
將dataSource標簽直接添加到dataConfig下面，即成為dataConfig的子元素.
<dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/dbname" user="db_username" password="db_password"/>數據源也可以配置在solrconfig.xml中
屬性type 指定了實現的類型。它是可選的。默認的實現是JdbcDataSource。
屬性 name 是datasources的名字，當有多個datasources時，可以使用name屬性加以區分
其他的屬性都是隨意的，根據你使用的DataSource實現而定。
當然 你也可以實現自己的DataSource。
多數據源
一個配置文件可以配置多個數據源。增加一個dataSource元素就可以增加一個數據源了。name屬性可以區分不同的數據源。如果配置了多於一個的數據源，那麼要注意將name配置成唯一的。
例如：
<dataSource type="JdbcDataSource" name="ds-1" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://db1-host/dbname" user="db_username" password="db_password"/>
<dataSource type="JdbcDataSource" name="ds-2" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://db2-host/dbname" user="db_username" password="db_password"/>
然後這樣使用 ..
<entity name="one" dataSource="ds-1" ...>
..
</entity>
<entity name="two" dataSource="ds-2" ...>
..
</entity>
..
配置JdbcDataSource
JdbcDataSource中的屬性有
driver(必需的)：jdbc驅動名稱
url（必需的）：jdbc鏈接
user：用戶名
password：密碼
批量大小：jdbc鏈接中的批量大小
任何其他的在JdbcDataSource中配置的屬性，都會被直接傳給jdbc
driver
配置data-config.xml
solr
document是schema，它的域上的值可能來自於多個表.
data-config.xml的根元素是document。一個document元素代表了一種文檔。一個document元素中包含了一個或者多個root實體。一個root實體包含著一些子實體，這些子實體能夠包含其他的實體。實體就是，關系資料庫上的表或者視圖。每個實體都能夠包含多個域，每個域對應著資料庫返回結果中的一列。域的名字跟列的名字默認是一樣的。如果一個列的名字跟solr
field的名字不一樣，那麼屬性name就應該要給出。其他的需要的屬性在solrschema.xml文件中配置。
為了能夠從資料庫中取得想要的數據，我們的設計支持標准sql規范。這使得用戶能夠使用他任何想要的sql語句。root實體是一個中心表，使用它的列可以把表連接在一起。
dataconfig的結構
dataconfig的結構不是一成不變的,entity和field元素中的屬性是隨意的，這主要取決於processor和transformer。
以下是entity的默認屬性
name(必需的):name是唯一的，用以標識entity
processor:只有當datasource不是RDBMS時才是必需的。默認值是SqlEntityProcessor
transformer:轉換器將會被應用到這個entity上，詳情請瀏覽transformer部分。
pk：entity的主鍵，它是可選的，但使用「增量導入」的時候是必需。它跟schema.xml中定義的uniqueKey沒有必然的聯系，但它們可以相同。
rootEntity：默認情況下，document元素下就是根實體了，如果沒有根實體的話，直接在實體下面的實體將會被看做跟實體。對於根實體對應的資料庫中返回的數據的每一行，solr都將生成一個document。
一下是SqlEntityProcessor的屬性
query (required) :sql語句
deltaQuery : 只在「增量導入」中使用
parentDeltaQuery : 只在「增量導入」中使用
deletedPkQuery : 只在「增量導入」中使用
deltaImportQuery : (只在「增量導入」中使用) .
如果這個存在，那麼它將會在「增量導入」中導入phase時代替query產生作用。這里有一個命名空間的用法${dataimporter.delta.}詳情請看solr1.4.