當今世界，資料就是金錢。各公司都在竭力收集盡可能多的資料，並力圖找出資料中隱藏的模式，進而通過這些模式獲得收入。然而，如果未能使用收集到的資料，或者未能通過分析資料探勘出隱藏的寶石，那資料就一文不值。
\ 當開始使用hadoop構建大資料解決方案時，了解如何利用手中的工具並將這些工具銜接起來是最大的挑戰之一。hadoop生態系統中包括很多不同的開源專案。我們該如何選擇正確的工具呢？
\\ 大多數資料管理系統至少可以分為資料獲取（data ingestion）、資料儲存（data storage）和資料分析（ data analysis）三個模組。這幾個模組之間的資訊流動可以用下圖表示：
\ 資料獲取系統負責連線起資料來源和資料的靜態儲存位置。資料分析系統用於處理資料，並給出可行的見解。轉換為關係架構的話，我們可以用通用術語替換一下：
\ 我們也可以將這一獲取、儲存和處理的基本架構對映到hadoop生態系統，架構如下：
\\ 社交**很受營銷團隊的歡迎，而twitter就是一種能引起大眾對產品的熱情的有效工具。利用twitter，更容易吸引使用者，還可以直接與使用者交流；反過來，使用者對產品的討論又會形成口碑營銷。在資源有限並且確定無法與目標群體中的每個人直接交流時，通過區別對待可接觸到的人，營銷部門的工作可以更為高效。
\ 為了了解哪些人才是我們的目標人群，我們先來看看twitter的運作方式。乙個使用者——比如說joe——關注了一些人，也有一些人關注他。當joe發布一條更新後，所有的關注者都能看到該更新。joe也可以**其他使用者的更新。如果joe看到sue的一條tweet並加以**，那麼joe的所有關注者都能看到sue的這條tweet，即便他們沒有關注sue。通過**，訊息不止傳給最初傳送者的關注者，還能傳得更遠。知道了這一點，我們可以嘗試吸引更新**量非常大的那些使用者。因為twitter會跟蹤所有tweet的**數，我們可以通過分析twitter資料發現我們所要尋找的使用者。
\ 現在知道了我們想問的問題：哪個twitter使用者被**的資訊最多？哪個人在我們這個行業影響力比較大？
\\ 可以使用sql查詢來回答這個問題：將**降序排列，我們希望找出最大的**量是由哪些使用者導致的。不過在傳統的關聯式資料庫中查詢twitter資料並不方便，因為twitter streaming api是以json格式輸出tweet的，這可能會非常複雜。在hadoop生態系統中，hive專案提供了查詢hdfs中資料的介面。hive的查詢語言與sql非常相似，但利用它為複雜型別建模很容易，因此我們可以輕鬆地查詢我們所擁有資料的型別。看來這是個不錯的起點。那麼如何把twitter資料匯入到hive中呢？首先，我們需要將twitter資料匯入到hdfs中，然後告知hive資料的位置以及如何讀取。
\ 為回答上面的問題，我們需要構建資料流水線，上圖就是匯集了某些cdh元件的高層檢視。
\\ twitter streaming api將為我們提供乙個來自twitter服務的穩定tweet流。使用像curl這樣的實用工具來訪問該api，然後周期性地載入檔案，這是乙個選擇。然而，這就需要我們編寫**來控制資料在何處進入hdfs，而且，如果使用了安全集群，還必須整合安全機制。利用cdh內部的元件將檔案自動從api移到hdfs就簡單得多，並且無需手工干預。
\\ 一旦將twitter資料載入到hdfs中，就可以通過在hive中建立外部表來查詢了。利用外部表，不需要改變hdfs中資料的位置，即可對錶進行查詢。為確保可伸縮性，隨著新增的資料越來越多，我們也需要對錶進行分割槽。分割槽表允許我們在查詢時剪掉已經讀過的檔案，這在處理大規模資料集時會帶來更好的效能。然而，twitter api將繼續輸出tweet，而flume也會不斷地建立新檔案。我們可以將隨著新資料進入而向表中新增分割槽的週期性過程自動化。
\ apache oozie是乙個工作流協同系統，可用於解決這裡的問題。對於作業工作流的設計而言，oozie非常靈活，可以基於一組條件排程執行。我們可以配置工作流來執行alter table命令，該命令負責向hive中新增乙個包含上一小時資料的分割槽。我們還可以控制這個工作流每小時執行。這就能確保我們看到的總是最新的資料。
\ oozie工作流的配置檔案見鏈結。
\\ 在開始查詢資料之前，我們需要確保hive表可以正確地解釋json資料。hive預設希望輸入檔案採用分隔的行格式，但我們的twitter資料是json格式的，因此在預設情況下無法工作。實際上這是hive最大的優勢之一。hive允許我們靈活定義或重定義資料在磁碟上的表現方式。模式只有讀資料的時候才需要真正保證，而且我們可以使用hive serde介面來指定如何解釋載入的資料。serde代表的是serializer和deserializer，這些介面會告訴hive，它如何將資料轉換為hive可以處理的東西。特別的是，deserializer介面用於從磁碟讀資料時，該介面還會將資料轉換為hive知道如何操作的物件。我們可以編寫乙個定製的serde，負責讀入json資料並為hive轉換物件。上述工作實施之後，我們就可以開始查詢了。json serde**見鏈結。serde會接收json格式的tweet並將json實體轉換為可查詢的列：
\
\select created_at, entities, text, user\from tweets\where user.screen_name='parvezjugon'\ and retweeted_status.user.screen_name='scottostby';\\
結果是：
\ created_at
entities
text
user
mon sep 10
\ 21:19:23 +0000
\ 2012
{\"urls\":,\"user_mentions\":
\ [ {\"screen_name\":\"scottostby\
IBM架構解決方案設計
ibm內部有一套自成體系的架構設計方 且是和togaf所互相承認效力的。相比較而言，ibm的架構設計理論，在實際上的可操作性會更強，也可以說是功利性更強些。當然，也會更容易落地使用。該理論包括5個架構設計的步驟 1 理解客戶的業務和需要 understand client s bussiness a...
大資料解決方案
原文 大資料解決方案 1 資料庫 垂直拆分 根據業務把錶放到不同的資料庫，解決表之間的io競爭 水平拆分 根據某種規則把單錶資料分成多張表儲存，解決單錶資料量大的問題 索引 根據業務場景建立合理的索引，如果資料量很小建議使用索引 300條以內 索引使用場景 動作描述 聚集索引 非聚集索引 主鍵列是 ...
解決方案設計 WCF增加身份驗證
請求流程 客戶端 發起請求 請求加密 服務端 接收到請求引數 解密 處理請求 處理結果加密 客戶端 接收到處理結果 解密 結束 服務端1 設計機構或應用表，機構表包含字段賬戶 密碼。2 生成機構客戶端公私鑰 3 生成服務端公鑰 4 業務處理服務 5 響應推送 6 介面文件編寫 7 示例 客戶端請求訊...