2017 年，我用 Airtable 这款表格利器建了一个「量化自我」数据库

　　2017 年，我用 Airtable 这款表格利器建了一个「量化自我」数据库

　　如今，数据早已被称之为信息时代的「黄金」，个人可以通过数据来量化自我，公司可以使用数据来帮助决策。互联网服务商可以通过搜集用户数据提供愈发个性化的服务，我们也可以搜集自己的数据来优化自己的生活方式。

　　近一年来，我开始意识到自己作为数据发生器的重要性，于是就开始下意识地集中搜集自己形成的各种数据，建立自己的数据搜集模式。而提到为何要集中搜集个人数据，主要缘由应当有两点：

　　目前使用了 Moves，RescueTime，Toggl 等各种应用来搜集自己的地理位置、时间消耗等数据。但是这种数据都存放于单独的应用之上，过于分散。自己看得见，摸得着的数据，比置于他人的服务器上更放心，也更容易集中加以借助。

　　集中搜集数据，意味着 Moves，RescueTime 等应用弄成了纯粹的搜集工具，而数据会汇总到自己手中。不同类型的数据一旦汇集到一起，不仅可以针对单一类别数据进行可视化展示，还能剖析出数据直接的关联性，对自己的行为更具有指导意义。

　　选择一款云端表格工具

　　数据搜集的末端，对应着用于储存数据的数据库。当然，对于个人数据搜集而言，我们常说的电子表格也许就足够了。最使大众熟知的电子表格工具一定是 Microsoft Excel 。但是，作为一款桌面软件，Excel 往往并不适用于现代的数据搜集流程。例如，你想将你的微博存档保留，难道是通过自动复制粘贴到 Excel 文档中吗？显然不太实际。

　　所以，如果我们有一个置于云端的电子表格，可想像的空间就大好多了。说到云端电子表格，不得不再度提及 Excel，只不过此次是它的孪生兄弟 Excel Online，作为 Office 365 的套件之一，Excel Online 除了未能处理宏命令，其他方面几乎就是桌面版 Excel 的完美克隆。

　　相比之下，本文的主角 Airtable 的名气就远不及 Excel 了。但是，作为一个典型的硅谷公司产品，Airtable 也拥有不错的口碑。此外，Google Sheets 也是优秀的云端表格工具，只是这朵云距我们稍为远了一些。

　　那么，对于这三款相对优秀的云端电子表格，到底哪一款愈发适宜用于个人数据搜集整理呢？我做了一个对比。

　　

　　当我选择的时侯，最看重的功能虽然是 API 支持。只有具备了 API 接口，才能使数据搜集流程可以实现自动化，也才是名副其实的「云端表格」。而使我最终选择 Airtable 的缘由，应该有如下几点：

　　基础功能同另外的两个产品相比没有显著的缺位，甚至拥有象条形码输入、iframe 嵌入等更多差异化功能。Airtable 同时支持 IFTTT 和 Zapier 云端自动化工具，且 API 使用上去更简单便捷。很多时侯，就算使用现有工具难以满足需求，也可以按照开发者文档自行编撰代码实现数据读取和写入。Airtable 外观设计愈发漂亮，这一点在长时间的使用过程中特别重要。Airtable 使用简介

　　在即将介绍我是怎样使用 Airitable 集中整理数据之前，我想先对 Airtable 做一个简单介绍。

　　如下图所示，Airtable 主要收录有 6 个基本组件，分别是：

　　

　　可以看出，Airtable 从诞生之初就具备了关系型数据库的样子，已经满足了对数据存储的日常需求。从功能上，除了 Excel Online，基本上没有竞品。

　　要想对个人数据进行集中搜集整理，首先须要在 Airtable 创建不同的数据库。建立数据库是个人数据搜集工程中的第一步，所以并不是随便乱建的。其中，我们须要先想一想搜集数据的大类，然后在细分大类中的小类，并对应到数据表中。我的数据库主要有下边 3 个，树形结构如图所示。

　　工作学习数据库

　　工作学习数据库会搜集平时我在工作或则学习中形成的相关数据。根据我的使用习惯，数据库收录了 4 张数据表，分别是：Calendar、Todoist、Trello 以及 Issues（同步 Github）。看到名子应当就很容易明白这 4 张表的意思了。

