1. 金融數(shù)據(jù)服務(wù)從零搭建的完整思路1.1 這個項目到底在做什么第一次看到financial-services這個命名的時候我腦子里蹦出來的第一個念頭就是這又是一個把行情、財報、宏觀數(shù)據(jù)揉在一起往外吐的聚合服務(wù)。事實也確實如此。這類項目的核心目標(biāo)非常明確——把散落在不同源頭、格式五花八門的金融數(shù)據(jù)經(jīng)過清洗、對齊、緩存之后用一套統(tǒng)一的接口暴露出去讓上層的量化策略、看板、風(fēng)控系統(tǒng)或者個人研究腳本都能直接消費(fèi)。它解決的問題其實很樸素。做過金融數(shù)據(jù)的人都知道原始數(shù)據(jù)有多臟時間戳?xí)r區(qū)不統(tǒng)一、字段命名一會兒駝峰一會兒下劃線、停牌日缺失、復(fù)權(quán)因子對不上、財報口徑隔年就變。如果每個消費(fèi)方都自己去對接、自己去清洗那就是重復(fù)造輪子而且每個人造的輪子還都不一樣。financial-services這類項目的價值就在于做那個中間層把臟活累活收斂到一處。適合誰來參考呢我的判斷是三類人一是想給自己量化策略搭一套穩(wěn)定數(shù)據(jù)源的個人開發(fā)者二是在小團(tuán)隊里負(fù)責(zé)數(shù)據(jù)基建、需要快速交付一個可用數(shù)據(jù)服務(wù)的后端工程師三是做金融類產(chǎn)品、需要理解數(shù)據(jù)鏈路全貌的產(chǎn)品或分析師。哪怕你只是想搞清楚行情數(shù)據(jù)從交易所到我的屏幕中間經(jīng)歷了什么跟著這個思路走一遍也會有收獲。1.2 為什么選擇服務(wù)化而不是腳本化很多人一開始是寫腳本的一個fetch_data.py跑定時任務(wù)把數(shù)據(jù)存進(jìn) CSV 或者 SQLite用的時候直接讀文件。這個方案在數(shù)據(jù)量小、只有自己用的時候完全沒問題我自己早期也是這么干的。但一旦出現(xiàn)下面幾種情況腳本方案就會迅速崩掉多個消費(fèi)方同時要數(shù)據(jù)文件鎖、并發(fā)讀寫問題開始冒頭數(shù)據(jù)源接口有頻率限制腳本各自為戰(zhàn)導(dǎo)致被限流需要做權(quán)限控制不同的人只能看不同的數(shù)據(jù)數(shù)據(jù)要實時更新腳本的批處理延遲滿足不了。服務(wù)化的本質(zhì)是把數(shù)據(jù)獲取和數(shù)據(jù)消費(fèi)解耦。消費(fèi)方不再關(guān)心數(shù)據(jù)從哪來、怎么清洗只關(guān)心接口穩(wěn)不穩(wěn)定、字段全不全。這個解耦帶來的好處是巨大的數(shù)據(jù)源換了消費(fèi)方無感知清洗邏輯改了只改一處要加緩存、加限流、加監(jiān)控都有統(tǒng)一的切入點(diǎn)。從架構(gòu)選型上講我傾向于分層設(shè)計而不是把所有邏輯塞進(jìn)一個進(jìn)程。典型的分層是這樣的層級職責(zé)常見實現(xiàn)接入層對外暴露 HTTP/RPC 接口做鑒權(quán)、限流Web 框架 網(wǎng)關(guān)服務(wù)層業(yè)務(wù)邏輯字段組裝、口徑轉(zhuǎn)換業(yè)務(wù)代碼數(shù)據(jù)層統(tǒng)一讀寫屏蔽底層存儲差異ORM / 數(shù)據(jù)訪問對象采集層對接外部數(shù)據(jù)源定時拉取調(diào)度器 采集任務(wù)存儲層持久化熱數(shù)據(jù)緩存關(guān)系庫 緩存 時序庫這么分的好處是每一層都能獨(dú)立演進(jìn)。比如某天你發(fā)現(xiàn)某個數(shù)據(jù)源不穩(wěn)定只需要在采集層加個備用源服務(wù)層和接入層完全不用動。這種改動局部化的能力是服務(wù)化相比腳本化最實在的收益。1.3 數(shù)據(jù)源選型的取舍邏輯金融數(shù)據(jù)源大致分幾類公開免費(fèi)接口、商業(yè)數(shù)據(jù)供應(yīng)商、自建采集。選型的時候不能只看免費(fèi)不免費(fèi)要綜合看穩(wěn)定性、字段完整度、歷史深度、更新頻率和合規(guī)性。免費(fèi)公開接口的優(yōu)點(diǎn)是零成本、上手快缺點(diǎn)是穩(wěn)定性沒保證、字段經(jīng)常缺、歷史數(shù)據(jù)淺、還有調(diào)用頻率限制。商業(yè)供應(yīng)商字段全、歷史深、有 SLA但成本高而且不同供應(yīng)商的口徑不一樣切換成本不低。自建采集最靈活但維護(hù)成本高還要處理反爬、數(shù)據(jù)校驗等一堆事。我的經(jīng)驗是分層組合核心的、高頻的、對穩(wěn)定性要求高的數(shù)據(jù)比如日線行情用商業(yè)源或者自建邊緣的、低頻的、錦上添花的數(shù)據(jù)比如某些宏觀指標(biāo)用免費(fèi)源并且做好降級預(yù)案。關(guān)鍵是所有數(shù)據(jù)源都要經(jīng)過同一套清洗和校驗流程不能讓上游的差異滲透到下游。提示無論用哪種數(shù)據(jù)源一定要在采集層做原始數(shù)據(jù)落地。也就是拉回來的原始報文先原樣存一份再做清洗。這樣一旦清洗邏輯有 bug可以重放原始數(shù)據(jù)修復(fù)而不用重新去拉。這個習(xí)慣幫我省過無數(shù)次事。2. 核心模塊拆解與關(guān)鍵實現(xiàn)細(xì)節(jié)2.1 數(shù)據(jù)模型設(shè)計字段口徑統(tǒng)一是命門金融數(shù)據(jù)服務(wù)最容易翻車的地方不是技術(shù)而是口徑。同一個收盤價不同數(shù)據(jù)源可能一個是未復(fù)權(quán)、一個是前復(fù)權(quán)、一個是后復(fù)權(quán)同一個凈利潤可能是歸母、可能是扣非、可能是單季、可能是累計。如果數(shù)據(jù)模型不把這些維度顯式建模出來下游用的時候必然踩坑。我的做法是在數(shù)據(jù)模型里強(qiáng)制帶上口徑標(biāo)簽。以行情為例一條 K 線記錄至少包含這些字段symbol標(biāo)的代碼統(tǒng)一成帶市場前綴的格式比如SH600000、SZ000001trade_date交易日統(tǒng)一成YYYY-MM-DD不帶時區(qū)歧義open/high/low/close價格明確標(biāo)注是否復(fù)權(quán)volume/amount成交量和成交額單位統(tǒng)一股/手、元/千元要寫清楚adjust_type復(fù)權(quán)類型none/qfq/hfqsource數(shù)據(jù)來源標(biāo)識方便追溯updated_at這條記錄的更新時間。把a(bǔ)djust_type和source顯式建?？雌饋硎切∈碌寯?shù)據(jù)可追溯成為可能。下游發(fā)現(xiàn)某個價格不對能立刻定位到是哪個源、哪種復(fù)權(quán)口徑出的問題。財報數(shù)據(jù)更復(fù)雜我一般會拆成三張表利潤表、資產(chǎn)負(fù)債表、現(xiàn)金流量表每張表用report_date報告期和announce_date公告日雙時間戳。為什么要兩個時間因為做回測的時候必須用當(dāng)時能看到的數(shù)據(jù)也就是按announce_date對齊否則就是未來函數(shù)回測結(jié)果全是假的。這個坑我見過太多人踩。2.2 采集調(diào)度別讓定時任務(wù)變成定時炸彈采集層最常見的實現(xiàn)是定時任務(wù)但定時任務(wù)有幾個經(jīng)典陷阱任務(wù)重疊、失敗無重試、單點(diǎn)故障、時間漂移。任務(wù)重疊是指上一次還沒跑完下一次又啟動了導(dǎo)致同一份數(shù)據(jù)被重復(fù)寫入或者互相覆蓋。解決辦法是加分布式鎖或者任務(wù)狀態(tài)標(biāo)記確保同一任務(wù)同一時刻只有一個實例在跑。我用過最簡單的方案是基于數(shù)據(jù)庫的唯一約束任務(wù)開始前插入一條帶唯一鍵的運(yùn)行記錄插入失敗就說明有實例在跑直接退出。失敗重試要區(qū)分可重試和不可重試。網(wǎng)絡(luò)超時、限流這種是暫時性的可以指數(shù)退避重試字段解析失敗、數(shù)據(jù)校驗不通過這種是邏輯性的重試多少次都沒用應(yīng)該直接告警。把這兩類分開處理能避免無意義的重復(fù)勞動。時間漂移是指任務(wù)實際執(zhí)行時間和預(yù)期時間越來越偏。比如你設(shè)了每天 8 點(diǎn)跑但任務(wù)本身耗時波動累積下來可能跑到 9 點(diǎn)。對于金融數(shù)據(jù)很多源在特定時間點(diǎn)更新錯過窗口就得等第二天。我的做法是任務(wù)只負(fù)責(zé)觸發(fā)具體拉取邏輯根據(jù)當(dāng)前時間動態(tài)決定拉哪個區(qū)間而不是寫死。# 采集任務(wù)的核心骨架示意 def run_collection(task_name, fetch_fn, store_fn, lock): if not lock.acquire(task_name): return # 已有實例在跑直接退出 try: raw fetch_fn() # 拉取原始數(shù)據(jù) persist_raw(raw) # 原始數(shù)據(jù)先落地 cleaned clean(raw) # 清洗 validate(cleaned) # 校驗不通過就拋異常 store_fn(cleaned) # 入庫 lock.release(task_name, successTrue) except TransientError as e: lock.release(task_name, successFalse) schedule_retry(task_name, backoffTrue) # 暫時性錯誤重試 except FatalError as e: lock.release(task_name, successFalse) alert(task_name, e) # 邏輯性錯誤告警2.3 緩存策略熱數(shù)據(jù)放內(nèi)存冷數(shù)據(jù)落盤金融數(shù)據(jù)服務(wù)的讀請求往往遠(yuǎn)多于寫請求而且有明顯的冷熱分布。當(dāng)天的行情、最近的財報被反復(fù)查詢幾年前的日線可能一個月才被翻一次。針對這種分布緩存策略要分層。熱數(shù)據(jù)放內(nèi)存緩存設(shè)置合理的過期時間。行情類數(shù)據(jù)在交易時段更新頻繁過期時間可以短一些比如幾十秒到幾分鐘財報類數(shù)據(jù)更新頻率低過期時間可以長一些幾小時甚至一天。冷數(shù)據(jù)直接落盤查詢時走數(shù)據(jù)庫必要時加一層磁盤緩存。這里有個容易忽略的點(diǎn)緩存鍵的設(shè)計。如果緩存鍵只包含symbol那不同復(fù)權(quán)類型、不同時間區(qū)間的請求會互相污染。緩存鍵必須包含所有影響結(jié)果的參數(shù)比如symbol adjust_type start_date end_date fields。鍵太長會影響性能可以用哈希壓縮但要保證唯一性。注意緩存和數(shù)據(jù)庫的一致性是永恒的話題。我的原則是緩存只做加速不做真相來源。任何寫操作先落庫再失效緩存絕不先寫緩存。這樣即使緩存出問題數(shù)據(jù)也不會丟。2.4 接口設(shè)計讓消費(fèi)方用得舒服接口設(shè)計的好壞直接決定這個服務(wù)好不好用。我見過太多數(shù)據(jù)服務(wù)字段命名隨心所欲錯誤碼含義不明分頁參數(shù)一會兒是page一會兒是offset用起來極其痛苦。我的接口設(shè)計原則有這么幾條。第一字段命名統(tǒng)一風(fēng)格要么全下劃線要么全駝峰別混著來。第二時間參數(shù)統(tǒng)一格式我一般用YYYY-MM-DD表示日期用 ISO8601 表示時間戳。第三分頁統(tǒng)一用limit offset或者游標(biāo)別兩套并存。第四錯誤響應(yīng)結(jié)構(gòu)化包含錯誤碼、錯誤信息、可能的解決建議。一個典型的行情查詢接口大概長這樣GET /api/v1/quotes?symbolSH600000start2024-01-01end2024-03-31adjustqfqfieldsopen,high,low,close,volume響應(yīng)體里除了數(shù)據(jù)我還會帶上元信息比如數(shù)據(jù)來源、最后更新時間、是否命中緩存。這些元信息對排查問題特別有用消費(fèi)方一看就知道拿到的數(shù)據(jù)新不新、從哪來的。3. 完整實操流程與關(guān)鍵環(huán)節(jié)落地3.1 環(huán)境準(zhǔn)備與依賴安裝假設(shè)我們從零開始搭一個最小可用的版本。技術(shù)棧我選 Python 生態(tài)因為金融數(shù)據(jù)處理相關(guān)的庫最全上手也快。Web 框架用 FastAPI異步性能好自帶文檔數(shù)據(jù)庫用 PostgreSQL對時間序列和復(fù)雜查詢支持都不錯緩存用 Redis調(diào)度用 APScheduler 或者 Celery Beat。先建虛擬環(huán)境把依賴裝好python -m venv venv source venv/bin/activate pip install fastapi uvicorn sqlalchemy psycopg2-binary redis apscheduler pandas numpy requests pydantic數(shù)據(jù)庫和 Redis 我建議用容器起省得污染本機(jī)環(huán)境docker run -d --name fin-pg -e POSTGRES_PASSWORDsecret -p 5432:5432 postgres:16 docker run -d --name fin-redis -p 6379:6379 redis:7這套環(huán)境跑起來一臺普通開發(fā)機(jī)綽綽有余。生產(chǎn)環(huán)境的話數(shù)據(jù)庫要做主從Redis 要做持久化調(diào)度器要做高可用這些后面再說。3.2 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計行情表我一般這么建CREATE TABLE quotes ( id BIGSERIAL PRIMARY KEY, symbol VARCHAR(16) NOT NULL, trade_date DATE NOT NULL, adjust_type VARCHAR(8) NOT NULL DEFAULT none, open NUMERIC(18, 4), high NUMERIC(18, 4), low NUMERIC(18, 4), close NUMERIC(18, 4), volume BIGINT, amount NUMERIC(24, 4), source VARCHAR(32), updated_at TIMESTAMPTZ DEFAULT NOW(), UNIQUE (symbol, trade_date, adjust_type) ); CREATE INDEX idx_quotes_symbol_date ON quotes (symbol, trade_date);那個唯一約束(symbol, trade_date, adjust_type)很關(guān)鍵它保證了同一標(biāo)的同一天同一種復(fù)權(quán)口徑只有一條記錄重復(fù)采集時用ON CONFLICT DO UPDATE就能實現(xiàn)冪等寫入不用先刪后插。財報表我拆成三張以利潤表為例CREATE TABLE income_statement ( id BIGSERIAL PRIMARY KEY, symbol VARCHAR(16) NOT NULL, report_date DATE NOT NULL, announce_date DATE NOT NULL, revenue NUMERIC(24, 4), net_profit NUMERIC(24, 4), net_profit_deducted NUMERIC(24, 4), source VARCHAR(32), updated_at TIMESTAMPTZ DEFAULT NOW(), UNIQUE (symbol, report_date, source) ); CREATE INDEX idx_income_announce ON income_statement (symbol, announce_date);注意announce_date上的索引回測時按公告日查詢是高頻操作這個索引能省很多時間。3.3 采集任務(wù)的實現(xiàn)采集任務(wù)的核心是拉取-清洗-校驗-入庫四步。我以日線行情為例寫一個可復(fù)用的骨架import pandas as pd from datetime import date, timedelta def fetch_daily_quotes(symbol, start, end): 從數(shù)據(jù)源拉取原始數(shù)據(jù)返回 DataFrame # 這里對接具體數(shù)據(jù)源示意用 raw data_source.get_kline(symbol, start, end) return pd.DataFrame(raw) def clean_quotes(df): 清洗統(tǒng)一字段名、類型、去重 df df.rename(columns{ date: trade_date, vol: volume, turnover: amount }) df[trade_date] pd.to_datetime(df[trade_date]).dt.date df[symbol] df[symbol].str.upper() df df.drop_duplicates(subset[symbol, trade_date]) return df def validate_quotes(df): 校驗價格非負(fù)、高低價關(guān)系合理、成交量非負(fù) assert (df[close] 0).all(), 存在負(fù)價格 assert (df[high] df[low]).all(), 最高價低于最低價 assert (df[volume] 0).all(), 存在負(fù)成交量 return True def store_quotes(df, adjust_typenone, sourcedemo): 冪等寫入 for _, row in df.iterrows(): upsert_quote(row, adjust_type, source)這里有幾個實操細(xì)節(jié)值得說。第一validate_quotes里的斷言不是擺設(shè)是真正的防線。我遇到過數(shù)據(jù)源返回的high小于low的情況如果不校驗直接入庫下游算出來的技術(shù)指標(biāo)全是錯的。第二清洗和校驗要分開清洗負(fù)責(zé)格式校驗負(fù)責(zé)邏輯職責(zé)清晰才好排查。第三入庫用 upsert 而不是 insert保證重復(fù)跑任務(wù)不會產(chǎn)生臟數(shù)據(jù)。3.4 服務(wù)接口的實現(xiàn)接口層用 FastAPI 寫起來很清爽from fastapi import FastAPI, Query, HTTPException from datetime import date app FastAPI(titleFinancial Services API) app.get(/api/v1/quotes) async def get_quotes( symbol: str Query(..., description標(biāo)的代碼如 SH600000), start: date Query(...), end: date Query(...), adjust: str Query(none, regex^(none|qfq|hfq)$), fields: str Query(open,high,low,close,volume), ): cache_key fq:{symbol}:{start}:{end}:{adjust}:{fields} cached redis_client.get(cache_key) if cached: return {data: json.loads(cached), meta: {cached: True}} rows query_quotes(symbol, start, end, adjust, fields.split(,)) if not rows: raise HTTPException(status_code404, detail無數(shù)據(jù)) redis_client.setex(cache_key, 60, json.dumps(rows)) return {data: rows, meta: {cached: False, source: db}}這個接口有幾個設(shè)計點(diǎn)。參數(shù)校驗用Query的regex約束復(fù)權(quán)類型非法值直接 400不用進(jìn)業(yè)務(wù)邏輯。緩存鍵包含所有影響結(jié)果的參數(shù)避免污染。返回體帶meta字段標(biāo)明是否命中緩存方便調(diào)試。緩存過期時間設(shè) 60 秒交易時段夠用非交易時段其實可以更長但統(tǒng)一設(shè)短一點(diǎn)更省心。3.5 調(diào)度配置調(diào)度我用 APScheduler配置簡單適合中小規(guī)模from apscheduler.schedulers.blocking import BlockingScheduler from apscheduler.triggers.cron import CronTrigger scheduler BlockingScheduler() # 每個交易日收盤后拉取日線 scheduler.add_job( collect_daily_quotes, CronTrigger(day_of_weekmon-fri, hour16, minute30), iddaily_quotes, max_instances1, # 防止任務(wù)重疊 misfire_grace_time3600, # 錯過窗口1小時內(nèi)仍執(zhí)行 ) scheduler.start()max_instances1是防重疊的關(guān)鍵參數(shù)misfire_grace_time處理任務(wù)錯過執(zhí)行窗口的情況。這兩個參數(shù)不設(shè)定時任務(wù)遲早出問題。4. 常見問題排查與避坑經(jīng)驗實錄4.1 數(shù)據(jù)不一致的排查思路數(shù)據(jù)不一致是金融數(shù)據(jù)服務(wù)最頭疼的問題。表現(xiàn)可能是同一個標(biāo)的同一天的價格接口返回的和數(shù)據(jù)庫里的對不上或者兩個接口返回的同一字段值不同。排查我一般按這個順序走。第一步確認(rèn)是不是緩存問題直接查數(shù)據(jù)庫對比。第二步確認(rèn)是不是復(fù)權(quán)口徑問題檢查請求參數(shù)里的adjust。第三步確認(rèn)是不是數(shù)據(jù)源本身的問題看原始落地數(shù)據(jù)。第四步確認(rèn)是不是并發(fā)寫入導(dǎo)致的看updated_at時間戳。我整理了一個速查表現(xiàn)象可能原因排查方法接口值與庫值不符緩存未失效清緩存后重查同標(biāo)的不同復(fù)權(quán)值混淆緩存鍵缺 adjust檢查緩存鍵構(gòu)造歷史數(shù)據(jù)被覆蓋采集任務(wù)重疊查任務(wù)運(yùn)行記錄財報數(shù)據(jù)對不上報告期/公告期混用確認(rèn)查詢用的是哪個時間價格明顯異常數(shù)據(jù)源臟數(shù)據(jù)查原始落地數(shù)據(jù)提示我強(qiáng)烈建議在服務(wù)里加一個數(shù)據(jù)質(zhì)量巡檢任務(wù)每天定時跑一批校驗規(guī)則比如價格連續(xù)性、成交量突變、財報勾稽關(guān)系。發(fā)現(xiàn)問題主動告警比等用戶反饋強(qiáng)得多。4.2 性能瓶頸的定位與優(yōu)化數(shù)據(jù)服務(wù)跑一段時間后性能問題會逐漸顯現(xiàn)。常見的瓶頸有這么幾個數(shù)據(jù)庫慢查詢、緩存命中率低、接口序列化開銷大、采集任務(wù)拖垮數(shù)據(jù)庫。數(shù)據(jù)庫慢查詢最常見的原因是缺索引或者索引沒走對。用EXPLAIN ANALYZE看執(zhí)行計劃如果出現(xiàn)全表掃描基本就是索引問題。行情表按(symbol, trade_date)建索引后單標(biāo)的區(qū)間查詢應(yīng)該走索引掃描如果沒走檢查查詢條件里的類型是否匹配比如trade_date是DATE類型傳字符串可能導(dǎo)致隱式轉(zhuǎn)換而放棄索引。緩存命中率低往往是緩存鍵設(shè)計不合理或者過期時間太短。我一般會統(tǒng)計緩存命中率低于 70% 就要審視緩存策略。有時候是查詢參數(shù)太發(fā)散比如用戶傳的fields順序不同導(dǎo)致緩存鍵不同這種情況可以在構(gòu)造緩存鍵前對參數(shù)做規(guī)范化。采集任務(wù)拖垮數(shù)據(jù)庫通常是因為批量寫入沒控制好。我的做法是分批寫入每批幾百到幾千條批間加短暫 sleep給數(shù)據(jù)庫喘息的機(jī)會。另外采集任務(wù)盡量避開業(yè)務(wù)高峰比如放在凌晨。4.3 數(shù)據(jù)源切換的平滑過渡數(shù)據(jù)源不是一成不變的供應(yīng)商漲價、接口下線、質(zhì)量下降都可能需要切換。切換最怕的是一刀切新源一上歷史數(shù)據(jù)對不上下游全亂。平滑過渡的做法是雙寫雙讀對比。新源接入后先不切換消費(fèi)方而是讓新舊兩個源同時采集寫進(jìn)不同的表或者帶不同的source標(biāo)識。然后跑一個對比任務(wù)逐條比對兩個源的數(shù)據(jù)差異差異在可接受范圍內(nèi)的字段才切換。切換時也不是全量切而是按標(biāo)的、按時間段逐步切觀察一段時間沒問題再全量。這個過程中source字段的價值就體現(xiàn)出來了。消費(fèi)方如果發(fā)現(xiàn)數(shù)據(jù)異常能立刻知道是哪個源的數(shù)據(jù)方便定位。4.4 幾個我踩過的坑第一個坑是時區(qū)。早期我沒在意時區(qū)數(shù)據(jù)源返回的是 UTC 時間我當(dāng)成北京時間存了結(jié)果所有時間戳差了 8 小時。行情數(shù)據(jù)還好財報的公告時間差 8 小時可能就跨天了回測直接錯位。后來我統(tǒng)一規(guī)定所有入庫時間戳一律用帶時區(qū)的TIMESTAMPTZ展示時再轉(zhuǎn)本地時區(qū)。第二個坑是浮點(diǎn)數(shù)精度。價格用FLOAT存累加計算后出現(xiàn)0.30000000000000004這種結(jié)果。金融數(shù)據(jù)對精度敏感必須用NUMERIC或者DECIMAL別圖省事用浮點(diǎn)。第三個坑是停牌處理。停牌日數(shù)據(jù)源可能返回空也可能返回前收盤價填充。如果不區(qū)分算出來的收益率會失真。我的做法是顯式記錄停牌狀態(tài)停牌日的行情標(biāo)記出來下游計算時自行決定怎么處理。第四個坑是復(fù)權(quán)因子的更新。前復(fù)權(quán)價格會隨著新的除權(quán)除息事件而變化也就是說歷史的前復(fù)權(quán)價格不是一成不變的。如果緩存了前復(fù)權(quán)數(shù)據(jù)又沒及時失效用戶拿到的就是過時的價格。解決辦法是除權(quán)除息事件發(fā)生后主動失效相關(guān)標(biāo)的的緩存。4.5 監(jiān)控與告警的落地服務(wù)上線只是開始能不能穩(wěn)定運(yùn)行靠的是監(jiān)控。我一般監(jiān)控這幾個維度接口的 QPS、延遲、錯誤率采集任務(wù)的成功率、耗時、數(shù)據(jù)量數(shù)據(jù)質(zhì)量指標(biāo)比如每日新增記錄數(shù)、異常值比例緩存命中率、內(nèi)存使用。告警要分級別什么都告警否則告警疲勞真出事了反而沒人看。我的分級是P0 是服務(wù)不可用或者數(shù)據(jù)大面積錯誤立即電話告警P1 是部分功能異?；蛘邤?shù)據(jù)質(zhì)量下降工作時間告警P2 是性能指標(biāo)偏離記錄到日報。監(jiān)控數(shù)據(jù)本身也要存起來方便事后復(fù)盤。我見過太多團(tuán)隊出問題時才發(fā)現(xiàn)監(jiān)控數(shù)據(jù)只保留了幾小時根本沒法追溯。5. 服務(wù)擴(kuò)展與長期維護(hù)的幾點(diǎn)思考5.1 從單機(jī)到分布式的演進(jìn)路徑一開始單機(jī)跑完全沒問題一臺配置好點(diǎn)的機(jī)器日線行情加財報數(shù)據(jù)撐幾年數(shù)據(jù)量也就幾十 GB。但業(yè)務(wù)增長后單機(jī)會遇到瓶頸磁盤、內(nèi)存、CPU、還有單點(diǎn)故障。演進(jìn)路徑我建議是漸進(jìn)的別一上來就上微服務(wù)。第一步數(shù)據(jù)庫讀寫分離主庫寫從庫讀緩解讀壓力。第二步采集和服務(wù)拆開部署采集任務(wù)重的時候不影響接口響應(yīng)。第三步接口層水平擴(kuò)展多個實例前面掛負(fù)載均衡。第四步數(shù)據(jù)分片按標(biāo)的或者按時間把數(shù)據(jù)分散到多個庫。每一步都要有明確的觸發(fā)條件比如數(shù)據(jù)庫 CPU 持續(xù)超過 70%才做讀寫分離接口 P99 延遲超過 500ms才做水平擴(kuò)展。沒有明確指標(biāo)就盲目擴(kuò)展只會增加復(fù)雜度。5.2 數(shù)據(jù)版本管理金融數(shù)據(jù)有個特殊需求可重現(xiàn)。同樣的查詢今天和半年前應(yīng)該返回同樣的結(jié)果除非數(shù)據(jù)源本身修正了歷史數(shù)據(jù)。這就要求數(shù)據(jù)有版本管理。我的做法是給每條記錄加version和valid_from、valid_to字段數(shù)據(jù)修正時不覆蓋舊記錄而是把舊記錄標(biāo)記失效插入新記錄。查詢時默認(rèn)查當(dāng)前有效版本需要?dú)v史版本時按時間點(diǎn)查。這樣既保證了可重現(xiàn)又保留了修正歷史。這個方案會增加存儲和查詢復(fù)雜度但對于嚴(yán)肅的金融應(yīng)用是值得的。如果只是個人研究可以簡化但至少要保留原始落地數(shù)據(jù)以便必要時重建。5.3 合規(guī)與數(shù)據(jù)安全金融數(shù)據(jù)涉及合規(guī)問題尤其是涉及個人交易數(shù)據(jù)或者未公開信息時。我的原則是只采集和使用公開數(shù)據(jù)不碰任何可能涉及內(nèi)幕的信息用戶數(shù)據(jù)脫敏存儲敏感字段加密接口做鑒權(quán)和審計誰在什么時候查了什么數(shù)據(jù)要有記錄。數(shù)據(jù)安全方面數(shù)據(jù)庫不要暴露公網(wǎng)接口必須走鑒權(quán)敏感配置用環(huán)境變量或者密鑰管理服務(wù)別硬編碼在代碼里。這些是老生常談但每年都有因為硬編碼密鑰泄露的事故。5.4 文檔與交接數(shù)據(jù)服務(wù)最怕的是只有作者懂。字段含義、口徑定義、數(shù)據(jù)源特性、已知問題這些如果不寫下來作者一走接手的人得從頭摸索。我一般會維護(hù)三份文檔一份是接口文檔用 OpenAPI 自動生成保證和代碼同步一份是數(shù)據(jù)字典逐字段說明含義、單位、口徑、來源一份是運(yùn)維手冊寫清楚部署、監(jiān)控、常見問題處理。文檔不用寫得多漂亮但要準(zhǔn)確、及時更新。提示數(shù)據(jù)字典尤其重要。我見過太多項目字段名看著一樣實際口徑天差地別就是因為沒有數(shù)據(jù)字典?；ò胩鞎r間把數(shù)據(jù)字典寫清楚能省下后面無數(shù)次的扯皮。這套東西搭下來一個最小可用的金融數(shù)據(jù)服務(wù)就成型了。從采集到清洗到接口到監(jiān)控每個環(huán)節(jié)都有它的門道沒有哪一步是可以隨便糊弄的。我自己是從寫腳本一步步踩坑踩過來的回頭看最值錢的不是代碼而是那些踩過的坑和總結(jié)出的規(guī)矩。數(shù)據(jù)這東西臟起來超乎想象但只要流程立住了后面就是體力活。