[合作] 游兰教授团队在图数据分析与可视化方向的事宜

[will-ww]

基于我们 29 日讨论的结果（记录文档），初定本周完成如下几个工作：

• 游兰教授的开源研究团队成员，以外部协作者的身份，导入到 X-lab 的“语雀”空间 @bifenglin
• 在“语雀”中进行团队设置、权限设置等操作，使其能方便地进行协作 @tyn1998
• 在 GitHub 中 X-lab 组织下面，加入 Prof-You 团队，并加入相关人员 @bifenglin
• 文章翻译工作的支持，基于 GitHub 的翻译流程设计 [Task] 设计并迭代一个开放式的翻译流程 #72 @xiaoya-Esther
• 完成 ClickHouse 的数据库重构，制作 2020 年 GitHub 全域数据镜像（6月15日之前） @frank-zsy
• 完成 ClickHouse 上的 github-explorer 项目到新的数据镜像上的迁移 @frank-zsy

[frank-zsy]

GitHub explorer 的示例已迁移完毕，具体可见 https://github.com/X-lab2017/open-digger/blob/master/notebook/clickhouse_demo.ipynb 。

总体而言，都是些较简单的统计工作，实际意义不大，可以用于熟悉 Clickhouse 的 SQL 语法。

[will-ww]

GitHub explorer 的示例已迁移完毕，具体可见 https://github.com/X-lab2017/open-digger/blob/master/notebook/clickhouse_demo.ipynb 。

总体而言，都是些较简单的统计工作，实际意义不大，可以用于熟悉 Clickhouse 的 SQL 语法。

Great, many thanks~

下学期，我的导论课程，也用这个教程了~

[frank-zsy]

关于数据镜像制作，之前的数据统计有问题，目前 2020 年全年的日志数据量大约为 8.8 亿条，即使用 Clickhouse 最高效的 Native 格式导出，也需要大约 900GB 的数据量。即使仅使用日志量最多的 10W 个项目数据，数据量也在 3 亿条左右。总体而言数据量还是过大。

[will-ww]

关于数据镜像制作，之前的数据统计有问题，目前 2020 年全年的日志数据量大约为 8.8 亿条，即使用 Clickhouse 最高效的 Native 格式导出，也需要大约 900GB 的数据量。即使仅使用日志量最多的 10W 个项目数据，数据量也在 3 亿条左右。总体而言数据量还是过大。

这个确实很大，我们想想怎么弄合适~

[frank-zsy]

其实要看分析诉求是什么，如果他们有预算，也可以在云上弄一个 Clickhouse 实例，一般从局部分析的角度出发，是不一定需要全域数据的，例如 Apache 的所有数据、Google 的所有数据、按时间的采样数据等等，全域数据的量怎么都是很大的，不太适合进行常态化的分发。

[will-ww]

其实要看分析诉求是什么，如果他们有预算，也可以在云上弄一个 Clickhouse 实例，一般从局部分析的角度出发，是不一定需要全域数据的，例如 Apache 的所有数据、Google 的所有数据、按时间的采样数据等等，全域数据的量怎么都是很大的，不太适合进行常态化的分发。

嗯，我来提出一些设计点吧，也不是专门为了他们，想慢慢把数据出版这件事情做起来了~

[bifenglin]

已经完成游老师团队在语雀和github中的人员添加与团队设置。

[will-ww]

关于数据镜像制作，之前的数据统计有问题，目前 2020 年全年的日志数据量大约为 8.8 亿条，即使用 Clickhouse 最高效的 Native 格式导出，也需要大约 900GB 的数据量。即使仅使用日志量最多的 10W 个项目数据，数据量也在 3 亿条左右。总体而言数据量还是过大。

貌似昨天的讨论可以回答这个问题了：X-lab2017/open-perf#27

数据集小于100G，应该是个比较合适的，有几个问题问一下：@frank-zsy

• 这个数据集从 2011 年开始的，到什么时候？
• 这个数据集是否拥有我们需要建图所需要的所有信息？
• 这个数据集，是否能够按照我们提出的活跃度和影响力进行计算出结果？

如果以上回答均是，我觉得直接给到游兰教授团队就可以了，即便不是，其实也是可以的~

[will-ww]

翻了下这个项目的 issue，貌似有些问题可以回答了，而且有些有意思的内容：

• GitHub issues burndown chart & survival analysis ClickHouse/github-explorer#8
• How often dataset updated? ClickHouse/github-explorer#6

