Ⅰ 大數據下的地質資料信息存儲架構設計
頡貴琴 胡曉琴
(甘肅省國土資源信息中心)
摘要 為推進我國地質資料信息服務集群化產業化工作，更大更好地發揮地質資料信息的價值，本文針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，基於現有系統的存儲架構，設計了一種大數據下的地質資料信息存儲架構，以便於我國地質資料信息服務集群化產業化工作能夠適應大數據時代的數據存儲。
關鍵詞 大數據 地質資料 存儲 NoSQL 雙資料庫
0 引言
新中國成立60多年來，我國形成了海量的地質資料信息，為國民經濟和社會發展提供了重要支撐。但在地質資料管理方面長期存在資料信息分散、綜合研究不夠、數字化信息化程度不高、服務渠道不暢、服務能力不強等問題，使地質資料信息的巨大潛在價值未能得到充分發揮。為進一步提高地質工作服務國民經濟和社會發展的能力，充分發揮地質資料信息的服務功能，擴大服務領域，國土資源部根據國內外地質工作的先進經驗，做出了全面推進地質資料信息服務集群化產業化工作的部署。
目前，全國各省地質資料館都在有條不紊地對本省成果、原始和實物地質資料進行清理，並對其中重要地質資料進行數字化和存儲工作。然而，由於我國地質資源豐富，經過幾十年的積累，已經形成了海量的地質資料，數據量早已經超過了幾百太位元組(TB)。在進行地質資料信息服務集群化工作中，隨著共享數據量的不斷增大，傳統的數據存儲方式和管理系統必然會展現出存儲和檢索方面的不足以及系統管理方面的缺陷。為了解決該問題，需要設計更加先進的數據存儲架構來實現海量地質資料的存儲。
而大數據(Big Data)作為近年來在雲計算領域中出現的一種新型數據，科技工作者在不斷的研究中，設計了適合大數據存儲管理的非關系型資料庫NoSQL進行大數據的存儲和管理。本文將針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，利用大數據存儲管理模式的思想，提出一種海量地質資料存儲架構，改進現有系統存儲架構，以便於我國全面推進地質資料信息服務集群化產業化工作。
1 工作現狀
1.1 國內外地質資料信息的存儲現狀
在美國，主要有兩大地質資料公共服務平台，分別是地球科學信息中心(ESIC)、地球資源觀測和科學中心(EROS)，其目的是通過為社會和政府提供更加便利、快速的地質信息服務。20世紀90年代初，澳大利亞出台了國家地球科學填圖協議，採用先進的科學方法和技術進行數據存儲，從而形成了第二代澳大利亞陸地地質圖。
目前，我國地質資料信息服務集群化產業化工作剛剛起步，雖然國土資源部信息中心已經開發了地質資料信息集群化共享服務平台，並倡導各地方用戶使用該系統。但由於各個地方早期的工作背景不一致，因此各地方所使用的存儲系統也不盡相同，主要有Access、SQL Server、Oracle、MySQL等系統。本文以國土資源部信息中心開發的地質資料信息集群化共享服務平台的存儲系統MySQL為例說明。該系統是基於關系資料庫管理系統MySQL的一套分布式存儲檢索系統。該系統的部署使得我國地質資料信息服務集群化產業化工作取得了重大進展，同時也為我國建立標准統一的地質資料信息共享服務平台和互聯互通的網路服務體系奠定了堅實的基礎。然而，該系統的研發並沒有考慮到地質資料信息進一步集群化以及在未來地質資料信息進入大數據時代的信息共享和存儲管理問題，也沒有給出明確的解決方案。
1.2 大數據的存儲架構介紹
大數據是近年在雲計算領域中出現的一種新型數據，具有數據量大、數據結構不固定、類型多樣、查詢分析復雜等特點。傳統關系型資料庫管理系統在數據存儲規模、檢索效率等方面已不再適合大數據存儲。NoSQL(Not Only SQL)是與關系資料庫相對的一類資料庫的總稱。這些資料庫放棄了對關系資料庫的支持，轉而採用靈活的、分布式的數據存儲方式管理數據，從而可以滿足大數據存儲和處理的需求。NoSQL基於非關系型數據存儲的設計理念，以鍵值對進行存儲，採用的數據字的結構不固定，每一個元組可以有不一樣的欄位，且每個元組可以根據自己的需要增加一些自己的鍵值對，可以減少一些檢索時間和存儲空間。目前，應用廣泛的 NoSQL 資料庫有 Google BigTable、HBase、MongoDB、Neo4 j、Infinite Graph等。
2 大數據下的地質資料信息存儲架構設計
根據國土資源部做出的全面推進地質資料信息服務集群化產業化工作的部署，國土資源部倡導全國地質資料館使用國土資源部信息中心開發的地質資料信息集群化共享服務平台，實現地質資料信息的存儲和共享。該系統採用了資料庫管理系統MySQL作為數據存儲系統。
為了與現有系統和現有的工作進行對接，並為將來地質資料進入大數據時代後的存儲工作做准備，本文設計了一種能用於海量地質資料信息存儲並且兼容MySQL的分布式的數據存儲架構(圖1)。
整個系統可以根據不同的用戶等級分為不同的用戶管理層，由於圖幅限制，在圖1 中僅僅展示了3級：國家級管理層(即共享服務平台用戶層)、省級管理層以及市級管理層(可根據實際需要延伸至縣級)。
每級管理層的每個用戶可以單獨管理一個伺服器。如國土資源部信息中心可以單獨管理一個伺服器；甘肅省國土資源信息中心可以單獨管理一個伺服器，陝西省國土資源信息中心可以單獨管理一個伺服器；甘肅的若干個市級國土資源局可以根據需要分別管理各自的伺服器。
在伺服器上分別安裝兩套資料庫管理系統，一套是原有的MySQL資料庫管理系統，另一套是為大數據存儲而配備的NoSQL型資料庫管理系統。在伺服器上還專門開發一個資料庫管理器中間件，用於進行用戶層和資料庫的通信以及兩套資料庫之間的通信。
由於各個管理層都各自維護自己的資料庫和數據。當用戶需要進行數據存儲時，他所影響的資料庫僅僅是本地資料庫，存儲效率較高；當用戶需要從多個資料庫讀取數據時，頂層的共享服務平台會根據用戶需求進行任務分解，將任務分發給下層的管理層進行資料庫讀取，由於各個資料庫並行讀取，從而提高了資料庫讀取效率。
圖1 大數據下的地質資料信息存儲架構框圖
2.1 用戶管理層
用戶管理層根據許可權范圍，分為多層(本文以3層為例)。
位於頂層的國家級管理層(共享服務平台用戶層)負責用戶訪問許可權的分配、與其直接關聯的資料庫的訪問、下級管理層任務的分配等工作。
用戶訪問許可權的分配是指為訪問本共享服務平台的個人用戶和單位用戶分配數據的使用許可權、安全性的設計等。
與其直接關聯的資料庫訪問是指直接存儲在其本地資料庫上的數據的訪問。在該資料庫中不僅要存儲所需要的地質資料，還要存儲注冊用戶信息等數據。
下級管理層任務分配是指如果用戶需要訪問多個下層資料庫，用戶只需要輸入查詢這幾個下層資料庫的命令，而如何查找下層資料庫則由該功能來完成。例如某用戶要查找甘肅、陝西、上海、北京的鐵礦分布圖，則用戶只需要輸入這幾個地方及鐵礦等查詢條件，系統將自動把各個省的資料庫查詢任務分派到下級管理層。
同理，位於下層的省級管理層和市級管理層除了沒有用戶訪問許可權功能外，其餘功能與國家級管理層是相同的。各層之間的資料庫通過互聯網相互連接成分布式的資料庫系統。
2.2 MySQL和NoSQL的融合
MySQL是關系型資料庫，它支持SQL查詢語言，而NoSQL是非關系型資料庫，它不支持SQL查詢語言。用戶要想透明地訪問這兩套資料庫，必須要設計資料庫管理器中間件，作為用戶訪問資料庫的統一入口和兩套資料庫管理系統的通信平台。本文所設計的資料庫管理器簡單模型如圖2所示。
圖2 資料庫管理器模型
伺服器管理器通過用戶程序介面與應用程序進行通訊，通過MySQL資料庫介面與MySQL伺服器通訊，通過NoSQL資料庫介面與NoSQL資料庫介面通訊。當應用程序介面接收到一條資料庫訪問命令之後，交由資料庫訪問命令解析器進行命令解析，從而形成MySQL訪問命令或者NoSQL訪問命令，通過相應的資料庫介面訪問資料庫；資料庫返回訪問結果後經過匯總，由應用程序介面返回給應用程序。
兩套資料庫可以通過雙資料庫通信協議進行相互的通信和互訪。此通信協議的建立便於地質工作人員將已經存入MySQL資料庫的不適合結構化存儲的數據轉存到NoSQL資料庫中，從而便於系統的升級和優化。
2.3 系統的存儲和檢索模式
在本存儲框架設計中，系統採用分布式網路存儲模式，即採用可擴展的存儲結構，利用分散在全國各地的多台獨立的伺服器進行數據存儲。這種方式不僅分擔了伺服器的存儲壓力，提高了系統的可靠性和可用性，還易於進行系統擴展。另外，由於地質資料信息存儲的特殊性，各地方用戶的數據存儲工作基本都是在本地伺服器進行，很少通過網路進行遠程存儲，所以數據存儲效率較高。
在一台資料庫伺服器上安裝有MySQL和NoSQL型兩套資料庫管理系統，分別用於存儲地質資料信息中的結構化數據和非結構化數據。其中，NoSQL型資料庫作為主資料庫，用於存儲一部分結構化數據和全部的非結構化數據；而MySQL資料庫作為輔助資料庫，用於存儲一部分結構化的數據，以及舊系統中已經存儲的數據。使用兩套資料庫不僅可以存儲結構化數據而且還可以適用於大數據時代地質資料信息的存儲，因此系統具有很好的適應性和靈活性。
2.4 安全性設計
地質資料信息是國家的機密，地質工作人員必須要保證它的安全。地質資料信息進入數字化時代之後，地質資料常常在計算機以及網路上進行傳輸，地質資料信息的安全傳輸和保存更是地質工作人員必須關注和解決的問題。在本存儲架構的設計中設計的安全問題主要有資料庫存儲安全、數據傳輸安全、數據訪問安全等問題。
資料庫設計時採用多邊安全模型和多級安全模型阻止資料庫中信息和數據的泄露來提高資料庫的安全性能，以保障地質信息在資料庫中的存儲安全；當用戶登錄系統訪問資料庫時，必須進行用戶甄別和實名認證，這主要是對用戶的身份進行有效的識別，防止非法用戶訪問資料庫；在對地質資料進行網路傳輸時，應該首先將數據進行加密，然後再進行網路傳輸，以防止地質信息在傳輸過程中被竊取。
3 結語
提高地質資料數字化信息化水平，是國外地質工作強國的普遍做法。為推進我國地質資料信息服務集群化產業化工作，本文針對我國現有的地質資料信息集群化共享服務平台存在的缺陷和問題，利用大數據存儲管理模式的思想，基於現有系統的存儲架構，設計了一種大數據下的地質資料信息存儲架構，以便於我國地質資料信息服務集群化產業化工作能夠適應大數據時代的數據存儲。該存儲架構的設計只涉及了簡單模型的構建，具體詳細復雜的功能設計和軟體實現還需要在進一步的研究工作中完成。
參考文獻
[1]吳金朋.一種大數據存儲模型的研究與應用[D].北京：北京郵電大學計算機學院，2012.
[2]吳廣君，王樹鵬，陳明，等.海量結構化數據存儲檢索系統[J].計算機研究與發展，2012，49(Suppl)：1～5.
[3]黃
Ⅱ 如何優化操作大數據量資料庫
下面以關系資料庫系統Informix為例，介紹改善用戶查詢計劃的方法。
1．合理使用索引
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（pound index）。
●使用系統工具。如Informix資料庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些資料庫伺服器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當資料庫表更新大量數據後，刪除並重建索引可以提高查詢速度。
2．避免或簡化排序
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
●索引中不包括一個或幾個待排序的列；
●group by或order by子句中列的次序與索引的次序不一樣；
●排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
3．消除對大型錶行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的 *** ，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
4．避免相關子查詢
一個列的標簽同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 「98_ _ _」
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >「98000」，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3]>「80」，在where子句中採用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>「98000」
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁碟存取是最慢的操作，表現在磁碟存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用資料庫的排序能力來替代非順序的存取能改進查詢。
實例分析
下面我們舉一個製造公司的例子來說明如何進行查詢優化。製造公司資料庫中包括3個表，模式如下所示：
1．part表
零件號?????零件描述????????其他列
（part_num）?（part_desc）??????（other column）
102，032???Seageat 30G disk?????……
500，049???Novel 10M neork card??……
……
2．vendor表
廠商號??????廠商名??????其他列
（vendor _num）?（vendor_name） （other column）
910，257?????Seageat Corp???……
523，045?????IBM Corp?????……
……
3．parven表
零件號?????廠商號?????零件數量
（part_num）?（vendor_num）?（part_amount）
102，032????910，257????3,450,000
234，423????321，001????4，000，000
……
下面的查詢將在這些表上定期運行，並產生關於所有零件數量的報表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查詢代碼的開銷將十分巨大。為此，我們在零件號和廠商號上建立索引。索引的建立避免了在嵌套中反復掃描。關於表與索引的統計信息如下：
表?????行尺寸???行數量?????每頁行數量???數據頁數量
（table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages）
part????150?????10，000????25???????400
Vendor???150?????1，000???? 25???????40
Parven???13????? 15，000????300?????? 50
索引?????鍵尺寸???每頁鍵數量???頁面數量
（Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages）
part?????4??????500???????20
Vendor????4??????500???????2
Parven????8??????250???????60
看起來是個相對簡單的3表連接，但是其查詢開銷是很大的。通過查看系統表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理順序存放的。parven表沒有特定的存放次序。這些表的大小說明從緩沖頁中非順序存取的成功率很小。此語句的優化查詢規劃是：首先從part中順序讀取400頁，然後再對parven表非順序存取1萬次，每次2頁（一個索引頁、一個數據頁），總計2萬個磁碟頁，最後對vendor表非順序存取1.5萬次，合3萬個磁碟頁。可以看出在這個索引好的連接上花費的磁碟存取為5.04萬次。
建議你直接用Jdbc好了，用batch，這樣是最快的。
打開資料庫
con.Open();
讀取數據
OdbcDataReader reader = cmd.ExecuteReader();
把數據載入到臨時表
dt.Load(reader);
在使用完畢之後，一定要關閉，要不然會出問題
reader.Close();
這個問題是這樣的：
首先你要明確你的插入是正常業務需求么？如果是，那麼只能接受這樣的數據插入量。
其次你說資料庫存不下了 那麼你可以讓你的資料庫上限變大 這個你可以在資料庫裡面設置的 裡面有個資料庫文件屬性 maxsize
最後有個方法可以使用，如果你的歷史數據不會對目前業務造成很大影響 可以考慮歸檔處理 定時將不用的數據移入歷史表 或者另外一個資料庫。
注意平時對資料庫的維護 定期整理索引碎片
時間維度分區表，然後定情按照規則將屬於歷史的分區數據遷移到，歷史庫上，寫個存儲自動維護分區表。
一次性插入大量數據，只能使用循環，
如：游標，while 循環語句
下面介紹While 循環插入數據，
SQL 代碼如下：
IF OBJECT_ID('dbo.Nums') IS NOT NULL
DROP TABLE dbo.Nums;
GO
CREATE TABLE dbo.Nums(n INT NOT NULL PRIMARY KEY);
DECLARE @max AS INT, @rc AS INT;
SET @max = 5000000;
SET @rc = 1;
INSERT INTO Nums VALUES(1);
WHILE @rc * 2 <= @max
BEGIN
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums;
SET @rc = @rc * 2;
END
INSERT INTO dbo.Nums SELECT n + @rc FROM dbo.Nums WHERE n + @rc <= @max;
--以上函數取自Inside SQL Server 2005: T-SQL Query一書。
INSERT dbo.Sample SELECT n, RAND(CAST(NEWID() AS BINARY(16))) FROM Nums
ini_set('max_execution_time',Ɔ');
$pdo = new PDO("mysql:host=localhost;dbname=test","root","123456");
$sql = "insert into test(name,age,state,created_time) values";
for($i=0; $i<100000; $i++){
$sql .="('zhangsan',21,1,-09-17')";
}
$sql = substr($sql,0,strlen($sql)-1);
var_mp($sql);
if($pdo -> exec($sql)){
echo "插入成功！";
echo $pdo -> lastinsertid();
}
試試吧。10萬條1分鍾多，我覺得還行
就是直接把DataSet 類型作為參數直接傳遞給服務端
WCF默認支持這么做，直接傳Datatable不行。
你看一下 「服務引用設置」中你選的 *** 類型是什麼，我選的是System.Array
字典 *** 類型是默認第一項 System.Collections.Generic.Dictionary
又是一個把自己架在火上烤的需求啊，
如果不考慮傳輸因素，可以調整wcf配置，提升傳遞的容量，如果是對象傳遞可能還要調整對象層次的深度
Ⅲ 大數據創業的5大要點,你知道嗎
大數據是當今最熱門的科技詞彙，同時也是最困難的創業項目。CSC對Infochimps的收購表明，那些無法順利拿到第二輪融資的大數據創業公司 面臨著要麼關張，要麼被人收購的命運
Harris的觀點可以歸納為五點，IT經理網摘譯整理如下：
1.基礎設施非常難
不僅開發基礎設施技術產品很難，銷售起來也很難，具體到大數據基礎設施工具如Hadoop、NoSQL資料庫和流處理系統則更是難上加難。客戶需要大量培訓和教育，付費喲娜谷需要大量支持和及時跟進的產品開發工作。
新興的大數據創業公司還必須與那些在客戶那裡已經有一些知名度甚至合作項目的公司競爭，例如Cloudera、Hortonworks、10gen、亞馬遜AWS、IBM、Oracle等。
反觀大數據應用創業則相對簡單的多，無論面向垂直行業應用還是數據可視化這樣的通用大數據應用都是如此。因為這些大數據應用的價值對於客戶來說更為直觀，距離業務也更近，進入企業IT系統的摩擦也更小。
2.雲計算是朋友
無論你是銷售大數據基礎設施還是應用，雲計算都是更有效的業務載體。選擇雲計算不僅僅是在雲端託管，更重要的是通過雲計算向客戶提供服務。你將擁有更多控制權，同時在有限的資源上優化運行也會讓你對產品的理解更加透徹。
雲計算也降低了潛在用戶試用產品的成本和門檻，從NewRelic到亞馬遜AWS都從雲計算+大數據模式中獲益。
3.開發者是朋友
如果你主要從事大數據分析，例如ClearStory、Platfora或者CRM營銷應用，數據分析師就是你的朋友。無論那種情況，最好的辦法就是圍繞以開發者和市場人員為主的目標受眾進行開發和營銷工作，CIO反而不是很好的目標受眾！
專注CIO而非開發者往往會導致你在實際簽約時碰到棘手問題。圍繞開發者營銷的戰術被很多雲計算創業公司和純大數據軟體公司所採用，例如Splunk和Tableau。
再比如Infochimps和Continuuity的產品類似（兩者都被迫按落雲頭，迫降在用戶數據中心），但Continuuity完全面向開發者，這意味著能積累更多技術粉絲。
4.將數據科學家推向前台中央
這既是市場也是銷售策略，數據科學家才是能夠展示數據和平台威力的人，他們也是會議上最受歡迎的演講者。
但大數據科學家也需要慎重選擇傳播內容。如今大家都接受了Hadoop和NoSQL，所以沒必要每次開會言必稱4V之類的科普。至於如何配置和集成大數據系統也只能吸引小部分聽眾，除非你的項目規模超大。
Cloudera比競爭對手出名的原因有很多，但其中Jeff hammerbacher絕對是一位舉足輕重的人物。不要空談大數據大數據的價值和架構，站在聽眾的立場說說具體能做哪些分析，如何做。
5.開源有多重要，取決於你自己
幾乎所有的大數據公司都依賴開源軟體，有些是「借」來的，如Hadoop、Storm以及各種資料庫，有些是自行開發的，有些則是混合模式，例如在HBase上增加的一些功能應用。這些開源項目如此流行是因為社區的力量。
開源絕不是看起來那麼輕松，不是說你在Github上放點代碼就談得上回饋社區了。開源的目的是將使用相同代碼的人聚攏成社區，並不斷改進代碼。這 里與第三點中我們提到的吸引開發者有關。只有更多的用戶和開發者對你產生興趣了，在你的產品上花時間和精力了，才有可能最終掏錢。
不計其數的創業公司都將代碼開源了，但那些真正能推動項目並建設社區的公司才能脫穎而出。例如Neo Technology的Neo4j、Concurrent的Casading以及10gen的MongoDB。甚至Twitter這樣面向大眾的公司都開源了Storm和Mesos等項目。