OpenSODA 挑战赛的初赛问答与赛题解读

[will-ww]

随着 OpenSODA 挑战赛的报名启动，本周需要完成两件事情，方便后续继续推动：

• [x] #266

赛题解读：

• [x] 「💁赛题解读」OpenSODA 赛题解读一览」
• [x] T1：OpenDigger 指标的实现与优化 @xgdyp
• [x] T2：命令行交互的指标结果查询子模块 @xiaoya-yaya
• [x] T3：基于机器学习的指标拟合与优化 @frank-zsy
• [x] W1：可视化艺术作品或数据洞察报告 @tyn1998
• [x] W2：开源领域的可视化大屏 @zhicheng-ning
• [x] W3：开源协作网络可视化 @frank-zsy

截至时间：4月1日

[will-ww]

赛题解读的模板，可以包括以下几个部分：

• 背景介绍：重点介绍相关背景知识
• 任务介绍：重点介绍本赛题任务重点需要做什么，交付物的形态是什么，以及如何提交
• 示范案例：尽量找相关或相似的范例，作为一个参照与指导

[tyn1998]

作品提交这个重要环节，我感觉要讨论并且明确一下。目前我有一个idea是：无论是任务类还是作品类，最后都要提供一个markdown文件作为参赛作品的介绍，并提交到统一的地方作为汇总，至于这个markdown里要包含什么内容可以再细化。

那有个问题就是这个作品介绍markdown提交到哪里去？我认为合适的是：

• https://atomgit.com/x-lab/OpenSODA
• 或 https://github.com/ECNU/OpenSODA

选择其中一个即可，另一个仓库作为同步。我倾向于把ECNU/OpenSODA作为活动仓库，AtomGit上的作为镜像仓库。

[tyn1998]

大家好，我捋了一些思路：

关于赛题解读

• 这两天我们会利用语雀发一篇『赛题（or赛制）解读』，这篇文章首先会给出一个整体的解读（例如难度和奖项高低是否有关系、是否支持参加不同队伍等、复赛怎么提交、决赛怎么提交），然后列出各个赛题的解读文章，也就是这个issue的6个task对应的语雀文章。
• 在每篇赛题解读文章的“任务介绍”小节，需要明确“1+X”的交付物形态，即一个README（介绍入口）和其他材料（如代码、视频演示等等）。复赛和决赛的交付物形态都是“1+X”，都需要明确。
• 至于“1+X”的README内容结构和X对应哪些材料，每个赛题的负责人自行决定。例如，复赛只要求提交方案就行了，可能“1+X”就是1个README+1个PPT。
• 各个赛题解读文章只需要明确“交付形态”，不需要说明“如何提交”。 “如何提交”在「赛题(or赛制)解读」中给出。

如何提交

上面提到，在「赛题(or赛制)解读」中，会说明“复赛怎么提交”、“决赛怎么提交”。我的想法是：

• 在“复赛怎么提交”中，我们表达“在初赛结束后另行通知”的意思
• 在“决赛怎么提交”中，我们表达“在复赛结束后另行通知”的意思

因为“如何提交”还需要进一步设计。不过目前我有一些想法：

• 在复赛/决赛成绩出来前，用金数据问卷（“上传附件”功能）收集“1+X”交付物。我体验了一下，非常好，估计要花100元开通10GB的容量包。
• 在复赛/决赛成绩出来后，让晋级队伍用PR的方式把“1+X”交付物提交到OpenSODA仓库中。
• 这是为了公平竞争，防止抄袭和纠纷。模仿了OSPP的做法，OSPP会在中选结果出来后再公布各个申请者的申请书。

[zhicheng-ning]

• [x] W2：开源领域的可视化大屏 @zhicheng-ning

已完成~

[xiaoya-yaya]

• [x] T2：命令行交互的指标结果查询子模块 @xiaoya-yaya

已完成

[bifenglin]

其中一些建议和不明白的地方：

1. T2:该子模块最终形态应该是一个至少可以通过 npm 安装的 CLI 工具，安装后，用户可以通过一系列的命令达成以下查询功能：

修改建议： 该子模块最终形态应该是一个可以运行的 CLI 工具，安装后，用户可以通过一系列的命令达成以下查询功能：

2. T3:OpenRank的数据在哪下载？只获得了项目名称，没有确定的值。评判指标最好标出公式说明。

[xiaoya-yaya]

T2:该子模块最终形态应该是一个至少可以通过 npm 安装的 CLI 工具，安装后，用户可以通过一系列的命令达成以下查询功能：