　　对于这四类服务的数据，我均是采用 IFTTT 或者 Zapier 将其同步到 Airtable 中。这里补充介绍一下 IFTTT 和 Zapier 的区别与联系。首先，二者都是整合不同应用提供的开发者 API 实现自动化流程的云端服务，这是她们的相同之处。但是，Zapier 相对于 IFTTT 会更强悍一些，它通常情况下会支持原服务更全面的 API 接口，且支持多个服务联动。相比之下，IFTTT 很多时侯只提供主要的插口，且只支持两个服务之间的数据传递。

　　

　　举个反例，当我在使用 Zapier 实现 Google Calendar → Airtable 的过程中，Zapier 支持读取 Google Calendar 中的 43 项数据（虽然有一些不实用），但 IFTTT 只支持 8 个。当然，IFTTT 也有比 Zapier 好用的时侯。比如将 Todoist 完成任务同步到 Airtable 时，Zapier 不支持检测任意 Project 下完成的任务，需针对每位 Project 设置单独的流程。

　　

　　四个服务同步到 Airtable 的设置都大同小异，这里我只拿 Todoist → Airtable 详细说明。当我选择 IFTTT 作为 Todoist → Airtable 的同步工具时，首先须要到 IFTTT 上看一看其支持读取 Todoist 的什么数据，你可以通过创建动作时查看。

　　

　　我们可以看见从 Todoist → Airtable 一共支持 7 个类别的数据。那么，现在可以先新建这个动作。注意，你须要遵循 IFTTT 制定的句型格式，才能正确地将数据写入到 Airtable 中。

　　也就是说，如果要将这 7 类数据全部同步到 Airtable，你须要在 IFTTT 动作的最后输入如下所示的内容。我习惯之间使用 IFTTT 的 ingredient 名称作为 Airtable 中的列名称。

　　格式：::airtable::Airtable 中的列名::{{IFTTT 中的 ingredient}}

　　示例内容：

　　::airtable::TaskContent::{{TaskContent}}

::airtable::LinkToTask::{{LinkToTask}}

::airtable::Project::{{Project}}

::airtable::Labels::{{Labels}}

::airtable::Priority:: {{Priority}}

::airtable::CompletedAt::{{CompletedAt}}

::airtable::DueDate::{{DueDate}}

　　接下来，就可以到 Airtable 中设置相应的列名称了。在设置对应的列属性（文本、数字、图片等）时，我建议一开始统一设置为「Single line text」，也就是单行文本格式，以避免导出数据出错。

　　

　　当测试导出成功以后，就可以调整列属性。例如这儿，Project 的数目是有限的，且每位任务只对应一个 Project。就可以将其列属性设定为 Single select（单选），这样也便捷日后对任务进行筛选。同样，日期可以使用 Date 属性，链接使用 URL 等。

　　

　　如果调整列属性以后，表格显示为空白或报错，那就意味着通过 IFTTT 传过来的数据格式并不能挺好地被 Airtable 支持。比如这儿的 CompletedAt，也就是项目的完成日期 + 时间。IFTTT 输出的数据格式是象这样的 January 20, 2018 at 10:18AM，Airtable 无法之间将其转换为对应的「日期+时间」的格式。

　　为了便捷以后的数据剖析，我们当然更偏向于将其处理成时间序列，也就是按 Airtable 中的「日期+时间」格式保存。此时，我们可以通过新建中间列作为过渡，然后借助 Airtable 的 Formula 公式将原文本列转换为可辨识的「日期+时间」列。具体步骤如下：

　　明确区别： 原文本列格式为January 20, 2018 at 10:18AM，Airtable 可辨识的格式为January 20, 2018 10:18 AM。注意观察两者之间的区别，文本格式多了 at + 一个空格 字符，同时 AM 字符前缺乏一个空格。格式转换：明白区别以后就可以开始使用 Airtable 提供的 Formula 公式转换格式。首先是去除 at 字符，然后在结尾的 AM 或者 PM 前面降低空格。

　　

　　这里使用了 SEARCH() 函数去定位要更改的位置，然后使用 REPLACE() 函数更改字符。最后再使用 DATATIME_FOMRMAT() 函数低格字符串为我们想要的「日期-时间」样式。一个小的方法是，如果你嫌降低的中间列较多，那么可以使用 Airtable 顶部菜单的 Hide fields 选项隐去不必要的列，只呈现我们须要的数据即可。

