后院采石场：将岩石转化为数据
Source: Dev.to
最近，科技行业又迎来了一轮裁员，我是其中受影响的人之一。
如果你在科技行业工作过一段时间，你一定熟悉随之而来的常规：更新简历、联系熟人、浏览招聘网站，并尝试弄清楚市场目前热衷哪些技术，哪些技术已经悄然失去关注。
经过几天的循环，我发现自己在户外的时间比在笔记本前的时间更多。某天下午，我在院子里散步时注意到一件有趣的事：我的后院竟然拥有一个出乎意料的大数据集。
意外的数据集
我的后院里到处都是各种形状和大小的岩石：
- 有的只有豌豆大小。
- 其他的大约相当于汽车发动机的大小。
- 有些则介于“建议使用手推车”和“这可能需要重型机械”之间的令人不安的范围。
自然地，我和很多人在盯着一大堆岩石时会产生同样的想法：我大概可以卖掉它们。在路边设一个小摊位，按大小分几堆，也许挂个写着“园林石”的招牌。这并不是风险投资支持的初创公司，但更奇怪的副业也曾存在。
不幸的是，工程师有一个众所周知的弱点：我们很少用最简单的方式做事。如果我要卖石头，我不会仅仅把它们堆在桌子上——我会建立一个系统。
Source: …
从岩石到记录
当你开始把岩石视作库存时，一系列熟悉的问题会出现：
- 有多少块岩石？
- 什么种类？
- 哪些是小的装饰石，哪些则明确属于我开始称之为 Engine Block Class 的类别？
像许多真实世界的数据集一样，这个数据集具有显著的变异性。有些物体只有几克重；另一些则重到需要小心的搬运技巧，并且在内部进行一次关于人生选择的简短对话。乍一看，数据集显得混乱，但在混乱之下隐藏着模式：不同的尺寸、形状、颜色和地质类型。有的岩石是光滑的河石；有的则是看起来像是从小规模山体滑坡中逃出的锯齿状碎片。
如果你稍微眯起眼睛，就会开始看到对任何从事数据系统工作的人来说都很熟悉的轮廓——一组可以表示为结构化记录的实体对象。
设计数字孪生
理论上，卖石头很简单：
- 收集石头。
- 把它们堆在一起。
- 等待有人停车并决定他们需要园林材料。
但一旦从工程角度思考，问题就会成倍增加：
- 每块石头都需要一个标识符吗？
- 需要照片吗？
- 系统要跟踪重量或尺寸吗？
- 分类怎么办？（卵石类、手推车类、发动机块类等）
概念上，每块石头的记录可能如下所示：
rock_id: # unique identifier
weight: # in grams or kilograms
dimensions: # length × width × height
color: # descriptive or hex code
rock_type: # e.g., river stone, basalt, limestone
location_found:# GPS coordinates or yard zone
status: # e.g., in stock, sold, reserved院子里的每块石头都会成为一个数字对象——一个结构化记录，代表现实世界中的实物。换句话说，每块石头现在都有了 数字孪生。在园林石材的情境下，这听起来可能有点荒唐，但其背后的概念却异常强大。
在许多行业中，组织面临相同的挑战：将混乱的物理现实与结构化的数字系统相连接。制造商跟踪机器部件，博物馆编目文物，农民监控作物，物流公司追踪仓库中的库存。在每一种情况下，某个实物都存在于世界的某个位置，而我们希望以软件系统能够理解的方式来表示它。
Source:
后院采石场项目
部分是开玩笑，部分是因为它捕捉到了项目的精神，我把这项工作命名为 后院采石场。最初的随意观察演变成了一个关于数据建模、对象目录和系统设计的小实验。
数据集可能很小，对象可能是石头，但其背后涉及的问题却相当丰富：
- 如何在软件中表示物理对象？
- 如何捕获关于它们的信息？
- 如何搜索并组织生成的数据？
- 当对象数量从几十个增长到数千甚至数百万时，这些系统如何扩展？
接下来
在本系列接下来的几篇文章中，我将通过围绕后院采石场构建一个小系统来探讨这些问题。主题包括：
- 为物理对象设计模式（schema）
- 捕获图像和测量
- 使用摄影测量法生成 3D 模型
- 构建摄取管道
- 对数据集进行索引和搜索
所有这些都从一小堆岩石开始。
结论
世界上并不缺乏复杂的工程问题。有时探索这些问题的最佳地点反而更为简单——比如后院的一堆石头。如果你恰好需要一块来自后院采石场的精心记录的标本，目前库存仍有（尽管运费可能超过岩石本身的价值）。