修改建议： 该子模块最终形态应该是一个可以运行的 CLI 工具，安装后，用户可以通过一系列的命令达成以下查询功能：

已修改～

[birdflyi]

T2 待确认：

1. 部分链接失效： 失效位置：“详细内容参考【这里】”
2. 术语讨论： “具体仓库”等似乎是“specific repository”的译文，另有一种常见译文为“特定仓库”，建议使用表示逻辑词汇的“特定”，可比较方便地区别于“任一”、“所有”、“全不”。
3. 自然月参数： 自然月使用month比date要好一些。（ps：若有统一月份格式的需要，碰巧我用python实现了月份的格式转换工具可供参考https://github.com/birdflyi/db_engines_ranking_table_crawling/blob/main/script/time_format.py）

[birdflyi]

T3 待确认:

1. 必要的链接： 建议添加必要的链接：“访问 OpenDigger 项目 GitHub 【README】”，其中README
2. 统一部分格式： 建议数据集统一查询语句（若数据查询本身属于任务，则时间月份month和项目名称repo_login等参数名可统一，预测结果的list变量类型、元素数值范围及有效位等要求可统一给出，便于后续测试）：“使用 2022 全年全域 OpenRank 全球 Top300 项目为样本，使用其 2023 年之前的所有数据为训练集，2023 年 1 - 3 月的数据为验证集。”
3. CHAOSS 统计型指标的说明： 其所含指标的范围说明或说明文档的链接是否必要？使用新指标的时间空间复杂度范围（如基于时序迭代的其他rank指标是否在此范围）是否需要说明？参赛者使用新指标的权利责任（如原创性和使用权归属、因新指标导致的超时限风险）是否需要声明？

[xiaoya-yaya]

T2 待确认： 部分链接失效： 失效位置：“详细内容参考【这里】” 术语讨论： “具体仓库”等似乎是“specific repository”的译文，另有一种常见译文为“特定仓库”，建议使用表示逻辑词汇的“特定”，可比较方便地区别于“任一”、“所有”、“全不”。 自然月参数： 自然月使用month比date要好一些。（ps：若有统一月份格式的需要，碰巧我用python实现了月份的格式转换工具可供参考https://github.com/birdflyi/db_engines_ranking_table_crawling/blob/main/script/time_format.py）

已修改，感谢娄博

[bifenglin]

W3：不建议开放clickhouse数据库，涉及很大的运维问题，可以直接提供一年的结构化数据，利用文件服务器的形式让用户下载。文件服务器搭建可以参照 https://xlab2017.yuque.com/me1x4f/openperf/mttwn3

[will-ww]

考虑到整个比赛的节奏与便利性，以及尽量轻量级的运营，咱们是否可以这样：

• 初赛：知识问答，出题即可，其他啥都不用提供；
• 进入复赛（估计150支队伍）：给进入复赛的同学提供统一的一份样例数据下载，覆盖6个赛题即可
• 进入决赛（估计50支队伍）：根据队伍的方案，可以定制化提供数据接口
• 决赛排名（16只队伍）

因此，就是要在复赛的时候（5月8日）提供一批开放数据即可，请@bifenglin 来统筹设计下，@birdflyi 帮忙辅助~

[bifenglin]

考虑到整个比赛的节奏与便利性，以及尽量轻量级的运营，咱们是否可以这样：

• 初赛：知识问答，出题即可，其他啥都不用提供；
• 进入复赛（估计150支队伍）：给进入复赛的同学提供统一的一份样例数据下载，覆盖6个赛题即可
• 进入决赛（估计50支队伍）：根据队伍的方案，可以定制化提供数据接口
• 决赛排名（16只队伍）

因此，就是要在复赛的时候（5月8日）提供一批开放数据即可，请@bifenglin 来统筹设计下，@birdflyi 帮忙辅助~

年 | 说明 | 数据量 -- | -- | -- 2015 | 2015年github_log数据 | 212221628 2016 | 2016年github_log数据 | 320726236 2017 | 2017年github_log数据 | 412942763 2018 | 2018年github_log数据 | 479185525 2019 | 2019年github_log数据 | 605544846 2020 | 2020年github_log数据 | 863415606 2021 | 2021年github_log数据 | 998564686

整体数据量是逐年递增的，每年的数据压缩后估计会有几十个G，个人建议直接拿2020年数据来展示即可，原因是图结构若是没有足够的关系很难形成规模化的图连线。需要计算出2020年每月的openrank值，来满足T1，T2，T3的题目要求。目前计划自己购买大流量的服务器自己搭建或者使用网盘。