　　量化自我数据库

　　我的第二个主要数据库为量化自我数据库，它是由：Moves、Location、Apple Health、RescueTime 以及 Commute 等 5 个数据表组成。这 5 个数据表分别对应着 Moves 记录的地理位置数据、手动签到数据、Apple Health 记录的运动健康数据、RescueTime 记录的工作效率数据以及通勤时间统计数据。

　　Moves 数据

　　Moves 是我仍然在使用的地理位置追踪应用，它的运动状态辨识和地点辨识做的非常好，以至于如今都没有找到可取代的应用。Moves 其实拥有健全的 API，但因为其认证方法的特殊性，IFTTT 和 Zapier 都仍未支持与 Moves 连接。于是，我只能自己编撰一个 Moves → Airtable 的脚本，然后布署在云服务器上，每天手动将今天形成的数据同步的 Airtable 中去。

　　

　　实现的过程比较麻烦，都能凑够一篇文章了，另找时间再细说。这里，Moves 的数据收录有经纬度信息，你可以直接使用 Airtable 提供的 Map Block 模块对地理位置可视化。

　　

　　关于 Airtable Blocks 的更多介绍，可以阅读官方的文章《Getting started with Airtable blocks》

　　Location 数据

　　除了使用 Moves 自动记录地理位置信息，我还自己制做了一个辅助签到的 Workflow 用来标记我觉得重要的地点，并把地理位置数据实时上传到 Airtable 中的 Location 数据表中。

　　

　　Workflow 非常简单，流程如下：定位 → 解析数据 [街道 - 城市 - 地区 - 国家] → 解析数据 [经度 - 纬度 - 高度] → 结合当前时间一并上传到 Airtable 中。

　　

　　Apple Health 数据

　　目前，追踪健康信息主要是使用 Apple Watch 和 iPhone，通过本身的健康应用以及配合 Moves，Autosleep 等第三方应用完成。Apple Health 无法实现 iCloud 同步，更没有 API 支持，所以只能*敏*感*词*同步到 Airtable。我采用的方式是定期从 Apple Health 中导入数据文件到 Dropbox 中，Dropbox 的数据压缩包会手动同步到云服务器中，再由云服务器中布署的 Python 脚本手动完成数据解析，并通过 API 同步到 Airtable 的表格中去。

　　RescueTime 数据

　　工作效率记录我会使用到 RescueTime 应用，RescueTime 会手动记录各种程序的前台运行时间，再和数据库进行比对得到相应应用属于效率应用还是非效率应用，从而手动统计每晚的工作效率。

　　RescueTime 的数据同步到 Airtable 就比较便捷了，可以使用 IFTTT，Zapier 或者开发者插口同步。我选择的是 Zapier，因为它可以同步多达 59 项数据信息。触发的动作选择「当每日数据汇总后」，然后再将对应的数据更新到对应的列即可。过程十分简单，就不再赘言了。

　　

　　这里介绍一个使用 RescueTime 的一个小技巧，那就是最好定期去自动标记相应应用的效率属性。首先，我们每晚浏览的大多数网页或则使用的应用都是比较固定的，手动标记耗费的时间不多。其次，有一些应用对每个人的效率属性不一致。比如，我早已好多年没用 QQ 作为和他人的聊天工具了，所以但凡当使用 QQ 时，基本上都属于处理工作里面的事情，它对于我而言就是效率状态，而不是闲暇状态。

　　通勤时间数据

　　Commute 表拿来统计我的通勤时间。每天，我就会选择轻轨作为下班通勤的主要交通工具，虽然轻轨在站与站之间的运行时间比较确定，但因为存在换乘，所以每晚的通勤时间的变化就比较大了。打个比方，有时候晚上只晚出发 5 分钟，如果刚好赶上一波高峰，实际抵达公司的时间常常会晚 20 分钟。所以，我从年初就开始每晚记录自己的通勤时间，打算等到数据累计到一定量以后，通过数据剖析得到自己每晚的合理出发时间。

