我們熟知的SQL是一種資料庫查詢語句，它友善了開發者在大型資料中執行高效的操作。但本文從另一角度嵌套SQL查詢語句而建構了一個簡單的三層全連接配接網絡，雖然由于語句的嵌套過深而不能高效計算，但仍然是一個非常有意思的實驗。
在這篇文章中，我們将純粹用SQL實作含有一個隐藏層（以及帶 ReLU 和 softmax 激活函數）的神經網絡。這些神經網絡訓練的步驟包含前向傳播和反向傳播，将在 BigQuery 的單個SQL查詢語句中實作。當它在 BigQuery 中運作時，實際上我們正在成百上千台伺服器上進行分布式神經網絡訓練。聽上去很贊，對吧？
也就是說，這個有趣的項目用于測試 SQL 和 BigQuery 的限制，同時從聲明性資料的角度看待神經網絡訓練。這個項目沒有考慮任何的實際應用，不過最後我将讨論一些實際的研究意義。
我們先從一個基于神經網絡的簡單分類器開始。它的輸入尺寸為 2，輸出為二分類。我們将有一個次元為 2 的單隐層和 ReLU 激活函數。輸出層的二分類将使用 softmax 函數。我們在實作網絡時遵循的步驟将是在 Karpathy’s CS231n 指南（https://cs231n.github.io/neural-networks-case-study/）中展示的基于 SQL 版本的 Python 示例。
模型
該模型含有以下參數：
輸入到隐藏層
W: 2×2 的權重矩陣（元素： w_00, w_01, w_10, w_11）
B: 2×1 的偏置向量（元素：b_0, b_1）
隐藏到輸出層
W2: 2×2 的權重矩陣(元素： w2_00, w2_01, w2_10, w2_11)
B2: 2×1 的偏置向量(元素：b2_0, b2_1)
訓練資料存儲在 BigQuery 表格當中，列 x1 和 x2 的輸入和輸出如下所示（表格名稱：example_project.example_dataset.example_table）
如前所述，我們将整個訓練作為單個 SQL 查詢語句來實作。在訓練完成後，通過 SQL 查詢語句将會傳回參數的值。正如你可能猜到的，這将是一個層層嵌套的查詢，我們将逐漸建構以準備這個查詢語句。我們将會從最内層的子查詢開始，然後逐個增加嵌套的外層。
前向傳播
首先，我們将權重參數 W 和 W2 設為服從正态分布的随機值，将權重參數 B 和 B2 設定為 0。 W 和 W2 的随機值可以通過 SQL 本身産生。為了簡單起見，我們将從外部生成這些值并在 SQL 查詢中使用。用于初始化參數的内部子查詢如下：
SELECT *,
-0.00569693 AS w_00,
0.00186517 AS w_01,
0.00414431 AS w_10,
0.0105101 AS w_11,
0.0 AS b_0,
0.0 AS b_1,
-0.01312284 AS w2_00,
- 0.01269512 AS w2_01,
0.00379152 AS w2_10,
-0.01218354 AS w2_11,
0.0 AS b2_0,
0.0 AS b2_1
FROM `example_project.example_dataset.example_table`
請注意，表格 example_project.example_dataset.example_table 已經包含了列 x1、 x2 和 y。模型參數将會被作為上述查詢結果的附加列添加。
接下來，我們将計算隐藏層的激活值。我們将使用含有元素 d0 和 d1 的向量 D 表示隐藏層。我們需要執行矩陣操作 D = np.maximum(0, np.dot(X, W) + B)，其中 X 表示輸入向量（元素 x1 和 x2）。這個矩陣運算包括将權重 W 和輸入 X 相乘，再加上偏置向量 B。然後，結果将被傳遞給非線性 ReLU 激活函數，該函數将會把負值設定為 0。SQL 中的等效查詢為：
SELECT *,
(CASE
WHEN ((x1*w_00 + x2*w_10) + b_0) > 0.0 THEN ((x1*w_00 + x2*w_10) + b_0)
ELSE 0.0
END) AS d0,
(CASE
WHEN ((x1*w_01 + x2*w_11) + b_0) > 0.0 THEN ((x1*w_01 + x2*w_11) + b_1)
END) AS d1
FROM {inner subquery}
上面的查詢将兩個新列 d0 和 d1 添加到之前内部子查詢的結果當中。 上述查詢的輸出如下所示。
這完成了從輸入層到隐藏層的一次轉換。現在，我們可以執行從隐藏層到輸出層的轉換了。
首先，我們将計算輸出層的值。公式是：scores = np.dot(D, W2) + B2。然後，我們将對計算出來的值用 softmax 函數來獲得每個類的預測機率。SQL 内部的等價子查詢如下：
SELECT *,
EXP(scores_0)/(EXP(scores_0) + EXP(scores_1)) AS probs_0,
EXP(scores_1)/(EXP(scores_0) + EXP(scores_1)) AS probs_1
FROM
( SELECT *,
((d0*w2_00 + d1*w2_10) + b2_0) AS scores_0,
((d0*w2_01 + d1*w2_11) + b2_1) AS scores_1
FROM {INNER sub-query})
首先，我們将使用交叉熵損失函數來計算目前預測的總損失。首先，計算每個樣本中正确類預測機率對數的負值。交叉熵損失隻是這些 X 和 Y 執行個體中數值的平均值。自然對數是一個遞增函數，是以，将損失函數定義為負的正确類預測機率對數很直覺。如果正确類的預測機率很高，損失函數将會很低。相反，如果正确類的預測機率很低，則損失函數值将很高。
為了減少過拟合的風險，我們也将同樣增加 L2 正則化。在整體損失函數中，我們将包含 0.5*reg*np.sum(W*W) + 0.5*reg*np.sum(W2*W2)，其中 reg 是超參數。在損失函數中包括這一函數将會懲罰那些權重向量中較大的值。
在查詢當中，我們同樣會計算訓練樣本的數量(num_examples)。這對于後續我們計算平均值來說很有用。SQL 查詢中計算整體損失函數的語句如下：
SELECT *,
(sum_correct_logprobs/num_examples) + 1e-3*(0.5*(w_00*w_00 + w_01*w_01 + w_10*w_10 + w_11*w_11) + 0.5*(w2_00*w2_00 + w2_01*w2_01 + w2_10*w2_10 + w2_11*w2_11)) AS loss
(SELECT *,
SUM(correct_logprobs) OVER () sum_correct_logprobs,
COUNT(1) OVER () num_examples
FROM
(SELECT *,
(CASE
WHEN y = 0 THEN -1*LOG(probs_0)
ELSE -1*LOG(probs_1)
END) AS correct_logprobs
FROM {inner subquery}))
反向傳播
接下來，對于反向傳播，我們将計算每個參數對于損失函數的偏導數。我們使用鍊式法則從最後一層開始逐層計算。首先，我們将通過使用交叉熵和 softmax 函數的導數來計算 score 的梯度。與此相對的查詢是：
(CASE
WHEN y = 0 THEN (probs_0–1)/num_examples ELSE probs_0/num_examples
END) AS dscores_0,
(CASE
WHEN y = 1 THEN (probs_1–1)/num_examples ELSE probs_1/num_examples
END) AS dscores_1
在上文中，我們用 scores = np.dot(D, W2) + B2 算出了分數。是以，基于分數的偏導數，我們可以計算隐藏層 D 和參數 W2，B2 的梯度。對應的查詢語句是：
SUM(d0*dscores_0) OVER () AS dw2_00,
SUM(d0*dscores_1) OVER () AS dw2_01,
SUM(d1*dscores_0) OVER () AS dw2_10,
SUM(d1*dscores_1) OVER () AS dw2_11,
SUM(dscores_0) OVER () AS db2_0,
SUM(dscores_1) OVER () AS db2_1,
CASE
WHEN (d0) <= 0.0 THEN 0.0
ELSE (dscores_0*w2_00 + dscores_1*w2_01)
END AS dhidden_0,
CASE
WHEN (d1) <= 0.0 THEN 0.0
ELSE (dscores_0*w2_10 + dscores_1*w2_11)
END AS dhidden_1
同理，我們知道 D = np.maximum(0, np.dot(X, W) + B)。是以，通過 D 的偏導，我們可以計算出 W 和 B 的導數。我們無須計算 X 的偏導，因為它不是模型的參數，且也不必通過其它模型參數進行計算。計算 W 和 B 的偏導的查詢語句如下：
SELECT *,
SUM(x1*dhidden_0) OVER () AS dw_00,
SUM(x1*dhidden_1) OVER () AS dw_01,
SUM(x2*dhidden_0) OVER () AS dw_10,
SUM(x2*dhidden_1) OVER () AS dw_11,
SUM(dhidden_0) OVER () AS db_0,
SUM(dhidden_1) OVER () AS db_1
最後，我們使用 W、B、W2 及 B2 各自的導數進行更新操作。計算公式是 param = learning_rate * d_param ，其中learning_rate 是參數。為了展現 L2 正則化，我們會在計算 dW 和 dW2 時加入一個正則項 reg*weight。我們也去掉如 dw_00, correct_logprobs 等緩存的列，它們曾在子查詢時被建立，用于儲存訓練資料(x1, x2 及 y 列) 和模型參數（權重和偏置項）。對應的查詢語句如下：
SELECT x1,
x2,
y,
w_00 — (2.0)*(dw_00+(1e-3)*w_00) AS w_00,
w_01 — (2.0)*(dw_01+(1e-3)*w_01) AS w_01,
w_10 — (2.0)*(dw_10+(1e-3)*w_10) AS w_10,
w_11 — (2.0)*(dw_11+(1e-3)*w_11) AS w_11,
b_0 — (2.0)*db_0 AS b_0,
b_1 — (2.0)*db_1 AS b_1,
w2_00 — (2.0)*(dw2_00+(1e-3)*w2_00) AS w2_00,
w2_01 — (2.0)*(dw2_01+(1e-3)*w2_01) AS w2_01,
w2_10 — (2.0)*(dw2_10+(1e-3)*w2_10) AS w2_10,
w2_11 — (2.0)*(dw2_11+(1e-3)*w2_11) AS w2_11,
b2_0 — (2.0)*db2_0 AS b2_0,
b2_1 — (2.0)*db2_1 AS b2_1
這包含了正向和反向傳播的一整個疊代過程。以上查詢語句将傳回更新後的權重和偏置項。部分結果如下所示：
為了進行多次訓練疊代，我們将反複執行上述過程。用一個簡單 Python 函數足以搞定，代碼連結如下：https://github.com/harisankarh/nn-sql-bq/blob/master/training.py。
因為疊代次數太多，查詢語句嵌套嚴重。執行 10 次訓練疊代的查詢語句位址如下：
https://github.com/harisankarh/nn-sql-bq/blob/master/out.txt
因為查詢語句的多重嵌套和複雜度，在 BigQuery 中執行查詢時多項系統資源告急。BigQuery 的标準 SQL 擴充的縮放性比傳統 SQL 語言要好。即使是标準 SQL 查詢，對于有 100k 個執行個體的資料集，也很難執行超過 10 個疊代。因為資源的限制，我們将會使用一個簡單的決策邊界來評估模型，如此一來，我們就可以在少量疊代後得到較好的準确率。
我們将使用一個簡單的資料集，其輸入 X1、X2 服從标準正态分布。二進制輸出 y 簡單判斷 x1 + x2 是否大于 0。為了更快的訓練完 10 個疊代，我們使用一個較大的學習率 2.0（注意：這麼大的學習率并不推薦實際使用，可能會導緻發散）。将上述語句執行 10 個疊代得出的模型參數如下：
我們将使用 Bigquery 的函數 save to table 把結果儲存到一個新表。我們現在可以在訓練集上執行一次推理來比較預測值和預期值的差距。查詢語句片段在以下連結中：
https://github.com/harisankarh/nn-sql-bq/blob/master/query_for_prediction.sql。
僅通過十個疊代，我們的準确率就可達 93%（測試集上也差不多）。
如果我們把疊代次數加到 100 次，準确率高達 99%。
優化
下面是對本項目的總結。我們由此獲得了哪些啟發？如你所見，資源瓶頸決定了資料集的大小以及疊代執行的次數。除了祈求谷歌開放資源上限，我們還有如下優化手段來解決這個問題。
建立中間表和多個 SQL 語句有助于增加疊代數。例如，前 10 次疊代的結果可以存儲在一個中間表中。同一查詢語句在執行下 10 次疊代時可以基于這個中間表。如此，我們就執行了 20 個疊代。這個方法可以反複使用，以應對更大的查詢疊代。
相比于在每一步增加外查詢，我們應該盡可能的使用函數的嵌套。例如，在一個子查詢中，我們可以同時計算 scores 和 probs，而不應使用 2 層嵌套查詢。
在上例中，所有的中間項都被保留直到最後一個外查詢執行。其中有些項如 correct_logprobs 可以早些删除（盡管 SQL 引擎可能會自動的執行這類優化）。
多嘗試應用使用者自定義的函數。如果感興趣，你可以看看這個 BigQuery 的使用者自定義函數的服務模型的項目（但是，無法使用 SQL 或者 UDFs 進行訓練）。
意義
現在，讓我們來看看基于深度學習的分布式 SQL 引擎的深層含義。 BigQuery、Presto 這類 SQL 倉庫引擎的一個局限性在于，查詢操作是在 CPU 而不是 GPU 上執行的。研究 blazingdb 和 mapd 等基于 GPU 加速的資料庫查詢結果想必十分有趣。一個簡單的研究方法就是使用分布式 SQL 引擎執行查詢和資料分布，并用 GPU 加速資料庫執行本地計算。
退一步來看，我們已經知道執行分布式深度學習很難。分布式 SQL 引擎在數十年内已經有了大量的研究工作，并産出如今的查詢規劃、資料分區、操作歸置、檢查點設定、多查詢排程等技術。其中有些可以與分布式深度學習相結合。如果你對這些感興趣，請看看這篇論文（https://sigmodrecord.org/publications/sigmodRecord/1606/pdfs/04_vision_Wang.pdf），該論文對分布式資料庫和分布式深度學習展開了廣泛的研究讨論。