序言
在 2023 年度总结 - 游戏篇#序言 中我曾提到要单独写一篇 gal 的年度总结，虽然 VNDB 本身支持导出用户数据和时长，但毕竟和 HLTB 目的不同，对于数据没有那么多可视化（但是不同视觉小说，乃至开发商关联的可视化做得还是不错的）。由于 length votes 与 user list 分开储存，同时需要兼顾 VN 和 release，导出的 XML 层级究级混乱，我不想再经历 HLTB Linear & Temporal Breakdown#Bar Chart Race 那种补全缺省项的恶梦，于是乎连夜调教 GPT3.5-16k 写了一个 VNDB 数据导出脚本，虽然 bug 很多，但比手动校正 XML 还是好用多了。
介绍
之前在 HLTB Linear & Temporal Breakdown#Conclusion 就提到过，对于数据分析本身我感觉良好，但在如何找到数据间的关联这方面，我还有所欠缺。为了分析 VNDB 数据，恰好尝试了自动化数据分析工具 Rath，被称为 Tableau 的开源替代，而且数据通过浏览器 IndexDB 存储在本地，所以安全性还🉑️，一些相关链接：
搜了一些资料，感觉自己部署也不是很难，于是开始折腾自建。
自建
Vercel 直接部署失败
首先直接 fork 后关联 repo，尝试在 Vercel 上直接运行，配置如下：
- Install command:
yarn install - Build command:
yarn workspace rath-client build
构建都正常，然而运行出错，如果在 build command 加 yarn workspace rath-client start 会弹窗提示无效。
GitHub Action 打包
好在 Vercel 的运行日志很完整，通过观察构建结果，发现和解压后的 chatchan-dist 有点像，感觉就是 React 打包之后的样子，于是乎魔改了一下 Rath 自带的 GitHub Action，添加了手动打包和上传打包功能：
首先修改 auto-build.yml 中的触发分支，默认是 main 然而公开的默认分支是 master，并且添加手动运行功能：
on:
push:
branches: [master, dev]
#pull_request:
# branches: [master, dev]
workflow_dispatch:
然后添加上传打包功能，理论上只需要压缩上传整个构建文件夹为 artifact，然后每次用 GitHub Action 构建项目不得不吐槽的路径问题（不局限于前端框架，像构建 Android app 也会遇到，而且 Gradle 打包的位置更加奇怪）又出现了，由于太久没用 （找不到抄的例子） 花了不少时间试错才想起来要用 tree ./ 暴力枚举：
jobs:
auto-build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [16.x]
steps:
# ...
- name: build project
run: |
sudo apt install -y tree
mkdir -p dist
yarn install
yarn workspace rath-client build
tree ./
tar -zcvf rath-dist.tar.gz packages/rath-client/build
mv rath-dist.tar.gz dist/
- name: save build as artifact
uses: actions/upload-artifact@v3
with:
retention-days: 14
name: rath-dist.zip
path: dist
最后发现路径配置保存在 buildspec.yml 中：
artifacts:
files:
- 'packages/rath-client/build/*'
name: 'rath/$AWS_REGION-$(date +%Y-%m-%d)'
于是移除 tree 命令快乐运行 workflow，终于成功构建。
Vercel 部署打包
将 artifact 下载到本地，解压，用 Vercel 部署，访问域名，一气呵成。 检查发现能够顺利运行，研究了一个多小时终于没白费力气。
使用
官方源码中自带数个示例数据，直接根据 #介绍 中的几个链接上手操作几分钟就能熟悉个大概。这里我就用 2023 年 HLTB 部分个人数据来演示，算是补全 HLTB Linear & Temporal Breakdown 没能多画几个表的遗憾。
平台和评分的柱状图看着还可以，不过可以设置上限却不能设置下限的设计有点迷，而且不能对数据进行预处理，这一堆长长的平台名看得密集恐惧症都犯了……
鬼畜的各平台平均分随时间增长的折线图，不能说毫无逻辑，只能说是鬼画符。探索列表中大部分数据都是如此，主要还是没有语义分析，不能根据标签判断数据的潜在关联，这点上还不如 ChatGPT，很多时候单看数据是什么都看不出来的。
感想
由于在 PostgreSQL 踩坑 & Vercel 搭建 Cusdis 心得 之前一直有意避开数据库，加上受 为什么：关于因果关系的新科学 这本统计学批判书影响，总觉得数据分析需要想像力，没想到有 Tableau 和 Rath 这种自动化分析探索工具，使用起来确实很便利。
不过一方面如果要对数据进行批量操作，而不是单纯分析，就需要提前处理，这点就限制了工具的使用范围（更别说好多人拿来当数据库用的 Excel，在支持 Lambda 函数 和 Python 后实用性再度大幅提升）；另一方面，难以免除主观因素的影响，「数据探索分析」的几种方法，都有强行关联之嫌。对于部分显而易见的因素，分析师可以根据自身经验直接确定或排除；但对于很多抽象概念而言，彼此的因果关系没有那么明确，还是需要深入探究，而不是为了写一份表面上图文并茂的分析报告强加因果，然后以讹传讹。有一说一，好多投行和企业的战略投资部门就是这么干的。
但就工具本身而言，只要不是刻意的设计（比如根据想要的结果一键修改对应数据，并扩充大量虚假数据），也说不上对或错，全看使用方式。比如在 DQ11S 中，勇者的最强武器「勇者之剑」，在被魔王夺走之后还会恶堕变成「魔王之剑」（大概，22 年退出 XGP 前夕花了 9 天全成就速通的，隔得太久忘得差不多了）。就我而言，能够避免繁杂的数据清洗，还有半自动探索，就足以在非 CI 场景使用 Rath。