隨着深圳實習在8月底告一段落，我搭乘9月1號的飛機回到上海，雖然外面的秋招氛圍如火如荼，但是中科院這個圈子裏總是風平浪靜，這是我喜歡他也討厭他的一點。
9月17號晚上收到部門沒有HC的通知，一瞬間竟然有點恍惚感。壓力值瞬間從觀望狀態調整至爆表。17號的那天晚上，睡了2小時，其餘的時間一口氣投了十幾家公司，同時也包括我心儀的webank，這裏真的感謝我的校友兼HR小姐姐HOPE。倘若我們還能在webank見面，我一定給你帶去武漢最好吃的周黑鴨。
9月18號晚，耳邊響着的是周杰倫的《開不了口》。深圳，真是一個我愛了卻充滿拒絕的城市，是心儀卻沒有迴應的女孩，是想去而沒有HC的公司。今天一口氣做完了webank和滴滴的筆試，那些SQL語句總是把我帶回南山區沙河西路的玻璃櫥窗前。那裏有我最心愛的姑娘啊~而我只是匆匆地在微信上給她做了最後的道別，或許至今我的存在對她都是打擾吧，真是抱歉。
言歸正傳，這次的失利可能在於我最後的總結匯報有所疏忽。從6月20號至8月31日，我所做的工作以及技術棧整理如下：
1、kylin+Mondrian+saiku/kylin+tableau 性能對比
Kylin介紹：
Kylin是爲減少在Hadoop/Spark上百億規模數據查詢延遲而設計，主要用於OLAP平臺，爲Hadoop提供標準SQL支持大部分查詢功能並通過事先預計算的方式生成CUBE。
Mondrian介紹：
是一個OLAP分析的引擎，主要工作是根據事先配置好的schema，將輸入的多維分析語句MDX(Multidimensional Expressions )翻譯成目標數據庫／數據引擎的執行語言（比如SQL）。
Saiku介紹：
提供了一個多維分析的用戶操作界面，可以通過簡單拖拉拽的方式迅速生成報表。Saiku的主要工作是根據事先配置好的schema，將用戶的操作轉化成MDX語句（多維分析語句）提供給Mondrian引擎執行。
由於saiku對新版的Java10還存在不兼容現象，經過對比發現saiku的組合還是相較於收費50美金一年的tableau慢，原因是開源的Mondrian並未對需要的SQL語句進行優化，且Schema的書寫尤爲麻煩，二度開發的成本較高，由於業務部門使用tableau並不多，遂決定繼續採用kylin+tableau的方式，但是kylin預先生成好的CUBE由於受到網絡帶寬傳輸的影響，需要先配置tableau推送到本地方纔能達到毫秒級的實時查詢速度。
2、OLAP和OLTP
OLTP是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持複雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。
OLTP系統最容易出現瓶頸的地方就是CPU與磁盤子系統，強調高可用性，用於傳統數據庫。OLAP主要考驗的磁盤吞吐量，用於數據倉庫。
3、關於異常值檢測
在實際我們處理業務的過程中，應該和業務多多商量，一起來定義什麼是異常值。而在實際工作中異常值往往是一個十分模糊的概念，業務也無法確定究竟什麼是異常值。這個時候往往採用一些平均值、衆數等統計數據進行規約。實際上，下一時刻的數據只和上幾個時刻的數據相關，可以採用相關模型進行最近一期的時域分析。
4、業務部門報表的開發
在Webank做數倉，是一個和業務結合的十分緊密的崗位，隸屬於消費者金融-數據管理科室。其實在哪裏做數倉，都應該是和業務結合緊密的，從數據的事實表、維度表設計、再到日常MIS報表（風險日報）的開發、最後到標準指標庫的建設。這一系列的工作都由數據倉庫崗位承擔。在實際操作中，做數據倉庫並不關心數據的稀疏以及冗餘。至少在webank開發的指標庫中就由於各個指標的維度數目不同而需要強行放在一張表裏便於操作時直接Group by而導致稀疏。所以數倉並不像傳統數據庫那樣關注數據庫的範式設計，爲業務而轉，而非爲實時性的增刪改查而轉，這是數倉的崗位職責。事實上也並不存在刪以及改，由於數據量十分龐大，刪除數據往往是打一個標籤而不會真的刪除，真的刪除會導致內存不連續從而造成大量的系統開銷。
數據倉庫的物理模型分爲星型和雪花型兩種。所謂星型，就是將模型中只有一個主題，其他的表中存儲的都是主題的一些特徵。比如貨物銷量的主題倉庫中，每次出售記錄是事實表，而時間，售貨員，商品是維度，都和事實表有聯繫，組織起來就是星型。而如果更細化來看，商品是有種類，產地，價格等特徵的，從這個角度來看，有兩個主題，一個是商品出售，一個是商品本身。組織起來就是雪花型。實際項目中，由於操作型系統業務的複雜性導致本身產生了大量的數據，所以，組織起來也以雪花型居多。
常見的數倉表有如下幾類：
全量表：每天的所有的最新狀態的數據，
增量表：每天的新增數據，增量數據是上次導出之後的新數據。
TIPS：增量表和全量表的區別可以用select count(*) from tablename group by partition_name 來做區別如果是一張全量表的話，那麼可以看到數據量始終是在遞增的，如果只是增量表的話，統計的結果會有起伏。
拉鍊表：維護歷史狀態，以及最新狀態數據的一種表，拉鍊表根據拉鍊粒度的不同，實際上相當於快照，只不過做了優化，去除了一部分不變的記錄而已,通過拉鍊表可以很方便的還原出拉鍊時點的客戶記錄。
流水錶： 對於表的每一個修改都會記錄，可以用於反映實際記錄的變更。
在webank由於騰訊雲做後臺支撐，幾乎可以看作空間無限，所以在很多表的使用上都是全量表，只需簡單依照DS字段來區分即可，但在實際空間有限的折中方案下，我們最好選擇拉鍊表來作爲數倉建設的基礎表。
同時在HIVE之中也有四種表：內部表、外部表、分區表和桶表。一般而言，都是創建的內部表，外部表的創建需要顯式申明external，此外，分區表也是很常用的表結構，幾乎webank所有的全量表都是以DS作爲字段進行分區的。桶表用於抽樣，利用hash算法讓數據分佈均勻，在實際工作中並未用到。
5、spark組件問題，
這個問題在滴滴的筆試題中有所出現，知識點比較零散，遂總結如下：
Spark SQL 通常用於交互式查詢，但這一領域同類產品太多，更多作爲MapReduce的替代者，用於批量作業。
Spark Streaming 流式batch處理。主要同類產品爲storm。除了storm延遲低以外，想不出不使用spark streaming的理由。（spark streaming 2.2以後延遲將降低到1ms以內;除了spark不穩定和不兼容的理由以外）
MLlib 機器學習
GraphX 圖計算
Spark core spark的核心框架，以上四大組件都依賴於core。
6、LSM樹
以上知識點也是來自於滴滴的筆試，對於存儲引擎而言，有以下三種基本存儲引擎算法：
• 哈希存儲引擎 是哈希表的持久化實現，支持增、刪、改以及隨機讀取操作，但不支持順序掃描，對應的存儲系統爲key-value存儲系統。對於key-value的插入以及查詢，哈希表的複雜度都是O(1)，明顯比樹的操作O(n)快,如果不需要有序的遍歷數據，哈希表就是your Mr.Right
• B樹存儲引擎 是B樹（關於B樹的由來，數據結構以及應用場景可以看之前一篇博文）的持久化實現，不僅支持單條記錄的增、刪、讀、改操作，還支持順序掃描（B+樹的葉子節點之間的指針），對應的存儲系統就是關係數據庫（Mysql等）。
• LSM樹（Log-Structured Merge Tree）存儲引擎和B樹存儲引擎一樣，同樣支持增、刪、讀、改、順序掃描操作。而且通過批量存儲技術規避磁盤隨機寫入問題。當然凡事有利有弊，LSM樹和B+樹相比，LSM樹犧牲了部分讀性能，用來大幅提高寫性能。
LSM樹原理把一棵大樹拆分成N棵小樹，它首先寫入內存中，隨着小樹越來越大，內存中的小樹會flush到磁盤中，磁盤中的樹定期可以做merge操作，合併成一棵大樹，以優化讀性能。（讀數據需要等待內存和磁盤同步）
7、mysql索引失效問題
• 1.如果條件中有or，即使其中有條件帶索引也不會使用(這也是爲什麼儘量少用or的原因) 要想使用or，又想讓索引生效，只能將or條件中的每個列都加上索引
• 2.對於多列索引，需要滿足最左匹配原則。
• 3.like查詢以%開頭
• 4.如果列類型是字符串，那一定要在條件中將數據使用引號引用起來,否則不使用索引