CrawlOS+Supabase：14县房产数据管道与自动线索评分实战

把房产批发（wholesaling）规模化，靠的不是更厚的电子表格，而是一套能跑通的数据基础设施。有开发者公开了一套生产环境的实现方案：将 CrawlOS 集成进自建 Supabase，覆盖休斯顿都会区 14 个县，用 pg_cron 做夜间调度，抓取 HCAD（哈里斯县评估区）数据，单次运行产出约 125 条合格线索。

这套方案的完整拆解包含 17 张表的 schema 设计、actor 部署模式、线索评分逻辑，以及从原型走到生产时踩过的坑。如果你正在搭建垂直房产技术栈，或者想把数据管道从"单县抓取"扩展到多县，这套结构值得逐层看一遍。

为什么单县管道一到多县就崩

很多房产数据项目起步时都是"一个县、一张表、一个脚本"。哈里斯县作为德州人口最多的县，单独抓取已经能产生可观线索，但问题出在扩展的那一刻：14 个县的评估区数据结构、字段命名、更新频率各不相同，原本写死的字段映射和去重逻辑立刻失效。

作者的核心判断是——把问题从"写爬虫"重新定义为"设计数据基础设施"。CrawlOS 承担抓取与解析的抽象层，Supabase 承担关系建模、权限与实时能力，pg_cron 负责编排。三层各司其职，县的增减不再意味着重写业务逻辑。

什么是房产批发（wholesaling）

房产批发是房地产投资中一种低资金门槛的套利模式：操作者（wholesaler）并不真正买下房产，而是与急于出售的业主签订购房合同，取得该物业的"合同权益"，再把这份合同加价转让给最终买家（通常是翻新转售者或出租型投资人），赚取中间差价（assignment fee）。其核心能力不在施工或持有，而在于持续、低成本地找到愿意低价出售的卖家——这解释了为什么数据管道会成为这门生意的瓶颈：谁能以更低的边际成本覆盖更多县、筛选出更高质量的潜在卖家，谁就拥有规模化优势。传统批发团队依赖驱车扫街、直邮明信片和人工拨打公record电话，单位线索成本高且难以跨区域复制。评估区（appraisal district）公开数据则是免费且结构化的替代来源，使得自动化抓取成为可能。

HCAD 与德州评估区体系

哈里斯县评估区（Harris County Appraisal District, HCAD）是德州 254 个县各自设立的独立评估机构之一，负责为本县不动产与个人财产估值，供地方政府征收房产税。德州实行"县自治"式的评估体系，这意味着每个县有独立的网站、数据导出格式、字段命名与更新节奏，彼此之间没有统一的州级 API。HCAD 作为人口第一大县的评估区，数据量最大、公开程度也相对较高，常被当作该类管道验证的首个数据源。跨县扩展难的根源正在于此：字段映射、产权所有人（owner of record）的表述方式、豁免类型代码、地块编号规则都因县而异，任一县的改版或反爬策略调整都会击穿写死的解析逻辑。理解这一体系，是理解本文为何强调"抽象层"而非"更强爬虫"的前提。

17 张表的 schema 设计思路

整套系统围绕 17 张表展开，覆盖物业主记录、地址标准化、所有者信息、交易历史、线索状态与评分快照等实体。拆得这么细的原因在于评估区数据本身高度冗余：同一处物业可能在不同抓取批次中出现，同一所有者可能关联多个地址。

关系建模把"线索"从一张大宽表里解放出来——线索被定义为跨表查询的结果，而不是一条记录。这样当评分规则调整时，不需要回填历史数据，只需重新计算视图。对于需要长期追踪批发机会的团队，这种设计的可维护性远高于单表方案。

Supabase 与 pg_cron 的定位

Supabase 是构建在 PostgreSQL 之上的开源后端平台，在原生 Postgres 之外提供身份认证、行级安全（RLS）、自动生成的 REST/实时 API 与对象存储。对本方案而言，关键在于它保留了完整的 Postgres 能力——可以用外键、视图、物化视图、触发器来建模物业与所有者的多对多关系，而不必迁就 NoSQL 的弱约束或纯 ORM 的抽象泄漏。pg_cron 是 Postgres 的定时任务扩展，直接在数据库内以 cron 语法注册任务，因此调度逻辑与数据本身同居一处，无需额外引入 Airflow、Celery 之类的外部编排组件。夜间窗口触发、按县错峰、失败重试都可以在数据库层描述，运维面被压缩到单一技术栈内，这也是作者强调"三层各司其职"的技术基础。

actor 部署与 pg_cron 夜间调度

抓取侧采用 CrawlOS 的 actor 模式部署：每个县、每类数据源对应独立的 actor，抓取结果统一写入 Supabase。调度交给 pg_cron，把抓取任务按夜间窗口分批触发，避开评估区站点的高峰访问时段。

值得关注的是批处理策略。14 个县如果在同一时刻并发抓取，既容易被限流，也会在写入端造成尖峰。作者的方案是按县错峰，并在单个 actor 内部保留重试与断点续抓能力——这是从原型走向生产时最关键的一处改动。

线索评分逻辑如何工作

线索评分的输入来自多个维度：物业状态、所有者类型（是否为外州或机构持有）、持有年限、地址标准化置信度等。评分结果以快照形式落库，而不是覆盖旧值，方便回溯"为什么这条线索当时被判为高分"。

单次运行产出约 125 条合格线索这个数字，本身也说明了过滤强度——原始抓取量远大于此，评分层承担了主要的降噪职责。对于线索质量比数量更重要的批发业务，这一层的价值往往被低估。

从原型到生产的几个坑

自建基础设施的坑集中在三处。其一是 HCAD 等评估区站点的反爬与页面结构变动，actor 需要具备解析失败时的降级路径；其二是数据库连接与并发写入在夜间批量任务下的稳定性；其三是地址标准化——跨 14 个县时，同一处物业的地址表述差异会直接污染去重结果。

这套方案的通用经验是：把"抓取成功率"和"线索准确率"拆成两个独立监控指标。前者反映管道健康度，后者反映数据质量，混在一起看会掩盖真正的问题所在。

对于评估是否要自建类似管道的团队，判断标准其实很简单——当你需要追踪的县超过两三个，或者线索质量直接影响成交转化时，基础设施的投入就会开始产生复利。

地址标准化与实体解析

地址标准化（address standardization / normalization）是把任意书写形式的地址解析为结构化、可比对的标准格式的过程，通常输出门牌号、街道名、方向前缀、单元号、城市、州、ZIP+4 等独立字段，并映射到权威坐标（geocoding）。在跨 14 个县抓取时，同一处物业可能以 "123 Main St"、"123 MAIN STREET"、"123 Main St., Apt B" 等形态反复出现，若不做标准化，去重逻辑会把同一标的判为多条线索，既虚增线索量也稀释评分。与之配套的实体解析（entity resolution）进一步判断两条记录是否指向同一真实对象——同一房产、同一所有者。二者共同决定线索准确率这一指标，也是本文把"地址标准化置信度"列为评分维度之一的原因：置信度低意味着该条记录的身份归属存疑，应被降权而非直接采纳。