1、memsql 分布式內存資料庫瞎凳鍵，號稱是速度最快的關系資料庫。由前Facebook工程師磨巧創建，兼容MySQL，但比MySQL快30倍，能實現每秒150萬次事務。原理是僅用內存並將SQL預編譯為C++。
2、你的問題，memsql 是怎麼保證數據存入沒錯，這是資料庫的基本功能，保證數據的保存和讀取，這是通過資料庫事務、以及鎖功能來實現的，具體的原理闡述請查閱資料庫基礎書籍。
3、希望對你有幫助。祝粗指你學有所得。
2. 如何架構大數據系統 hadoop
大數據數量龐大，格式多樣化。大量數據由家庭、製造工廠和辦公場所的各種設備、互聯網事務交易、社交網路的活動、自動化感測器、移動設備以及科研儀器等生成。它的爆炸式增長已超出了傳統IT基礎架構的處理能力，給企業和社會帶來嚴峻的數據管理問題。因此必須開發新的數據架構，圍繞「數據收集、數據管理、數據分析、知識形成、智慧行動」的全過程，開發使用這些數據，釋放出更多數據的隱藏價值。
一、大數據建設思路
1）數據的獲得
四、總結
基於分布式技術構建的大數據平台能夠有效降低數據存儲成本，提升數據分析處理效率，並具備海量數據、高並發場景的支撐能力，可大幅縮短數據查詢響應時間，滿足企業各上層應用的數據需求。
3. memcached和redis的區別
Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：
1、Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更復雜的結構和操作，那麼Redis會是不錯的選擇。
2、內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。
3、性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。
具體為什麼會出現上面的結論，以下為收集到的資料：
1、數據類型支持不同
與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：
type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果春判圓是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。
1）String
常用命令：set/get/decr/incr/mget等；
應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；
實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。
常用命令：hget/hset/hgetall等
應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；
實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標簽) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。
常用命令：lpush/rpush/lpop/rpop/lrange等；
應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列沖春表等都可以用Redis的list結構來實現；
實現方式：Redis list的實現為一個雙向鏈表，即可以扒塌支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。
常用命令：sadd/spop/smembers/sunion等；
應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；
實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。
常用命令：zadd/zrange/zrem/zcard等；
應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。
實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。
appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁碟上。
appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鍾。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鍾會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。
appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。
2）Hash
3）List
4）Set
5）Sorted Set
2、內存管理機制不同
在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。
對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。
Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。
當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。
Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。
Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。
3、數據持久化支持
Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。
1）RDB快照
Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的 on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鍾就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。
Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。
2）AOF日誌
AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標准命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成後，會將所有緩沖區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。
AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。
對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。
4、集群管理的不同
Memcached是全內存的數據緩沖系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分布式集群來擴展存儲能力。
Memcached本身並不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式演算法來實現Memcached的分布式存儲。下圖給出了Memcached的分布式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分布式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。
相較於Memcached只能採用客戶端實現分布式存儲，Redis更偏向於在伺服器端構建分布式存儲。最新版本的Redis已經支持了分布式存儲功能。Redis Cluster是一個實現了分布式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分布式存儲架構，其中節點與節點之間通過二進制協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分布式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。
為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。
4. presto 配置 優先順序
presto主要配置文件如下： catalog/:配置各數據源的信息。presto是由facebook開源，基於內存的分布式查詢引擎。支持多數據源，可支持PB級海量數據查詢，本身不作數據存儲。由於基於內存查詢，減少了IO開銷，故查詢效率很高，但不適用於多表聯合查詢。
拓展資料：
1、presto架構 ：
與眾多分布式框架類似，由某組件進行請求處理以及分發任務至各執行節點。在presto架構中，Coordinator即為這樣的角色。負責解析SQL，生成執行計劃，分發任務到各節點。 Worker即各實際執行查詢的節點。worker收到任務後,通過各種connector取各數據源中的數據。 Discovery service即聯系Coordinator及Worker的服務。Worker啟動會向Discovery server注冊服務，Coordinator向Discovery server獲取Worker節點信息。
2、Presto因其優秀的查詢速度被我們所熟知，它本身基於MPP架構，可以快速的對Hive數據進行查詢，同時支持擴展Connector，目前對Mysql、MongoDB、Cassandra、Hive等等一系列的資料庫都提供了Connector進行支持。是我岩舉們常用的SQL on Hadoop的解決方案。那麼我們今天就來看一下，當我們選擇Presto作為我們的查詢引擎之後，我們需要考慮的問題。
3、單機維度
GENERAL_POOL每次內存申請時，都會判斷內存使用量是否超過了最大內存，如果超過了就報錯，錯誤為「Query exceeded local memory limit of x」，這保護了Presto會無限申請內存，只會導致當前查詢出錯。同時，如果該節點的GENERAL_POOL可使用內存以及可回收內存為0，那麼認為該node為Block node。RESERVED_POOL可以認為是查詢最大的SQL，其能滿足GENERAL_POOL的內存限制策略，那麼肯定會滿足RESERVED_POOL的策略(復用了GENERAL_POOL策略)。
4、Resource Groups
Resource Groups 可以認為是Presto實現了一個弱資源限制和隔離功能。其可以為每個group指定隊列大小、並發大小、內存使用大小。為每個group設置合理的hardConcurrencyLimit(最大並發數)、softMemoryLimit(內存最大使用值)及maxQueued(隊列大小)一方面可以使不同業務影響降低，另一方面也大概率粗扒碧避免OOM問題，當此攔然善於運用user及做下二次開發，就可以讓Presto支持多用戶共用同一分組和許可權認證功能。
5. 如何實現企業數據 大數據平台 分布式存放
Hadoop在可伸縮性、健壯性、計算性能和成本上具有無可替代的優勢，事實上已成為當前互聯網企業主流的大數據分析平台。本文主要介紹一種基於Hadoop平台的多維分析和數據挖掘平台架構。作為一家互聯網數據分析公司，我們在海量數據的分析領域那真是被「逼上樑山」。多年來在嚴苛的業務需求和數據壓力下，我們幾乎嘗試了所有可能的大數據分析方法，最終落地於Hadoop平台之上。
1. 大數據分析大分類
Hadoop平台對業務的針對性較強，為了讓你明確它是否符合你的業務，現粗略地從幾個角度將大數據分析的業務需求分類，針對不同的具體需求，應採用不同的數據分析架構。
按照數據分析的實時性，分為實時數據分析和離線數據分析兩種。
實時數據分析一般用於金融、移動和互聯網B2C等產品，往往要求在數秒內返回上億行數據的分析，從而達到不影響用戶體驗的目的。要滿足這樣的需求，可以採用精心設計的傳統關系型資料庫組成並行處理集群，或者採用一些內存計算平台，或者採用HDD的架構，這些無疑都需要比較高的軟硬體成本。目前比較新的海量數據實時分析工具有EMC的Greenplum、SAP的HANA等。
對於大多數反饋時間要求不是那麼嚴苛的應用，比如離線統計分析、機器學習、搜索引擎的反向索引計算、推薦引擎的計算等，應採用離線分析的方式，通過數據採集工具將日誌數據導入專用的分析平台。但面對海量數據，傳統的ETL工具往往徹底失效，主要原因是數據格式轉換的開銷太大，在性能上無法滿足海量數據的採集需求。互聯網企業的海量數據採集工具，有Facebook開源的Scribe、LinkedIn開源的Kafka、淘寶開源的Timetunnel、Hadoop的Chukwa等，均可以滿足每秒數百MB的日誌數據採集和傳輸需求，並將這些數據上載到Hadoop中央系統上。
按照大數據的數據量，分為內存級別、BI級別、海量級別三種。
這里的內存級別指的是數據量不超過集群的內存最大值。不要小看今天內存的容量，Facebook緩存在內存的Memcached中的數據高達320TB，而目前的PC伺服器，內存也可以超過百GB。因此可以採用一些內存資料庫，將熱點數據常駐內存之中，從而取得非常快速的分析能力，非常適合實時分析業務。圖1是一種實際可行的MongoDB分析架構。
圖1 用於實時分析的MongoDB架構
MongoDB大集群目前存在一些穩定性問題，會發生周期性的寫堵塞和主從同步失效，但仍不失為一種潛力十足的可以用於高速數據分析的NoSQL。
此外，目前大多數服務廠商都已經推出了帶4GB以上SSD的解決方案，利用內存+SSD，也可以輕易達到內存分析的性能。隨著SSD的發展，內存數據分析必然能得到更加廣泛的應用。
BI級別指的是那些對於內存來說太大的數據量，但一般可以將其放入傳統的BI產品和專門設計的BI資料庫之中進行分析。目前主流的BI產品都有支持TB級以上的數據分析方案。種類繁多，就不具體列舉了。
海量級別指的是對於資料庫和BI產品已經完全失效或者成本過高的數據量。海量數據級別的優秀企業級產品也有很多，但基於軟硬體的成本原因，目前大多數互聯網企業採用Hadoop的HDFS分布式文件系統來存儲數據，並使用MapRece進行分析。本文稍後將主要介紹Hadoop上基於MapRece的一個多維數據分析平台。
數據分析的演算法復雜度
根據不同的業務需求，數據分析的演算法也差異巨大，而數據分析的演算法復雜度和架構是緊密關聯的。舉個例子，Redis是一個性能非常高的內存Key-Value NoSQL，它支持List和Set、SortedSet等簡單集合，如果你的數據分析需求簡單地通過排序，鏈表就可以解決，同時總的數據量不大於內存（准確地說是內存加上虛擬內存再除以2），那麼無疑使用Redis會達到非常驚人的分析性能。
還有很多易並行問題（Embarrassingly Parallel），計算可以分解成完全獨立的部分，或者很簡單地就能改造出分布式演算法，比如大規模臉部識別、圖形渲染等，這樣的問題自然是使用並行處理集群比較適合。
而大多數統計分析，機器學習問題可以用MapRece演算法改寫。MapRece目前最擅長的計算領域有流量統計、推薦引擎、趨勢分析、用戶行為分析、數據挖掘分類器、分布式索引等。
2. 面對大數據OLAP大一些問題
OLAP分析需要進行大量的數據分組和表間關聯，而這些顯然不是NoSQL和傳統資料庫的強項，往往必須使用特定的針對BI優化的資料庫。比如絕大多數針對BI優化的資料庫採用了列存儲或混合存儲、壓縮、延遲載入、對存儲數據塊的預統計、分片索引等技術。
Hadoop平台上的OLAP分析，同樣存在這個問題，Facebook針對Hive開發的RCFile數據格式，就是採用了上述的一些優化技術，從而達到了較好的數據分析性能。如圖2所示。
然而，對於Hadoop平台來說，單單通過使用Hive模仿出SQL，對於數據分析來說遠遠不夠，首先Hive雖然將HiveQL翻譯MapRece的時候進行了優化，但依然效率低下。多維分析時依然要做事實表和維度表的關聯，維度一多性能必然大幅下降。其次，RCFile的行列混合存儲模式，事實上限制死了數據格式，也就是說數據格式是針對特定分析預先設計好的，一旦分析的業務模型有所改動，海量數據轉換格式的代價是極其巨大的。最後，HiveQL對OLAP業務分析人員依然是非常不友善的，維度和度量才是直接針對業務人員的分析語言。
而且目前OLAP存在的最大問題是：業務靈活多變，必然導致業務模型隨之經常發生變化，而業務維度和度量一旦發生變化，技術人員需要把整個Cube（多維立方體）重新定義並重新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系統成為死板的日常報表系統。
使用Hadoop進行多維分析，首先能解決上述維度難以改變的問題，利用Hadoop中數據非結構化的特徵，採集來的數據本身就是包含大量冗餘信息的。同時也可以將大量冗餘的維度信息整合到事實表中，這樣可以在冗餘維度下靈活地改變問題分析的角度。其次利用Hadoop MapRece強大的並行化處理能力，無論OLAP分析中的維度增加多少，開銷並不顯著增長。換言之，Hadoop可以支持一個巨大無比的Cube，包含了無數你想到或者想不到的維度，而且每次多維分析，都可以支持成千上百個維度，並不會顯著影響分析的性能。
而且目前OLAP存在的最大問題是：業務靈活多變，必然導致業務模型隨之經常發生變化，而業務維度和度量一旦發生變化，技術人員需要把整個Cube（多維立方體）重新定義並重新生成，業務人員只能在此Cube上進行多維分析，這樣就限制了業務人員快速改變問題分析的角度，從而使所謂的BI系統成為死板的日常報表系統。
3. 一種Hadoop多維分析平台的架構
整個架構由四大部分組成：數據採集模塊、數據冗餘模塊、維度定義模塊、並行分 析模塊。
數據採集模塊採用了Cloudera的Flume，將海量的小日誌文件進行高速傳輸和合並，並能夠確保數據的傳輸安全性。單個collector宕機之後，數據也不會丟失，並能將agent數據自動轉移到其他的colllecter處理，不會影響整個採集系統的運行。如圖5所示。
數據冗餘模塊不是必須的，但如果日誌數據中沒有足夠的維度信息，或者需要比較頻繁地增加維度，則需要定義數據冗餘模塊。通過冗餘維度定義器定義需要冗餘的維度信息和來源（資料庫、文件、內存等），並指定擴展方式，將信息寫入數據日誌中。在海量數據下，數據冗餘模塊往往成為整個系統的瓶頸，建議使用一些比較快的內存NoSQL來冗餘原始數據，並採用盡可能多的節點進行並行冗餘；或者也完全可以在Hadoop中執行批量Map，進行數據格式的轉化。
維度定義模塊是面向業務用戶的前端模塊，用戶通過可視化的定義器從數據日誌中定義維度和度量，並能自動生成一種多維分析語言，同時可以使用可視化的分析器通過GUI執行剛剛定義好的多維分析命令。
並行分析模塊接受用戶提交的多維分析命令，並將通過核心模塊將該命令解析為Map-Rece，提交給Hadoop集群之後，生成報表供報表中心展示。
核心模塊是將多維分析語言轉化為MapRece的解析器，讀取用戶定義的維度和度量，將用戶的多維分析命令翻譯成MapRece程序。核心模塊的具體邏輯如圖6所示。
圖6中根據JobConf參數進行Map和Rece類的拼裝並不復雜，難點是很多實際問題很難通過一個MapRece Job解決，必須通過多個MapRece Job組成工作流（WorkFlow），這里是最需要根據業務進行定製的部分。圖7是一個簡單的MapRece工作流的例子。
MapRece的輸出一般是統計分析的結果，數據量相較於輸入的海量數據會小很多，這樣就可以導入傳統的數據報表產品中進行展現。
6. 嵌入式實時資料庫系統並發控制機制的特點主要體現在哪些方面
1. CouchDB 所用語言： Erlang 特點：DB一致性，易於使用 使用許可： Apache 協議： HTTP/REST 雙向數據復制， 持續進行或臨時處理， 處理時帶沖突檢查， 因此，採用的是master-master復制（見編注2） MVCC – 寫操作不阻塞讀操作 可保存文件之前的版本 Crash-only（可靠的）設計 需要不時地進行數據壓縮 視圖：嵌入式 映射/減少 格式化視圖：列表顯示 支持進行伺服器端文檔驗證 支持認證 根據變化實時更新 支持附件處理 因此， CouchApps（獨立的 js應用程序） 需要 jQuery程序庫 最佳應用場景：適用於數據變化較少，執行預定義查詢，進行數據統計的應用程序。適用於需要提供數據版本支持的應用程序。 例如： CRM、CMS系統。 master-master復制對於多站點部署是非常有用的。 （編注2：master-master復制：是一種資料庫同步方法，允許數據在一組計算機之間共享數據，並且可以通過小組中任意成員在組內進行數據更新。） 2. Redis 所用語言：C/C++ 特點：運行異常快 使用許可： BSD 協議：類 Telnet 有硬碟存儲支持的內存資料庫， 但自2.0版本以後可以將數據交換到硬碟（注意， 2.4以後版本不支持該特性！） Master-slave復制（見編注3） 雖然採用簡單數據或以鍵值索引的哈希表，但也支持復雜操作，例如 ZREVRANGEBYSCORE。 INCR & co （適合計算極限值或統計數據） 支持 sets（同時也支持 union/diff/inter） 支持列表（同時也支持隊列；阻塞式 pop操作） 支持哈希表（帶有多個域的對象） 支持排序 sets（高得分表，適用於范圍查詢） Redis支持事務 支持將數據設置成過期數據（類似快速緩沖區設計） Pub/Sub允許用戶實現消息機制 最佳應用場景：適用於數據變化快且資料庫大小可遇見（適合內存容量）的應用程序。 例如：股票價格、數據分析、實時數據搜集、實時通訊。 （編注3：Master-slave復制：如果同一時刻只有一台伺服器處理所有的復制請求，這被稱為 Master-slave復制，通常應用在需要提供高可用性的伺服器集群。） 3. MongoDB 所用語言：C++ 特點：保留了SQL一些友好的特性（查詢，索引）。 使用許可： AGPL（發起者： Apache） 協議： Custom, binary（ BSON） Master/slave復制（支持自動錯誤恢復，使用 sets 復制） 內建分片機制 支持 javascript表達式查詢 可在伺服器端執行任意的 javascript函數 update-in-place支持比CouchDB更好 在數據存儲時採用內存到文件映射 對性能的關注超過對功能的要求 建議最好打開日誌功能（參數 –journal） 在32位操作系統上，資料庫大小限制在約2.5Gb 空資料庫大約占 192Mb 採用 GridFS存儲大數據或元數據（不是真正的文件系統） 最佳應用場景：適用於需要動態查詢支持；需要使用索引而不是 map/rece功能；需要對大資料庫有性能要求；需要使用 CouchDB但因為數據改變太頻繁而占滿內存的應用程序。 例如：你本打算採用 MySQL或 PostgreSQL，但因為它們本身自帶的預定義欄讓你望而卻步。 4. Riak 所用語言：Erlang和C，以及一些Javascript 特點：具備容錯能力 使用許可： Apache 協議： HTTP/REST或者 custom binary 可調節的分發及復制(N, R, W) 用 JavaScript or Erlang在操作前或操作後進行驗證和安全支持。 使用JavaScript或Erlang進行 Map/rece 連接及連接遍歷：可作為圖形資料庫使用 索引：輸入元數據進行搜索（1.0版本即將支持） 大數據對象支持（ Luwak） 提供「開源」和「企業」兩個版本 全文本搜索，索引，通過 Riak搜索伺服器查詢（ beta版） 支持Masterless多站點復制及商業許可的 SNMP監控 最佳應用場景：適用於想使用類似 Cassandra（類似Dynamo）資料庫但無法處理 bloat及復雜性的情況。適用於你打算做多站點復制，但又需要對單個站點的擴展性，可用性及出錯處理有要求的情況。 例如：銷售數據搜集，工廠控制系統；對宕機時間有嚴格要求；可以作為易於更新的 web伺服器使用。 5. Membase 所用語言： Erlang和C 特點：兼容 Memcache，但同時兼具持久化和支持集群 使用許可： Apache 2.0 協議：分布式緩存及擴展 非常快速（200k+/秒），通過鍵值索引數據 可持久化存儲到硬碟 所有節點都是唯一的（ master-master復制） 在內存中同樣支持類似分布式緩存的緩存單元 寫數據時通過去除重復數據來減少 IO 提供非常好的集群管理 web界面 更新軟體時軟無需停止資料庫服務 支持連接池和多路復用的連接代理 最佳應用場景：適用於需要低延遲數據訪問，高並發支持以及高可用性的應用程序 例如：低延遲數據訪問比如以廣告為目標的應用，高並發的 web 應用比如網路游戲（例如 Zynga） 6. Neo4j 所用語言： Java 特點：基於關系的圖形資料庫 使用許可： GPL，其中一些特性使用 AGPL/商業許可 協議： HTTP/REST（或嵌入在 Java中） 可獨立使用或嵌入到 Java應用程序 圖形的節點和邊都可以帶有元數據 很好的自帶web管理功能 使用多種演算法支持路徑搜索 使用鍵值和關系進行索引 為讀操作進行優化 支持事務（用 Java api） 使用 Gremlin圖形遍歷語言 支持 Groovy腳本 支持在線備份，高級監控及高可靠性支持使用 AGPL/商業許可 最佳應用場景：適用於圖形一類數據。這是 Neo4j與其他nosql資料庫的最顯著區別 例如：社會關系，公共交通網路，地圖及網路拓譜 7. Cassandra 所用語言： Java 特點：對大型表格和 Dynamo支持得最好 使用許可： Apache 協議： Custom, binary (節約型) 可調節的分發及復制(N, R, W) 支持以某個范圍的鍵值通過列查詢 類似大表格的功能：列，某個特性的列集合 寫操作比讀操作更快 基於 Apache分布式平台盡可能地 Map/rece 我承認對 Cassandra有偏見，一部分是因為它本身的臃腫和復雜性，也因為 Java的問題（配置，出現異常，等等） 最佳應用場景：當使用寫操作多過讀操作（記錄日誌）如果每個系統組建都必須用 Java編寫（沒有人因為選用 Apache的軟體被解僱） 例如：銀行業，金融業（雖然對於金融交易不是必須的，但這些產業對資料庫的要求會比它們更大）寫比讀更快，所以一個自然的特性就是實時數據分析 8. HBase （配合 ghshephard使用） 所用語言： Java 特點：支持數十億行X上百萬列 使用許可： Apache 協議：HTTP/REST （支持 Thrift，見編注4） 在 BigTable之後建模 採用分布式架構 Map/rece 對實時查詢進行優化 高性能 Thrift網關 通過在server端掃描及過濾實現對查詢操作預判 支持 XML, Protobuf, 和binary的HTTP Cascading, hive, and pig source and sink moles 基於 Jruby（ JIRB）的shell 對配置改變和較小的升級都會重新回滾 不會出現單點故障 堪比MySQL的隨機訪問性能 最佳應用場景：適用於偏好BigTable:)並且需要對大數據進行隨機、實時訪問的場合。 例如： Facebook消息資料庫（更多通用的用例即將出現） 編注4：Thrift 是一種介面定義語言，為多種其他語言提供定義和創建服務，由Facebook開發並開源。 當然，所有的系統都不只具有上面列出的這些特性。這里我僅僅根據自己的觀點列出一些我認為的重要特性。與此同時，技術進步是飛速的，所以上述的內容肯定需要不斷更新。我會盡我所能地更新這個列表。
7. Firebase是怎樣成為Google Cloud對標Amazon AWS競爭中的重要一環
Google I/O大會推出了全新的Firebase平台，開發者反響強烈。Google一年半前收購Firebase時後者團隊僅26人，按照Google的作風，收購後的公司品牌就要關掉。至今收購而保留下來的品牌並不多，除非收購前品牌影響力很大，比如Nest、Android，都是特別大體量的產品。Firebase能夠保留下品牌，足見這個產品的影響力。
那一家由26人組成的公司做出了怎樣的產品?又怎樣成為Google Cloud戰略中重要的一環?因為野狗和Firebase的API完全兼容，所以由我來寫這篇文章還是很有發言權。
Firebase究竟好在哪?
1、本地副本，弱中心化的架構
Firebase的實現原理可以理解為是一個客戶端分布式實時資料庫。在每個客戶端上都有一個雲端資料庫的副本。當客戶端被更改的時候，每個設備上的資料庫副本都會相應的進行同步。
當實現本地副本、弱中心化以後，有很多好處。比如可以提供離線處理，在網路不好的情況下可以無需中斷。只要網路一好，立刻進行同步。還有可以很簡化開發模型，因為數據在每個客戶端的SDK里都有緩存，執行速度非常的快。
PS：這樣的特性對使用者特別友好，但是對系統開發來說特別考驗架構和編程能力，因為要在每個端上要實現一個內存資料庫。更別提還有事務處理等復雜功能。
2、前端化思維
Firebase的產品和Facebook的Parse不一樣的地方是，Firebase對前端工程師特別友好。
Web工程師逐漸正在崛起，不再只是寫個代碼，做個頁面這么簡單。
有人說Firebase平均每月2萬的凈增是從Google導入的新用戶，但實際情況是產品優秀。
Firebase是一個BaaS ( Backend as a Service ) 服務。Firebase的應用場景非常豐富，比如多人互動、游戲、物聯網等。
傳統雲服務體驗怎麼樣?
先說下傳統雲服務公司的定義：SaaS、PaaS、IaaS。越往下自由度越高，越往上使用起來越簡單。
SaaS解決的是開箱即用的模鄭問題，不用寫代碼，直接用。PaaS解決的是運維的問題，寫完代碼往雲端一扔，搞定。而IaaS解決的是硬體資源彈性擴容的問題，像個水龍頭，用多少擰多少。
目前PaaS代表的產品比如HeroKu，信碼磨Google App Engine、國內SAE等，幾乎全線已掛或半死不活。PaaS掛掉的原因是沒有解決根本問題，半吊子。又不簡單，又不自由。
廣義BaaS是指用戶需要通過遠程API獲得服務的雲服務產品。比如類滑斗似統計服務MixPanel、友盟等。狹義的BaaS是指通過遠程API提供計算和存儲資源的產品，比如Parse、Firebase、Twilio、Pusher，Apple Cloud Kit這樣的產品。
新版Firebase能為Google帶來什麼?
BaaS接近SaaS，但是提供更多的自由度。用戶使用Firebase API可以很方便的開發出實時通信功能，而無需後端雲服務。蘋果、AWS、Paypal等很多公司都有自己的BaaS平台。不同於傳統的PaaS服務還需要上傳到容器，BaaS服務僅需要API介面就可以進行編程。
比如新版Firebase與分析服務實現了深度集成，它可以向Firebase反饋基礎的用戶信息，與Google Analytics一樣，開發者也可以指定特定的細節，例如追蹤按鈕的按壓或者購買的操作。
藉助這些數據Firebase能夠給出一個直觀的分析報告，以便開發者深入了解用戶的行為或者廣告的投放效果。
本次更新後，Firebase可以遠程變更應用配置，開發者可以藉此進行某些A/B測試。同時Firebase開放了全新的通知系統，此功能基於Google Cloud Messaging。
除此之外，Google還將Firebase與Cloud Test Lab深度結合了起來，以便開發者在真實設備上測試移動應用，並重命名為Firebase Test Lab。
在美國的市場，IaaS亞馬遜已經是絕對的老大，Google沒有機會。Google希望通過Firebase這個產品能夠連接它的底層Google Cloud和上層的SaaS業務：Nest、Google Works、Admob、分析等。甚至Nest的API也是使用的Firebase。
在這次Google推出的包括分析、Push、Storage等功能，看起來沒有新意，但恰是透露了Google通過以Firebase為中心，以應用為切入口去和亞馬遜AWS競爭的戰略。
8. snorkelling和scuba diving的區別
snorkelling和scuba diving的區別：
1、Snorkelling是浮潛，浮在水面上；scuba diving是水肺潛水，要深入水底。
2、Snorkelling是帶著潛水面鏡（Mask）和呼吸管（Snorkel）浮在水面。
scuba diving背後背一個（甚至多個）氣瓶 (Tank)下到水底。
(8)facebook內存資料庫擴展閱讀：
SCUBA
英語：Self-Contained Underwater Breathing Apparatus，SCUBA），又稱水肺潛水、SCUBA DIVING，指潛水員自行攜帶水下呼吸系統所進行禪茄的潛水活陸賣動。
其中有開放式(open-circuit)呼吸系統，及封閉式(closed-circuit)呼吸系統，原理都是利用調節器(Regulator)裝置把氣瓶中的壓縮氣體轉化成可供人體正常呼吸的壓力。
計算早襲逗機專用詞彙：Scuba，Facebook的一個非常快速、分布式的內存資料庫，用於實時分析和查詢。是Facebook的回歸分析代碼、錯誤報告監控、廣告收入監控和性能調試的背後主力。
snorkel
呼吸管的英文snorkel一字本來是指第二次世界大戰時，德國U-潛艇的通氣管。通氣管讓潛艇在潛航狀態下可以開動柴油機為電池組充電。
從材質上，根據咬嘴和蛇腹管材質可以分為硅膠呼吸管和pvc呼吸管
從設計結構來分，可分為全濕式、半濕式、全乾式，區別就是呼吸管頂部是否有浮力閉氣閥或防浪結構。
參考資料：snorkel-網路
9. memcached與redis區別
1.性能上：
性能上都很出色，具體到細節，由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起 Memcached，還是稍有遜色。
2.內存空間和數據量大小：
MemCached可以修改最大內存，採用LRU演算法。Redis增加了VM的特性，突破了物理內存的限制。
3.操作便利上：
MemCached數據陸昌結構單一，僅用來緩存數據，而Redis支持更加豐富的數據類型，也可以在伺服器端直接對數據進行豐富的操作,這樣可以減少網路IO次數和數據體積。
4.可靠性上：
MemCached不支持數據持久化，早埋扒斷電或重啟後數據消失，但其穩定性是有保證的。Redis支持數據持久化和數據恢復，允許單點故障，但是同時也會付出性能的代價。
5.應用場景：
Memcached：動態系統中減輕資料庫負載，提升性能；做緩存，適合多讀少寫，大數據量的情況（如人人網大量查詢用戶信息、好友信息、文章信息等）。
Redis：適用於對讀寫效率要求都很高，數據處理業務復雜和對安全性要求較高的系統（如新浪微博的計數和微博發布部分系統，對數據安全性、讀寫要求都很高）。
----
需要慎重考慮的部分
1.Memcached單個key-value大小有限，一個value最大隻支持1MB，而Redis最大支持512MB
2.Memcached只是個內存緩存，對可靠性無要求；而Redis更傾向於內存資料庫，因此對對可靠性方面要求比較高
3.從本質上講，Memcached只是一個單一key-value內存Cache；而Redis則是一個數據結構內存資料庫，支持五種數據類型，因此Redis除單純緩存作用外，還可以處理一些簡單的邏輯運算，Redis不僅可以緩存，而且還可以作為資料庫用
4.新版本（3.0）的Redis是指集群分布式，也就是說集群本身均衡客戶端請求，各個節點可以交流，可拓展行、可維護性更強大。
----
介紹
Memcached 是一個高性能的分布式內存對象緩存系統，用於動態Web應用以減輕資料庫負載。它通過在內存中緩存數據和對象來減少讀取資料庫的次數，從而提供動態、資料庫驅動網站的速度，現在已被LiveJournal、hatena、Facebook、Vox、LiveJournal等公司所使用。
Redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、 list(鏈表)、set(集合)和zset(有序集合)。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更液局豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步,當前 Redis的應用已經非常廣泛，國內像新浪、淘寶，國外像 Flickr、Github等均在使用Redis的緩存服務。