数据建模功能上线那天，MongoDB专业服务团队的老张可能比产品经理还激动。这个功能被客户追问了整整10年，结果真做出来之后，没人拿它做Schema验证——全拿去当数据字典了。
这很合理。团队对齐数据长什么样，比约束数据格式更急迫。模型一敲定，下一步就是造点假数据开始写代码。问题是，写脚本生成符合模型、看起来还真实的测试数据，是个体力活。老张说："我给客户干过太多次了。"
于是他决定让机器干。不是从零造轮子，而是嫁接一个2008年就存在的Perl脚本库——Faker。这个库被移植到各种语言，自带280多种生成器，邮箱、人名、地址、车牌号一应俱全。老张选了Python版本。
核心难题：怎么让机器"看懂"字段该生成什么
模型有了，生成器也有了，中间缺一座桥。老张的方案写在JSON Schema的description字段里：用#号包裹Faker方法名和参数。比如#"faker.name.name"#。你自己的描述可以照常写，工具只提取两个#号之间的内容。
这能跑通，但不够懒。老张想要的是：你扔给我一个字段名，我直接猜该用哪个生成器。猜的依据是语义相似度——用向量搜索实现。
为了轻量化，他选了ChromaDB做向量数据库。实现逻辑很直白：
把Faker所有方法的名字和描述向量化，存进ChromaDB；用户字段名也向量化，去库里找最接近的匹配。
几个细节优化让猜测更准确：字段名预处理、多候选投票、常见数据类型的硬编码映射。最终成品叫mock-data，开源在GitHub。
三种输出姿势，覆盖开发全流程
工具支持三种数据落点。最轻的是导出ejson文件，直接扔进output文件夹；要联调就直写MongoDB，传个连接串就行；还有Kafka模式，方便测流处理管道。
命令行界面刻意做得极简。指定Schema文件、造多少条、输出到哪，三句话搞定：
mockdata -s schemas/BookStore.json -n 50 -t mongodb mongodb://localhost/
老张在10年服务生涯里见过太多团队的手动造数据脚本——写一遍、改一遍、废弃一遍。他的判断是：模型即代码的趋势下，数据生成应该和模型绑定，而不是和某个临时脚本绑定。
这个工具现在还在早期。向量搜索的准确率取决于字段命名规范程度，叫user_email的字段一猜一个准，叫ue的就容易翻车。老张留了手动注解的兜底方案。
有意思的是，MongoDB Compass的数据建模功能本身也是个"迟到"的需求。10年间被反复提起，优先级始终打不过其他特性。真上线后，开发者们的用法和产品经理的设想完全不同——没人拿它约束数据，全拿它对齐认知。老张的工具，算是给这个"跑偏"的用法补上了最后一环。
你团队的测试数据现在怎么造？是手写脚本、用现成的Mock平台，还是直接copy生产环境然后祈祷别泄露？
热门跟贴