[tyn1998]

选择其中一个即可，另一个仓库作为同步。我倾向于把ECNU/OpenSODA作为活动仓库，AtomGit上的作为镜像仓库。

@will-ww 王老师，我之前期望能使用镜像仓库这个功能实现自动同步，但是GitHub只支持将其他服务器上的Git仓库自动同步到GitHub，而不支持把GitHub的仓库同步到其他。

所以以后的同步方式是：

• ECNU/OpenSODA 作为活动仓库
• 「同步者」密切关注，如果ECNU/OpenSODA的main分支有更新，「同步者」需要在本地手动git pull upstream-github main
• 本地的Git仓库中同时设置了AtomGit OpenSODA仓库的remote
• 「同步者」手动推送到AtomGit：git push -f upstream-atomgit main:master（两个仓库的主分支名不一样）

这名「同步者」需要有AtomGit的OpenSODA仓库的写权限，本地需要至少track两个remote分支：

有没有毛遂自荐的「同步者」 😃 ？ @Zzzzzhuzhiwei @lhbvvvvv @wj23027 @andyhuang18

[bifenglin]

补充说明：

1. T3赛题提议：

   • 我们T3题目可以开放一些，提供数据集在上面做数据挖掘相关任务，查找有趣的现象，然后提供一个备选的openrank拟合指标。意思是鼓励大家用机器学习等方法进行探索。题目开放个口，例如：在开源社区中，通常会有各种指标用于衡量项目的质量和效率，如代码质量、测试覆盖率、代码可读性等。然而，这些指标的计算和优化往往需要大量的人力和时间，而且很难考虑到所有的变量和复杂性，因此在实践中往往不够准确和高效。因此鼓励大家挖掘里面的各种需求，但是需要自己提供数据集和评测指标。

   • T3只要求了对repo的openrank值进行拟合，我建议也添加上对应的actor，可以大家自由进行探索拟合。actor的openrank值与repo具备同样的意义。

   另外还需要 @frank-zsy 来提供actor和repo的openrank值。

2. W3赛题因为需要进行大规模图可视化，所以我们应该需要进行初加工一下，但是加工图数据造成的连边数量级过于大。因此我建议用之前做的三个大型社区内的actor issue pr的网络数据。

[tyn1998]

2. W3赛题因为需要进行大规模图可视化，所以我们应该需要进行初加工一下，但是加工图数据造成的连边数量级过于大。因此我建议用之前做的三个大型社区内的actor issue pr的网络数据。

三个大型社区是指三个仓库吗？如果是那样的话也太少了 😆 像OpenGalaxy这种应用是需要全域范围内数据（当然也有过滤）的，两三个仓库完全没效果了。。如果有可能，并且有合适的方式，尽量提供一个时间跨度大、包含repo和developer多的数据集。

当然，这只是我不考虑数据提供侧，只考虑应用侧的想法。

[bifenglin]

@tyn1998 OpenGalaxy目前的数据集是哪里的？若是阿里云OSS里面的大文件一次性加载需要多大的流量？

[frank-zsy]

关于题目 T3 的数据说明：

由于 T3 题目所使用的所有数据都已经在 OpenDigger 中公开发布，题目中已经给出需要使用的 300 个仓库的名称，而这 300 个仓库所对应的所有数据都已经发布在 OSS 中，因此参赛者可以直接使用对应的数据来进行拟合，不需要额外提供数据集。当然，如果考虑到可能有选手不会使用 HTTP 请求或 Curl 来获取网络数据，也可以打包一份对应的离线数据集，但个人感觉意义不大。

[bifenglin]

关于题目 T3 的数据说明：

由于 T3 题目所使用的所有数据都已经在 OpenDigger 中公开发布，题目中已经给出需要使用的 300 个仓库的名称，而这 300 个仓库所对应的所有数据都已经发布在 OSS 中，因此参赛者可以直接使用对应的数据来进行拟合，不需要额外提供数据集。当然，如果考虑到可能有选手不会使用 HTTP 或 Curl 来获取网络数据，也可以打包一份对应的离线数据集，但个人感觉意义不大。

那么就不需要单独提供一份离线数据集了。

[frank-zsy]

关于题目 W3 的数据说明：

题目 W3 是网络展示型任务，需要网络数据支持。目前 OpenDigger 发布的网络数据有两类：

