編輯導語：作為一名數據人員，需要掌握SQL嗎？掌握的程度需要到多少？作為一名專注于分析結論/項目在業務落地以實現增長的分析師，掌握SQL相關工作內容，有助于更好地解決業務問題。本文作者總結了一些SQL的必備知識與應用場景以及相關的實戰應用。

數據分析人員需要掌握SQL到什么程度？

請問做一名數據分析人員，在SQL方面需要掌握到什么程度呢？會增刪改查就可以了嗎？還是說關于開發的內容也要會？不同階段會有不同的要求嗎？

作為專注數據分析結論/項目在業務落地以實現增長的分析師，建議在開始學習新技能前，先明確應用場景。有的放矢才能不枉費努力。

翻譯過來就是：先了解與SQL相關的數據分析工作有哪些？有了目標，才能知道需要準備什么知識來應對。

按我目前與SQL相關的工作內容，為你提供以下參考：

食用說明：根據以下場景，選擇需要重點學習的知識點。

一、SQL應用場景及必備知識

星標根據使用頻率標記，而非重要性。

1. 數據查詢 ★★★

（1）業務場景

也就是常說的“提數”。

實際工作場景中，如果向IT提提數需求，一般都需要溝通+排期，所以最有效率的建議就是自己會從數據庫里提數，此簡單查詢可以應對部分提數需求，例如運營想查看某段時間訂單數據分析師除了自身的分析工作外，有時（甚至是經常）還需要應付產品、運營等部門同事的提數需求。

（2）必備知識

① 簡單查詢

即最簡單的關鍵字組合SELECT?+FROM?+WHERE?+(BETWEEN?/IN) 是SQL查詢的地基，此簡單查詢可以應對部分提數需求，例如運營想查看某段時間訂單。

② 多表查詢

即INNER JOIN、LEFT JOIN?等聯結關鍵字，想象中的取數可能是直接在某個表SELECT想要的字段？

NO! 實際上為了查詢效率，數據會散落到數據庫的各個角落，例如想要了解一筆訂單情況，信息存在這些表中：訂單流水表、訂單詳情表、商品詳情表、門店表、會員表等。

該部分知識的關鍵在于「明確業務分析需求→選擇合適的聯結方式」。

2. 數據更新 ★★☆

（1）業務場景

即“增刪改”，該場景之所以僅兩星的原因，是實際工作中，數據庫運維部門給到我們數據分析師的數據庫賬號多半是只讀權限，也就無法去“增刪改”。

此外，還有數據管控的原因，所以此場景可能更多在于自建數據庫中，如在電腦上新建虛擬機搭建數據庫服務器，導入數據后方便進行下一步分析。

（2）必備知識數據庫與表的創建、刪除和更新

該部分知識點關鍵在于「字段類型的設置」要符合后續分析需求，如訂單商品數量就要設成數值類型、訂單日期設成日期類型等（因為見過都設成字符類型的表，所以就簡單提一下）。

3. 分析數據 ★★★

（1）業務場景

該部分可謂是數據分析師的核心工作。面對復雜的業務問題，重點在于將其拆解、轉譯成簡單的SQL問題。

「案例」例如教育行業中某領導要求你“分析某課程的效果如何”→ 翻譯：課程效果可通過學生成績反映，即是要計算成績最大值、最小值、學生成績分布 → SQL語句。

（2）必備知識

① 匯總分析

即GROUP BY關鍵字。

② 解決業務問題

如計算每個課程學生的平均成績：SELECT avg(成績) FROM 成績表 GROUP BY 課程

③ 復雜查詢

如嵌套子查詢、標量子查詢、關聯子查詢，可應對更復雜的業務問題：

如找出每個課程最高分的學生 → 需要按課程分組后找到最高成績記錄，可以應用關聯子查詢：SELECT 學生名字 FROM 成績表 a WHERE 成績 = ( SELECT max(成績) FROM 成績表 b WHERE a.課程=b.課程)

④ 窗口函數

聚合/排序函數 ( ) OVER (PARTITION BY…ORDER BY…)

此函數可解決復雜業務問題，如常見的TOP N問題：

找出每個課程成績前三的學生 → 按課程分組對學生按成績排名，再從中找出排名前三的學生：SELECT 學生名字 FROM ( SELECT 學生名字, dense_rank( ) over (partitionby 課程 orderby 成績 desc) as ‘成績排名’ FROM 成績表 ) as t WHERE t.成績排名<4

4. 數據產品 ★☆☆

（1）業務場景

對于部分崗位，如我在的集團用戶數據中心，需要負責搭建如CDP這樣的數據產品，雖然多數情況下是由開發負責數據庫工作，但是對于里面核心的功能如運營指標體系、模型報表等，背后的計算邏輯、數據流，要求數據分析師了如指掌。

此外，對于剛開始建立數據分析團隊的部門，還存在「數據同步」的需求，即要從ERP、CRM等系統將需要分析的原數據同步到自己的數據庫里便于分析，而此需求需要通過存儲過程實現。

