- A+
挑战
1-gram 的数据集在硬盘上可以展开成为 27 Gb 的数据，这在读入 python 时是一个很大的数据量级。Python可以轻易地一次性地处理千兆的数据，但是当数据是损坏的和已加工的，速度就会变慢而且内存效率也会变低。
总的来说，这 14 亿条数据（1,430,727,243）分散在 38 个源文件中，一共有 2 千 4 百万个（24,359,460）单词（和词性标注，见下方），计算自 1505 年至 2008 年。
Loading the data
下面所有的代码/例子都是运行在 8 GB 内存 的 2016 年的 Macbook Pro。 如果硬件或云实例有更好的 ram 配置，表现会更好。
1-gram 的数据是以 tab 键分割的形式储存在文件中，看起来如下：
每一条数据包含下面几个字段：
为了按照要求生成图表，我们只需要知道这些信息，也就是：
1. 这个单词是我们感兴趣的？2. 发布的年份3. 单词使用的总次数
通过提取这些信息，处理不同长度的字符串数据的额外消耗被忽略掉了，但是我们仍然需要对比不同字符串的数值来区分哪些行数据是有我们感兴趣的字段的。这就是 pytubes 可以做的工作：
差不多 170 秒（3 分钟）之后， one_grams 是一个 numpy 数组，里面包含差不多 14 亿行数据，看起来像这样（添加表头部为了说明）：
╒═══════════╤════════╤═════════╕│ Is_Word │ Year │ Count │╞═══════════╪════════╪═════════╡│ 0 │ 1799 │ 2 │├───────────┼────────┼─────────┤│ 0 │ 1804 │ 1 │├───────────┼────────┼─────────┤│ 0 │ 1805 │ 1 │├───────────┼────────┼─────────┤│ 0 │ 1811 │ 1 │├───────────┼────────┼─────────┤│ 0 │ 1820 │ ... │╘═══════════╧════════╧═════════╛
从这开始，就只是一个用 numpy 方法来计算一些东西的问题了：
每一年的单词总使用量
谷歌展示了每一个单词出现的百分比（某个单词在这一年出现的次数/所有单词在这一年出现的总数），这比仅仅计算原单词更有用。为了计算这个百分比，我们需要知道单词总量的数目是多少。
幸运的是，numpy让这个变得十分简单：
绘制出这个图来展示谷歌每年收集了多少单词：
很清楚的是在 1800 年之前，数据总量下降很迅速，因此这回曲解最终结果，并且会隐藏掉我们感兴趣的模式。为了避免这个问题，我们只导入 1800 年以后的数据：
这返回了 13 亿行数据（1800 年以前只有 3.7% 的的占比）
Python 在每年的占比百分数
获得 python 在每年的占比百分数现在就特别的简单了。
绘制出 word_counts 的结果：
形状看起来和谷歌的版本差不多
性能
谷歌生成图片在 1 秒钟左右，相较于这个脚本的 8 分钟，这也是合理的。谷歌的单词计算的后台会从明显的准备好的数据集视图中产生作用。
举个例子，提前计算好前一年的单词使用总量并且把它存在一个单独的查找表会显著的节省时间。同样的，将单词使用量保存在单独的数据库/文件中，然后建立第一列的索引，会消减掉几乎所有的处理时间。
这次探索 确实 展示了，使用 numpy 和 初出茅庐的 pytubes 以及标准的商用硬件和 Python，在合理的时间内从十亿行数据的数据集中加载，处理和提取任意的统计信息是可行的，
结果:
对比谷歌 ( 没有任何的基准线调整 ):
更多的过滤逻辑 - Tube.skip_unless() 是一个比较简单的过滤行的方法，但是缺少组合条件（AND/OR/NOT）的能力。这可以在一些用例下更快地减少加载数据的体积。
更好的字符串匹配 —— 简单的测试如下：startswith, endswith, contains, 和 is_one_of 可以轻易的添加，来明显地提升加载字符串数据是的有效性。
谢谢阅读！！是不是超级叼，14亿啊 这可不是一个小数目！