• 一类是仓库自身的内部协作网络，以月为维度发布，具体可见 OpenDigger README 中关于 Network 指标中的 Project OpenRank 的部分。目前支持阿里开源开发者贡献排行榜、XSOSI 所有参与项目以及 Apache Pulsar、Redis、Sealos 等数十个仓库的数据。我认为这部分是可以很好的支撑该题目的开发。能够清晰流畅的展示一个项目的协作网络随时间的演化动态效果就已经非常好了。
• 另一种是全域协作网络数据，目前仅有 2023-1 一个数据集，这个数据集本身的大小不大，节点+边信息大约 4MB 左右，预计算好的位置信息约 1MB 左右，总结点数大约 9.5W，总边数约 13.3W。但这个数据集本身生产成本较高，而且由于数据量较大，使用的是 ngraph 的 binary 数据格式，对边进行了编码压缩，因此也只能配合 ngraph 的 decoder 来使用，因此目前只用于 OpenGalaxy 项目。如果需要这部分数据，可能需要时间来生成历史数据，并且需要提供对应的数据 decoder 才能使用。

[bifenglin]

全域网络数据节点平均度为2，整体4M的话，这样的数据集量应该可以直接提供出去。

[tyn1998]

前几天我代写了 W3 的赛题解读，在解读中，我给出的“协作网络”范围比较宽泛，参赛选手可以构建他们自己的协作网络。所以对应的，就夸下了“提供数据库访问权限”的海口。

如果要限定在“仓库自身的内部协作网络”或“以ngraph为基础的全域协作网络二进制文件”，那么 W3 赛题解读文档需要大改。

[frank-zsy]

我认为我们完全可以提供我提到的两种数据集，并且同时提供数据库访问接口，让开发者可以构建自己的协作网络，我相信大部分人会选择使用数据集来做。

[will-ww]

我认为我们完全可以提供我提到的两种数据集，并且同时提供数据库访问接口，让开发者可以构建自己的协作网络，我相信大部分人会选择使用数据集来做。

+1

[tyn1998]

又温习了几遍大家的讨论，我问几个问题，主要是希望能得到“是否提供数据库访问权限”的最终答案：

1. T2命令行查询是直连数据库查询吗？还是基于已有导出的JSON文件查询？
2. 毕博在这里 https://github.com/X-lab2017/open-wonderland/issues/262#issuecomment-1495431303 提到的2020年的数据打包，如果采用这种方式，参赛选手如何使用打包后的数据呢？是不是就是Docker镜像起本地ClickHouse的方式？
3. 由于我对实验室数据基础设施基本没有多少使用经验，所以对“是否提供数据库访问权限”没有什么发言权。但是毕博说有很大的运营问题，Frank学长相信大部分人会选择已经导出的网络数据，所以如果T2也不需要直连数据库进行开发，那么我也支持不要提供这个能力了。

大家怎么看？

[frank-zsy]

我个人的看法：

• 命令行查询应该是使用已导出的 JSON 文件的
• 可以直接提供一个大赛专用的只读账号，比赛结束后删除。运营风险层面，我很早以前不建议开放数据库直连是害怕长查询或者恶意查询导致数据库卡死，但后来在 OpenDigger 添加单元测试时，为专门提供测试能力的数据库添加了一些配置，感觉是可以用来限制访问资源的，可以参考这里：https://github.com/X-lab2017/open-digger/pull/1127#issuecomment-1371740457 。在做好资源限制的情况下，我不认为会有非常大的问题。

当然主要还是根据以往的课程经验，自己启动和运维一个数据库实例还是有非常高的成本的，尤其是全年数据这种，需要上 TB 的原始空间来初始化，对于绝大多数开发者都是不太可行的。

[will-ww]

我个人的看法：

• 命令行查询应该是使用已导出的 JSON 文件的
• 可以直接提供一个大赛专用的只读账号，比赛结束后删除。运营风险层面，我很早以前不建议开放数据库直连是害怕长查询或者恶意查询导致数据库卡死，但后来在 OpenDigger 添加单元测试时，为专门提供测试能力的数据库添加了一些配置，感觉是可以用来限制访问资源的，可以参考这里：ci: add test to opendigger open-digger#1127 (comment) 。在做好资源限制的情况下，我不认为会有非常大的问题。

当然主要还是根据以往的课程经验，自己启动和运维一个数据库实例还是有非常高的成本的，尤其是全年数据这种，需要上 TB 的原始空间来初始化，对于绝大多数开发者都是不太可行的。

同意 Frank 的建议，我们就针对特定赛题、特定队伍，提供这种只读账号支持好了，也是对入围队伍的一种奖励支持~

[tyn1998]

收到，那我会在W3解读中对Frank学长提到的两个已有网络数据做个补充~