　　在记录通勤时间的时侯，由于打算将数据保存到 Airtable，所以一开始就直接就排除了现有的计时器或则第三方 App，然后把目标集中到 Workflow。但是，很快我就发觉 Workflow 的现有动作中，并没有支持在后台完成计时的动作。后来，我就想到了直接利用 Airtable 来完成这个功能，这个功能的逻辑十分简单。流程如下：

　　

　　每天从屋内出发的时侯，点击 workflow 将此刻的时间上传到 Airtable，并记为出发时间。当抵达公司时，再次点击 Workflow 将时间上传到 Airtable 。由于 Airtable 本身可以使用数据函数，就能估算出两个时间差，并直接在我第二次点击 Workflow 上传时间后，将估算好的通勤时间推送到手机上。这样，既可以实时见到记录出来的通勤时间，也不再须要二次过程将数据上传到 Airtable 中。

　　

　　信息存档数据库

　　信息存档数据库是拿来保存我觉得有必要存档的互联网数据。其中，主要有三个 Tables，分别是：微博、博客以及稍后读。

　　我喜欢定期清空自己的微博，防止在互联网上留下过多的「? 历史」。但又不想扔掉自己转发过的微博，于是就有了这个微博存档表。存档微博的方式十分简单，使用 IFTTT 新建一个动作，实时将微博记录到 Airtable 中保存。

　　

　　同样，我使用 Pocket 作为稍后阅读工具，也就通过创建 IFTTT 动作，将保存在 Pocket 中的文章同步存档到 Airtable 中。

　　除此之外，博客存档表拿来备份自己在互联网上创作的内容。比如在少数派写的文章以及自己的博客文章。该表单使用了自己编撰的 Python 脚本，定期将我的博客文章以及在少数派发表的文章同步保存到 Airtable 中。

　　其他数据库

　　除了前面提及的这三个主要的数据库，我还有几个自己比较喜欢的数据库，也分享一下。

　　票据存档数据库

　　票据存档的数据库主要是记录平时我觉得比较重要的支票、*敏*感*词*、合同文件等。当然，超市购物小票这类不太重要的票据也就没必要存档了。

　　

　　教育让利统计数据库

　　几个月前，我在少数派写过一篇 《在校师生福利：Apple、微软、Adobe 等产品怎样通过教育让利订购》 ，这篇文章中介绍一些院校中学生可以享受的教育让利项目。不久前，我通过 Airtable 整理了一份愈发详尽的教育让利表单，希望更多的中学生能享受到优价有品质的服务。

　　

　　你可以通过检索的形式来获取自己感兴趣的教育让利项目。当然，我也号召你们来一起建立这个表单。如果有一些教育让利项目非常好，但表单中未涉及到，欢迎直接通过下边的链接补充递交到表单中去。

　　菜品、餐馆统计数据库

　　最近，我正在建立的一个数据库来源于我生活中的一个疼点，那就是常常不知道喝哪些。这个数据库中会记录下一些餐厅和食材。我会将平时喝过觉得不错的，或者想吃的餐厅信息添加到餐厅数据表中，同时会记录一些做过或则想做的菜肴。

　　当我自己想做饭喝的时侯，我都会通过 Workflow 随机返回食材作为灵感，而想出去喝的时侯，也可以随机返回餐厅信息。目前，这个数据库和 Workflow 还没有完全做好，等建立以后，会同你们一起分享。

　　另外，文中提及的一些自动化数据获取的 Python 脚本，我也会整理后择时与少数派读者分享。

　　结语

　　我虽然很早就晓得 Airtable 了，但真正有效地借助上去也是近一年才开始的。目前，虽然 Airtable 已经帮我存出来不少的数据，但是我对它的借助程度还并不满意，今年我会继续开掘 Airtable 的「正确使用方法」。

　　如今，我们都晓得经常须要备份自己的相片、手机、电脑，防止资料遗失。除此之外，我们同样应当注重起自己每晚形成的其他数据。目前初步构建上去的数据集中搜集模式只是开始。等待数据积累到一定量时，就须要着手「数据集中剖析」，使其真正地能帮助自己发觉某个坏习惯，提升一些效率，改变一些东西。

　　少数派一年一度的奖品超级优厚的 征文活动 又开始了！我们打算了 5 万+ 的奖品等你来拿。

　　本文是「我是少数派，这是我的 2017」征文活动的第入围作品。