On this page
p.s. 本次访谈由 GreptimeDB 社区核心成员（即 Greptime 工程师）Lei 主导，Ruihang 参与，社区运营 Beryl 共同完成，本次叙述视角为 GreptimeDB 内部，访谈者 GitHub ID 为 lyang24，文中简称 Lanqing。
一开始，只是出于兴趣；后来，成了社区中的熟面孔；再之后，他收到了 Committer 的邀请。
Lanqing 是我们社区的新晋 Committer，相识于 Slack，结缘于 GitHub。**与之前的大部分 Committer 不同，他真的是一位“用户”。**他是一位在海外工作的工程师，过去在 Facebook、字节跳动、Roblox 做过基础设施相关的工作，现在则在一家科技公司从事存储系统的研发。也是因为如此，他才逐渐参与到 GreptimeDB 的开源社区里。
🧭 看到一篇文章，然后顺手提了个 PR
“我最开始是看到一篇你们写的博客，好像是对 VictoriaMetrics 的一个优化。当时我们公司刚好在用 VM，我觉得这东西写得挺认真的，就开始关注了。”
他口中的这篇博客，是社区早期写的性能对比文章，现在我们也发布了最新的测试报告。不过那时候他还没提 PR，只是围观者。但没过多久，他就开始动手了。
一开始他只是提了点配置相关的改动，“就是修修配置文件、改点文档的那种 PR。” 但意外地收到了很快的反馈，还不断鼓励他继续探索，就坚定了留在社区探索的信念。于是他继续提 PR，从外围功能，慢慢往内核靠近。
💻 把 GreptimeDB 当作练习 Rust 的 Playground
Lanqing 原来就用过 Rust，上一份工作中，他在做数据库接入层时几乎全程使用 Rust。再往前，很多大厂都在加速推广和使用 Rust——Facebook 和 Bytedance 很多新项目都用 Rust 起步；TikTok 在部分组件中使用 Rust 重写；他当年在 Roblox 时，也亲历了一波 Rust 项目的引入潮。
“我挺看好 Rust 的，尤其是做 infra。这语言写起来不讨巧，但它的保障机制太适合 infra 场景了。”
现在的工作虽然不再用 Rust 了，但也不希望“手艺生疏”，开源社区是一个很好的场景。
“我其实挺喜欢 Rust 的，但现在的工作里已经用不上它了。开源对我来说，是个让自己别生疏的方式。”
在他看来，参与 GreptimeDB 的过程，不光让他保持了语言的熟练度，也让他重新建立起一套“技术判断和实现路径”的思维方式。
🔧 从外围 PR 到深入存储引擎，没有什么“野心”
**Lanqing 在 GreptimeDB 的第一次“技术跃迁”，来自一次 string trait 的实现。**那个涉及到 Rust 字符串处理的小 PR，让他在实现过程中搞懂了数据结构是怎么在内部转换、序列化和返回的。这类细节上的理解，一般不会出现在文档里，而是来源于社区同学 review 后的一次次反馈。
每一次 PR review 都能让他多学点东西。他说自己不是那种“初上手就能改内核”的 contributor，但一步步地拓展自己在 KV 存储、协议支持、系统行为方面的理解。
“社区的 review 非常 responsive，而且不是那种敷衍式通过，是真的一条一条地指出来该怎么做更好。”
但总的来说，这是他参与过 onboarding 体验最顺畅的开源项目之一了。
🗣️ Slack 有点冷，“我”也不好意思老发问
老生常谈的社区氛围话题，之前我们就根据一位 Committer 的反馈增加了社群的多样性和发言权。当我们问到 Lanqing 这个问题的时候，他也给了一些真实的反馈。
“Slack 群有点冷，我其实也不太好意思经常问问题，怕打扰到别人。”
后来他发现其实大家都有同样的想法，结果就是群越冷越没人说话。不过好像提问本身就是一种反馈，对社区和项目都有所助益。
海外 Slack 群不活跃，也有可能是因为很多开源项目背后有商业公司支持，天然形成了“内群和外群”的交流区别。但是谈及活跃社区，他似乎并不在意。
“我觉得比起造一个活跃社区，更重要的是把文档和技术文章写好，让人能找到答案、能开始用。”
🏅 成为 Committer 意味着什么
当我们内部决议一致通过了 Lanqing 的 Committer 提名时，他刚从西雅图下班。
“这是对我这一段努力的肯定。但我并不会因此觉得自己‘必须做更多’，反而是我更想去研究底层了，比如你们现在在搞的 Mito2 存储引擎。”
他目前对数据库引擎底层的实现越来越感兴趣，也在尝试搞清楚存储引擎的逻辑路，计划未来把更多时间花在读存储相关的代码上，也希望能慢慢补足这部分的理解。
🚗 一点题外话：电车上的数据库
作为生活在西雅图的工程师，他说周围开电车的人非常多。我们聊到电车和边缘数据库，他忽然说：
“这样的解决方案在北美还是挺新鲜的。你们应该讲讲这个方案是怎么在车端落地的。”
他认为这个方向非常有前景，尤其是在统一采集协议、在车端节约数据回传成本的场景里。
“你们可能是全球第一个把时序数据库‘跑在车上’的团队了”。
但他也提到，这类方向要想在北美真正落地，除了技术以外，还需要理解供应链生态、合作流程等更复杂的因素。
🧩 一点心声
整个采访下来，我们最喜欢的一句话是他轻描淡写说的那句：
“我不是为了头衔，我只是想别忘了 Rust。”
没有宏大叙事，没有“技术改变世界”，但有对语言的喜爱、对社区的投入、有从一次 PR 开始的好奇心。就只是一个工程师在日常工作之外，找到了一个能继续写代码、保持思维清晰、并且有人回应的地方。
我们感谢并欢迎每一位这样的人。
📌 你也可以：
- 和 Lanqing 交个朋友：https://github.com/lyang24
- 访问 GreptimeDB 的 GitHub 仓库：https://github.com/GreptimeTeam/greptimedb
- 加入社区 Slack：https://greptime.com/slack
- 阅读我们的技术文档：https://docs.greptime.com
Interviewer：Lei，Ruihang，Beryl Interviewee：lyang24
关于 Greptime
Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。
欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~
Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