[frank-zsy]

他的数据集是 2011 到 2020 年底的。就目前建图而言，信息是完整的，也可以计算活跃度和影响力。但也有很多做不了，例如邮箱域名统计。

但他的构建方式有一个致命的问题，就是没有存项目和开发者的 ID，这对有过改名的项目非常不友好，没有办法在时序上关联，这与我们现在使用的方式是完全不兼容的，而且这意味着这个数据集肯定无法在生产环境使用。而且建图时没有办法关联改名的项目，这会是巨大的问题，例如微软的 org 名就改过，他的数据集无法关联改名前后的 VSCode 项目，会因为项目名不同而变成两个项目。

我也在思考为什么他的数据集会小很多，目前看到的可能包含几点：

• 他的 body 列是复用的，也就是说无论是 issue、PR、comment、review comment，内容都是存在 body 列，这可以大幅减少冗余，但每行的数据是不完整的，如果要做内容分析，就需要提取多行的数据。但其实这也是可以接受的，虽然使用上会较困难，但数据存储的压力很小。
• 所有与时间相关的列，在导出时没有数据的列默认都是 1970-01-01 00:00:00，这会导致出现大量的空时间列占据较多字符空间的问题。但我不确定这是不是我的问题，因为建表方式上我们是一模一样的，理论上他的表导出时也会如此，可能需要验证一下他的数据。
• 另外就是他丢掉了很多字段的数据，这与数据周期也有较大关系，由于要兼容 2011-2014 年的数据，导致有些列不包含在他的数据里，这也会使得他的数据小很多。

以上是我感觉他的数据会比较小的几个重要的因素。

[will-ww]

以上是我感觉他的数据会比较小的几个重要的因素。

那我基本理解了，我们有两个选项，看觉得哪个合适：

原则：进 OpenPerf 主要是科研与教学目的的数据，可以不用考虑生产需求；而 OpenDigger 产出的，是需要保证生产需求的。可以有交集的部分，但不强求。因此，OpenPerf 的定位主要是创造学术影响力，协同高校、科研院所、跨学科等的智力资源。

1. 我们自己生产一套类似的数据，对数据集做压缩优化，丢掉一些不必要的，包括缩短年份（例如1年），控制在 100G 左右；这样做的好处主要是，可以尽量兼容 OpenDigger，研究成果迁移到 OpenDigger 中相对容易；
2. 直接用他的这个数据，我们什么也不用做，也可以更灵活的引入其它第三方数据，缺点是只能收获想法层面的，如果觉得有用，还是需要移植到 OpenDigger 中去。

长远来看，可以开发一个数据生成器，从我们的原始数据上可以根据需求定制各种数据集（时间、范围、时间类型等等），以供各种用途。

我在想，创新效率和工程效率，是否何以适当兼顾下~

[frank-zsy]

是的，最好的方式还是能够进行统一，都归到 OpenDigger 下面，用统一和完整的一套数据格式和数据内容来做，否则长远来看是有局限性的，我拉一下目前所有列的数据空间占用情况：

看起来确实是 issue_body 占用了较大的空间，大约占到了总数据量的 31%，如果 body 列复用可以大幅度减少数据库的用量，这块我可以优化一下。

另外 push_head 和 push_before 存储的是 commit 对应的 Git SHA 值，也占用了较大的空间，这块在我们的第一版数据结构中是没有的，后来加入是由于 PR 和 commit 的关联是需要通过 SHA 值来做的。这块的分析诉求不多，例如 PR 的作者邮件域分析是需要的。但可能存储空间上却占了一大块，也可以考虑去掉。

而且 commit message 在他的表中也是不存储的，目前我们也还没有对 commit message 的文本分析，但不确定之后是否会有。

其实数据镜像的生成工程上并没有很大的难度，目前主要还是数据量导致的网络 I/O 开销，如果可以减少数据量，就可以方便的做一些分发工作。

[frank-zsy]

目前可以考虑的优化点：

• issue_body, issue_comment_body, pull_review_comment_body, commit_comment_body 合并为 body 列
• 除 created_at 列以外，所有 DateTime 相关列修改为 Nullable(DateTime) 类型，不会因为缺失数据置入默认值
• 删除 push_before 列，push_head 列用于对 PR 和 Push 事件进行关联，还是需要存储的
• push_commits.message 列保留，commit message 长远来看还是存在分析的价值的

上述优化后可以看下导出数据量的情况。

