hive 存儲 ： 存儲數據相關標簽表、人群計算表的表結構設計以及ID-Mapping的一種實現方式
建立用戶畫像首先需要建立數據倉庫，用於存儲用戶標簽數據。Hive是基於Hadoop的數據倉庫工具，依賴於HDFS存儲數據，提供的SQL語言可以查詢存儲在HDFS中的數據。開發時一般使用Hive作為數據倉庫，存儲標簽和用戶特征庫等相關數據
mysql 存儲 ： 存儲標簽元數據、監控數據及結果集數據
MySQL作為關系型數據庫，在用戶畫像中可用於元數據管理、監控預警數據、結果集存儲等應用中。
Hive適合於大數據量的批處理作業，對於量級較小的數據，MySQL具有更快的讀寫速度。Web端產品讀寫MySQL數據庫會有更快的速度，方便標簽的定義、管理。
MySQL還可用於存儲每天對ETL結果的監控信息。從整個畫像調度流的關鍵節點來看，需要監控的環節主要包括對每天標簽的產出量、服務層數據同步情況的監控等主要場景。
服務層一般采用HBase、Elasticsearch等作為數據庫存儲標簽數據供線上調用，將標簽相關數據從Hive數倉向服務層同步的過程中，有出現差錯的可能，因此需要記錄相關數據在Hive中的數量及同步到對應服務層后的數量，如果數量不一致則觸發告警。
Hbase 存儲 ： 存儲線上接口實時調用的數據
HBase是一個高性能、列存儲、可伸縮、實時讀寫的分布式存儲系統，同樣運行在HDFS之上。與Hive不同的是，HBase能夠在數據庫上實時運行，而不是跑MapReduce任務，適合進行大數據的實時查詢。
row key：用來表示唯一一行記錄的主鍵，HBase的數據是按照row key的字典順序進行全局排列的。
訪問HBase中的行只有3種方式：○通過單個row key訪問；○通過row key的正則訪問；○全表掃描。由於HBase通過rowkey對數據進行檢索，而rowkey由於長度限制的因素不能將很多查詢條件拼接在rowkey中，因此HBase無法像關系數據庫那樣根據多種條件對數據進行篩選。一般地，HBase需建立二級索引來滿足根據復雜條件查詢數據的需求。
Rowkey設計時需要遵循三大原則：○唯一性原則：rowkey需要保證唯一性，不存在重復的情況。在畫像中一般使用用戶id作為rowkey。○長度原則：rowkey的長度一般為10-100bytes。○散列原則：rowkey的散列分布有利於數據均衡分布在每個RegionServer，可實現負載均衡。
❑columns family：指列簇，HBase中的每個列都歸屬於某個列簇。列簇是表的schema的一部分，必須在使用表之前定義。划分columns family的原則如下：○是否具有相似的數據格式；○是否具有相似的訪問類型。
Elasticsearch 存儲 ： 存儲標簽用於人群計算和人群多維透視分析
Elasticsearch是一個開源的分布式全文檢索引擎，可以近乎實時地存儲、檢索數據。而且可擴展性很好，可以擴展到上百台服務器，處理PB級別的數據。
對於用戶標簽查詢、用戶人群計算、用戶群多維透視分析這類對響應時間要求較高的場景，也可以考慮選用Elasticsearch進行存儲。Elasticsearch是面向文檔型數據庫，一條數據在這里就是一個文檔，用json作為文檔格式。
在關系型數據庫中查詢數據時可通過選中數據庫、表、行、列來定位所查找的內容，在Elasticsearch中通過索引（index）、類型（type）、文檔（document）、字段來定位查找內容。一個Elasticsearch集群可以包括多個索引（數據庫），也就是說，其中包含了很多類型（表），這些類型中包含了很多的文檔（行），然后每個文檔中又包含了很多的字段（列）
應用場景
基於HBase的存儲方案並沒有解決數據的高效檢索問題。在實際應用中，經常有根據特定的幾個字段進行組合后檢索的應用場景，而HBase采用rowkey作為一級索引，不支持多條件查詢，如果要對庫里的非rowkey進行數據檢索和查詢，往往需要通過MapReduce等分布式框架進行計算，時間延遲上會比較高，難以同時滿足用戶對於復雜條件查詢和高效率響應這兩方面的需求。
為了既能支持對數據的高效查詢，同時也能支持通過條件篩選進行復雜查詢，需要在HBase上構建二級索引，以滿足對應的需要。采用Elasticsearch存儲HBase的索引信息，以支持復雜高效的查詢功能。
主要查詢過程包括：1）在Elasticsearch中存放用於檢索條件的數據，並將rowkey也存儲進去；2）使用Elasticsearch的API根據組合標簽的條件查詢出rowkey的集合；3）使用上一步得到的rowkey去HBase數據庫查詢對應的結果。
HBase數據存儲數據的索引放在Elasticsearch中，實現了數據和索引的分離。在Elasticsearch中documentid是文檔的唯一標識，在HBase中rowkey是記錄的唯一標識。在工程實踐中，兩者可同時選用用戶在平台上的唯一標識（如userid或deviceid）作為rowkey或documentid，進而解決HBase和Elasticsearch索引關聯的問題。
流失標簽存儲
Spark Streaming是Spark Core API的擴展，支持實時數據流的處理，並且有可擴展、高吞吐量、容錯的特點。數據可以從Kafka、Flume等多個來源獲取，可以使用map、reduce、window等多個高級函數對業務邏輯進行處理。最后，處理后的數據被推送到文件系統、數據庫等。
在內部Spark Streaming接收實時數據流並將數據分成多個batch批次，然后由Spark引擎進行處理，批量生成結果流。Spark Streaming提供了一個高層抽象，稱為Discretized Stream或Dstream，它表示連續的數據流。Dstream可以通過Kafka、Flume等來源的數據流創建，也可以通過在其他Dstream上應用高級操作來創建。
Kafka的核心功能是作為分布式消息中間件。Kafka集群由多個Broker server組成，其中，消息的發送者稱為Producer；消息的消費者稱為Cousumer；Broker是消息處理的節點，多個Broker組成Kafka集群；Topic是數據主題，用來區分不同的業務系統，消費者通過訂閱不同的Topic來消費不同主題的數據，每個Topic又被分為多個Partition，Partition是topic的分組，每個Partition都是一個有序隊列；offset用於定位消費者在每個Partition中消費的位置。Kafka對外使用Topic概念，生產者向Topic里寫入消息，消費者從Topic中讀取消息。一個Topic由多個Partition組成。生產者向Brokers指定的Topic中寫消息，消費者從Brokers里面拉取指定的Topic消息，然后進行業務處理。
Spark Streaming可以通過Receiver和Direct兩種模式來集成Kafka。在Receiver模式下，Spark Streaming作為Consumer拉取Kafka中的數據，將獲取的數據存儲在Executor內存中。但可能會因為數據量大而造成內存溢出，所以啟用預寫日志機制（Write AheadLog）將溢出部分寫入到HDFS上。在接收數據中，當一個Receiver不能及時接收所有的數據時，再開啟其他Receiver接收，它們必須屬於同一個Consumer Group，這樣可以提高Streaming程序的吞吐量（如圖4-21所示）。整體來說，Receiver模式效率較低，容易丟失數據，在生產環境中使用較少。
流程
❑讀取數據源，這里講解消費Kafka中的數據；❑解析數據，即解析消費的Kafka數據；❑將解析后的數據存儲到指定位置（如MySQL、HDFS、HBase等）；❑存儲消費的Offset，Direct模式下需要保存消費到的位置。