从计算、建模到回测：因子挖掘的最佳实践
量化投資與機器學習微信公眾號，是業內垂直于量化投資、對沖基金、Fintech、人工智能、大數據等領域的主流自媒體。公眾號擁有來自公募、私募、券商、期貨、銀行、保險、高校等行業30W+關注者，榮獲2021年度AMMA優秀品牌力、優秀洞察力大獎，連續2年被騰訊云+社區評選為“年度最佳作者”。
前言
因子挖掘是量化交易的基礎。除傳統的基本面因子外，從中高頻行情數據中挖掘有價值的因子，并進一步建模和回測以構建交易系統，是一個量化團隊的必經之路。金融或者量化金融是一個高度市場化、多方機構高度博弈的領域。因子的有效時間會隨著博弈程度的加劇而縮短，如何使用更加高效的工具和流程，更快的找到新的有效的因子，是每一個交易團隊必須面對的問題。
交易團隊用于因子挖掘的常見技術棧有幾個大的類別：
使用 python、matlab 等數據分析工具
委托第三方開發有圖形界面的因子挖掘工具
使用 java、c++ 等編程語言自行開發挖掘工具
在 DolphinDB 等專業工具上進行二次開發
之前，公眾號跟大家分享過一個超高性能分布式時序數據庫神器：DolphinDB
DolphinDB：金融高頻因子流批統一計算神器！
DolphinDB 作為分布式計算、實時流計算及分布式存儲一體化的高性能時序數據庫，在因子的存儲、計算、建模、回測和實盤交易等場景中有著得天獨厚的優勢。
內置的多范式編程語言（函數式，命令式，向量式、SQL式），可以幫助研發人員高效開發不同風格的因子。
超過1400個性能高效的內置計算函數，尤其是優化過的窗口處理方面的內置算子，大大縮短了因子計算的延時。
同時，DolphinDB 自帶的數據回放和流式增量計算引擎可以方便地解決因子挖掘中研發和生產一體化的問題。DolphinDB 的分布式存儲和計算框架，天生便于解決工程中的可靠性、擴展性等問題。
通過部署 DolphinDB 單機或集群環境，用戶可以快速地處理 GB 級別甚至 PB 級別的海量數據集，日級、分鐘級、快照和逐筆委托數據均能高效響應。
下文中，將基于國內 A 股市場各個頻率的數據，根據批量因子計算、實時因子計算、多因子建模、因子庫存儲規劃、因子計算工程化等各個場景的實操演練，以及針對不同方案的對比分析，為大家介紹在 DolphinDB 中進行因子計算的最佳實踐。
這里給大家推薦一下，5月19日（周四）晚7點，DolphinDB CEO 周小華博士將在線上開講，通過日頻因子、分鐘頻因子、快照因子、逐筆因子四個實際案例，為大家詳細介紹因子挖掘的最佳實踐。干貨滿滿！快來報名吧~
長按下方海報識別二維碼即可參與活動！
1、測試數據集
本文的因子計算基于三類國內 A 股行情數據集：逐筆數據、快照數據和 K 線數據（分鐘 K 線和日 K 線）。快照數據以兩種形式存儲：（1）各檔數據分別存儲為一列；（2）用 array vector （DolphinDB中一種特殊的向量，用于存儲可變長度的二維數組）將所有檔位的數據存儲為一列。
2、投研階段的因子計算
在投研階段，會通過歷史數據批量計算生成因子。通常，推薦研究員將每一種因子的計算都封裝成自定義函數。根據因子類型和使用者習慣的不同，DolphinDB 提供了面板和 SQL 兩種計算方式。
2.1 面板數據模式
面板數據（panel data）是以時間為索引，標的為列，指標作為內容的一種數據載體，它非常適用于以標的集合為單位的指標計算，將數據以面板作為載體，可以大大簡化腳本的復雜度，通常最后的計算表達式可以從原始的數學公式中一對一的翻譯過來。除此之外，可以充分利用 DolphinDB 矩陣計算的高效能。
在因子計算中，面板數據通常可以通過?panel?函數，或者?exec?搭配?pivot by?得到，具體樣例如下表：每一行是一個時間點，每一列是一個股票。
000001 000002 000003 000004 ...--------- ---------- ------- ------ --- 2020.01.02T09:29:00.000|3066.336 3212.982 257.523 2400.042 ... 2020.01.02T09:30:00.000|3070.247 3217.087 258.696 2402.221 ... 2020.01.02T09:31:00.000|3070.381?3217.170??259.066?2402.029?...在面板數據上，由于是以時間為索引，標的為列，因子可以方便地在截面上做各類運算。DolphinDB 包含 row 系列函數以及各類滑動窗口函數，在下面兩個因子計算例子中，原本復雜的計算邏輯，在面板數據中，可以用一行代碼輕松實現。
Alpha 1 因子計算中，下例使用了 rowRank 函數，可以在面板數據中的每一個時間截面對各標的進行排名；iif 條件運算，可以在標的向量層面直接篩選及計算；mimax 及 mstd 等滑動窗口函數也是在標的層面垂直計算的。因此，在面板計算中合理應用 DolphinDB 的內置函數，可以從不同維度智慧計算。
Alpha 98 因子計算中，同時使用了三個面板數據，分別是 vwap, open 和 vol。不僅各矩陣內部運用了 rowRank 函數橫向截面運算以及m系列垂直滑動窗口計算，矩陣之間也進行了二元運算。用一行代碼解決了多維度的復雜的嵌套計算邏輯。
2.2 SQL 模式
DolphinDB 在存儲和計算框架上都是基于列式結構，表中的一個列可以直接作為一個向量化函數的輸入參數。因此如果一個因子的計算邏輯只涉及股票自身的時間序列數據，不涉及多個股票橫截面上的信息，可以直接在 SQL 中按股票分組，然后在 select 中調用因子函數計算每個股票在一段時間內的因子值。如果數據在數據庫中本身是按股票分區存儲的，那么可以非常高效地實現數據庫內并行計算。
def sum_diff(x, y){return (x-y)\(x+y) }@state def factorDoubleEMA(price){ema_2 = ema(price, 2)ema_4 = ema(price, 4)sum_diff_1000 = 1000 * sum_diff(ema_2, ema_4)return ema(sum_diff_1000, 2) - ema(sum_diff_1000, 3) }res?=?select?tradetime,?securityid,?`doubleEMA?as?factorname,?factorDoubleEMA(close)?as?val?from?loadTable("dfs://k_minute","k_minute")?where??tradetime?between?2020.01.01?:?2020.01.31?context?by?securityid上面的例子中定義了一個因子函數 factorDoubleEMA，只需要用到股票的價格序列信息。在 SQL 中通過?context by?子句按股票代碼分組，然后調用factorDoubleEMA函數，計算每個股票的因子序列。值得注意的是，context by?是 DolphinDB SQL 對?group by?的擴展，是 DolphinDB 特有的 SQL 語句。group by 只適用于聚合計算，也就是說輸入長度為n，輸出長度是1；context by?適用于向量計算，輸入長度是n，輸出長度也是n。另外因子函數 factorDOubleEMA 除了可以接受一個向量作為輸入，也可以接受一個面板數據作為輸入。這也是DolphinDB所強調的，因子函數的粒度盡可能細，這樣可以應用于很多場景。
3、不同頻率的因子開發舉例
不同頻率數據的因子，有著不同的特點。本章節將分別舉例分鐘頻、日頻、快照、逐筆數據的特點因子，闡述不同頻率數據計算因子的最佳實踐。
3.1?分鐘級和日級數據
日級數據的計算，通常是涉及多個截面的復雜計算，在上面的章節中已展現。對于稍簡單的計算，則與分鐘級數據的因子相似。
針對分鐘級數據，下面的例子是日內收益率偏度的因子計算，對于這類只涉及表內字段的計算，通常使用 SQL 模式，配合?group by?語句將計算分組：
defg dayReturnSkew(close){return skew(ratios(close)) }minReturn = select `dayReturnSkew as factorname, dayReturnSkew(close) as val from loadTable("dfs://k_minute_level", "k_minute") where date(tradetime) between 2020.01.02 : 2020.01.31 group by date(tradetime) as tradetime, securityid#output tradetime securityid factorname val ---------- ---------- ------------- ------- 2020.01.02 000019 dayReturnSkew 11.8328 2020.01.02 000048 dayReturnSkew 11.0544 2020.01.02?000050?????dayReturnSkew?10.61863.2?基于快照數據的有狀態因子計算
有狀態的因子，意為因子的計算需要基于之前的計算結果，如一般的滑動窗口計算，聚合計算等，都是有狀態的因子計算。
下例 flow 這個自定義函數中，參數為四個列字段，運用?mavg?滑動平均函數以及?iif?條件運算函數，可以直接在SQL中得到因子結果：
@state def flow(buy_vol, sell_vol, askPrice1, bidPrice1){buy_vol_ma = round(mavg(buy_vol, 5*60), 5)sell_vol_ma = round(mavg(sell_vol, 5*60), 5)buy_prop = iif(abs(buy_vol_ma+sell_vol_ma) < 0, 0.5 , buy_vol_ma/ (buy_vol_ma+sell_vol_ma))spd = askPrice1 - bidPrice1spd = iif(spd < 0, 0, spd)spd_ma = round(mavg(spd, 5*60), 5)return iif(spd_ma == 0, 0, buy_prop / spd_ma) }res_flow = select TradeTime, SecurityID, `flow as factorname, flow(BidOrderQty[1],OfferOrderQty[1], OfferPrice[1], BidPrice[1]) as val from loadTable("dfs://LEVEL2_Snapshot_ArrayVector","Snap") where date(TradeTime) <= 2020.01.30 and date(TradeTime) >= 2020.01.01 context by SecurityID# output sample TradeTime SecurityID factorname val ----------------------- ---------- ---------- ----------------- 2020.01.22T14:46:27.000 110065 flow 3.7587 2020.01.22T14:46:30.000 110065 flow 3.7515 2020.01.22T14:46:33.000 110065 flow 3.7443 ...3.3 快照數據的多檔賦權無狀態因子計算
計算 Level 2的多檔快照數據，傳統的方式是將多檔量價數據存儲成為多個列, 再將多檔掛單或者報價用 matrix 轉換與權重做計算。更推薦的做法是，將多檔數據存儲為 array vector，仍舊可以用原來的自定義函數，但是資源消耗包括效率都有提升。下面的例子是計算多檔報價的權重偏度因子，使用 array vector 后計算時間從 4 秒縮短到 2 秒。
def mathWghtCovar(x, y, w){v = (x - rowWavg(x, w)) * (y - rowWavg(y, w))return rowWavg(v, w) }@state def mathWghtSkew(x, w){x_var = mathWghtCovar(x, x, w)x_std = sqrt(x_var)x_1 = x - rowWavg(x, w)x_2 = x_1*x_1len = size(w)adj = sqrt((len - 1) * len) \ (len - 2)skew = rowWsum(x_2, x_1) \ (x_var * x_std) * adj \ lenreturn iif(x_std==0, 0, skew) }//weights: w = 10 9 8 7 6 5 4 3 2 1//權重偏度因子： resWeight = select TradeTime, SecurityID, `mathWghtSkew as factorname, mathWghtSkew(BidPrice, w) as val from loadTable("dfs://LEVEL2_Snapshot_ArrayVector","Snap") where date(TradeTime) = 2020.01.02 map resWeight1 = select TradeTime, SecurityID, `mathWghtSkew as factorname, mathWghtSkew(matrix(BidPrice0,BidPrice1,BidPrice2,BidPrice3,BidPrice4,BidPrice5,BidPrice6,BidPrice7,BidPrice8,BidPrice9), w) as val from loadTable("dfs://snapshot_SH_L2_TSDB", "snapshot_SH_L2_TSDB") where date(TradeTime) = 2020.01.02 map#output TradeTime SecurityID factorname val ----------------------- ---------- ---------- ------ ... 2020.01.02T09:30:09.000 113537 array_1 -0.8828 2020.01.02T09:30:12.000 113537 array_1 0.7371 2020.01.02T09:30:15.000 113537 array_1 0.6041 ...3.4 基于快照數據的分鐘聚合
投研中經常需要基于快照數據聚合分鐘線的 OHLC ，下例就是這一場景中的通用做法：
//基于快照因子的分鐘聚合OHLC，vwap tick_aggr?=?select?first(LastPx)?as?open,?max(LastPx)?as?high,?min(LastPx)?as?low,?last(LastPx)?as?close,?sum(totalvolumetrade)?as?vol,sum(lastpx*totalvolumetrade)?as?val,wavg(lastpx,?totalvolumetrade)?as?vwap?from?loadTable("dfs://LEVEL2_Snapshot_ArrayVector","Snap")?where?date(TradeTime)?<=?2020.01.30?and?date(TradeTime)?>=?2020.01.01?group?by?SecurityID,?bar(TradeTime,1m)3.5 逐筆數據
逐筆數據量較大，一般會針對成交量等字段進行計算，下面的例子計算了每天主買成交量占全部成交量的比例，同樣使用 SQL 模式，發揮庫內并行計算的優勢，并使用 csort 語句用來對組內數據按照時間順序排序：
@state def buyTradeRatio(buyNo, sellNo, tradeQty){return cumsum(iif(buyNo>sellNo, tradeQty, 0))\cumsum(tradeQty) }factor = select TradeTime, SecurityID, `buyTradeRatio as factorname, buyTradeRatio(BuyNo, SellNo, TradeQty) as val from loadTable("dfs://tick_SH_L2_TSDB","tick_SH_L2_TSDB") where date(TradeTime)<2020.01.31 and time(TradeTime)>=09:30:00.000 context by SecurityID, date(TradeTime) csort TradeTime#output TradeTime???????????SecurityID?factorname?????? val?????????????? -------------------?----------?----------------?------ 2020.01.08T09:30:07 511850 buyTradeRatio 0.0086 2020.01.08T09:30:31 511850 buyTradeRatio 0.0574 2020.01.08T09:30:36 511850 buyTradeRatio 0.0569 ...4、生產環境的流式因子計算
在生產環境中，DolphinDB 提供了實時流計算框架。在流計算框架下，用戶在投研階段封裝好的基于批量數據開發的因子函數，可以無縫投入交易和投資方面的生產程序中，這就是通常所說的批流一體。
使用流批一體可以加速用戶的開發和部署。同時流計算框架還在算法的路徑上，做了極致的優化，在具有高效開發的優勢的同時，又兼顧了計算的高效性能。在這一章中，將會基于實際的狀態因子案例，展示實時流計算的使用方法。
DolphinDB 流計算解決方案的核心部件是流計算引擎和流數據表。流計算引擎用于時間序列處理、橫截面處理、窗口處理、表關聯、異常檢測等操作。流數據表可以看作是一個簡化版的消息中間件，或者說是消息中間件中的一個主題（topic），可以往其發布（publish）數據，也可以從其訂閱（subscribe）數據。
流計算引擎和流數據表均繼承于 DolphinDB 的數據表（table），因此都可以通過 append! 函數往其注入數據。流計算引擎的輸出也是數據表的形式，因此多個計算引擎可以跟搭積木一樣自由組合，形成流式處理的流水線。
4.1?流式增量計算
金融方面的原始數據和計算指標，在時間上通常有延續性的關系。以最簡單的五周期移動均線?mavg(close,5)?為例，當新一個周期的數據傳入模型時，可以將之前最遠的第五周期值從 sum 中減出，再把最新一個周期的值加入 sum ，這樣就不必每個周期只更新一個值時都重算一遍 sum 。這種增量計算是流計算的核心，可以大大降低實時計算的延時。DolphinDB內置了大量量化金融中需要用到的基本算子，并為這些算子實現了高效的增量算法。不僅如此，DolphinDB還支持自定義函數的增量實現。在前一章節中，部分自定義的因子函數加了修飾符?@state，表示該函數支持增量計算。
4.1.1主買成交量占比因子的流式處理
第三章的逐筆數據因子的例子展示了主買成交量占比因子（buyTradeRatio）的批量實現方式。此處演示如何使用響應式狀態引擎（reactive state engine）來實現該因子的流式增量計算。
@state def buyTradeRatio(buyNo, sellNo, tradeQty){return cumsum(iif(buyNo>sellNo, tradeQty, 0))\cumsum(tradeQty) }tickStream = table(1:0, `SecurityID`TradeTime`TradePrice`TradeQty`TradeAmount`BuyNo`SellNo, [SYMBOL,DATETIME,DOUBLE,INT,DOUBLE,LONG,LONG]) result = table(1:0, `SecurityID`TradeTime`Factor, [SYMBOL,DATETIME,DOUBLE]) factors = <[TradeTime, buyTradeRatio(BuyNo, SellNo, TradeQty)]> demoEngine = createReactiveStateEngine(name="demo", metrics=factors, dummyTable=tickStream, outputTable=result, keyColumn="SecurityID")上述代碼創建了一個名為 demo 的響應式狀態引擎，SecurityID 作為分組鍵，輸入的消息格式同內存表 tickStrea。需要計算的指標定義在 factors 中，其中1個是輸入表中的原始字段 TradeTime，另一個是需要計算的因子的函數表示。輸出到內存表 result，除了在 factors 中定義的指標外，輸出結果還會添加分組鍵。請注意，自定義的因子函數跟批計算中的完全一致！創建完引擎之后，即可往引擎中插入幾條數據，并觀察計算結果。
4.1.2 大小單的流式處理
資金流分析是逐筆委托數據的一個重要應用場景。在實時處理逐筆數據時，大小單的統計是資金流分析的一個具體應用。大小單在一定程度上能反映主力、散戶的動向。
但在實時場景中，大小單的生成有很多難點：
（1）大小單的計算涉及歷史狀態，如若不能實現增量計算，當計算下午的數據時，可能需要回溯有關這筆訂單上午的數據，效率會非常低下。
（2）計算涉及至少兩個階段。在第一階段需要根據訂單分組，根據訂單的累計成交量判斷大小單，在第二階段要根據股票來分組，統計每個股票的大小單數量及金額。
大小單是一個動態的概念，一個小單在成交量增加后可能變成一個大單。DolphinDB 的兩個內置函數：dynamicGroupCumsum?和?dynamicGroupCumcount?，可以用于對動態組的增量計算。
@state def factorSmallOrderNetAmountRatio(tradeAmount, sellCumAmount, sellOrderFlag, prevSellCumAmount, prevSellOrderFlag, buyCumAmount, buyOrderFlag, prevBuyCumAmount, prevBuyOrderFlag){cumsumTradeAmount = cumsum(tradeAmount)smallSellCumAmount, bigSellCumAmount = dynamicGroupCumsum(sellCumAmount, prevSellCumAmount, sellOrderFlag, prevSellOrderFlag, 2)smallBuyCumAmount, bigBuyCumAmount = dynamicGroupCumsum(buyCumAmount, prevBuyCumAmount, buyOrderFlag, prevBuyOrderFlag, 2) f = (smallBuyCumAmount - smallSellCumAmount) \ cumsumTradeAmountreturn smallBuyCumAmount, smallSellCumAmount, cumsumTradeAmount, f }def createStreamEngine(result){tradeSchema = createTradeSchema()result1Schema = createResult1Schema()result2Schema = createResult2Schema()engineNames = ["rse1", "rse2", "res3"]cleanStreamEngines(engineNames)metrics3 = <[TradeTime, factorSmallOrderNetAmountRatio(tradeAmount, sellCumAmount, sellOrderFlag, prevSellCumAmount, prevSellOrderFlag, buyCumAmount, buyOrderFlag, prevBuyCumAmount, prevBuyOrderFlag)]>rse3 = createReactiveStateEngine(name=engineNames[2], metrics=metrics3, dummyTable=result2Schema, outputTable=result, keyColumn="SecurityID")metrics2 = <[BuyNo, SecurityID, TradeTime, TradeAmount, BuyCumAmount, PrevBuyCumAmount, BuyOrderFlag, PrevBuyOrderFlag, factorOrderCumAmount(TradeAmount)]>rse2 = createReactiveStateEngine(name=engineNames[1], metrics=metrics2, dummyTable=result1Schema, outputTable=rse3, keyColumn="SellNo")metrics1 = <[SecurityID, SellNo, TradeTime, TradeAmount, factorOrderCumAmount(TradeAmount)]>return createReactiveStateEngine(name=engineNames[0], metrics=metrics1, dummyTable=tradeSchema, outputTable=rse2, keyColumn="BuyNo") }自定義函數?factorSmallOrderNetAmountRatio?是一個狀態因子函數，用于計算小單的凈流入資金占總的交易資金的比例。createStreamEngine?創建流式計算引擎。DolphinDB 一共創建了3個級聯的響應式狀態引擎，后一個作為前一個的輸出，因此從最后一個引擎開始創建。前兩個計算引擎 rse1 和 rse2 分別以買方訂單號（BuyNo）和賣方訂單號（SellNo）作為分組鍵，計算每個訂單的累計交易量，并以此區分是大單或小單。第三個引擎rse3把股票代碼（SecurityID）作為分組鍵，統計每個股票的小單凈流入資金占總交易資金的比例。下面輸入一些樣本數據來觀察流計算引擎的運行。
result = createResultTable() rse = createStreamEngine(result) insert into rse values(`000155, 1000, 1001, 2020.01.01T09:30:00, 20000) insert into rse values(`000155, 1000, 1002, 2020.01.01T09:30:01, 40000) insert into rse values(`000155, 1000, 1003, 2020.01.01T09:30:02, 60000) insert into rse values(`000155, 1004, 1003, 2020.01.01T09:30:03, 30000)select * from resultSecurityID TradeTime smallBuyOrderAmount smallSellOrderAmount totalOrderAmount factor ---------- ------------------- ------------------- -------------------- ---------------- ------ 000155 2020.01.01T09:30:00 20000 20000 20000 0 000155 2020.01.01T09:30:01 60000 60000 60000 0 000155 2020.01.01T09:30:02 0 120000 120000 -1 000155 2020.01.01T09:30:03 30000 150000 150000 -0.84.1.3 復雜因子Alpha #1流式計算的快捷實現
從前一個大小單的例子可以看到，有些因子的流式實現比較復雜，需要創建多個引擎進行流水線處理來完成。完全用手工的方式來創建多個引擎其實是一件耗時的工作。如果輸入的指標計算只涉及一個分組鍵，DolphinDB提供了一個解析引擎?streamEngineParser?來解決此問題。下面以第三章3.1面板數據模式的alpha #1因子為例，展示?streamEngineParser?的使用方法。以下為核心代碼。
@state def alpha1TS(close){return mimax(pow(iif(ratios(close) - 1 < 0, mstd(ratios(close) - 1, 20),close), 2.0), 5) }def alpha1Panel(close){return rowRank(X=alpha1TS(close), percent=true) - 0.5 }inputSchema = table(1:0, ["SecurityID","TradeTime","close"], [SYMBOL,TIMESTAMP,DOUBLE]) result = table(10000:0, ["TradeTime","SecurityID", "factor"], [TIMESTAMP,SYMBOL,DOUBLE]) metrics = <[SecurityID, alpha1Panel(close)]> streamEngine?=?streamEngineParser(name="alpha1Parser",?metrics=metrics,?dummyTable=inputSchema,?outputTable=result,?keyColumn="SecurityID",?timeColumn=`tradetime,?triggeringPattern='keyCount',?triggeringInterval=4000)因子alpha1實際上包含了時間序列處理和橫截面處理，需要響應式狀態引擎和橫截面引擎串聯來處理才能完成。但這兒僅僅使用了 streamEngineParser 就創建了全部引擎，大大簡化了創建過程。
前面三個例子展示了 DolphinDB 如何通過流計算引擎實現因子在生產環境中的增量計算。在傳統的研究框架下，用戶往往需要對同一個因子計算邏輯寫兩套代碼，一套用于在歷史數據上建模、回測，另外一套專門處理盤中傳入的實時數據。值得注意的是，DolphinDB 的流式計算時直接使用了投研階段生成的核心因子代碼，這很好的解決了傳統金融分析面臨的批流一體問題。
除了三個例子中用到的響應式狀態引擎（reactive state engine）和橫截面引擎（cross sectional engine），DolphinDB 還提供了多種流數據處理引擎包括做流表連接的 asof join engine，equal join engine，lookup join engine，window join engine ，時間序列聚合引擎（time series engine），異常檢測引擎(anomaly detection engine)，會話窗口引擎（session window engine）等。
4.2 數據回放
前一節介紹了因子計算的批流一體實現方案，簡單地說，就是一套代碼（自定義的因子函數），兩種引擎（批計算引擎和流計算引擎）。事實上，DolphinDB提供一種更為簡潔的批流一體實現方案，那就是在歷史數據建模時，通過數據回放，也用流引擎來實現計算。
在第三章中介紹了用 SQL 語句方式批處理計算 factorDoubleEMA 因子的例子，這里介紹如何使用流計算的方式回放數據，計算 factorDoubleEMA 的因子值。
//創建流引擎，并傳入因子算法factorDoubleEMA factors = <[TradeTime, factorDoubleEMA(close)]> demoEngine = createReactiveStateEngine(name=engineName, metrics=factors, dummyTable=inputDummyTable, outputTable=resultTable, keyColumn="SecurityID")//demo_engine訂閱snapshotStreamTable流表 subscribeTable(tableName=snapshotSharedTableName, actionName=actionName, handler=append!{demoEngine}, msgAsTable=true)//創建播放數據源供replay函數歷史回放；盤中的時候，改為行情數據直接寫入snapshotStreamTable流表 inputDS = replayDS(<select SecurityID, TradeTime, LastPx from tableHandle where date(TradeTime)<2020.07.01>, `TradeTime, `TradeTime)4.3 對接交易系統
DolphinDB 本身具有多種常用編程語言的 API，包括 C++, java, javascript, c#, python, go 等。使用這些語言的程序，都可以調用該語言的 DolphinDB 接口，訂閱到 DolphinDB 服務器的流數據。本例提供一個簡單的 python 接口訂閱流數據樣例。
DolphinDB-Python API 訂閱流數據例子：
current_ddb_session.subscribe(host=DDB_datanode_host,tableName=stream_table_shared_name,actionName=action_name,offset=0,resub=False,filter=None,port=DDB_server_port, handler=python_callback_handler,#此處傳入python端要接收消息的回調函數 )在金融生產環境中，更常見的情況，是流數據實時的灌注到消息隊列中，供下游的其他模塊消費。DolphinDB 也支持將實時計算結果推送到消息中間件，與交易程序對接。示例中提供的樣例，使用 DolphinDB 的開源 ZMQ 插件，將實時計算的結果推送到 ZMQ 消息隊列，供下游ZMQ協議的訂閱程序消費(交易或展示)。除ZMQ之外，其他支持的工具都在 DolphinDB 插件庫中提供。所有已有的 DolphinDB 插件都是開源的，插件的編寫組件也是開源的，用戶也可按自己的需要編寫。
DolphinDB 向 ZMQ 消息隊列推送流數據代碼樣例：
（1）首先啟動下游的 ZMQ 數據消費程序，作為監聽端（ZeroMQ消息隊列的服務端）。
zmq_context = Context() zmq_bingding_socket = zmq_context.socket(SUB)#見完整版代碼設定socket選項 zmq_bingding_socket.bind("tcp://*:55556") async def loop_runner(): while True:msg=await zmq_bingding_socket.recv()#阻塞循環until收到流數據print(msg)#在此編寫下游消息處理代碼 asyncio.run(loop_runner())（2）啟動因子數據的流處理計算和發布。
在外部消費 ZMQ 消息的程序啟動后，DolphinDB 端要啟動流計算，并開始對外發布計算結果。以下是 DolphinDB 端的代碼。輸出結果表之前的所有代碼部分，和 4.2 中流處理計算 doubleEma 因子例子的一致，故下例代碼中不再贅述。
resultSchema=table(1:0,["SecurityID","TradeTime","factor"], [SYMBOL,TIMESTAMP,DOUBLE])//輸出到消息隊列的表結構def zmqPusherTable(zmqSubscriberAddress,schemaTable){SignalSender=def (x) {return x}pushingSocket = zmq::socket("ZMQ_PUB", SignalSender)zmq::connect(pushingSocket, zmqSubscriberAddress)pusher = zmq::createPusher(pushingSocket, schemaTable) return pusher }zmqSubscriberAddress="tcp://192.168.1.195:55556"//流表resultStream向zmq隊列推送，使用時根據不同的zmq地址修改此字符串pusherTable=zmqPusherTable(zmqSubscriberAddress,resultSchema)//生成一個邏輯表向上述地址發送zmq包，字段結構參照resultSchemademoEngine = createReactiveStateEngine(name="reactiveDemo", metrics=<[TradeTime,doubleEma(LastPx)]>, dummyTable=snapshotSchema, outputTable=pusherTable, keyColumn="SecurityID",keepOrder=true)//創建流引擎，output指定輸出到pusher表5、因子的存儲和查詢
無論是批量計算還是實時計算，將 DolphinDB 中計算生成的因子保存下來提供給投研做后續的分析都是很有意義的。本章主要是根據存儲、查詢，使用方式等方面，來分析如何基于使用場景來選擇更高效的存儲模型。
在實際考慮數據存儲方案時，需要從以下三個方面考慮：
選擇 OLAP 引擎還是 TSDB 引擎。OLAP 最適合全量跑批計算，TSDB 則在序列查詢上優勢突出，性能和功能上比較全面。
因子的存儲方式是單值縱表方式還是多值寬表方式。單值方式的最大優點是靈活性強，增加因子和股票時，不用修改表結構，缺點是數據冗余度高。多值寬表的數據冗余度很低，配合 TSDB 引擎的 array vector，存儲效率很高，但是新因子或新股票的出現，需要重新生成因子表。
分區方式選擇。可用于分區的列包括時間列，股票代碼列和因子列。OLAP 引擎推薦的分區大小為原始數據 100MB 左右。TSDB 引擎推薦的分區設置為原始數據 100MB~1GB 范圍會性能最佳。
結合以上考慮因素，本文以 4000 只股票，1000 個因子，存儲分鐘級因子庫為例，有如下三種選擇：
以縱表存儲,使用 OLAP 引擎，每行按時間存儲一只股票一個因子數據，分區方案 VALUE(天)+ HASH(因子名，125)。
以縱表存儲,使用 TSDB 引擎，每行按時間存儲一只股票一個因子數據，分區方案 VALUE(月)+ HASH(因子名，50)， 按股票代碼+時間排序。
以寬表存儲,使用 TSDB 引擎，每行按時間存儲全部股票一個因子，或者一支股票全部因子數據，分區方案VALUE(月)+ HASH(因子名，20)，按因子名+時間排序。
OLAP 引擎是純列式存儲，不適合表過寬，在列數超過80以后，寫入性能會逐漸下降，故不做考慮。
縱表結構：
寬表結構：
5.1 因子存儲
下文中以存儲五個因子一年的分鐘級數據來進行測試，比對這三種存儲模式在數據大小、實際使用的存儲空間、寫入速度等方面的優劣。
從比對結果來看，寬表 TSDB 模式的寫入速度是縱表 OLAP 的4倍，縱表 TSDB 的5倍，存儲空間上寬表 TSDB 和 OLAP 縱表相近，均約為 TSDB 縱表的三分之二，壓縮比上縱表 OLAP 最優，縱表 TSDB 次之，寬表 TSDB 最差。這是因為首先實際產生的數據字節上，縱表模式是寬表模式的三倍，這決定了寬表 TSDB 的的寫入速度最優，磁盤使用空間最優，也導致了寬表 TSDB 模式的壓縮比會相對差一些，另外模擬數據隨機性很多大，也影響了 TSDB 引擎寬表得數據壓縮；其次 TSDB 引擎會進行數據排序，生成索引，所以同樣是縱表，TSDB 引擎在存儲空間、存儲速度、壓縮比方面都要略遜于 OLAP 引擎。
5.2 因子查詢
接下來模擬大數據量來進行查詢測試，模擬 4000 支股票，200 個因子，一年的分鐘級數據，詳細數據信息及分區信息見下面表格：
查詢 1 個因子 1 支股票指定時間點數據
在點查詢上 TSDB 引擎優勢明顯，而寬表 TSDB 因為數據行數少，速度上還要快于縱表 TSDB 模式。
查詢 1 個因子 1 只股票一年分鐘級數據
查詢單因子單股票一年的分鐘級數據寬表 TSDB 引擎速度最快，這是因為 TSDB 引擎分區較大，讀取的文件少，且數據有排序，而 OLAP 引擎本身數據分區較小，需要掃描的行數又同樣不少，所以速度最慢。
查詢 1 個因子全市場股票一年分鐘級數據
寬表 TSDB 讀取速度最快，讀取的總數據量比較大時，這幾種模式都會讀取很多完整分區，而寬表 TSDB 模式因為實際數據比較小，所以速度上是縱表 OLAP 的一半，是縱表 TSDB 的三分之一略多。
查詢 3 個因子全市場股票一年分鐘級數據
更大數據量的數據讀取，查詢耗時線性增長，同樣原因，寬表 TSDB 讀取速度仍然最快。
查詢 1 支股票全部因子一年的分鐘級數據
寬表在進行該查詢時，查詢 SQL 應只選擇需要股票代碼列，SQL 如下：
//縱表查詢sql, 查詢全部字段，使用通配符* tsdb_symbol_all=select * from tsdb_min_factor where symbol=`sz000056 //寬表查詢sql,只檢索部分字段，詳細列出 select?mtime,factorname,sz000001?from?tsdb_wide_min_factor以上結果可以看到，寬表 TSDB 引擎和縱表 TSDB 都可以很快的查出數據，而縱表模式 OLAP 則需要百倍以上的時間才能查詢出數據。這是因為縱表模式 OLAP 的分區字段是時間和因子，這種情況下查詢某只股票所有的因子需要掃描全部分區的全部列才能取出所需的數據；而寬表TSDB引擎只需要取三列數據，所以可以很快查出數據；縱表TSDB引擎可以按股票代碼進行索引檢索所以速度也比較快。
綜上所述，因子的存儲需根據不同的查詢習慣去做規劃。本節中的這些查詢，推薦使用寬表 TSDB 的方式存儲因子。
5.3 在線獲取面板數據
針對不同的存儲模型，在使用時若需要面板數據，DolphinDB 也有在線轉換的方式。
生成1個因子全市場股票一年分鐘級面板數據
寬表 TSDB 模式查詢面板數據時的速度是縱表 OLAP 和縱表 TSDB 的十倍以上，這是因為寬表 TSDB 的數據本身就以類似面板數據的方式存儲，不需要再轉換為面板數據，而縱表模式無論 OLAP 引擎還是 TSDB 引擎查詢出數據后還要使用 pivot by 進行列轉行操作，這個命令要進行數據比對去重、排序等操作，所以會耗費一些時間，在數據量大時，耗時明顯，所以速度會大幅幅度落后于寬表 TSDB 模式。
生成3個因子全市場股票一年分鐘級面板數據
寬表 TSDB 引擎具有最佳的查詢性能，隨著數據量上升，縱表數據列轉行操作要額外增加?piovt by?的列，從而增加更多的去重、排序操作，導致生成面板數據的耗時進一步增加。
使用寬表 TSDB 模式存儲在以下方面給均有明顯優勢：
(1) 存儲空間：雖然寬表 TSDB 在壓縮比上相對遜色，但是由于寬表模式本書數據字節只有縱表模式的三分之一，所以在空間開銷上寬表 TSDB 模式使用最小；
(2) 存儲速度：寬表 TSDB 模式的在寫入相同有效數據的情況下寫入速度是縱表 OLAP 的4倍，縱表 TSDB 的5倍；
(3) 直接檢索數據：寬表TSDB模式在不同場景的查詢速度至少是縱表OLAP和縱表TSDB的1.5倍，甚至可能達到100倍以上；
(4) 以面板模式檢索數據：寬表 TSDB 模式的查詢速度是縱表 OLAP 和縱表 TSDB 的至少10倍以上；
(5) 在以非分區維度檢索數據：例如，按因子分區的按股票檢索數據，此場景寬表TSDB模式查詢速度是縱表 OLAP 和縱表 TSDB 的300倍和500倍。
綜上，如果一定時期內股票和因子數量固定，因子存儲的最佳選擇方式為TSDB寬表的模式進行存儲，用戶可以按實際的查詢習慣，來選擇生成以股票名或因子名做為列的寬表。
6、因子回測和建模
很多時候，計算因子只是投研階段的第一部分，而最重要的部分其實在于如何挑選最為有效的因子。在本章節中，將會講述如何在 DolphinDB中 做因子間的相關性分析，以及回歸分析。
6.1 因子回測
因子的建模和計算等，一旦從圖表上分析出有方向性的結論，就要做成策略。按照確定的因子信號來設計出來的一套買賣條件，就是所謂的投資策略。把一套投資策略代入到歷史數據當中，計算按照這樣的策略條件去做交易是否長期有利可圖的過程就是回測。
事件驅動型回測主要用來分析少量標的，中高頻的交易策略。在按因子配置投資組合的策略類型中不是核心或重點，在這里 DolphinDB 選取了向量化的因子回測作為案例進行說明。
首先，在k線數據上，實現了一個按多日股票收益率連乘打分的因子。之后根據分值排序高低分配標的持倉權重。
得到分配持倉權重后，再與持倉股票的日收益率做矩陣乘法，最后按天相加，可得整個投資組合的回報率變化曲線。
6.2 因子相關性分析
在之前的章節中，存儲因子的庫表可以是多值模型，也可以是單值模型。在求因子間相關性時，推薦利用?array vector?將同一股票同一時間的多個因子放在一個列中，這樣可以避免枚舉多個列名。下面以單值模型為例，演示如何有效地先在股票內求因子間相關性，然后根據股票個數求均值。
單值模型計算因子間自相關性矩陣 其原理是先將當天的因子根據時間和標的，轉換成?array vector?，再對生成的小內存表進行計算求值。
6.3 多因子建模
在大部分場景中，多因子投資模型的搭建可分為：（1）簡單加權法；（2）回歸法；兩種方式均可以在 DolphinDB 中實現。
簡單加權法
對不同的因子不同的權重，計算出所有因子預測的各只股票的預期回報率的加權平均值，然后選擇預期回報率最高的股票。這類方法比較簡單，故不在本小節贅述。
回歸法
在DolphinDB官方發布的機器學習教程中內置了多種線性回歸模型，包括普通最小二乘法回歸（OLS Regression），脊回歸（Ridge Regression），廣義線性模型（Generalized Linear Model）等。目前，普通最小二乘法回歸?olsEx，脊回歸?ridge?中的 'cholesky' 算法，廣義線性模型?glm?都支持分布式并行計算。
其他回歸模型，DolphinDB 支持 Lasso 回歸，ElasticNet 回歸，隨機森林回歸，AdaBoost 回歸等。其中，AdaBoost 回歸?adaBoostRegressor?，?randomForestRegressor?支持分布式并行計算。
7、因子計算的工程化
在實際量化投研過程，研究員要聚焦策略因子研發，而因子計算框架的開發維護通常是IT部門人員來負責，為了加強協作，通常要進行工程化管理。好的工程化管理能減少重復、冗余工作，極大的提高生產效率，使策略投研更加高效。本章節將會通過一些案例來介紹如何對因子計算進行工程化管理。
7.1 代碼管理
因子的開發往往涉及到 QUANT 團隊和 IT 團隊。QUANT 團隊主要負責因子開發和維護因子邏輯代碼；IT 團隊負責因子計算框架的開發和運維。因此要把計算框架的代碼和因子本身的邏輯代碼做到有效的分離，降低耦合，并且可以支持因子開發團隊單獨提交因子邏輯代碼，計算框架能夠自動更新并進行因子重算等任務。本節主要討論因子邏輯代碼管理，計算框架和運維請參考7.3和7.6。
DolphinDB 推薦用戶使用自定義函數來封裝核心的因子邏輯，每個因子對應一個自定義函數。DolphinDB 對自定義函數的管理提供了兩種方法，函數視圖（Function View）和模塊（Module）。函數視圖的優點包括：
（1）集中管理，添加到集群后，所有節點都可以使用；
（2）支持權限管理。
函數視圖的主要缺點是無法進行模塊化管理，當數量增加時，運維難度增加。模塊的優缺點正好同函數視圖相反。模塊可以將大量函數按目錄樹結構組織在不同模塊中。既可以在系統初始化時預加載，也可以在需要使用的時候使用 use 語句，引入這個模塊。但是模塊必須復制到每個需要使用的節點才可以使用，另外無法對模塊中的函數進行權限管理。后續版本會統一函數視圖和模塊的優點。
下文中，DolphinDB分別介紹通過 Module 和 Function View 兩種方式來實現計算框架與因子代碼的分離。
7.1.1 通過 Module 實現代碼分離
對于需要調整和新研發因子的情況，研究員經常需要從自己電腦（Client 端）來執行因子的計算，并對因子計算結果進行檢驗，以及保存數據。這種場景，DolphinDB用戶通常在數據庫 Server 端通過 Module 來部署通用的計算框架，然后研究員通過 python 客戶端發送自己的因子計算方法，調用 Server 端 Module 中計算框架來接收算法，加載對應數據，并進行計算、返回結果。下文具體展示這種需求的 Server 端和 Client 端實現，以及他們聯和運作。
7.1.2 通過 Function View 實現代碼分離
對于已經研發完成，不再需要調試的因子，則通常將因子算法通過 Funciton View 保存到數據庫中，并通過數據庫的Job來對所有保存到數據庫中的因子進行批量調用計算、并保存因子計算結果。大致過程如下：
（1）準備因子腳本，并通過 addFunctionView 將因子腳本保存到數據庫中，保存的 functionview 可以進行權限管理。
（2）在服務端通過腳本循環調用 submitJob 可以批量的創建因子調用任務，實現批量因子調用。
7.2 單元測試
遇到因子代碼重構、計算框架調整、數據庫升級等情況，必須對最基本的因子邏輯進行正確性測試。DolphinDB內置了單元測試框架，可用于自動化測試。
這個單元測試框架主要包含了以下內容：
test?函數，可以測試一個單元測試文件或一個目錄下的所有單元測試文件。
@testing 宏，用于描述一個測試case。
assert 語句，判斷結果是否符合預期。
eqObj 等函數，用于測試結果是否符合預期。
下面通過對因子函數factorDoubleEMA的測試來展示單元測試的撰寫。代碼中展示了三個測試cases，兩個用于批處理，一個用于流計算處理。
@testing: case = "factorDoubleEMA_without_null" re = factorDoubleEMA(0.1 0.1 0.2 0.2 0.15 0.3 0.2 0.5 0.1 0.2) assert 1, eqObj(re, NULL NULL NULL NULL NULL 5.788743 -7.291889 7.031123 -24.039933 -16.766359, 6)@testing: case = "factorDoubleEMA_with_null" re = factorDoubleEMA(NULL 0.1 0.2 0.2 0.15 NULL 0.2 0.5 0.1 0.2) assert 1, eqObj(re, NULL NULL NULL NULL NULL NULL 63.641310 60.256608 8.156385 -0.134531, 6)@testing: case = "factorDoubleEMA_streaming" try{dropStreamEngine("factorDoubleEMA")}catch(ex){} input = table(take(1, 10) as id, 0.1 0.1 0.2 0.2 0.15 0.3 0.2 0.5 0.1 0.2 as price) out = table(10:0, `id`price, [INT,DOUBLE]) rse = createReactiveStateEngine(name="factorDoubleEMA", metrics=<factorDoubleEMA(price)>, dummyTable=input, outputTable=out, keyColumn='id') rse.append!(input) assert 1, eqObj(out.price, NULL NULL NULL NULL NULL 5.788743 -7.291889 7.031123 -24.039933 -16.766359, 6)7.3 并行計算
到現在為止，上文討論的都是因子的核心邏輯實現，尚未涉及通過并行計算或分布式計算來加快計算速度的問題。在因子計算的工程實踐中，可以通過并行來加速的維度包括：證券（股票），因子和時間。
在DolphinDB中，實現并行（或分布式）計算的技術路徑有以下4個途徑。
通過SQL語句來實現隱式的并行計算。當SQL語句作用于一個分布式表時，引擎會盡可能下推計算到各個分區執行。
創建多個數據源（data source），然后使用mr函數（map reduce）來實現并行計算。
用戶通過?submitJob?或?submitJobEx?提交多個任務。
用 peach 或 ploop 實現并行。
DolphinDB 不建議在因子計算中采用 peach 或 ploop 的方式來實現并行。DolphinDB 中可用于計算的線程分為兩類，分別稱之為 worker 和 executor。一般 worker 用于接受一個任務（job），并將任務分解成多個子任務（task）在本地的 executor 或遠程的 worker 上執行。一般executor執行的都是本地的耗時比較短的子任務，也就是說在 executor 上執行的任務一般不會再分解出子任務。peach 或 ploop 將所有的子任務都在本地的 exeuctor 執行。如果子任務本身再分解出子任務（譬如子任務是一個分布式 SQL Query），將嚴重影響整個系統的吞吐量。
下文將討論前三種方法在因子并行計算中的應用。
7.3.1 分布式SQL
分布式SQL的第一個應用是計算無狀態的因子。對于無狀態的因子，即計算本身可能只涉及單條記錄內一個或者幾個字段。這樣的計算可以利用分布式表的機制，在各分區內并行計算。
以第三章中的權重偏度因子為例，此因子計算只用了一個字段，且計算邏輯不涉及前后數據，所以在SQL中調用時，DolphinDB會自動在各分區內并行計算。如果目標數據是內存表，可以使其變為內存分區表，使之分布式并行計算。內存分區表的創建，參考?createPartitionedTable。
resWeight = select TradeTime, SecurityID, `mathWghtSkew as factorname, mathWghtSkew(BidPrice, w) as val from loadTable("dfs://LEVEL2_Snapshot_ArrayVector","Snap") where date(TradeTime) = 2020.01.02分布式 SQL 的第二個應用場景是計算按標的分組的時序相關因子。對于組內計算的因子，在 SQL 模式中，將組字段設為分區字段，可以用?context by?組字段并行。如若計算涉及到的數據不跨分區，則可以用 map 語句，加速結果輸出。如若計算涉及到的數據跨分區，則 SQ L會在分區內并行計算，最后在結果部分檢查再合并。
以日內收益率偏度的因子?dayReturnSkew?計算為例， 這個計算本身是需要對標的分組，在組內每天分別做計算。涉及到的數據為分鐘頻數據，數據源是按月分區，標的 HASH 3 分區。因此，做計算時除了可以用?context by?組字段并行以外，還可以用 map 語句加速輸出結果。
minReturn = select `dayReturnSkew as factorname, dayReturnSkew(close) as val from loadTable("dfs://k_minute_level", "k_minute") where date(tradetime) between 2020.01.02 : 2020.01.31 group by date(tradetime) as tradetime, securityid map7.3.2 map reduce
當用戶不想根據分區做并行計算時，可以通過 mr 函數自定義做并行計算。
以第三章中介紹的 factorDoubleEMA 因子為例。DoubleEMA 因子的計算是對標的分組，在組內連續做窗口計算。此類計算由于將窗口的劃分會跨時間分區，所以在 SQL 計算中會先在分區內做計算，然后最后合并再做一次計算，耗時會比較長。
更合理的做法是，如果分區只按照標的分區，那么計算就可以直接在分區內做完而不用合并檢查最終結果了。此時可以用?repartitionDS?函數先將原本的數據重新分區再通過 map reduce 的方式做并行計算。
//將原數據按股票重新10個HASH分區 ds = repartitionDS(<select * from loadTable("dfs://k_minute_level", "k_minute") where date(tradetime) between 2020.01.02 : 2020.03.31>, `securityid, HASH,10)def factorDoubleEMAMap(table){ return select tradetime, securityid, `doubleEMA as factorname, factorDoubleEMA(close) as val from table context by securityid map }res = mr(ds,factorDoubleEMAMap,,unionAll)7.3.3 通過submitJob提交任務
之前的兩種并行計算都是在前臺執行的，并行度是由參數?localExecutors?設置。而有些作業可能很大，或者用戶不想影響前臺使用，此時可以通過?submitJob?提交任務。submitJob?的并行度由?maxBatchJobWorker?參數設置。由于后臺作業之間是獨立的，通常不需要返回到前端的任務都推薦用后臺提交 submitJob 的形式。
仍舊以 dayReturnSkew 因子為例。通常需要將因子寫入因子庫表，此時可以將整一個過程提交幾個后臺作業去執行，而在客戶端中，同時可以繼續做其他計算。由于此例存入的因子庫的分區是按月和因子名 VALUE 分區，故此時應按照月份去提交作業。這樣既可以并行寫入不會沖突，又可以將作業提交到后臺，不影響前臺提交其他任務。
def writeDayReturnSkew(dBegin,dEnd){dReturn = select `dayReturnSkew as factorname, dayReturnSkew(close) as val from loadTable("dfs://k_minute_level", "k_minute") where date(tradetime) between dBegin : dEnd group by date(tradetime) as tradetime, securityid //寫入因子庫 loadTable("dfs://K_FACTOR_VERTICAL","factor_k").append!(dReturn)}for (i in 0..11){dBegin = monthBegin(temporalAdd(2020.01.01,i,"M"))dEnd = monthEnd(temporalAdd(2020.01.01,i,"M"))submitJob("writeDayReturnSkew","writeDayReturnSkew_"+dBegin+"_"+dEnd, writeDayReturnSkew,dBegin,dEnd) }7.4 內存管理
在配置 DolphinDB 后端環境時，計算和事務的內存占用可在單節點的 ”dolphindb.cfg” 或集群的 cluster.cfg（以下簡稱“節點配置文件”）中，通過參數”maxMemSize“配置單節點最大占用內存。
在調試大任務量的計算完成后，可通過 undef 函數將變量賦值為 NULL，或者關閉 session 來及時釋放變量的內存。
章節3.2中的例子，對半年的快照數據做操作，批處理方式的中間變量占用內存達到21GB，如果設置的內存小于21GB，則報Out of Memory錯誤。這種情況下可以將作業拆分后再提交寫入。
更多有關內存管理的詳細內容，請參閱DolphinDB內存管理教程。
7.5 權限管理
因子數據是非常重要的數據，并不是每一個用戶都可以隨意訪問所有因子的，所以要對因子數據做好權限管理。DolphinDB database 提供了強大、靈活、安全的權限控制系統，可以滿足因子庫表級，函數視圖級的管理。控制節點（controller）作為權限管理中心，使用RSA加密方式對用戶關鍵信息進行加密。DolphinDB的權限管理主要有以下功能，可以方便研究員和運維人員安全有效的管理權限：
提供用戶和組角色，方便權限控制
提供9種權限控制類別，適應各種場景
豐富的權限控制函數
函數視圖兼顧保護數據隱私與提供分析結果
對任務調度和流數據任務動態鑒權，保證系統安全
使用RSA對用戶關鍵信息加密
支持SSO，簡化登錄，方便系統擴展
更多有關權限管理的詳細內容，請參閱DolphinDB權限管理和安全教程。
7.6 任務管理
因子計算的任務通常分為全量計算所有因子任務、交互式單因子重算任務、所有因子增量計算任務這三種，本章會對每一種因子計算任務進行詳細介紹。
因子任務可以通過以下三種方式執行:
通過交互的方式執行。
?通過 submitJob ? 提交一個Job來執行。
通過 scheduleJob ? 提交一個定時任務來進行周期性的執行。
7.6.1 全量計算
因子的全量跑批任務，通常是系統初始化因子數據時的一次性任務，或者較長周期進行一次的任務，這類任務可以通過單次觸發或者定時任務(scheduleJob)的方式進行管理。
單次觸發的任務：建議通過submitJob?函數提交任務。通過submitJob?提交的任務，會提交到服務器的Job 隊列中執行，不再受客戶端影響。可以通過 getRecentJobs 觀察任務是否完成。
周期性任務：如果計算的因子頻率較低需要每天盤后或者其他周期定期全部重算一次，可以使用定時任務(ScheduleJob)的方式進行管理。
7.6.2 因子運維管理
在因子研發過程中，當碰到因子算法、參數調整的情況，需要對該因子進行重新計算，同時需要將計算的新的因子數據更新到數據庫中，對于不同更新的頻率的因子，通常有以下兩種方式：
因子的數據頻率較高，因子的總數據量較大
因子的數據頻率較高，數據量很大時，推薦在因子數據分區時拉長時間維度，以因子名進行VALUE分區。這樣可以使每個因子的數據獨立的保存在一個分區中，控制分區大小在一個合適的范圍。當用戶碰到因子重算的情況，便可以用dropPartition函數先刪除這個因子所對應的分區數據，然后直接重算這個因子并保存到數據表中。
因子的數據頻率較低，因子的總數據量較小
當因子的數據頻率較低，因子的總數據量較小時，如若將每個因子劃分為獨立的分區會使得每個分區特別小，而過小的分區可能會影響寫入速度。這種情況下，可以按照因子 HASH 分區。使用?update!?來進行因子數據更新操作，或使用 upsert 來進行插入更新操作。此外，對于 TSDB 引擎，可以設置參數?keepDuplicates=LAST?, 此時可以直接使用append!或者?tableInsert?插入數據，從而達到效率更高的更新數據的效果。
update!?,?upsert?以及 TSDB 引擎特殊設置下的直接?append!?覆蓋數據，這三種更新操作都建議在數據量較小，且更新不頻繁的情況下使用。對于需要大量因子重算的數據更新的場景，DolphinDB 推薦使用單因子獨立分區的方式。當因子重算時先用dropPartition函數刪除因子所在分區，再重算寫入新因子入庫。
總 結
用DolphinDB來進行因子的計算時，可選擇面板和SQL兩種方式來封裝因子的核心邏輯。面板方式使用矩陣來計算因子，實現思路非常簡練；而SQL方式要求投研人員使用向量化的思路進行因子開發。無論哪種方式，DolphinDB均支持批流一體的實現。DolphinDB內置了相關性和回歸分析等計算工具，可分析因子的有效性，可對多因子建模。
在因子庫的規劃上，如果追求靈活性，建議采用單值縱表模型。如果追求效率和性能，推薦使用TSDB引擎，啟用多值寬表模式，標的（股票代碼）作為表的列。
最后，基于大部分團隊的IT和投研相對獨立的事實，給出了在代碼管理上的工程化方案，投研團隊通過模塊和自定義函數封裝核心因子業務邏輯，IT團隊則維護框架代碼。同時利用權限模塊有效隔離各團隊之間的數據訪問權限。
長按上方海報識別二維碼即可參與活動
總結
以上是生活随笔為你收集整理的从计算、建模到回测：因子挖掘的最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Hbase 操作命令
- 下一篇： 软件项目管理和软件工程的区别