[will-ww]

非常赞同！好的，那我们就还是坚持 OpenDigger 的一致性，等你重构与优化好后，看看数据量的情况，many thanks~

[frank-zsy]

上述优化项已完成并开始重新导入，大约需要两天左右完成，目前导出来看，日期类列不会再出现默认值情况

[frank-zsy]

关于数据镜像制作事宜同步如下：

• 修改结构后的数据导入已完成，较之前的方式总体存储空间减少
• 考虑可扩展性，静态数据制作方式设计如下：
  • 使用标准的定制化 Clickhouse 服务器镜像作为统一的启动镜像
  • 静态数据以 Native + tar.gz 压缩方式随表结构文件打包上传到 OSS
  • 使用者下载数据文件，启动服务器镜像时挂载数据文件到容器指定目录
  • 容器在第一次启动初始化时加载并导入数据，导入完成后设置标志位，以防止后续启停时重启导入
• 目前大致的估算基准参考如下，数据规模均为每一亿条日志数据：
  • 导出为 Clickhouse Native 格式数据存储空间约 94 GB
  • 数据压缩为 .tar.gz 文件后的存储空间约 9.5 GB
  • 导入到 Clickhouse 服务器镜像后存储空间约 15 GB
  • 2.4 GHz 4 核 4 GB 内存容器中导入时间约为 35 min
  • 使用 Native 格式导入时内存用量不超过 3 GB
• 按上述估计，以 2020 全年数据为例：
  • 总数据量约 8.5 亿条
  • 导出为 Clickhouse Native 格式数据存储空间约 802 GB
  • 数据压缩为 .tar.gz 文件后的存储空间约 81 GB
  • 导入到 Clickhouse 服务器镜像后存储空间约 125 GB
  • 总导入时间约 5 小时
  • OSS 地址 https://oss.x-lab.info/sample-data/2020/data.tar.gz

以上流程可作为标准流程进入 OpenDigger，我后续会在 OpenDigger 中上传相关脚本，包含：

• 标准的数据制作 shell 脚本，流程为：
  • 可外部传入 SQL 文件作为采样数据查询语句
  • 导出整体表结构
  • 导出相应数据
  • 压缩为 .tar.gz 文件
  • 压缩文件上传至 OSS
• 定制化 Clickhouse 服务器镜像的制作文件，包含：
  • 基于官方镜像打包定制化镜像的 Dockerfile 文件
  • 定制化镜像中用于初始化数据库的 shell 脚本文件
• 用于启动特定数据集的 Clickhouse 服务器容器的启动脚本示例

使用方的最大挑战为：

• 磁盘空间需要大小为压缩前+压缩后数据量，以 2020 全年为例，需 802 + 81 GB，近 1 TB 存储空间
• 内存用量约 4 GB，可满足基本的导入和简单查询。复杂查询需 32 GB 以上内存

[will-ww]

感谢 Frank 的基础性工作，实在太棒！

[will-ww]

完成 Translation Guidance.md，整个 issue 中的内容基本上就完成了~ @xiaoya-Esther #72

[frank-zsy]

根据该文档：https://github.com/X-lab2017/open-digger/tree/master/sample_data 可以进行采样数据的集成工作。

目前尚未完成：

• 2020 全年数据的上传。2020 年全年数据从数据库导出到本地压缩后上传到 OSS，总体数据约 1TB，即便不算压缩时间，若网络带宽稳定在 5MB/s，总网络时间需要 60 小时左右。总体制作时间约在 3 天。若出现网络抖动，时间可能更久。
• Clickhouse 的基础镜像上传到实验室 docker hub。

已全部完成，具体详情见上述链接。

[tisonkun]

他的 body 列是复用的，也就是说无论是 issue、PR、comment、review comment，内容都是存在 body 列，这可以大幅减少冗余，但每行的数据是不完整的，如果要做内容分析，就需要提取多行的数据。但其实这也是可以接受的，虽然使用上会较困难，但数据存储的压力很小。

为什么说每行数据是不完整的呢？

BTW 这种交流方式似乎 Discussions 的 Thread 会舒服一点..

[frank-zsy]

@tisonkun 我来晚了。这里不完整的意思是例如对于 IssueCommentEvent 类型的事件，body 列只会存储当前评论的内容，而如果是用多列分开的，那么原始 Issue 的内容也会在这一行中。如果在分析评论时也想得到 Issue 的内容，就需要去提取对应的 IssuesEvent 行了。