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