❶ 數據倉庫與資料庫的區別
簡而言之，資料庫是面向事務的設計，數據倉庫是面向主題設計的。
資料庫一般存儲在線交易數據悶孝，數據倉庫存儲的一般是歷史數據。
資料庫設計是盡量避免冗餘，一般採用符合範式的規則來設計，數據倉庫在設計是有意引入冗餘，採用反範式的方式來設計。
資料庫是為捕獲數據而設計，數據倉庫是為分析數據而設計，它的兩個基本的元素是維表和事實表。維是看問題的角度，比如時間，部門，維表放的就是這些東西的定義，事實表裡放著要查詢的數據，同時有維的ID。
單從概念上講，有些晦澀。任何技術都是為應用服務的，結合應用可以很容易地理解。以銀行業務為例。資料庫是事務系統的數據平台，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這里，可以簡單地理解為用資料庫記帳。數據倉庫是分析系統的數據平台，它從事務系統獲取數據，並做匯總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月擾孫發生多少交易，該分行當前存款余額是多少。如果存款又多，螞李稿消費交易又多，那麼該地區就有必要設立ATM了。
顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能存儲很短一段時間的數據。而分析系統是事後的，它要提供關注時間段內所有的有效數據。這些數據是海量的，匯總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。
數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型資料庫」。那麼，數據倉庫與傳統資料庫比較，有哪些不同呢?讓我們先看看W.H.Inmon關於數據倉庫的定義:面向主題的、集成的、與時間相關且不可修改的數據集合。
「面向主題的」:傳統資料庫主要是為應用程序進行數據處理，未必按照同一主題存儲數據;數據倉庫側重於數據分析工作，是按照主題存儲的。這一點，類似於傳統農貿市場與超市的區別—市場裡面，白菜、蘿卜、香菜會在一個攤位上，如果它們是一個小販賣的;而超市裡，白菜、蘿卜、香菜則各自一塊。也就是說，市場里的菜(數據)是按照小販(應用程序)歸堆(存儲)的，超市裡面則是按照菜的類型(同主題)歸堆的。
「與時間相關」:資料庫保存信息的時候，並不強調一定有時間信息。數據倉庫則不同，出於決策的需要，數據倉庫中的數據都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對於決策者意義是不同的。
「不可修改」:數據倉庫中的數據並不是最新的，而是來源於其它數據源。數據倉庫反映的是歷史信息，並不是很多資料庫處理的那種日常事務數據(有的資料庫例如電信計費資料庫甚至處理實時信息)。因此，數據倉庫中的數據是極少或根本不修改的;當然，向數據倉庫添加數據是允許的。
數據倉庫的出現，並不是要取代資料庫。目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。
補充一下，數據倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的存儲也較大。為了更好地為前端應用服務，數據倉庫必須有如下幾點優點，否則是失敗的數據倉庫方案。
1.效率足夠高。客戶要求的分析數據一般分為日、周、月、季、年等，可以看出，日為周期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的。
2.數據質量。客戶要看各種信息，肯定要准確的數據，但由於數據倉庫流程至少分為3步，2次ETL，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益。
3.擴展性。之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，客戶不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。
❷ 技術干貨：sql on Hadoop在快手大數據平台的實踐與優化
快手大數據架構工程師鍾靚近日在 A2M 人工智慧與機器學習創新峰會分享了題為《SQL on Hadoop 在快手大數據平台的實踐與優化》的演講，主要從 SQL on Hadoop 介紹、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用經驗和改進分析、快手 SQL on Hadoop 的未來計劃四方面介紹了 SQL on Hadoop 架構。
SQL on Hadoop，顧名思義它是基於 Hadoop 生態的一個 SQL 引擎架構，我們其實常常聽到 Hive、SparkSQL、Presto、Impala 架構。接下來，我會簡單的描述一下常用的架構情況。
HIVE，一個數據倉庫系統。它將數據結構映射到存儲的數據中，通過 SQL 對大規模的分布式存儲數據進行讀、寫、管理。
根據定義的數據模式，以及輸出 Storage，它會對輸入的 SQL 經過編譯、優化，生成對應引擎的任務，然後調度執行生成的任務。
HIVE 當前支持的引擎類型有：MR、SPARK、TEZ。
基於 HIVE 本身的架構，還有一些額外的服務提供方式，比如 HiveServer2 與 MetaStoreServer 都是 Thrift 架構。
此外，HiveServer2 提供遠程客戶端提交 SQL 任務的功能，MetaStoreServer 則提供遠程客戶端操作元數據的功能。
Spark，一個快速、易用，以 DAG 作為執行模式的大規模數據處理的統一分析引擎，主要模塊分為 SQL 引擎、流式處理 、機器學習、圖處理。
SPARKSQL 基於 SPARK 的計算引擎，做到了統一數據訪問，集成 Hive，支持標准 JDBC 連接。SPARKSQL 常用於數據交互分析的場景。
SPARKSQL 的主要執行邏輯，首先是將 SQL 解析為語法樹，然後語義分析生成邏輯執行計劃，接著與元數據交互，進行邏輯執行計劃的優化，最後，將邏輯執行翻譯為物理執行計劃，即 RDD lineage，並執行任務。
PRESTO，一個互動式分析查詢的開源分布式 SQL 查詢引擎。
因為基於內存計算，PRESTO 的計算性能大於有大量 IO 操作的 MR 和 SPARK 引擎。它有易於彈性擴展，支持可插拔連接的特點。
業內的使用案例很多，包括 FaceBook、AirBnb、美團等都有大規模的使用。
我們看到這么多的 SQL on Hadoop 架構，它側面地說明了這種架構比較實用且成熟。利用 SQL on Hadoop 架構，我們可以實現支持海量數據處理的需求。
查詢平台每日 SQL 總量在 70 萬左右，DQL 的總量在 18 萬左右。AdHoc 集群主要用於交互分析及機器查詢，DQL 平均耗時為 300s；AdHoc 在內部有 Loacl 任務及加速引擎應用，所以查詢要求耗時較低。
ETL 集群主要用於 ETL 處理以及報表的生成。DQL 平均耗時為 1000s，DQL P50 耗時為 100s，DQL P90 耗時為 4000s，除上述兩大集群外，其它小的集群主要用於提供給單獨的業務來使用。
服務層是對上層進行應用的。在上層有四個模塊，這其中包括同步服務、ETL 平台、AdHoc 平台以及用戶程序。在調度上層，同樣也有四方面的數據，例如服務端日誌，對它進行處理後，它會直接接入到 HDFS 里，我們後續會再對它進行清洗處理；服務打點的數據以及資料庫信息，則會通過同步服務入到對應的數據源里，且我們會將元數據信息存在後端元數據系統中。
網頁爬取的數據會存入 hbase，後續也會進行清洗與處理。
HUE、NoteBook 主要提供的是互動式查詢的系統。報表系統、BI 系統主要是 ETL 處理以及常見的報表生成，額外的元數據系統是對外進行服務的。快手現在的引擎支持 MR、Presto 及 Spark。
管理系統主要用於管理我們當前的集群。HiveServer2 集群路由系統，主要用於引擎的選擇。監控系統以及運維系統，主要是對於 HiveServer2 引擎進行運維。
我們在使用 HiveServer2 過程中，遇到過很多問題。接下來，我會詳細的為大家闡述快手是如何進行優化及實踐的。
當前有多個 HiveServer2 集群，分別是 AdHoc 與 ETL 兩大集群，以及其他小集群。不同集群有對應的連接 ZK，客戶端可通過 ZK 連接 HiveServer2 集群。
為了保證核心任務的穩定性，將 ETL 集群進行了分級，分為核心集群和一般集群。在客戶端連接 HS2 的時候，我們會對任務優先順序判定，高優先順序的任務會被路由到核心集群，低優先順序的任務會被路由到一般集群。
BeaconServer 服務為後端 Hook Server 服務，配合 HS2 中的 Hook，在 HS2 服務之外實現了所需的功能。當前支持的模塊包括路由、審計、SQL 重寫、任務控制、錯誤分析、優化建議等。
•無狀態，BeaconServer 服務支持水平擴展。基於請求量的大小，可彈性調整服務的規模。
•配置動態載入，BeaconServer 服務支持動態配置載入。各個模塊支持開關，服務可動態載入配置實現上下線。比如路由模塊，可根據後端加速引擎集群資源情況，進行路由比率調整甚至熔斷。
•無縫升級，BeaconServer 服務的後端模塊可單獨進行下線升級操作，不會影響 Hook 端 HS2 服務。
•Hive 支持 SPARK 與 TEZ 引擎，但不適用於生產環境。
•SQL on Hadoop 的 SQL 引擎各有優缺點，用戶學習和使用的門檻較高。
•不同 SQL 引擎之間的語法和功能支持上存在差異，需要大量的測試和兼容工作，完全兼容的成本較高。
•不同 SQL 引擎各自提供服務會給數倉的血緣管理、許可權控制、運維管理、資源利用都帶來不便。
•在 Hive 中，自定義實現引擎。
•自動路由功能，不需要設置引擎，自動選擇適合的加速引擎。
•根絕規則匹配 SQL，只將兼容的 SQL 推給加速引擎。
•復用 HiveServer2 集群架構。
基於 HiveServer2，有兩種實現方式。JDBC 方式是通過 JDBC 介面，將 SQL 發送至後端加速引擎啟動的集群上。PROXY 方式是將 SQL 下推給本地的加速引擎啟動的 Client。
JDBC 方式啟動的後端集群，均是基於 YARN，可以實現資源的分時復用。比如 AdHoc 集群的資源在夜間會自動回收，作為報表系統的資源進行復用。
路由方案基於 HS2 的 Hook 架構，在 HS2 端實現對應 Hook，用於引擎切換；後端 BeaconServer 服務中實現路由 服務，用於 SQL 的路由規則的匹配處理。不同集群可配置不同的路由規則。
為了保證後算路由服務的穩定性，團隊還設計了 Rewrite Hook，用於重寫 AdHoc 集群中的 SQL，自動添加 LIMIT 上限，防止大數據量的 SCAN。
•易於集成，當前主流的 SQL 引擎都可以方便的實現 JDBC 與 PROXY 方式。再通過配置，能簡單的集成新的查詢引擎，比如 impala、drill 等。
•自動選擇引擎，減少了用戶的引擎使用成本，同時也讓遷移變得更簡單。並且在加速引擎過載 的情況下，可以動態調整比例，防止因過載 對加速性能的影響。
•自動降級，保證了運行的可靠性。SQL 路由支持 failback 模塊，可以根據配置選擇是否再路由引擎執行失敗後，回滾到 MR 運行。
•模塊復用，對於新增的引擎，都可以復用 HiveServer2 定製的血緣採集、許可權認證、並發鎖控制等方案，大大降低了使用成本。
•資源復用，對於 adhoc 查詢佔用資源可以分時動態調整，有效保證集群資源的利用率。
當查詢完成後，本地會輪詢結果文件，一直獲取到 LIMIT 大小，然後返回。這種情況下，當有大量的小文件存在，而大文件在後端的時候，會導致 Bad Case，不停與 HDFS 交互，獲取文件信息以及文件數據，大大拉長運行時間。
在 Fetch 之前，對結果文件的大小進行預排序，可以有數百倍的性能提升。
示例：當前有 200 個文件。199 個小文件一條記錄 a，1 個大文件混合記錄 a 與 test 共 200 條，大文件名 index 在小文件之後。
Hive 中有一個 SimpleFetchOptimizer 優化器，會直接生成 FetchTask，減小資源申請時間與調度時間。但這個優化會出現瓶頸。如果數據量小，但是文件數多，需要返回的條數多，存在能大量篩掉結果數據的 Filter 條件。這時候串列讀取輸入文件，導致查詢延遲大，反而沒起到加速效果。
在 SimpleFetchOptimizer 優化器中，新增文件數的判斷條件，最後將任務提交到集群環境，通過提高並發來實現加速。
示例：讀取當前 500 個文件的分區。優化後的文件數閾值為 100。
一個表有大量的子分區，它的 DESC 過程會與元數據交互，獲取所有的分區。但最後返回的結果，只有跟表相關的信息。
與元數據交互的時候，延遲了整個 DESC 的查詢，當元數據壓力大的時候甚至無法返回結果。
針對於 TABLE 的 DESC 過程，直接去掉了跟元數據交互獲取分區的過程，加速時間跟子分區數量成正比。
示例：desc 十萬分區的大表。
•復用 split 計算的數據，跳過 rece 估算重復統計輸入過程。輸入數據量大的任務，調度速率提升 50%。
•parquetSerde init 加速，跳過同一表的重復列剪枝優化，防止 map task op init 時間超時。
•新增 LazyOutputFormat，有 record 輸出再創建文件，避免空文件的產生，導致下游讀取大量空文件消耗時間。
•statsTask 支持多線程聚合統計信息，防止中間文件過多導致聚合過慢，增大運行時間。
•AdHoc 需要打開並行編譯，防止 SQL 串列編譯導致整體延遲時間增大的問題。
HS2 啟動時會對物化視圖功能進行初始化，輪詢整個元資料庫，導致 HS2 的啟動時間非常長，從下線狀態到重新上線間隔過大，可用性很差。
將物化視圖功能修改為延遲懶載入，單獨線程載入，不影響 HS2 的服務啟動。物化視圖支持載入中獲取已緩存信息，保證功能的可用性。
HS2 啟動時間從 5min+提升至<5s。
HS2 本身上下線成本較高，需要保證服務上的任務全部執行完成才能進行操作。配置的修改可作為較高頻率的操作，且需要做到熱載入。
在 HS2 的 ThriftServer 層我們增加了介面，與運維系統打通後，配置下推更新的時候自動調用，可實現配置的熱載入生效。
HiveServer2 的 scratchdir 主要用於運行過程中的臨時文件存儲。當 HS2 中的會話創建時，便會創建 scratchdir。在 HDFS 壓力大的時候，大量的會話會阻塞在創建 scratchdir 過程，導致連接數堆積至上限，最終 HS2 服務無法再連入新連接，影響服務可用性。
對此，我們先分離了一般查詢與 create temporay table 查詢的 scratch 目錄，並支持 create temporay table 查詢的 scratch 的懶創建。當 create temporay table 大量創建臨時文件，便會影響 HDFS NameNode 延遲時間的時候，一般查詢的 scratchdir HDFS NameNode 可以正常響應。
此外，HS2 還支持配置多 scratch，不同的 scratch 能設置載入比率，從而實現 HDFS 的均衡負載。
Hive 調度其中存在兩個問題。
一、子 Task 非執行狀態為完成情況的時候，若有多輪父 Task 包含子 Task，導致子 Task 被重復加入調度隊列。這種 Case，需要將非執行狀態修改成初始化狀態。
二、當判斷子 Task 是否可執行的過程中，會因為狀態檢測異常，無法正常加入需要調度的子 Task，從而致使查詢丟失 Stage。而這種 Case，我們的做法是在執行完成後，加入一輪 Stage 的執行結果狀態檢查，一旦發現有下游 Stage 沒有完成，直接拋出錯誤，實現查詢結果狀態的完備性檢查。
•HS2 實現了介面終止查詢 SQL。利用這個功能，可以及時終止異常 SQL。
•metastore JDOQuery 查詢優化，關鍵字異常跳過，防止元數據長時間卡頓或者部分異常查詢影響元數據。
•增加開關控制，強制覆蓋外表目錄，解決 insert overwrite 外表，文件 rename 報錯的問題。
•hive parquet 下推增加關閉配置，避免 parquet 異常地下推 OR 條件，導致結果不正確。
•executeForArray 函數 join 超大字元串導致 OOM，增加限制優化。
•增加根據 table 的 schema 讀取分區數據的功能，避免未級聯修改分區 schema 導致讀取數據異常。
•部分用戶並沒有開發經驗，無法處理處理引擎返回的報錯。
•有些錯誤的報錯信息不明確，用戶無法正確了解錯誤原因。
•失敗的任務排查成本高，需要對 Hadoop 整套系統非常熟悉。
•用戶的錯誤 SQL、以及需要優化的 SQL，大量具有共通性。人力維護成本高，但系統分析成本低。
SQL 專家系統基於 HS2 的 Hook 架構，在 BeaconServer 後端實現了三個主要的模塊，分別是 SQL 規則控制模塊、SQL 錯誤分析模塊，與 SQL 優化建議模塊。SQL 專家系統的知識庫，包含關鍵字、原因說明、處理方案等幾項主要信息，存於後端資料庫中，並一直積累。
通過 SQL 專家系統，後端可以進行查詢 SQL 的異常控制，避免異常 SQL 的資源浪費或者影響集群穩定。用戶在遇到問題時，能直接獲取問題的處理方案，減少了使用成本。
示例：空分區查詢控制。
SQL 專家系統能解決一部分 HS2 的任務執行的錯誤診斷需求，但是比如作業 健康 度、任務執行異常等問題原因的判斷，需要專門的系統來解決，為此我們設計了作業診斷系統。
作業診斷系統在 YARN 的層面，針對不同的執行引擎，對搜集的 Counter 和配置進行分析。在執行層面，提出相關的優化建議。
作業診斷系統的數據也能通過 API 提供給 SQL 專家系統，補充用於分析的問題原因。
作業診斷系統提供了查詢頁面來查詢運行的任務。以下是命中 map 輸入過多規則的任務查詢過程：
❸ 零基礎能成為數據分析師嗎
不少人後台問我，如何轉行做數據分析師，或畢業生怎樣入行。我之前的文章都是圍繞硬技能來寫，這次以我知乎上的一篇答案為基礎談一下軟技能。權當做雜談。
我進入互聯網行業完全是零基礎，不是數據分析零基礎，是樣樣能力零基礎。
零基礎到什麼樣子？我找工作花了三到四個月時間，最後以運營身份入職。
我從來不是數理強人，大學雖學習過高數、統計學、SQL和C語言，均是低空略過，考試還藉助了小夥伴的力量。現在回頭看，當時應該多學些。
最開始我不會vlookup，也沒人教我，Excel只能做基礎的操作。那時要關聯多張報表，我仗著手速快，一個個搜索復制黏貼的…數據量一多肯定哭。後來我想這可不是辦法啊。於是藉助萬能的網路：
「Excel怎麼匹配多張表的數據。」
然後第一次看到vlookup函數。我也沒有一次學會，每次用都要先看一遍網上的樣例。後續我教組員的時候，他們學得比我快多了。
Excel一步一個腳印，學習都是依賴搜索和琢磨，抽空用工作中的內容練習分析：比如什麼樣的用戶願意用我們APP，用戶哪些指標特別好。
即使在此期間，我也不會數據透視表。
記得15年初，老闆給了我一個任務：網上收集數據，大約需要幾萬條，我不可能全部復制黏貼下來啊，便繼續查詢：
如何快速下載網頁上的數據。
於是知道了爬蟲，知道了Python，但我並不會。最後靠第三方爬蟲工具，按照教程學習。早期已經學習過HTML+CSS，然後再了解網頁結構，學習Get／Post，學習正則。花了一周時間加班，才下載下來。
可沒有結束，數據是臟數據，我還需要清洗。再花一周時間學習Excel的find,right,mid,replace,trim等文本處理函數。那時候不知道這叫數據清洗，但是學會了很多技巧，即使我盡可能快速省力，還是花費數天。
當我現在寫Python爬蟲的時候，效率快速很多。包括文本清洗，用Levenshtein速度杠杠的。加起來一晚上就搞定。
任何學習都不是無用的，很多知識相通。我因為爬蟲學習了HTML+CSS，後續便觸理旁通地了解了網站結構和網站分析。
後續知道布置網路統計，知道JS，學習網頁端的各類指標，了解訪問路徑、漏斗轉化、跳出率退出率等。這些知識不止能用在網站上。也能用在APP分析、用戶行為上。
我們把學習當成一個點，學完這本書就看下本書，其實這樣發揮不出學習的效率。任何知識都具有關聯性，A知識可以應用在B知識上，知識技能樹應該是呈網狀發散的。
上面鏈條是我基於前置知識掌握新知識的關系譜。數據分析涉及的領域很寬廣，除了本身扎實的業務背景，還需要瑞士軍刀般的技能樹，屬於T型能力（一專多才）。
比如你看到某個頁面跳出率較高。除了常規的分析外，還要檢查網路速度，用戶弱網環境，是不是HTML頁面載入過多，是否使用了緩存，網路DNS如何等。這些知識不會有人教你，但它左右業務結果。
看到這里別怕，雖然要學的多，但是隨著學習的加深，很多知識是共通的。就像轉化率來源於網站分析，卻能用於產品路徑，既能升華為桑基圖，又能做用戶分層。越學到後面，越容易一法通萬法通。
驅動力
其實零基礎學習數據分析，最難的門檻不是技能，而是學習動力。我從零培養過數據分析師，從零教過Excel、從零教過SQL、從零教過分析思維、從零教過Python。難點從不在於這些知識，而是你真的想不想學。
不是下載了十幾G的資料就是學習，不是關注了很多公眾號就是學習。因為十幾G的資料最終不會打開，很多公眾號最後都是未讀。這能說明想學習？零基礎太容易無從下手，難以堅持，淺嘗則止了。
無從下手，這是不知道學什麼，我說過數據分析是一門比較寬廣的學科。它既有傳統商業分析的方法論，也有數據時代的統計和編程。可它又偏偏是任何崗位任何職業都能用到的技能，繞不過。
學習是很主觀的事情，我們從小學開始讀到大學，數十年的學生生涯，最缺漏的能力是主動學習。中考高考打磨那麼多年，很大情況是環境因素逼迫人去學習，本身沒有任何學習的驅動力和習慣。大學四年再一度過，可能學習性就消磨殆盡了。
之所以說我們習慣被動學習，是大家都有一道題目做一道題目，只知道公式應用，不需要知曉原理。教材輔導題海戰術，內容也不會超綱。整個大的學習環境都是為被動打造。
現在學習數據分析，拿起書籍、打開PDF資料、關注公眾號。不會有老師糾正你輔導你，不會有作業鞭策你訓練你。也不知道工作中哪個會經常用到，沒有練手的數據題目，甚至連網路上的知識質量都難以辨別。
無從下手，對吧，可這才是主動學習。
心態要轉變。
零基礎學習數據分析，最大的老師只能是自己，不會有任何一篇文章一夜教人成為數據分析師。我帶過願意學習並且成長很快的實習生，也教導過有興趣但依舊帶不出節奏的同事。前者是主動學習，後者是止於興趣的被動學習。
因為是零基礎，所以才更需要主動性。數據分析本事是發展很快的行業，幾年前會SQL就行，現在得了解些MR和HIVE，過幾年SparkSQL也許就是必備，如果想在這一行做的好一些。持續的學習是必須的能力。或者基礎不如其他人，至少學習性別輸吧。
我也給出我的建議，學習應該是具體為解決某一個問題而設立目標，說透徹點，實戰為王。不論是何種職業，一定或多或少能接觸數據。先別去分析，而是想，能用這些數據干什麼，做一個簡單的假設。
我是HR，我的假設就是最近招人越來越困難啦，
我是市場，我的假設就是現在營銷成本太高，又沒有什麼效果。
我是運營或者產品，更好辦了，假設某指標的數據因為ABC等原因而無法提升。
哪怕是學生，也能假設在學校商圈賺錢是容易還是困難。
數據圍繞假設去收集、生成、組合、利用、論證和分析。這是麥肯錫式的思維方法，也可以作為學數據的方法。新人容易陷入數據的迷途：我沒有數據，有了數據也不知道幹啥，知道幹啥又不知道方法。想的太多，遠不如有方向好用。
基於假設的好處是，我首先有了一個方向，別管它對不對，至少能按照方向做分析。
HR認為招人越來越困難，則可以拿出歷史數據，以前我招人需要下載幾份簡歷，打幾個電話，發出幾個Offer最終入職。現在呢？我還可以拿各個環節的數據觀察，這不就是轉化率嘛？時間維度放得寬一點，看看去年這時候招人困難不，是不是年底都難招，這樣就了解折線圖概念。
市場專員做分析，可以拿更多的數據作參考，假設營銷成本太高，現在高到什麼地步了，什麼時候開始高的，找出時間點分析一下。效果不好，是什麼時候效果不好，那時市場環境有什麼變化嗎？我假設市場環境有了變化，這又是一個新的假設，可以繼續拎出一堆深入研究。
雖然各人分析效率和成果肯定不同，但是思路都能以這樣訓練出來。不是有了數據才有了分析，而是有了分析的方向才能收集分析數據。我的學習從來都是以解決問題為主，不是突然靈光一閃就會了。
如果把數據分析的學習旅程想成一條很長道路的話，我們不是一路開到終點，這沒人能行。而是把這條道路分割成一段段，每段上面擺一個旗幟作目標，以旗幟為前行方向，不是以幾十公里外的終點站作為目標。
好奇心
除了學習驅動力外，想成為數據分析師，還需要一顆好奇心。
好奇心就是問問題，想問題，琢磨問題，解決問題。如果你是一個天生八卦的人，那麼將它用在數據分析上絕對是天選分析師，良材美玉。
很多人喜歡追求數據分析的工具、知識、要點、竅門。但是從來很少提到好奇心。
好奇心是解決問題的核心能力，編程可以鍛煉，統計可以學習，這些最終都不是瓶頸。你學全了十八般武藝，臨敵對戰，最終需要的什麼？是求勝心。數據的求勝心就是好奇。
知識決定解決問題的下限，好奇心決定解決問題的上限。好的數據分析師一定會有好奇心，會提問，會想問題，也能去解決問題。
我們最早期推的所有活動，都沒有監控體系，整個運營也缺乏數據指導。對當時的我來說，很多運營的運作是黑箱。我不知道發什麼了什麼，怎麼發生，只有一個結果輸出。
別人若問我問什麼，我只能做出假設，有可能一二三點。是否是這樣，我也不知道。
運營活躍數上升，原因是什麼？不知道。
簡訊推送後效果怎麼樣？不知道。
新注冊用戶來源有哪些？不知道。
那時隨著公司業務線的拓展、用戶數量提升。我用Excel做關聯越來越吃力。我再一次向研發提數據需求時，CTO對我說：要不給你開個資料庫許可權，你自己查吧。
我告別了Excel，學習和了解資料庫。從幾張表的接觸擴展到幾百張表。
知道left join 和 inner join的區別。知道group by，知道數據結構，知道index。
那時期需要建立用戶數據體系，包括留存、活躍、迴流、分層等指標。我網上一邊查運營指標的應用和解釋，一邊查SQL的實現。
和研發解釋、溝通，因為了解資料庫，很多需求以更合理的要求實現。這是我第一次開始接觸、了解和建立以業務為核心的數據體系。
舉一個例子：用戶用過APP很長一段時間，我們管他叫忠誠用戶，後來突然他連續幾周不用，那麼我們會通過SQL找出這類用戶，分析他行為，電話訪談為什麼不用，嘗試喚回他。其他運營都是同理。
這時候，我才可以說我了解了活躍數，知道它為什麼上升，為什麼下降。
我們給不同用戶推簡訊，藉助SQL我能查詢到數據的好壞，但是有沒有更明確的指標？比如多少用戶因為簡訊打開APP，簡訊打開率是多少？
當時短鏈用了url scheme，可以自動跳轉到app，為了監控，我們也在短鏈中埋了參數。通過推送數據，觀察這條簡訊會有多少人打開。
這是衡量一個文案的標准，好文案一定能觸動用戶打開。我們經常拿文案作為AB測試。舉一個例子，我們會用簡訊營銷，運營是和禮品掛鉤的，當時有不少用戶線上注冊完並不下載APP，我們有那麼一條針對此類的簡訊文案：
丨我們已經為您准備好了專屬心意，XXXXX，請打開APP領取。
這條簡訊的打開率約在10%左右。但是還有優化空間，於是我不斷修改文案，後續修改為：
丨既然您已經注冊，為什麼不來領取屬於您的專屬心意呢，XXXXX，請打開APP領取（中間內容不變）。
打開率被優化到18%。因為它用了營銷心理，已經注冊，契合了沉默成本的暗示：我做都做了，為什麼不繼續，不然白注冊了。這種心理常見於旅遊景點，景點很坑爹，但絕大多數人還是會說：既然來都來了，就是一種共通的心理。
後續簡訊又採取個性化方案，最終優化到25%。比最早期的文案效果好三倍左右。如果不好奇簡訊效果，如果不收集數據監控指標，那麼優化無從談起。我們可能憑感覺寫出好文案，但你不知道具體效果，而數據能。
再來個例子，最開始我們藉助微信朋友圈進行用戶拉新，起初有多個渠道，但是我不知道哪個渠道效果好。然後我的好奇症又犯了，哪個渠道效果好？邀請轉化率還能不能優化？渠道拉新成本是多少？
依舊是推動和落地數據分析的執行，因為微信的網頁分享，會自動帶from=timeline等參數，通過參數我能過濾出微信端瀏覽和訪問的數據。後來又拜託研發針對不同渠道設置參數。通過參數統計轉化率，並且給新用戶打渠道來源標簽。
期間發現一個渠道的轉化率過低。我們大概分兩類渠道，一個是落地頁直接邀請用戶注冊，附加有禮品信息。一個是讓用戶先挑選禮品樣式，最後領取步驟中跳到注冊。通過轉化率分析，後者的流失較為嚴重。因為步驟太冗餘了，還有快遞地址要填寫，選取禮品的吸引力不足以支持用戶走完流程。
於是便更改第二個渠道流程。不同注冊渠道的用戶來源，因為有標簽，所以在後續新用戶的運營中，可以有針對性地做措施。這也是簡訊通過個性化達到25%打開率的原因之一。
好奇是為了解決問題而服務的。通過不斷的想問題，解決問題，數據分析相關的能力自然會提升。
幸運的是，好奇心能夠後天鍛煉，就是多問問題多想問題，鍛煉難度不高。
非數據
零基礎學習還會有另外一個問題，就是輕視業務的重要性。
實際上，想成為數據分析師，難點不在於Excel、SQL、統計等知識欠缺。而是業務知識的匱乏。
一個人懂業務不懂數據，另一個懂數據不懂業務，前者更有可能解決實際的問題。因為數據分析師始終是為業務而服務。
我曾向產品提出（沒請吃飯）布置APP和Web埋點，通過用戶的路徑了解用戶，也彌補網路統計的缺點。
當時通過Hadoop存儲數據，使用Hive建立離線的腳本清洗、分區、加工。用戶瀏覽產品的頁面、使用的功能、停留的時間都能構成用戶畫像的基礎。
我曾經很好奇什麼是用戶畫像，因為網路上說用戶的性別、地域、年齡、婚姻、財務、興趣、偏好是構成用戶畫像的基礎。但是我們的業務獲取不到那麼多數據。而我認為，用戶畫像是為了業務服務的，它不該有嚴格統一的標准。只要在業務上好用，就是好的用戶畫像。
就像在線視頻的用戶畫像會收集電影的演員、上映時間、產地、語言、類型。還會細分到用戶是否快進，是否拖拽。這些都是以業務為導向。甚至視頻網站的分析師們本身就得閱片無數，才能根據業務分析。不然那麼多電影類目和類型，如何細分各類指標？能通過拖拽快進去判斷用戶是否有興趣，自身也得用過類似行為才能理解。
零基礎怎麼學習行業和業務知識？如果本身和業務接觸，只是想做數據分析，難度小不少。如果像當初的我一樣，既沒有義務知識又不懂數據，也是可以的。
數據如果是假設性思維學習的話，那麼業務應該是系統性思維學習。業務知識也需要一個目的和方向，但是和數據分析不同。業務注重的是系統性，系統性不是大而全，而是上而下的結構知識。先瞄準一個方向鑽取深度，廣度會隨著深度的挖掘逐漸拓展。
比如你是一個外行，想學用戶運營體系的分析，不要先考慮啥是用戶運營，這問題太大。而是瞄準一個方向，例如活躍度，了解它的定義和含義，再想怎麼應用。線下商場的活躍度如何定義，醫院患者的活躍度如何定義，某個學校社團的活躍度如何？拿身邊例子去思考活躍度。商場的活躍，可以是走來走去的人流，可以是進行消費購物的客流，可以是大包小包的土豪。什麼因素會影響活躍？促銷還是打折，節假日還是地理。等這些問題想通了，上手用戶運營會很快。
再通過同樣的思維去想留存、去想拉新。就會知道，如果商場的人流下次繼續來消費，就是留存，有新客人來，就是拉新。這又有哪些因素互相影響？最後的知識思維一定是金字塔結構的。上層是用戶運營，中間是拉新、活躍、留存。下層是各個要點和要素。
數據分析的學習注重演繹和推理，業務的學習注重關聯和適用，學以致用就是說的這種情況。期間也會用到好奇心和假設，這兩點都是加速學習的途徑之一。
實際上說了這么多，對於零基礎想當數據分析師的同學來說，可能仍舊有一些雲山霧罩吧。這些軟技能也不會助人一步登天的，其實的七周成為數據分析師，從最開始我也說過是入門的大綱。重要的是自己是否真的想學和學好，師傅領進門，修行靠個人，其他一切都是虛的。
想起很久以前看的一句雞湯話，當你想要前行時，一切都會為你讓路。我想這比我說的一切都更有力。
所以你問我零基礎能成為數據分析師嗎？我的回答是能。
文章其實有一些趕，最後祝大家聖誕快樂。
❹ 2019數據架構選型必讀：1月資料庫產品技術解析
本期目錄
DB-Engines資料庫排行榜
新聞快訊
一、RDBMS家族
二、NoSQL家族
三、NewSQL家族
四、時間序列
五、大數據生態圈
六、國產資料庫概覽
七、雲資料庫
八、推出dbaplus Newsletter的想法
九、感謝名單
為方便閱讀、重點呈現，本期Newsletter（2019年1月）將對各個板塊的內容進行精簡。需要閱讀全文的同學可點擊文末 【閱讀原文】 或登錄https://pan..com/s/13BgipbaHeMfvm0YPtiYviA
DB-Engines資料庫排行榜
以下取自2019年1月的數據，具體信息可以參考http://db-engines.com/en/ranking/，數據僅供參考。
DB-Engines排名的數據依據5個不同的因素：
新聞快訊
1、2018年9月24日，微軟公布了SQL Server2019預覽版，SQL Server 2019將結合Spark創建統一數據平台。
2、2018年10月5日，ElasticSearch在美國紐約證券交易所上市。
3、亞馬遜放棄甲骨文資料庫軟體，導致最大倉庫之一在黃金時段宕機。受此消息影響，亞馬遜盤前股價小幅跳水，跌超2%。
4、2018年10月31日，Percona發布了Percona Server 8.0 RC版本，發布對MongoDB 4.0的支持，發布對XtraBackup測試第二個版本。
5、2018年10月31日，Gartner陸續發布了2018年的資料庫系列報告，包括《資料庫魔力象限》、《資料庫核心能力》以及《資料庫推薦報告》。
今年的總上榜資料庫產品達到了5家，分別來自：阿里雲，華為，巨杉資料庫，騰訊雲，星環 科技 。其中阿里雲和巨杉資料庫已經連續兩年入選。
6、2018年11月初，Neo4j宣布完成E輪8000萬美元融資。11月15日，Neo4j宣布企業版徹底閉源：
7、2019年1月8日，阿里巴巴以1.033億美元（9000萬歐元）的價格收購了Apache Flink商業公司DataArtisans。
8、2019年1月11日早間消息，亞馬遜宣布推出雲資料庫軟體，亞馬遜和MongoDB將會直接競爭。
RDBMS家族
Oracle 發布18.3版本
2018年7月，Oracle Database 18.3通用版開始提供下載。我們可以將Oracle Database 18c視為採用之前發布模式的Oracle Database 12c第2版的第一個補丁集。未來，客戶將不再需要等待多年才能用上最新版Oracle資料庫，而是每年都可以期待新資料庫特性和增強。Database 19c將於2019年Q1率先在Oracle cloud上發布雲版本。
Oracle Database 18c及19c部分關鍵功能：
1、性能
2、多租戶，大量功能增強及改進，大幅節省成本和提高敏捷性
3、高可用
4、數據倉庫和大數據
MySQL發布8.0.13版本
1、賬戶管理
經過配置，修改密碼時，必須帶上原密碼。在之前的版本，用戶登錄之後，就可以修改自己的密碼。這種方式存在一定安全風險。比如用戶登錄上資料庫後，中途離開一段時間，那麼非法用戶可能會修改密碼。由參數password_require_current控制。
2、配置
Innodb表必須有主鍵。在用戶沒有指定主鍵時，系統會生成一個默認的主鍵。但是在主從復制的場景下，默認的主鍵，會對叢庫應用速度帶來致命的影響。如果設置sql_require_primary_key，那麼資料庫會強制用戶在創建表、修改表時，加上主鍵。
3、欄位默認值
BLOB、TEXT、GEOMETRY和JSON欄位可以指定默認值了。
4、優化器
1）Skip Scan
非前綴索引也可以用了。
之前的版本，任何沒有帶上f1欄位的查詢，都沒法使用索引。在新的版本中，它可以忽略前面的欄位，讓這個查詢使用到索引。其實現原理就是把(f1 = 1 AND f2 > 40) 和(f1 = 2 AND f2 > 40)的查詢結果合並。
2）函數索引
之前版本只能基於某個列或者多個列加索引，但是不允許在上面做計算，如今這個限制消除了。
5、SQL語法
GROUP BY ASC和GROUP BY DESC語法已經被廢棄，要想達到類似的效果，請使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC。
6、功能變化
1）設置用戶變數，請使用SET語句
如下類型語句將要被廢棄SELECT @var, @var:=@var+1。
2）新增innodb_fsync_threshold
該變數是控制文件刷新到磁碟的速率，防止磁碟在短時間內飽和。
3）新增會話級臨時表空間
在以往的版本中，當執行SQL時，產生的臨時表都在全局表空間ibtmp1中，及時執行結束，臨時表被釋放，空間不會被回收。新版本中，會為session從臨時表空間池中分配一個臨時表空間，當連接斷開時，臨時表空間的磁碟空間被回收。
4）在線切換Group Replication的狀態
5）新增了group_replication_member_expel_timeout
之前，如果某個節點被懷疑有問題，在5秒檢測期結束之後，那麼就直接被驅逐出這個集群。即使該節點恢復正常時，也不會再被加入集群。那麼，瞬時的故障，會把某些節點驅逐出集群。
group_replication_member_expel_timeout讓管理員能更好的依據自身的場景，做出最合適的配置（建議配置時間小於一個小時）。
MariaDB 10.3版本功能展示
1、MariaDB 10.3支持update多表ORDER BY and LIMIT
1）update連表更新，limit語句
update t1 join t2 on t1.id=t2.id set t1.name='hechunyang' limit 3;
MySQL 8.0直接報錯
MariaDB 10.3更新成功
2）update連表更新，ORDER BY and LIMIT語句
update t1 join t2 on t1.id=t2.id set t1.name='HEchunyang' order by t1.id DESC limit 3;
MySQL 8.0直接報錯
MariaDB 10.3更新成功
參考：
https://jira.mariadb.org/browse/MDEV-13911
2、MariaDB10.3增補AliSQL補丁——安全執行Online DDL
Online DDL從名字上看很容易誤導新手，以為不論什麼情況，修改表結構都不會鎖表，理想很豐滿，現實很骨感，注意這個坑！
有以下兩種情況執行DDL操作會鎖表的，Waiting for table metadata lock（元數據表鎖）：
針對第二種情況，MariaDB10.3增補AliSQL補丁-DDL FAST FAIL，讓其DDL操作快速失敗。
例：
如果線上有某個慢SQL對該表進行操作，可以使用WAIT n（以秒為單位設置等待）或NOWAIT在語句中顯式設置鎖等待超時，在這種情況下，如果無法獲取鎖，語句將立即失敗。 WAIT 0相當於NOWAIT。
參考：
https://jira.mariadb.org/browse/MDEV-11388
3、MariaDB Window Functions窗口函數分組取TOP N記錄
窗口函數在MariaDB10.2版本里實現，其簡化了復雜SQL的撰寫，提高了可讀性。
參考：
https://mariadb.com/kb/en/library/window-functions-overview/
Percona Server發布8.0 GA版本
2018年12月21日，Percona發布了Percona Server 8.0 GA版本。
在支持MySQL8.0社區的基礎版上，Percona Server for MySQL 8.0版本中帶來了許多新功能：
1、安全性和合規性
2、性能和可擴展性
3、可觀察性和可用性
Percona Server for MySQL 8.0中將要被廢用功能：
Percona Server for MySQL 8.0中刪除的功能：
RocksDB發布V5.17.2版本
2018年10月24日，RocksDB發布V5.17.2版本。
RocksDB是Facebook在LevelDB基礎上用C++寫的高效內嵌式K/V存儲引擎。相比LevelDB，RocksDB提供了Column-Family，TTL，Transaction，Merge等方面的支持。目前MyRocks，TiKV等底層的存儲都是基於RocksDB來構建。
PostgreSQL發布11版本
2018年10月18日，PostgreSQL 11發布。
1、PostgreSQL 11的重大增強
2、PostgreSQL 插件動態
1）分布式插件citus發布 8.1
citus是PostgreSQL的一款sharding插件，目前國內蘇寧、鐵總、探探有較大量使用案例。
https://github.com/citusdata/citus
2）地理信息插件postgis發布2.5.1
PostGIS是專業的時空資料庫插件，在測繪、航天、氣象、地震、國土資源、地圖等時空專業領域應用廣泛。同時在互聯網行業也得到了對GIS有性能、功能深度要求的客戶青睞，比如共享出行、外賣等客戶。
http://postgis.net/
3）時序插件timescale發布1.1.1
timescale是PostgreSQL的一款時序資料庫插件，在IoT行業中有非常好的應用。github star數目前有5000多，是一個非常火爆的插件。
https://github.com/timescale/timescaledb
4）流計算插件 pipelinedb 正式插件化
Pipelinedb是PostgreSQL的一款流計算插件，使用這個創建可以對高速寫入的數據進行實時根據定義的聚合規則進行聚合（支持概率計算），實時根據定義的規則觸發事件（支持事件處理函數的自定義）。可用於IoT，監控，FEED實時計算等場景。
https://github.com/pipelinedb/pipelinedb
3、PostgreSQL衍生開源產品動態
1）agensgraph發布 2.0.0版本
agensgraph是兼容PostgreSQL、opencypher的專業圖資料庫，適合圖式關系的管理。
https://github.com/bitnine-oss/agensgraph
2）gpdb發布5.15
gpdb是兼容PostgreSQL的mpp資料庫，適合OLAP場景。近兩年，gpdb一直在追趕PostgreSQL的社區版本，預計很快會追上10的PostgreSQL，在TP方面的性能也會得到顯著提升。
https://github.com/greenplum-db/gpdb
3）antdb發布3.2
antdb是以Postgres-XC為基礎開發的一款PostgreSQL sharding資料庫，亞信主導開發，開源，目前主要服務於亞信自有客戶。
https://github.com/ADBSQL/AntDB
4）遷移工具MTK發布52版本
MTK是EDB提供的可以將Oracle、PostgreSQL、MySQL、MSSQL、Sybase資料庫遷移到PostgreSQL, PPAS的產品，遷移速度可以達到100萬行/s以上。
https://github.com/digoal/blog/blob/master/201812/20181226_01.md
DB2發布 11.1.4.4版本
DB2最新發布Mod Pack 4 and Fix Pack 4，包含以下幾方面的改動及增強：
1、性能
2、高可用
3、管理視圖
4、應用開發方面
5、聯邦功能
6、pureScale
NoSQL家族
Redis發布5.0.3版本
MongoDB升級更新MongoDB Mobile和MongoDB Stitch
2018年11月21日，MongoDB升級更新MongoDB Mobile和MongoDB Stitch，助力開發人員提升工作效率。
MongoDB 公司日前發布了多項新產品功能，旨在更好地幫助開發人員在世界各地管理數據。通過利用存儲在移動設備和後台資料庫的數據之間的實時、自動的同步特性，MongoDB Mobile通用版本助力開發人員構建更快捷、反應更迅速的應用程序。此前，這只能通過在移動應用內部安裝一個可供選擇或限定功能的資料庫來實現。
MongoDB Mobile在為客戶提供隨處運行的自由度方面更進了一步。用戶在iOS和安卓終端設備上可擁有MongoDB所有功能，將網路邊界擴展到其物聯網資產范疇。應用系統還可以使用MongoDB Stitch的軟體開發包訪問移動客戶端或後台數據，幫助開發人員通過他們希望的任意方式查詢移動終端數據和物聯網數據，包括本地讀寫、本地JSON存儲、索引和聚合。通過Stitch移動同步功能(現可提供beta版)，用戶可以自動對保存在本地的數據以及後台資料庫的數據進行同步。
本期新秀：Cassandra發布3.11.3版本
2018年8月11日，Cassandra發布正式版3.11.3。
Apache Cassandra是一款開源分布式NoSQL資料庫系統，使用了基於Google BigTable的數據模型，與面向行(row)的傳統關系型資料庫或鍵值存儲key-value資料庫不同，Cassandra使用的是寬列存儲模型(Wide Column Stores)。與BigTable和其模仿者HBase不同，數據並不存儲在分布式文件系統如GFS或HDFS中，而是直接存於本地。
Cassandra的系統架構與Amazon DynamoDB類似，是基於一致性哈希的完全P2P架構，每行數據通過哈希來決定應該存在哪個或哪些節點中。集群沒有master的概念，所有節點都是同樣的角色，徹底避免了整個系統的單點問題導致的不穩定性，集群間的狀態同步通過Gossip協議來進行P2P的通信。
3.11.3版本的一些bug fix和改進：
NewSQL家族
TiDB 發布2.1.2版本
2018 年 12 月 22 日，TiDB 發布 2.1.2 版，TiDB-Ansible 相應發布 2.1.2 版本。該版本在 2.1.1 版的基礎上，對系統兼容性、穩定性做出了改進。
TiDB 是一款定位於在線事務處理/在線分析處理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型資料庫產品。除了底層的 RocksDB 存儲引擎之外，分布式SQL層、分布式KV存儲引擎（TiKV）完全自主設計和研發。
TiDB 完全開源，兼容MySQL協議和語法，可以簡單理解為一個可以無限水平擴展的MySQL，並且提供分布式事務、跨節點 JOIN、吞吐和存儲容量水平擴展、故障自恢復、高可用等優異的特性；對業務沒有任何侵入性，簡化開發，利於維護和平滑遷移。
TiDB：
PD：
TiKV：
Tools：
1）TiDB-Lightning
2）TiDB-Binlog
EsgynDB發布R2.5版本
2018年12月22日，EsgynDB R2.5版本正式發布。
作為企業級產品，EsgynDB 2.5向前邁進了一大步，它擁有以下功能和改進：
CockroachDB發布2.1版本
2018年10月30日，CockroachDB正式發布2.1版本，其新增特性如下：
新增企業級特性：
新增SQL特性：
新增內核特性：
Admin UI增強：
時間序列
本期新秀：TimescaleDB發布1.0版本
10月底，TimescaleDB 1.0宣布正式推出，官方表示該版本已可用於生產環境，支持完整SQL和擴展。
TimescaleDB是基於PostgreSQL資料庫開發的一款時序資料庫，以插件化的形式打包提供，隨著PostgreSQL的版本升級而升級，不會因為另立分支帶來麻煩。
TimescaleDB架構：
數據自動按時間和空間分片(chunk)
更新亮點：
https://github.com/timescale/timescaledb/releases/tag/1.0.0
大數據生態圈
Hadoop發布2.9.2版本
2018年11月中旬，Hadoop在2.9分支上發布了新的2.9.2版本，該版本進行了204個大大小小的變更，主要變更如下：
Greenplum 發布5.15版本
Greenplum最新的5.15版本中發布了流式數據載入工具。
該版本中的Greenplum Streem Server組件已經集成了Kafka流式載入功能，並通過了Confluent官方的集成認證，其支持的主要功能如下：
國產資料庫概覽
K-DB發布資料庫一體機版
2018年11月7日，K-DB發布了資料庫一體機版。該版本更新情況如下：
OceanBase遷移服務發布1.0版本
1月4日，OceanBase 正式發布OMS遷移服務1.0版本。
以下內容包含 OceanBase 遷移服務的重要特性和功能：
SequoiaDB發布3.0.1新版本
1、架構
1）完整計算存儲分離架構，兼容MySQL協議、語法
計算存儲分離體系以松耦合的方式將計算與存儲層分別部署，通過標准介面或插件對各個模塊和組件進行無縫替換，在計算層與存儲層均可實現自由的彈性伸縮。
SequoiaDB巨杉資料庫「計算-存儲分離」架構詳細示意
用戶可以根據自身業務特徵選擇面向交易的SQL解析器（例如MySQL或PGSQL）或面向統計分析的執行引擎（例如SparkSQL）。眾所周知，使用不同的SQL優化與執行方式，資料庫的訪問性能可能會存在上千上萬倍的差距。計算存儲分離的核心思想便是在數據存儲層面進行一體化存儲，在計算層面則利用每種執行引擎的特點針對不同業務場景進行選擇和優化，用戶可以在存儲層進行邏輯與物理的隔離，將面向高頻交易的前端業務與面向高吞吐量的統計分析使用不同的硬體進行存儲，確保在多類型數據訪問時互不幹擾，以真正達到生產環境可用的多租戶與HTAP能力。
2、其他更新信息
1）介面變更：
2）主要特性：
雲資料庫
本期新秀：騰訊發布資料庫CynosDB，開啟公測
1、News
1）騰訊雲資料庫MySQL2018年重大更新：
2）騰訊雲資料庫MongoDB2018年重大更新：
3）騰訊雲資料庫Redis/CKV+2018年重大更新：
4）騰訊雲資料庫CTSDB2018年重大更新：
2、Redis 4.0集群版商業化上線
2018年10月，騰訊雲資料庫Redis 4.0集群版完成邀測、公測、商業化三個迭代，在廣州、上海、北京正式全量商業化上線。
產品特性：
使用場景：
官網文檔：
https://cloud.tencent.com/document/proct/239/18336
3、騰訊自研資料庫CynosDB發布，開啟公測
2018年11月22日，騰訊雲召開新一代自研資料庫CynosDB發布會，業界第一款全面兼容市面上兩大最主流的開源資料庫MySQL和PostgreSQL的高性能企業級分布式雲資料庫。
本期新秀：京東雲DRDS發布1.0版本
12月24日，京東雲分布式關系型資料庫DRDS正式發布1.0版本。
DRDS是京東雲精心自研的資料庫中間件產品，獲得了2018年 」可信雲技術創新獎」。DRDS可實現海量數據下的自動分庫分表，具有高性能，分布式，彈性升級，兼容MySQL等優點，適用於高並發、大規模數據的在線交易， 歷史 數據查詢，自動數據分片等業務場景，歷經多次618，雙十一的考驗，已經在京東集團內大規模使用。
京東雲DRDS產品有以下主要特性
1）自動分庫分表
通過簡單的定義即可自動實現分庫分表，將數據實際存放在多個MySQL實例的資料庫中，但呈現給應用程序的依舊是一張表，對業務透明，應用程序幾乎無需改動，實現了對資料庫存儲和處理能力的水平擴展。
2）分布式架構
基於分布式架構的集群方案，多個對等節點同時對外提供服務，不但可有效規避服務的單點故障，而且更加容易擴展。
3）超強性能
具有極高的處理能力，雙節點即可支持數萬QPS，滿足用戶超大規模處理能力的需求。
4）兼容MySQL
兼容絕大部分MySQL語法，包括MySQL語法、數據類型、索引、常用函數、排序、關聯等DDL，DML語句，使用成本低。
參考鏈接：
https://www.jdcloud.com/cn/procts/drds
RadonDB發布1.0.3版本
2018年12月26日，MyNewSQL領域的RadonDB雲資料庫發布1.0.3版本。
推出dbaplus Newsletter的想法
dbaplus Newsletter旨在向廣大技術愛好者提供資料庫行業的最新技術發展趨勢，為社區的技術發展提供一個統一的發聲平台。為此，我們策劃了RDBMS、NoSQL、NewSQL、時間序列、大數據生態圈、國產資料庫、雲資料庫等幾個版塊。
我們不以商業宣傳為目的，不接受任何商業廣告宣傳，嚴格審查信息源的可信度和准確性，力爭為大家提供一個純凈的技術學習環境，歡迎大家監督指正。
至於Newsletter發布的周期，目前計劃是每三個月左右會做一次跟進， 下期計劃時間是2019年4月14日~4月25日， 如果有相關的信息提供請發送至郵箱：[email protected]
感謝名單
最後要感謝那些提供寶貴信息和建議的專家朋友，排名不分先後。
往期回顧：
↓↓別忘了點這里下載 2019年1月 完整版Newsletter 哦~
❺ 基於spark地震數據分析的目的
從速度的角度看，Spark從流行的MapRece模型繼承而來，可以更有效地支持多種類型的計算，如互動式查詢和流處理。速度在大數據集的處理中非常重要，它可以決定用戶可以互動式地處理數據，還是等幾分鍾甚至幾小時。Spark為速度提供的一個重要特性是其可以在內存中運行計算，即使對基於磁碟的復雜應用，Spark依然比MapRece更有效。
從通用性來物老說，Spark可以處理之前需要多個獨立的分布式系統來處理的任務，這些任務包括批處理應用、互動式演算法、互動式查詢和數據流。通過用同一個引擎支持這些任務，Spark使得合並不同的處理類型變得簡單，而合並操作在生產數據分析中頻繁使用。而且，Spark降低了維護不同工具的管理負擔。
Spark被設計的高度易訪問，用Python、Java、Scala和SQL提供簡單的API，而且提供豐富的內建庫。Spark也與其他大數據工具進行了集成。特別地，Spark可以運行在Hadoop的集群上，可以訪問任何Hadoop的數據源，包括Cassandra。
Spark 核心組件
Spark核心組件包含Spark的基本功能，有任務調度組件、內存管理組件、容錯恢復組件、與存儲系統交互的組件等。Spark核心組件提供了定義彈性分布式數據集(resilient distributed datasets，RDDs)的API，這組API是Spark主要的編程抽象。RDDs表示分布在多個不同機器節點上，可以被並行處理的數據集合。Spark核心組件提供許多API來創建和操作這些集合。
Spark SQLSpark SQL是Spark用來處理結構化數據的包。它使得可以像Hive查詢語言(Hive Query Language, HQL)一樣通過SQL語句來查詢數據，支持多種數據源，包括Hive表、Parquet和JSON。除了為Spark提供一個SQL介面外，Spark SQL允許開發人員將SQL查詢和由RDDs通過Python、Java和Scala支持的數據編程操作混合進一個單一的應用中，進而將SQL與復雜的分析結合。與計算密集型環境緊密集成使得Spark SQL不同於任何其他開源的數據倉庫工具。Spark SQL在Spark 1.0版本中引入Spark。
Shark是一個較老的由加利福尼亞大學和伯克利大學開發的Spark上的SQL項目，通過修裂芹改Hive而運行在Spark上。現在已經被Spark SQL取代，以提供與Spark引擎和API更好的集成。
Spark流(Spark Streaming)Spark流作為Spark的一個組件，可以處理實時流數據。流數據的例子有生產環境的Web伺服器生成的日誌文件，用戶向一個Web服務請求包含狀態更新的消息。Spark流提供一個和Spark核心RDD API非常匹配的操作數據流的API，使得編程人員可以更容易地了解項目，並且可以在操作內存數據、磁碟數據、實時數據的應用之間快速切換。Spark流被設計為和Spark核心組件提供相同級別的容錯性，吞吐量和可伸縮性。
MLlibSpark包含一個叫做MLlib的關於機器學習的庫。MLlib提供多種類型的機器學習演算法，包括分類、回歸、聚類和協同過濾，並支持模型評估和數據導入功能。MLlib也提供一個低層的機器學習原語，包括一個通用的梯度下降優化演算法。所有這些方法都可以應用到一個集群上。
GraphXGraphX是一個操作圖(如社交網路的好友圖)和執行基於圖的並行計算的庫。與Spark流和Spark SQL類似，GraphX擴展了Spark RDD API，允許我們用和每個罩源升節點和邊綁定的任意屬性來創建一個有向圖。GraphX也提供了各種各樣的操作圖的操作符，以及關於通用圖演算法的一個庫。
集群管理器Cluster Managers在底層，Spark可以有效地從一個計算節點擴展到成百上千個節點。為了在最大化靈活性的同時達到這個目標，Spark可以運行在多個集群管理器上，包括Hadoop YARN，Apache Mesos和一個包含在Spark中的叫做獨立調度器的簡易的集群管理器。如果你在一個空的機器群上安裝Spark，獨立調度器提供一個簡單的方式;如果你已經有一個Hadoop YARN或Mesos集群，Spark支持你的應用允許在這些集群管理器上。第七章給出了不同的選擇，以及如何選擇正確的集群管理器。
誰使用Spark?用Spark做什麼?
由於Spark是一個面向集群計算的通用框架，可用於許多不同的應用。使用者主要有兩種：數據科學家和數據工程師。我們仔細地分析一下這兩種人和他們使用Spark的方式。明顯地，典型的使用案例是不同的，但我們可以將他們粗略地分為兩類，數據科學和數據應用。
數據科學的任務數據科學，近幾年出現的一門學科，專注於分析數據。盡管沒有一個標準的定義，我們認為一個數據科學家的主要工作是分析和建模數據。數據科學家可能會SQL，統計學，預測模型(機器學習)，用Python、MATLAB或R編程。數據科學家能將數據格式化，用於進一步的分析。
數據科學家為了回答一個問題或進行深入研究，會使用相關的技術分析數據。通常，他們的工作包含特殊的分析，所以他們使用互動式shell，以使得他們能在最短的時間內看到查詢結果和代碼片段。Spark的速度和簡單的API介面很好地符合這個目標，它的內建庫意味著很多演算法可以隨時使用。
Spark通過若干組件支持不同的數據科學任務。Spark shell使得用Python或Scala進行互動式數據分析變得簡單。Spark SQL也有一個獨立的SQL shell，已經為大家精心准備了大數據的系統學習資料，從Linux-Hadoop-spark-......，需要的小夥伴可以點擊它可以用SQL進行數據分析，也可以在Spark程序中或Spark shell中使用Spark SQL。MLlib庫支持機器學習和數據分析。而且，支持調用外部的MATLAB或R語言編寫的程序。Spark使得數據科學家可以用R或Pandas等工具處理包含大量數據的問題。
❻ 以道教育大數據課程都講什麼
1、web開發基礎
2、javase課程
3、主流的框架
4、關系型資料庫/MySQL/NoSQL
5、操作系統/Linux、雲架構仿備橡
6、Hadoop生態滾肢系統
7、Spark生態系統
8、Storm生態系備旁統
9、項目實操階段
❼ 大數據培訓課程安排有哪些，深圳大數據培訓哪家好
首先我們要了解Java語言和Linux操作系統，這兩個是學習大數據的基礎，學習的順序不分前後。
大數據
Java ：只要了解一些基礎即可，做大數據不需要很深的Java 技術，學java SE 就相當於有學習大數據基礎。
Linux：因為大數據相關軟體都是在Linux上運行的，所以Linux要學習的扎實一些，學好Linux對你快速掌握大數據相關技術會有很大的幫助，能讓你更好的理解hadoop、hive、hbase、spark等大數據軟體的運行環境和網路環境配置，能少踩很多坑，學會shell就能看懂腳本這樣能更容易理解和配置大數據集群。還能讓你對以後新出的大數據技術學習起來更快。
Hadoop：這是現在流行的大數據處理平台幾乎已經成為大數據的代名詞，所以這個是必學的。Hadoop裡麵包括幾個組件HDFS、MapRece和YARN，HDFS是存儲數據的地方就像我們電腦的硬碟一樣文件都存儲在這個上面，MapRece是對數據進行處理計算的，它有個特點就是不管多大的數據只要給它時間它就能把數據跑完，但是時間可能不是很快所以它叫數據的批處理。
Zookeeper：這是個萬金油，安裝Hadoop的HA的時候就會用到它，以後的Hbase也會用到它。它一般用來存放一些相互協作的信息，這些信息比較小一般不會超過1M，都是使用它的軟體對它有依賴，對於我們個人來講只需要把它安裝正確，讓它正常的run起來就可以了。
Mysql：我們學習完大數據的處理了，接下來學習學習小數據的處理工具mysql資料庫，因為一會裝hive的時候要用到，mysql需要掌握到什麼層度那?你能在Linux上把它安裝好，運行起來，會配置簡單的許可權，修改root的密碼，創建資料庫。這里主要的是學習SQL的語法，因為hive的語法和這個非常相似。
Sqoop：這個是用於把Mysql里的數據導入到Hadoop里的。當然你也可以不用這個，直接把Mysql數據表導出成文件再放到HDFS上也是一樣的，當然生產環境中使用要注意Mysql的壓力。
Hive：這個東西對於會SQL語法的來說就是神器，它能讓你處理大數據變的很簡單，不會再費勁的編寫MapRece程序。有的人說Pig那?它和Pig差不多掌握一個就可以了。
Oozie：既然學會Hive了，我相信你一定需要這個東西，它可以幫你管理你的Hive或者MapRece、Spark腳本，還能檢查你的程序是否執行正確，出錯了給你發報警並能幫你重試程序，最重要的是還能幫你配置任務的依賴關系。我相信你一定會喜歡上它的，不然你看著那一大堆腳本，和密密麻麻的crond是不是有種想屎的感覺。
Hbase：這是Hadoop生態體系中的NOSQL資料庫，他的數據是按照key和value的形式存儲的並且key是唯一的，所以它能用來做數據的排重，它與MYSQL相比能存儲的數據量大很多。所以他常被用於大數據處理完成之後的存儲目的地。
Kafka：這是個比較好用的隊列工具，隊列是干嗎的?排隊買票你知道不?數據多了同樣也需要排隊處理，這樣與你協作的其它同學不會叫起來，你干嗎給我這么多的數據(比如好幾百G的文件)我怎麼處理得過來，你別怪他因為他不是搞大數據的，你可以跟他講我把數據放在隊列里你使用的時候一個個拿，這樣他就不在抱怨了馬上灰流流的去優化他的程序去了，因為處理不過來就是他的事情。而不是你給的問題。當然我們也可以利用這個工具來做線上實時數據的入庫或入HDFS，這時你可以與一個叫Flume的工具配合使用，它是專門用來提供對數據進行簡單處理，並寫到各種數據接受方(比如Kafka)的。
Spark：它是用來彌補基於MapRece處理數據速度上的缺點，它的特點是把數據裝載到內存中計算而不是去讀慢的要死進化還特別慢的硬碟。特別適合做迭代運算，所以演算法流們特別稀飯它。它是用scala編寫的。Java語言或者Scala都可以操作它，因為它們都是用JVM的。
❽ Spark RDD，DataFrame和DataSet的區別
RDD、DataFrame和DataSet是容易產生混淆的概念，必須對其相互之間對比，才可以知道其中異同。
RDD和DataFrame
RDD-DataFrame
上圖直觀地體現了DataFrame和RDD的區別。左側的RDD[Person]雖然以Person為類型參數，但Spark框架本身不了解
Person類的內部結構。而右側的DataFrame卻提供了詳細的結構信息，使得Spark
SQL可以清楚地知道該數據集中包含哪些列，每列的名稱和類型各是什麼。DataFrame多了數據的結構信息，即schema。RDD是分布式的
Java對象的集合。DataFrame是分布式的Row對象的集合。DataFrame除了提供了比RDD更豐富的運算元以外，更重要的特點是提升執行效
率、減少數據讀取以及執行計劃的優化，比如filter下推、裁剪等。
提升執行效率
RDD
API是函數式的，強調不變性，在大部分場景下傾向於創建新對象而不是修改老對象。這一特點雖然帶來了干凈整潔的API，卻也使得Spark應用程序在運
行期傾向於創建大量臨時對象，對GC造成壓力。在現有RDD
API的基礎之上，我們固然可以利用mapPartitions方法來重載RDD單個分片內的數據創建方式，用復用可變對象的方式來減小對象分配和GC的
開銷，但這犧牲了代碼的可讀性，而且要求開發者對Spark運行時機制有一定的了解，門檻較高。另一方面，Spark
SQL在框架內部已經在各種可能的情況下盡量重用對象，這樣做雖然在內部會打破了不變性，但在將數據返回給用戶時，還會重新轉為不可變數據。利用
DataFrame API進行開發，可以免費地享受到這些優化效果。
減少數據讀取
分析大數據，最快的方法就是 ——忽略它。這里的「忽略」並不是熟視無睹，而是根據查詢條件進行恰當的剪枝。
上文討論分區表時提到的分區剪 枝便是其中一種——當查詢的過濾條件中涉及到分區列時，我們可以根據查詢條件剪掉肯定不包含目標數據的分區目錄，從而減少IO。
對於一些「智能」數據格 式，Spark
SQL還可以根據數據文件中附帶的統計信息來進行剪枝。簡單來說，在這類數據格式中，數據是分段保存的，每段數據都帶有最大值、最小值、null值數量等
一些基本的統計信息。當統計信息表名某一數據段肯定不包括符合查詢條件的目標數據時，該數據段就可以直接跳過(例如某整數列a某段的最大值為100，而查
詢條件要求a > 200)。
此外，Spark SQL也可以充分利用RCFile、ORC、Parquet等列式存儲格式的優勢，僅掃描查詢真正涉及的列，忽略其餘列的數據。
執行優化
人口數據分析示例
為了說明查詢優化，我們來看上圖展示的人口數據分析的示例。圖中構造了兩個DataFrame，將它們join之後又做了一次filter操作。如
果原封不動地執行這個執行計劃，最終的執行效率是不高的。因為join是一個代價較大的操作，也可能會產生一個較大的數據集。如果我們能將filter
下推到 join下方，先對DataFrame進行過濾，再join過濾後的較小的結果集，便可以有效縮短執行時間。而Spark
SQL的查詢優化器正是這樣做的。簡而言之，邏輯查詢計劃優化就是一個利用基於關系代數的等價變換，將高成本的操作替換為低成本操作的過程。
得到的優化執行計劃在轉換成物 理執行計劃的過程中，還可以根據具體的數據源的特性將過濾條件下推至數據源內。最右側的物理執行計劃中Filter之所以消失不見，就是因為溶入了用於執行最終的讀取操作的表掃描節點內。
對於普通開發者而言，查詢優化 器的意義在於，即便是經驗並不豐富的程序員寫出的次優的查詢，也可以被盡量轉換為高效的形式予以執行。
RDD和DataSet
DataSet以Catalyst邏輯執行計劃表示，並且數據以編碼的二進制形式被存儲，不需要反序列化就可以執行sorting、shuffle等操作。
DataSet創立需要一個顯式的Encoder，把對象序列化為二進制，可以把對象的scheme映射為SparkSQl類型，然而RDD依賴於運行時反射機制。
通過上面兩點，DataSet的性能比RDD的要好很多。
DataFrame和DataSet
Dataset可以認為是DataFrame的一個特例，主要區別是Dataset每一個record存儲的是一個強類型值而不是一個Row。因此具有如下三個特點：
DataSet可以在編譯時檢查類型
並且是面向對象的編程介面。用wordcount舉例：
//DataFrame
// Load a text file and interpret each line as a java.lang.String
val ds = sqlContext.read.text("/home/spark/1.6/lines").as[String]
val result = ds
.flatMap(_.split(" ")) // Split on whitespace
.filter(_ != "") // Filter empty words
.toDF() // Convert to DataFrame to perform aggregation / sorting
.groupBy($"value") // Count number of occurences of each word
.agg(count("*") as "numOccurances")
.orderBy($"numOccurances" desc) // Show most common words first
後面版本DataFrame會繼承DataSet，DataFrame是面向Spark SQL的介面。
//DataSet,完全使用scala編程，不要切換到DataFrame
val wordCount =
ds.flatMap(_.split(" "))
.filter(_ != "")
.groupBy(_.toLowerCase()) // Instead of grouping on a column expression (i.e. $"value") we pass a lambda function
.count()
DataFrame和DataSet可以相互轉化， df.as[ElementType] 這樣可以把DataFrame轉化為DataSet， ds.toDF() 這樣可以把DataSet轉化為DataFrame。
❾ 技術選型 - OLAP大數據技術哪家強
Lambda架構的核心理念是「流批一體化」，因為隨著機器性能和數據框架的不斷完善，用戶其實不關心底層是如何運行的，批處理也好，流式處理也罷，能按照統一的模型返回結果就可以了，這就是Lambda架構誕生的原因。現在很多應用，例如Spark和Flink，都支持這種結構，也就是數據進入平台後，可以選擇批處理運行，也可以選擇流式處理運行，但不管怎樣，一致性都是相同的。
Kylin
Kylin的主要特點是預計算，提前計算好各個cube，這樣的優點是查詢快速，秒級延遲；缺點也非常明顯，靈活性不足，無法做一些 探索 式的，關聯性的數據分析。
適合的場景也是比較固定的，場景清晰的地方。
ClickHouse
Clickhouse由俄羅斯yandex公司開發。專為在線數據分析而設計。
Clickhouse最大的特點首先是快 ，為了快採用了列式儲存，列式儲存更好的支持壓縮，壓縮後的數據傳輸量變小，所以更快；同時支持分片，支持分布式執行，支持SQL。
ClickHouse很輕量級，支持數據壓縮和最終數據一致性，其數據量級在PB級別。
另外Clickhouse不是為關聯分析而生，所以多表關聯支持的不太好。
同樣Clickhouse不能修改或者刪除數據，僅能用於批量刪除或修改。沒有完整的事務支持，不支持二級索引等等，缺點也非常明顯。
與Kylin相比ClickHouse更加的靈活，sql支持的更好，但是相比Kylin，ClickHouse不支持大並發，也就是不能很多訪問同時在線。
總之ClickHouse用於在線數據分析，支持功能簡單。CPU 利用率高，速度極快。最好的場景用於行為統計分析。
Hive
Hive這個工具，大家一定很熟悉，大數據倉庫的首選工具。可以將結構化的數據文件映射為一張資料庫表，並提供完整的sql查詢功能。
主要功能是可以將sql語句轉換為相對應的MapRece任務進行運行，這樣可能處理海量的數據批量，
Hive與HDFS結合緊密，在大數據開始初期，提供一種直接使用sql就能訪問HDFS的方案，擺脫了寫MapRece任務的方式，極大的降低了大數據的門檻。
當然Hive的缺點非常明顯，定義的是分鍾級別的查詢延遲，估計都是在比較理想的情況。 但是作為數據倉庫的每日批量工具，的確是一個穩定合格的產品。
Presto
Presto極大的改進了Hive的查詢速度，而且Presto 本身並不存儲數據，但是可以接入多種數據源，並且支持跨數據源的級聯查詢，支持包括復雜查詢、聚合、連接等等。
Presto沒有使用MapRece，它是通過一個定製的查詢和執行引擎來完成的。它的所有的查詢處理是在內存中，這也是它的性能很高的一個主要原因。
Presto由於是基於內存的，缺點可能是多張大表關聯操作時易引起內存溢出錯誤。
另外Presto不支持OLTP的場景，所以不要把Presto當做資料庫來使用。
Presto相比ClickHouse優點主要是多表join效果好。相比ClickHouse的支持功能簡單，場景支持單一，Presto支持復雜的查詢，應用范圍更廣。
Impala
Impala是Cloudera 公司推出，提供對 HDFS、Hbase 數據的高性能、低延遲的互動式 SQL 查詢功能。
Impala 使用 Hive的元數據, 完全在內存中計算。是CDH 平台首選的 PB 級大數據實時查詢分析引擎。
Impala 的缺點也很明顯，首先嚴重依賴Hive，而且穩定性也稍差，元數據需要單獨的mysql/pgsql來存儲，對數據源的支持比較少，很多nosql是不支持的。但是，估計是cloudera的國內市場推廣做的不錯，Impala在國內的市場不錯。
SparkSQL
SparkSQL的前身是Shark，它將 SQL 查詢與 Spark 程序無縫集成，可以將結構化數據作為 Spark 的 RDD 進行查詢。
SparkSQL後續不再受限於Hive，只是兼容Hive。
SparkSQL提供了sql訪問和API訪問的介面。
支持訪問各式各樣的數據源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像國內使用的很少，根據定義，Drill是一個低延遲的分布式海量數據互動式查詢引擎，支持多種數據源，包括hadoop，NoSQL存儲等等。
除了支持多種的數據源，Drill跟BI工具集成比較好。
Druid
Druid是專為海量數據集上的做高性能 OLAP而設計的數據存儲和分析系統。
Druid 的架構是 Lambda 架構，分成實時層和批處理層。
Druid的核心設計結合了數據倉庫，時間序列資料庫和搜索系統的思想，以創建一個統一的系統，用於針對各種用例的實時分析。Druid將這三個系統中每個系統的關鍵特徵合並到其接收層，存儲格式，查詢層和核心體系結構中。
目前 Druid 的去重都是非精確的，Druid 適合處理星型模型的數據，不支持關聯操作。也不支持數據的更新。
Druid最大的優點還是支持實時與查詢功能，解約了很多開發工作。
Ku
ku是一套完全獨立的分布式存儲引擎，很多設計概念上借鑒了HBase，但是又跟HBase不同，不需要HDFS，通過raft做數據復制；分片策略支持keyrange和hash等多種。
數據格式在parquet基礎上做了些修改，支持二級索引，更像一個列式存儲，而不是HBase schema-free的kv方式。
ku也是cloudera主導的項目，跟Impala結合比較好，通過impala可以支持update操作。
ku相對於原有parquet和ORC格式主要還是做增量更新的。
Hbase
Hbase使用的很廣,更多的是作為一個KV資料庫來使用，查詢的速度很快。
Hawq
Hawq是一個Hadoop原生大規模並行SQL分析引擎，Hawq採用 MPP 架構，改進了針對 Hadoop 的基於成本的查詢優化器。
除了能高效處理本身的內部數據，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部數據源。HAWQ全面兼容 SQL 標准，還可用 SQL 完成簡單的數據挖掘和機器學習。無論是功能特性，還是性能表現，HAWQ 都比較適用於構建 Hadoop 分析型數據倉庫應用。