（2）必備知識存儲過程

即PROCEDURE，可以將某業務需求，或者數據產品中的報表對應的所有SQL語句放在一起，方便一鍵執行，如RFM模型里的語句可以寫成存儲過程，計算結果實時同步到前端。

「SQL SERVER」計劃：面對「數據同步」需求，有了存儲過程后，還需要進行定時任務，在非業務時間執行數據同步的存儲過程。

如是使用SQL SERVER版本，可以通過“計劃”實現定時任務。

5. 項目部署 ★☆☆

（1）業務場景

數據分析結論在業務場景測試有效后，就需要通過報表、模型等方式落地形成業務常態。而這個項目落地，可能交給開發處理，但更有效的方式是分析師可以參與到部署的過程中。這個過程，其中一個重要的部分就是數據庫的設計：如何設計表格以提高計算效率。

（2）必備知識

數據庫設計與「SQL三范式」：SQL三范式的目的在于解決數據冗余、計算效率低等問題，另一方面對數據增加、修改更友好。

以上部分從業務場景出發，討論業務問題的解決方案與SQL知識點的關系，解決學習了SQL之后可以做什么的問題。

下面將從實戰分析場景出發，講解分析報告中需要掌握哪些SQL知識？

二、實戰：如何分析用戶？

用SQL做一份數據分析報告涉及什么哪些知識點？

在工作中，每個數據分析師都離不開做數據分析報告，而一份可落地的報告更是要求靈活地應用工具及理論知識。接下來，我們從工具應用的角度，看看如何用SQL做一份完整的數據分析報告。

1. 數據導入

（1）新建數據庫

用優秀的數據庫管理工具Navicat 連接數據庫，通過Navicat 將數據（如Excel、SQL腳本等格式）導入數據庫。

2. 數據清洗

數據清洗的目的是為了將數據按照業務分析需求，剔除異常值、離群值，使分析結果更準確反映業務實際。

常見的步驟如下：

是否存在空值：WHERE`字段名`is null

是否存在重復數據：通過GROUP BY關鍵字實現

SELECT COUNT(*) FROM 表名 GROUP BY 字段名 HAVING COUNT(*) >1

是否存在業務定義以外的數據：比如需要分析華南區域數據，而數據中出現華北數據

3. 數據格式化

這一步是要根據后續分析需求，調整表格結構、數據格式等，如出于數據存放原因，拿到的數據表格可能是一維表，不滿足分析需求，需要將其調整為二維表。常見的步驟如下：

1. 時間函數：如將「時間戳」格式化為日期、時間、月份、周幾（常見于周分析）等，可通過「FROM_UNIXTIME」「DATE_FORMAT」等函數實現
2. 行列互換：如解決上述的一維表轉為二維表的問題，可通過關鍵字「CASE WHEN」實現
3. 字段的拆分與合并：如將收貨地址字段拆為省、市、鎮等字段，可通過「CONCAT」「LEFT」「RIGHT」「SUBSTRING」等函數實現

4. 整體分析

在開始真正的分析之前，需要進行探索性數據分析(Exploratory Data Analysis，EDA)，也就是對現有數據進行整體分析，對現狀有大體的了解。

更重要的是，通過整體分析，找出業務運營存在的問題，進而提出業務目標，展開后續的深度分析。

常見的步驟如下：

漏斗分析：如海盜模型AARRR，阿里營銷模型AIPL等，通過簡單的「COUNT」函數，直接數就可實現

5. 建立視圖

面對復雜的業務分析，SQL語句也會變得復雜，往往需要不斷嵌套。為了減少分析時語句的復雜性、避免重復執行相同語句，可以采用新建視圖的方式，將重復性高的語句固定為視圖，再在此基礎上進行復雜查詢。

新建視圖：CREATE VIEW 視圖名 AS SELECT…

6. 用戶分析

從整體分析中，明確業務問題、目標后，便可開始進行用戶分析。根據分析目的的不同，采用不同的分析方法，而常見的分析方法如下：

（1）「人貨場」分析

（2）「復購」分析

核心問題在于如何計算“復購”：用「窗口函數+DENSE_RANK()」統計每個訂單是該用戶的第幾次消費，命名為’N_CONSUME’。

第一次消費即為用戶“首購訂單”，大于等于第二次消費的訂單則為“復購訂單“，針對復購訂單進行統計，即可進行復購分析。

（3）「RFM模型」分析

核心問題在于如何定義閾值及人群劃分：通過【窗口函數】可計算出每個用戶的RFM值：

• R：每個用戶最后消費日期，與分析日期相減的天數即為R
• F：通過復購分析中得出的N_CONSUME，計算最大消費次數即為F
• M：簡單地SUM用戶所有消費金額，即為M

閾值：可通過計算所有用戶的R,F,M平均值獲得

所有用戶的RFM值與閾值比較，通過「CASE WHEN」轉為 ‘高’、’低’ 兩個值，根據RFM高低值通過「CASE WHEN」將所有用戶劃分到八個人群中。

本文由 @餅干哥哥 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議