パイソンと14億個のデータの分析は、とてもエキサイティングです!

あなたはどのくらいのPython最大のデータセットを処理しますか?私はそれはおそらく、Pythonで14億のデータ処理の事例分析を共有するために、今日、今以上の億を続かないだろうと思います

毎年印刷された本によるとGoogleのNGRAMビューアによって生成されたGoogleブックス、、、Googleブックスで特定の単語やフレーズの使用の記録量から14億個のデータセット。データセットは、時間に16世紀から2008年に至るまで、数十冊の何百万ものがあります。あなたは、このようなクエリの周波数と時間をかけて使用状況の変化、「Pythonは」歴史に表示される単語を描くことができます。

以下のPython PyTubesデータベースを使用して、上記データセットをロードし、その後、上記の図を生成するために分析します。PyTubesは、大規模なデータソースをロードするように設計されたライブラリです。

ハードディスク上のデータの1グラムのセットは、時間順に読まれるのpythonで多くのデータであるデータの27 GB、なるように拡張することができます。Pythonは簡単にギガビット一度データを処理することができますが、データが破壊され、処理されたときに、スローダウンやメモリ効率が低くなります。

全体として、このデータは1505年から2008年までの計算38個のソースファイルに分散した14億(1430727243)、2,400百万円(24359460)の単語の合計(音声タグ付け、以下を参照)、です。

データの10億行を扱う場合、速度はすぐに遅くなります。そして、生のPythonと、この点でのデータの処理を最適化していません。幸いなことに、データの一般的なボリュームを扱うのは本当に良いnumpyの。私たちは、この分析が可能となる作るためにnumpyのを使用することができますいくつかの簡単なテクニックを使用します。

Pythonで/ numpyの文字列処理は複雑です。Pythonの文字列メモリのオーバーヘッドが非常に重要である、とだけnumpyの知られており、固定長文字列を扱うことができます。このような状況を踏まえ、言葉のほとんどは、異なる長さを持っているので、これは理想的ではありません。
学習プロセスが私のpythonゼロベースのシステムの学習交流Qiuqiuのqun参加することができます理解していないのPython:784、フロント、ミドル758、214、現在の企業の株式のPython Pythonの人材ニーズとどのようにゼロベースから学ぶ続くと、そして何を学びます。関連ビデオ教材は、開発ツールが共有する必要が

ロードデータセット

以下のコード/例のすべてがで実行されている8ギガバイトのメモリ 2016のMacBook Proの。ハードウェアやクラウドインスタンスが良くラムの構成を持っている場合、パフォーマンスが良くなります。

次のように分割されたデータをファイル形式で保存されているタブの1グラムは、それが見えます:


1Python 1587 4 2
2Python 1621 1 1
3Python 1651 2 2
4Python 1659 1 1

以下のいくつかのフィールドを含むデータの各:


11. Word
22. Year of Publication
33. Total number of times the word was seen
44. Total number of books containing the word


要件に合わせてグラフを生成するために、我々はこの情報を知っておく必要があり、それは次のようになります。


11.  这个单词是我们感兴趣的?
22. 发布的年份
33. 单词使用的总次数

情報を抽出することによりどのような著名なラインデータは、異なる長さのデータ処理の追加消費文字列は無視されますが、我々はまだ別の文字列の値が関心の私達の分野で比較する必要があります。これはpytubesは仕事をすることができます:


1import tubes
 2
 3FILES = glob.glob(path.expanduser("~/src/data/ngrams/1gram/googlebooks*"))
 4WORD = "Python"
 5one_grams_tube = (tubes.Each(FILES)
 6    .read_files()
 7    .split()
 8    .tsv(headers=False)
 9    .multi(lambda row: (
10        row.get(0).equals(WORD.encode('utf-8')),
11        row.get(1).to(int),
12        row.get(2).to(int)
13    ))
14)

ほぼ170秒(3分)後、 grams_は、データのほぼ14億行を含むnumpyの配列である(表のヘッドは説明のために添加される)のようになります。


1╒═══════════╤════════╤═════════╕
 2│   Is_Word │   Year │   Count │
 3╞═══════════╪════════╪═════════╡
 4│         0 │   1799 │       2 │
 5├───────────┼────────┼─────────┤
 6│         0 │   1804 │       1 │
 7├───────────┼────────┼─────────┤
 8│         0 │   1805 │       1 │
 9├───────────┼────────┼─────────┤
