Python 适合大数据量的处理吗

Python021

Python 适合大数据量的处理吗,第1张

python可以处理大数据，python处理大数据不一定是最优的选择。适合大数据处理。而不是大数据量处理。 如果大数据量处理，需要采用并用结构，比如在hadoop上使用python，或者是自己做的分布式处理框架。

python的优势不在于运行效率，而在于开发效率和高可维护性。针对特定的问题挑选合适的工具，本身也是一项技术能力。

Python处理数据的优势（不是处理大数据）：

1. 异常快捷的开发速度，代码量巨少

2. 丰富的数据处理包，不管正则也好，html解析啦，xml解析啦，用起来非常方便

3. 内部类型使用成本巨低，不需要额外怎么操作（java，c++用个map都很费劲）

4. 公司中，很大量的数据处理工作工作是不需要面对非常大的数据的

5. 巨大的数据不是语言所能解决的，需要处理数据的框架（hadoop， mpi）虽然小众，但是python还是有处理大数据的框架的，或者一些框架也支持python。

扩展资料：

Python处理数据缺点：

Python处理大数据的劣势：

1、python线程有gil，通俗说就是多线程的时候只能在一个核上跑，浪费了多核服务器。在一种常见的场景下是要命的：并发单元之间有巨大的数据共享或者共用（例如大dict）。

多进程会导致内存吃紧，多线程则解决不了数据共享的问题，单独的写一个进程之间负责维护读写这个数据不仅效率不高而且麻烦

2、python执行效率不高，在处理大数据的时候，效率不高，这是真的，pypy（一个jit的python解释器，可以理解成脚本语言加速执行的东西）能够提高很大的速度，但是pypy不支持很多python经典的包，例如numpy。

3. 绝大部分的大公司，用java处理大数据不管是环境也好，积累也好，都会好很多。

参考资料来源：百度百科-Python

Tensorflow的JIT（just-in-time）是指在运行 @tf.function 修饰的python函数时，由 jit 、 tf2xla 和 XLA 一起完成一系列如子图构造、子图优化、图编译和图执行等操作。编译后的可执行程序-- executable 会存放到cache中，供再次调用时直接获取执行。JIT的好处在 开篇 已经讲过了，这里不再赘述。

JIT的流程可以概括为：Tensorflow子图构造/优化，graph ->HLO，编译/执行，合并计算结果到Tensorflow图这四部分。本文只涉及图编译和图执行。

函数中ops在子图构造阶段被包裹进一个cluster node，并替换成 xla_compile 和 xla_run 这两op，而 XlaCompileOp 和 XlaRunOp 就是它们的 OpKernel ，分别用于图编译和执行。

XlaCompileOp通过 XlaCompilationCache 获取或编译executable，并将其封装成 XlaExecutableClosure ，并缓存在 XlaExecutableClosureStore 。 XlaRunOp 用从XlaCompileOp传递来的key在cache中查找并执行executable。

从编译流程图可以看到，XLA的编译结果会缓存到XlaCompilationCache，后续调用可以根据 signature 在cache中查找executable。

函数的 signature 是由 BuildSignature(function, args) 根据函数和arguments生成的。即使是同一个函数，只要input tensors不同，signature也会不一样，这就是 power() 被编译两次的原因：第三次函数调用时，由于无法通过signature在cache中找到executable而触发编译。

signature表示唯一的计算图：只要函数中的ops序列和arguments（type/shape）是确定的，那么计算图也是确定的。

编译之前需要通过 tf2xla 将图转换成XLA支持的语言 HLO 。tf2xla为每个Tensorflow op创建了生成HLO的 XlaOp ，因此，只要执行该Tensorflow子图，就可以生成具有相同的拓扑排序的HLO -- XlaComputation 。

XlaComputation （HLO）可以认为是一个运行在device上的纯函数，它的input/output会伴随着host-to-device（H2D）和device-to-host（D2H）的数据传输。

我们知道，Tensorflow图中的input tensor有两种： tf.Placeholder 和 tf.Variable ，前者每个step都会将新data发送到device，而后者是模型参数，它们会常驻内存，只在store/load checkpoint才会有H2D/D2H。

而纯函数的定义是：

不管是input还是output，虽然variable和其他argument一样存在于HLO的参数列表和返回值列表中，但它们实际上是常驻于device的，不需要也不应该H2D/D2H。

因此，HLO在编译时还需要通过 argument_input_indices 、 resource_input_indices 和 resource_update_to_input_index 等options来区分arguments和variables。

此外，如果有input是常数，为了避免无谓的H2D开销，可以把它固化到函数内部。同理，对于常数output，它没必要出现在函数中，可以直接定义在 XlaCompilationResult 的output buffer。

XlaCompilationResult是 Graph ->HLO 的output，它封装了HLO以及上述部分metadata、buffers。

XlaCompileOp会把编译好的executable、metadata、input/output buffers、options等统统封装进一个closure -- XlaExecutableClosure ，并将其缓存在 XlaExecutableClosureStore 供 XlaRunOp 获取。

XlaRunOp 可以通过一个数字字符串key（从0开始累加）从cache中查找并执行XlaExecutableClosure，这个key由XlaCompileOp提供。

我用python执行时间23秒，用pypy执行时间1.54秒，用numba加速为1.5秒，c语言在本机macos上执行时间1.3秒,java运行速度1.45秒（jre8）,详细见图片，可见引入jit编译后，性能直逼c语言，而写python比写c容易太多,比java简洁，写代码速度也是非常非常重要。由于历史原因，很多python库用的c语言库，如pandas（pandas的矩阵计算用numpy优化过非常快，可能比手写c语言循环还要快），可以通过设计来分离c语言加速后的python代码和pure python，分别用不同的加速方法，如numba可以单独加速一个函数，把需要大量计算的放在一个函数用numba加速（numbapro支持显卡加速但是商业版的）。

所以只适当设计一下，python在一般计算问题下有这些解决方案下性能不是问题，实在不行，你还可以用boost::python来写个c/c++调用库来解决性能问题。

下面的测试说明，对于性能，原生python比较慢，在windows下python比linux,macos要快，用pypy后相当于java,c#速度，pypy,c#在windows下受益msvc表现较快，,go语言速度表现比较稳定，c语言理论上是最快，但受环境和编译器影响较大。对c#,java可能在GC垃圾回收时会表现不稳定，因为在oop中有大量计算后可能要回收垃圾内存对象，这个没有用到oop，只是纯计算，理论上还是c/c++语言最快。

python和java比，运行速度比java慢，java强大于改进n次的强大jre，但python在很多领域能调用很多现成的开源库，在数据分析中有优势，pyhton的代码比java要简洁，容易入门和使用。在优化的计算库帮助下,如numpy numba，pandas，scikit-learn，python的实际问题运算性能并不低于java。java主要是框架太多，相对复杂，java主要用于业务程序开发，符合软件工程理论，可伸缩性强,强类型有利于对程序的静态检查分析。java随着安卓,hadoop,spark的兴起，加入java语言的公司很多，性能也可以通过优化解决很多问题。很多服务器如ubuntu server,centos都默认支持python，而java虚拟机需要安装配置，python的安装使用也相对简单。python的库有开箱即用感，很多业务领域，你可能还在用oop写代码，考虑设计模式，用锄头挖沟时，而python调用挖掘机api已经炒菜完工开饭了，缺点是油耗比较大。