指標:GitHub PR/Issue 同步服務的本地 Docker 運行方法與同步機制解析)
批處理流處理大數(shù)據(jù)【免費下載鏈接】beamApache Beam is a unified programming model for Batch and Streaming data processing.項目地址https://gitcode.com/gh_mirrors/beam15/beam點擊查看免費下載本文基于 Apache Beam 倉庫中 .test-infra/metrics/sync/github/README.md 展開完整覆蓋該文檔給出的兩條本地運行命令構(gòu)建鏡像后運行同步腳本、運行 pylint 檢查并結(jié)合 sync.py、Dockerfile、queries.py 等源碼深入講解這個 GitHub 數(shù)據(jù)采集服務的工作原理它如何通過 GraphQL 增量拉取apache/beam倉庫的 PR 與 Issue 元數(shù)據(jù)、如何寫入 PostgreSQL、以及如何實現(xiàn)冪等的 upsert 同步循環(huán)。讀完本文你可以復現(xiàn) Beam 社區(qū)指標棧中 GitHub 同步組件的本地部署流程并理解其增量同步與數(shù)據(jù)建模細節(jié)。一、同步服務在 Beam 指標棧中的定位Beam 的社區(qū)指標體系位于.test-infra/metrics/目錄其 README 說明該棧包含兩類指標社區(qū)指標Community metrics由 Python 腳本從 Jenkins 和 GitHub 兩個數(shù)據(jù)源采集寫入 Postgres 分析型數(shù)據(jù)庫測試結(jié)果指標Test ResultsIO 性能測試、負載測試、Nexmark 測試等產(chǎn)出的時序數(shù)據(jù)存儲在 InfluxDB 中。兩類指標最終都通過 Grafana 面板呈現(xiàn)且整個??梢酝ㄟ^ docker-compose.yml 在本地以 Docker 容器方式部署生產(chǎn)環(huán)境則運行在 GCP 的 Kubernetes 上。本文關(guān)注的 GitHub 同步組件正是“社區(qū)指標”中負責 GitHub 數(shù)據(jù)源采集的部分由 sync.py 文件頭注釋概括為This module queries GitHub to collect Beam-related metrics and put them in PostgreSQL.該組件的目錄結(jié)構(gòu)如下均位于 .test-infra/metrics/sync/github/文件作用sync.py主同步腳本建表、增量拉取 GitHub 數(shù)據(jù)、upsert 入庫queries.py兩條 GraphQL 查詢模板MAIN_PR_QUERY拉取 PRMAIN_ISSUES_QUERY拉取 Issueghutilities.pyGitHub 時間格式轉(zhuǎn)換、mention 提取等工具函數(shù)sync_test.py針對findMentions等工具函數(shù)的單元測試Dockerfile構(gòu)建syncgithub鏡像requirements.txtPython 依賴aiohttp、backoff、psycopg2-binary、PyGithub二、構(gòu)建容器鏡像README 的第一步是“Build container”。構(gòu)建依據(jù)是本目錄下的 Dockerfile其關(guān)鍵內(nèi)容為FROM python:3.8-slim WORKDIR /usr/src/app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt pylint yapf nose COPY . . CMD python ./sync.py從源碼結(jié)構(gòu)看鏡像基于python:3.8-slim一次性裝入了運行時依賴requirements.txt與靜態(tài)檢查工具pylint、yapf、nose——后者正是 README 中“Runnin linter”一節(jié)得以直接在容器內(nèi)執(zhí)行pylint的前提。默認的CMD是啟動同步腳本本身。在.test-infra/metrics/sync/github目錄下執(zhí)行構(gòu)建即可得到本地鏡像與 README 中后續(xù)命令使用的鏡像名syncgithub保持一致docker build -t syncgithub .生產(chǎn)/本地編排中該鏡像同樣由 compose 定義docker-compose.yml 中的syncgithub服務第 76-91 行指定了build.context: ./sync/github并在環(huán)境中注入了DB_HOSTbeampostgresql、DB_PORT5432、DB_DBNAMEbeam_metrics、DB_DBUSERNAMEadmin等變量與 compose 中postgresql服務創(chuàng)建的數(shù)據(jù)庫實例對應。三、本地運行同步腳本README 給出的運行命令是docker run -it --rm --name sync -v $PWD:/usr/src/myapp \ -w /usr/src/myapp \ -e DB_PORT5432 \ -e DB_DBNAMEbeam_metrics \ -e DB_DBUSERNAMEadmin \ -e DB_DBPWDaaa \ -e GH_ACCESSTOKENgithubaccesstoken \ syncgithub python sync.py命令語義逐項說明-v $PWD:/usr/src/myapp -w /usr/src/myapp把當前目錄即sync/github源碼目錄掛載為容器工作目錄使python sync.py直接執(zhí)行掛載后的腳本便于本地調(diào)試改動--name sync --rm命名容器并在退出后自動清理-e DB_PORT5432 -e DB_DBNAMEbeam_metrics -e DB_DBUSERNAMEadmin -e DB_DBPWDaaaPostgreSQL 連接參數(shù)。其中數(shù)據(jù)庫名beam_metrics、用戶名admin、端口5432與 docker-compose.yml 中postgresql服務的環(huán)境變量POSTGRES_DBbeam_metrics、POSTGRES_USERadmin、端口映射5432:5432完全一致說明 README 命令預設你已在本機 5432 端口擁有一個按此約定初始化過的 Postgres可通過 compose 的docker-compose up postgresql快速搭建。3.1 環(huán)境變量與 README 命令的對照對照 sync.py 第 43-49 行腳本啟動時讀取的環(huán)境變量為DB_HOST os.environ[DB_HOST] DB_PORT os.environ[DB_PORT] DB_NAME os.environ[DB_DBNAME] DB_USER_NAME os.environ[DB_DBUSERNAME] DB_PASSWORD os.environ[DB_DBPWD] GH_ACCESS_TOKEN os.environ[GH_ACCESS_TOKEN]由此有兩點實操注意事項DB_HOST是必需變量而 README 的命令未顯式傳入。在 compose 棧內(nèi)它被設為beampostgresql即 Postgres 容器名若在宿主機上單獨docker run需要指向宿主機的可達地址。腳本中特意保留了一個注釋掉的調(diào)試工具findDockerNetworkIP()第 34-38 行它通過ip route show取 Docker 宿主機的網(wǎng)關(guān) IP供本地調(diào)試時作為DB_HOST使用。令牌變量名的差異腳本讀取的是GH_ACCESS_TOKEN第 49 行而 README 命令中寫的是GH_ACCESSTOKEN。按當前 sync.py 源碼實際生效的變量名應為GH_ACCESS_TOKEN若嚴格按 README 命令傳GH_ACCESSTOKEN腳本會在讀取環(huán)境變量時拋KeyError。運行前請以源碼中的變量名為準確認。另外initDBConnection()第 94-106 行實現(xiàn)了連接重試邏輯連不上數(shù)據(jù)庫時打印提示并每 60 秒重試一次因此若 Postgres 稍后啟動同步容器會持續(xù)等待而不會直接退出。四、運行 LinterREADME 的第二條命令是運行 pylint 靜態(tài)檢查docker run -it --rm --name sync -v $PWD:/usr/src/myapp \ -w /usr/src/myapp syncgithub pylint sync.py該命令不需要數(shù)據(jù)庫與 GitHub 令牌只依賴鏡像中預裝的pylint見 Dockerfile 第 25 行掛載源碼后對sync.py做靜態(tài)檢查適合作為本地修改同步腳本后的快速代碼風格驗證手段。鏡像中還裝有yapf與nose前者可用于代碼格式化檢查后者可用于執(zhí)行本目錄下的單元測試 sync_test.py該測試基于unittestddt驗證ghutilities.findMentions對mention的提取行為例如輸入sample text with several mentions first, second third應得到[first, second, third]。五、啟動后的同步機制從建表到增量拉取python sync.py并不是一次性任務而是一個常駐循環(huán)。sync.py 的__main__段第 500-527 行流程為打印 Started. 并調(diào)用initDbTablesIfNeeded()初始化數(shù)據(jù)庫表進入無限循環(huán)先調(diào)用probeGitHubIsUp()做連通性探測第 490-496 行通過 TCP 連接github.com:443判斷 GitHub 是否可用不可用則跳過本輪可用時執(zhí)行fetchNewData()完成一次同步打印 Sleeping for 5 minutes. 并休眠 300 秒等待下一輪。也就是說容器以每 5 分鐘一輪的增量同步方式持續(xù)運行。5.1 自動建表三張核心表initDbTablesIfNeeded()第 116-145 行會依次檢查并按需創(chuàng)建三張表gh_pull_requests第 53-68 行create table gh_pull_requests ( pr_id integer NOT NULL PRIMARY KEY, author varchar NOT NULL, created_ts timestamp NOT NULL, first_non_author_activity_ts timestamp NULL, first_non_author_activity_author varchar NULL, closed_ts timestamp NULL, updated_ts timestamp NOT NULL, is_merged boolean NOT NULL, requested_reviewers varchar[] NOT NULL, beam_reviewers varchar[] NOT NULL, mentioned varchar[] NOT NULL, reviewed_by varchar[] NOT NULL )其中first_non_author_activity_ts/author記錄 PR 作者以外的第一位參與者評論、Review 或合并動作出現(xiàn)的時間與身份是衡量“首次響應時長”的基礎字段beam_reviewers則是 Beam 社區(qū)口徑的評審人列表提取規(guī)則見下文 5.4 節(jié)。gh_issues第 72-83 行issue_id、author、created_ts、updated_ts、closed_ts、title、assignees varchar[]、labels varchar[]。gh_sync_metadata第 86-91 行name varchar PRIMARY KEYtimestamp用于持久化“上次同步到哪一刻”的增量水位。表是否已存在通過查詢information_schema.tables判斷tableExists第 109-113 行因此建表邏輯對重復啟動是冪等的。5.2 增量水位fetchNewData的主流程fetchNewData()第 413-487 行分別以kind pr和kind issue兩輪執(zhí)行同樣的邏輯取水位從gh_sync_metadata表按name LIKE gh_{kind}_sync查詢上次同步時間戳fetchLastSyncTimestamp第 164-175 行。若從未同步過PR 走fetchLastSyncTimestampFallback第 149-161 行兼容歷史元數(shù)據(jù)行g(shù)h_syncIssue 直接使用回退值1980-01-01即首次運行會回溯全量數(shù)據(jù)拉取以當前水位為參數(shù)調(diào)用fetchGHData(currTS, query)第 204-208 行它把 ghutilities.datetimeToGHTimeStr 轉(zhuǎn)換出的 GitHub 時間字符串格式%Y-%m-%dT%H:%M:%SZ替換進查詢模板中的TemstampSubstitueLocation占位符再 POST 到 GitHub GraphQL 端點api.github.com/graphql攜帶Bearer {GH_ACCESS_TOKEN}寫入遍歷返回的data.search.edges逐條調(diào)用extractRowValuesFromPr/extractRowValuesFromIssue提取行值然后upsertIntoPRsTable/upsertIntoIssuesTable第 354-410 行以ON CONFLICT (pr_id) DO UPDATE/ON CONFLICT (issue_id) DO UPDATE的方式整行覆蓋寫入保證重復同步不產(chǎn)生重復行推進水位每處理完一個節(jié)點用currTS max(currTS, node.updatedAt)推進本輪水位第 479-481 行整輪結(jié)束后updateLastSyncTimestamp第 178-193 行以INSERT ... ON CONFLICT (name) DO UPDATE寫回元數(shù)據(jù)表。如果 GitHub 返回體含errors字段常見于限流、令牌失效腳本會打印錯誤并提前返回等待 5 分鐘后的下一輪重試——這構(gòu)成了腳本層面的容錯閉環(huán)。5.3 GraphQL 查詢模板queries.py 定義了兩條搜索型查詢MAIN_PR_QUERY第 18-116 行search(query: type:pr repo:apache/beam updated:TemstampSubstitueLocation sort:updated-asc, type: ISSUE, first: 100)即按更新時間升序拉取晚于水位時間戳的apache/beamPR每頁 100 條節(jié)點內(nèi)聯(lián)展開comments、reviewRequests、assignees、reviews、merged/mergedAt/mergedBy等字段MAIN_ISSUES_QUERY第 123-174 行結(jié)構(gòu)類似但限定type:issue并展開assignees與labels(first: 10)。由于fetchNewData的循環(huán)條件是“本次查詢是否還有結(jié)果”resultsPresent配合updated:ts的時間過濾一輪同步會持續(xù)翻頁直至該水位之后的更新全部取完。5.4 數(shù)據(jù)提取Beam 特色的評審人口徑extractBeamReviewerssync.py 第 272-306 行是 PR 建模中最有社區(qū)特色的部分它合并四類信號GitHub 的assignees與reviewRequests實際執(zhí)行過 Review 的用戶PR 描述與評論中形如user ... PTAL/look的請求正則r(\w).*?(?:PTAL|ptal|look)貢獻者常用的Rr1 r2/R r1寫法正則r(?:^|\W)[Rr]\s*:.)且支持-user從列表中移除評審人。最終結(jié)果會排除 PR 作者本人并去重。類似的“社區(qū)語言”解析還有extractMentions第 222-238 行聚合 PR 描述、評論、Review 中所有 提及findMentions由 ghutilities.py 提供并過濾掉username占位符以及extractFirstNAActivity第 241-269 行在他人評論、他人 Review、合并動作三者中取時間最早者。這些字段正是上層 Grafana 面板計算響應時長、評審協(xié)作等社區(qū)指標的數(shù)據(jù)基礎。六、與 docker-compose 全棧的關(guān)系如果不想單獨運行同步容器可以直接使用 docker-compose.yml 拉起整個指標棧Postgres InfluxDB Grafana syncgithub syncjenkins。其中syncgithub服務注入的環(huán)境變量包括DB_HOSTbeampostgresql、DB_DBNAMEbeam_metrics等與 postgres/init.sql初始化時創(chuàng)建tablefunc擴展共同構(gòu)成同步腳本的運行環(huán)境按 metrics 目錄 README 的說明本地啟動后可通過localhost:5432訪問 Postgres、localhost:3000訪問 Grafana。需要注意的是compose 中syncgithub服務額外聲明了GH_APP_ID、GH_APP_INSTALLATION_ID、GH_PEM_KEY、GH_NUMBER_OF_WORKFLOW_RUNS_TO_FETCH等變量而當前 sync.py 源碼實際讀取的是GH_ACCESS_TOKEN從源碼結(jié)構(gòu)看compose 配置與腳本之間應處于演進過渡狀態(tài)本地部署前建議以sync.py讀取的變量名DB_*GH_ACCESS_TOKEN為準進行核對。七、小結(jié)與適用前提適用前提本地已安裝 Docker目標 PostgreSQL 已按beam_metrics庫、admin用戶初始化持有具備 GitHub GraphQL API 訪問權(quán)限的 Access Token。運行形態(tài)同步腳本是常駐進程每 5 分鐘一輪增量同步GitHub 不可達或返回錯誤時自動降級等待下一輪不會崩潰退出。冪等設計三張表按需創(chuàng)建PR/Issue 行按主鍵 upsert水位按名稱 upsert重復啟動安全。驗證手段修改 sync.py 后可用 README 的 pylint 命令做靜態(tài)檢查sync_test.py 覆蓋了 mention 提取等核心解析邏輯可用于回歸驗證。這條 GitHub 同步鏈路是 Beam 社區(qū)指標的數(shù)據(jù)入口之一與同目錄的 Jenkins 同步組件.test-infra/metrics/sync/jenkins/配合共同支撐著社區(qū)活躍度與代碼協(xié)作效率的量化觀測。贊分享批處理流處理大數(shù)據(jù)【免費下載鏈接】beamApache Beam is a unified programming model for Batch and Streaming data processing.項目地址https://gitcode.com/gh_mirrors/beam15/beam點擊查看免費下載相關(guān)推薦Apache Beam 社區(qū)指標同步基于 GitHub GraphQL API 的 PR/Issue 數(shù)據(jù)采集與 PostgreSQL 落地實踐Apache Beam 社區(qū)指標同步基于 GitHub GraphQL API 的 PR/Issue 數(shù)據(jù)采集與 PostgreSQL 落地實踐 本文以 Ap大數(shù)據(jù)批處理流處理數(shù)據(jù)工程Apache Beam 社區(qū)指標之 GitHub 數(shù)據(jù)同步sync.py 的本地運行與調(diào)試實戰(zhàn)指南Apache Beam 社區(qū)指標之 GitHub 數(shù)據(jù)同步sync.py 的本地運行與調(diào)試實戰(zhàn)指南 Apache Beam 通過一套基于 Docker 的社區(qū)Apache Beam 社區(qū)指標棧Jenkins 構(gòu)建指標同步工具syncjenkins本地運行與原理實戰(zhàn)指南Apache Beam 社區(qū)指標棧Jenkins 構(gòu)建指標同步工具syncjenkins本地運行與原理實戰(zhàn)指南 Apache Beam 項目維護著一套面向大數(shù)據(jù)批處理流處理數(shù)據(jù)工程上一篇RxSwift中文文檔MVVM架構(gòu)指南構(gòu)建可維護的iOS應用的終極教程下一篇標題探索未來游戲之路SharpNav 開源導航庫創(chuàng)作聲明:本文部分內(nèi)容由AI輔助生成(AIGC),僅供參考