10│         0 │   1811 │       1 │
11├───────────┼────────┼─────────┤
12│         0 │   1820 │     ... │
13╘═══════════╧════════╧═════════╛

ここでは、データの分析を開始することができます。

年間の言葉の総量

Googleは、この言葉が使わただ、元の計算を超えている、すべての割合単語の出現(単語がすべての単語の合計数が表示され、今年/年表示された回数)を示しています。割合を計算するために、我々は、ある単語の合計数を知っておく必要があります。

幸いなことに、これは非常にシンプルになってみましょうnumpyの:


 1last_year = 2008
 2YEAR_COL = '1'
 3COUNT_COL = '2'
 4year_totals, bins = np.histogram(
 5    one_grams[YEAR_COL],
 6    density=False,
 7    range=(0, last_year+1),
 8    bins=last_year + 1,
 9    weights=one_grams[COUNT_COL]
10)

この図は、Googleが年間多くの単語を収集し表示するためにプロットさ:

很清楚的是在 1800 年之前,数据总量下降很迅速,因此这回曲解最终结果,并且会隐藏掉我们感兴趣的模式。为了避免这个问题,我们只导入 1800 年以后的数据:


 1one_grams_tube = (tubes.Each(FILES)
 2    .read_files()
 3    .split()
 4    .tsv(headers=False)
 5    .skip_unless(lambda row: row.get(1).to(int).gt(1799))
 6    .multi(lambda row: (
 7        row.get(0).equals(word.encode('utf-8')),
 8        row.get(1).to(int),
 9        row.get(2).to(int)
10    ))
11)

这返回了 13 亿行数据(1800 年以前只有 3.7% 的的占比)

Python 在每年占比百分数

获得 python 在每年的占比百分数现在就特别的简单了。

使用一个简单的技巧,创建基于年份的数组,2008 个元素长度意味着每一年的索引等于年份的数字,因此,举个例子,1995 就只是获取 1995 年的元素的问题了。

这都不值得使用 numpy 来操作:


1word_rows = one_grams[IS_WORD_COL]
2word_counts = np.zeros(last_year+1)
3for _, year, count in one_grams[word_rows]:
4    word_counts[year] += (100*count) / year_totals[year]

绘制出 word_counts 的结果:

形状看起来和谷歌的版本差不多

实际的占比百分数并不匹配,我认为是因为下载的数据集,它包含的用词方式不一样(比如:Python_VERB)。这个数据集在 google page 中解释的并不是很好,并且引起了几个问题:

  • 人们是如何将 Python 当做动词使用的?

  • ‘Python’ 的计算总量是否包含 ‘Python_VERB’?等

幸运的是,我们都清楚我使用的方法生成了一个与谷歌很像的图标,相关的趋势都没有被影响,因此对于这个探索,我并不打算尝试去修复。

性能

谷歌生成图片在 1 秒钟左右,相较于这个脚本的 8 分钟,这也是合理的。谷歌的单词计算的后台会从明显的准备好的数据集视图中产生作用。

举个例子,提前计算好前一年的单词使用总量并且把它存在一个单独的查找表会显著的节省时间。同样的,将单词使用量保存在单独的数据库/文件中,然后建立第一列的索引,会消减掉几乎所有的处理时间。

这次探索 确实 展示了,使用 numpy 和 初出茅庐的 pytubes 以及标准的商用硬件和 Python,在合理的时间内从十亿行数据的数据集中加载,处理和提取任意的统计信息是可行的,

Python,Pascal 和 Perl 对比

为了用一个稍微更复杂的例子来证明这个概念,我决定比较一下三个相关提及的编程语言: Python,Pascal,Perl.

源数据比较嘈杂(它包含了所有使用过的英文单词,不仅仅是编程语言的提及,并且,比如,python 也有非技术方面的含义!),为了这方面的调整, 我们做了两个事情:

  1. 只有首字母大写的名字形式能被匹配(Python,不是 python)

  2. 每一个语言的提及总数已经被转换到了从 1800 年到 1960 年的百分比平均数,考虑到 Pascal 在 1970 年第一次被提及,这应该有一个合理的基准线。

结果:

对比谷歌 (没有任何的基准线调整):

运行时间: 只有 10 分钟多一点。

おすすめ

転載: blog.csdn.net/weichen090909/article/details/93486903