@BIGUFO RDD 的 distinct 中每一条记录会创建一个对象，10 亿条记录会创建 10 亿个对象，即使集群多机计算，中间生成这么多对象 GC 压力也很大。SQL API 有钨丝计划优化，gc 问题会小很多。

这个就是转无向图的过程吧？

使用 Spark SQL API （ Spark RDD API 的 distinct 有严重的 GC 问题，不推荐）。

1. 将数据导入 Spark SQL 的表
2. 将 from 和 to 规则化（确保 from 的顶点 ID 小于 to 的）
3. 使用 Spark SQL API 进行 distinct 去重

fcitx-diagnose 运行一下，如果 fcitx 配置的有问题，里面会提示的。

Manjaro 基于 Arch，但在烧制的 USB 安装盘上提供一个 GUI 的 Live 环境，可以提前试用一下看是否能正常驱动显卡。

无向图做连通分量用 GraphX 性能还是可以的。如果是有向图做强连通分量检测的话，GraphX 的性能就比较拙计了，还不如直接单机串行算法。

如果图规模不大的话，GraphX 的额外开销太大，性能比不上单机 C++实现的版本。

Deepin+1 在国内的环境下能帮你少折腾很多东西，比如 QQ 和 WPS Office。

vnote + 坚果云 /Dropbox 等网盘

@niubee1 竟然是永中 Office，永中还活着！！！

VNote 是可以直接用网盘进行同步的，而且不依赖任何一家网盘的 API，支持的同步网盘更多。
将笔记本的存储目录设置为同步云盘上的路径，可以直接利用底下云盘的自动同步机制实现多机同步。我现在就是这样用的。

VNote 还有另一个好处：笔记本使用文件夹的形式组织，天然支持多层嵌套。每个笔记都是裸的 md 文件（不像其他的笔记软件还会加密或存数据库），可以直接用文本编辑器编辑。而 VNote 的元信息都是保存成 json 文件的，因此同步时不涉及二进制文件同步。

手机端使用目前没直接方案，但有间接的方案：
在手机端用 Markdown 编辑器直接编辑云盘里的 md 文件，由云盘负责多端同步。

表格移动的功能都没有，很难替代标准的笔记编辑器啊。

初学上手 Deepin 啊，估计初学者上去还离不开 QQ 什么的。

24 寸 1080p 不能算高分屏，普通分辨率，字体显示效果本来就不会太好，Windows 下也差不多。

有些服务商（比如百度)提供 IP 到地址的精确定位服务，说不定在不经意间你的代理 IP 已经被关联了真实地址。

"不低于原产品性能的同品牌商品"，这个可操作空间很大啊。同品牌好定义，不低于原产品性能就比较难定义了。

在手机上用微信里的京东购物（逃

感觉去牛校牛组学的技术：要么就是特别新的新技术，还在原型探索阶段，离商用还很远；要么是离商业环境差很远的旧技术，毕竟学校的硬件条件和数据都赶不上公司。
不过学校里面有个很好的优势：允许你*有时间*涉猎计算机的方方面面；而且可以通过撰写论文，来学习从提出问题到解决问题再到向别人解释自己的工作这样一整套流程，在学校有时间和机会进行试错和尝试，还有人指导。

微博的技术大拿在网上有技术分享 PPT，应该还能搜到。
我印象中，当时的 PPT 是这样说的（约至少 2 年前），如果说的有问题，还请拍砖：
1. 微博信息数据（即微博的具体内容等）是存储在关系型数据库中的。使用标准的分库分表技术就能水平扩展。
2. 微博的关系数据（即 Follow 关系）和 Feed 流数据，我记得没有细说。但是每个用户是会维护自己的 Feed 流，这个 Feed 流应该只保存了微博 ID 编号，不保存具体微博内容。等用户浏览自己的 Feed 流的时候，再从关系数据库中取出微博内容，并将网页返回给用户。
3. 微博的通知数据（你有 XX 新粉丝，有 XX 新回复，有 XX 新点赞等信息），因为体积不大而且经常变动，是保存在 Redis 中。

当一个用户发了一条新微博之后，后续的更新动作一般是推拉结合：
1. 对于普通用户（粉丝数小于某个值）的微博更新，用“推”的方式比较划算。当一个用户更新微博后，把新微博的 ID 信息写入他的粉丝的 Feed 流存储之中。
2. 对于大 V 用户（粉丝数大于某个值）的微博更新，用“拉”的方式比较划算。当大 V 更新微博后，并不会将新微博 ID 推送到粉丝的 Feed 流。而是在粉丝查看自己的 Feed 流的时候，现场去查询其关注的大 V 的最新动态，并加入 Feed 流。这种“拉”的好处是减少了大 V 更新微博时的一系列数据库操作代价，而且大 V 微博的时效性很强，能很好地进行热缓存。

@zuolan 这个项目看起来有些厉害