g****t
发帖数: 31659 | 1 如果是实战，要把大csv文件读入数组。
我会这样做：
1. 先用fseek ...写一个文件分割器。将其分为n个小文件。
2.用常用的读，parse csv第三方软件，依次读取。
这个办法的目的是：最小化uncertainty。
parse csv不是trivial 的任务。自己写不划算。必须用第三方。
然而第三方csv parse根据个人经验，对大文件的表现是未知的。
中间未必不会出错。所以分成小文件，一个一个读是最可预测结果的办法。
这个设计把大文件处理，和parse文件分成两个任务。也符合divide and
conquer的原则。
大家怎么看？有给予更低的surprise概率办法吗？
我比较倾向于设计阶段想定稳妥的办法，这样写码基本上就是比较单纯的labor。 |
m******r
发帖数: 1033 | 2 对我最难的是parse. 各种标点符号，不可见字符，CRLF,逗号引号，正斜杠，反斜杠，
水平制表符，竖直制表符，单引号，双引号，派普，中文，法文，拉丁文，希腊文，阿
拉伯文，带引号的版本，不带引号的版本， 够你喝一壶的。
1.最省力的，如果可能，和生成文件的人员谈好。 特殊字符都删掉，统一分隔符。
2.找实习来做。 实习可以实验不同工具，不同设置。
3.不是所有记录都能读出来。 有时一两个个百分点读不出来，很正常的事。
虽然没编过程 ， 读文件各种奇葩的事情见过很多。 年轻时还有因为读文件把IT部门
惹毛了的故事， 以后给你们讲讲。 |
g****t
发帖数: 31659 | 3 有经验的数据人员，都知道csv parse最好不要自己做----除非数据来源在你同一个程
序控制之下。这一点要有认知。不然这个活是干不了的。
和数据生成人员谈好，也不是就没问题了。下次换人，或者outsource到印度了，
你还继续谈吗？找实习生来做csv parse也是错误的。一年以后csv parse出错，花1星
期debug，划算吗？
【在 m******r 的大作中提到】
: 对我最难的是parse. 各种标点符号，不可见字符，CRLF,逗号引号，正斜杠，反斜杠，
: 水平制表符，竖直制表符，单引号，双引号，派普，中文，法文，拉丁文，希腊文，阿
: 拉伯文，带引号的版本，不带引号的版本， 够你喝一壶的。
: 1.最省力的，如果可能，和生成文件的人员谈好。 特殊字符都删掉，统一分隔符。
: 2.找实习来做。 实习可以实验不同工具，不同设置。
: 3.不是所有记录都能读出来。 有时一两个个百分点读不出来，很正常的事。
: 虽然没编过程 ， 读文件各种奇葩的事情见过很多。 年轻时还有因为读文件把IT部门
: 惹毛了的故事， 以后给你们讲讲。
|
d******e
发帖数: 2265 | 4 科班毕业的吗？
你就一个线程。
分个屁啊。
DMA, cache了解一下。
最优是pipeline。
另外，多大csv?
没见过达到还自己写parser的。
back of envelope自己算算知道了。
实在csv 太大，劈成几十个小csv然后逃别人的parser不就得了。
最快实现方法pands直接读入到data frame.
能比pandas快再说吧。
【在 g****t 的大作中提到】
: 如果是实战，要把大csv文件读入数组。
: 我会这样做：
: 1. 先用fseek ...写一个文件分割器。将其分为n个小文件。
: 2.用常用的读，parse csv第三方软件，依次读取。
: 这个办法的目的是：最小化uncertainty。
: parse csv不是trivial 的任务。自己写不划算。必须用第三方。
: 然而第三方csv parse根据个人经验，对大文件的表现是未知的。
: 中间未必不会出错。所以分成小文件，一个一个读是最可预测结果的办法。
: 这个设计把大文件处理，和parse文件分成两个任务。也符合divide and
: conquer的原则。
|
g****t
发帖数: 31659 | 5 “实在csv 太大，劈成几十个小csv然后逃别人的parser不就得了。”
你这句话和我说的是一样的。
你再读读我的贴。（我第一步没写清楚，现加入“小文件”三个字）
dma,cache,弄得越复杂，和平台绑定越紧。分割大文件这一步，其实
就是个
random access文件的问题，linux或者windows标准答案就可以。
pandas多数情况下不可取。除非本来就有python的模块，不然
把python的deploy维护弄进来，得不偿失。
以前我用pandas的时候，发现还有不少别的不确定性，就不说了。
【在 d******e 的大作中提到】
: 科班毕业的吗？
: 你就一个线程。
: 分个屁啊。
: DMA, cache了解一下。
: 最优是pipeline。
: 另外，多大csv?
: 没见过达到还自己写parser的。
: back of envelope自己算算知道了。
: 实在csv 太大，劈成几十个小csv然后逃别人的parser不就得了。
: 最快实现方法pands直接读入到data frame.
|
l*******m
发帖数: 1096 | 6 数据多而且大，还一定c++. design 直接上protobuf就行了
：如果是实战，要把大csv文件读入数组。
：我会这样做： |
g****t
发帖数: 31659 | 7 我这是有一说一。没学过protobuf。
会用的人，这可能是个捷径。
: 数据多而且大，还一定c . design 直接上protobuf就行了
: ：如果是实战，要把大csv文件读入数组。
: ：我会这样做：
【在 l*******m 的大作中提到】
: 数据多而且大，还一定c++. design 直接上protobuf就行了
:
: ：如果是实战，要把大csv文件读入数组。
: ：我会这样做：
|
C*****l
发帖数: 1 | 8 csv的痛苦就是有人把乱七八糟的东西往里扔，一个简单的东西搞成垃圾堆。 按照简单
规矩来，谁改坏了谁去fix
【在 g****t 的大作中提到】
: 有经验的数据人员，都知道csv parse最好不要自己做----除非数据来源在你同一个程
: 序控制之下。这一点要有认知。不然这个活是干不了的。
: 和数据生成人员谈好，也不是就没问题了。下次换人，或者outsource到印度了，
: 你还继续谈吗？找实习生来做csv parse也是错误的。一年以后csv parse出错，花1星
: 期debug，划算吗？
|
n******t
发帖数: 4406 | 9 这也是乱堆轮子的。protobuf都来了。
: 数据多而且大，还一定c . design 直接上protobuf就行了
: ：如果是实战，要把大csv文件读入数组。
: ：我会这样做：
【在 l*******m 的大作中提到】
: 数据多而且大，还一定c++. design 直接上protobuf就行了
:
: ：如果是实战，要把大csv文件读入数组。
: ：我会这样做：
|
a********c
发帖数: 3657 | 10
笨。既然是csv，肯定是数据file。那当然是先convert to binary file,比csv快百倍
。
【在 g****t 的大作中提到】
: 如果是实战，要把大csv文件读入数组。
: 我会这样做：
: 1. 先用fseek ...写一个文件分割器。将其分为n个小文件。
: 2.用常用的读，parse csv第三方软件，依次读取。
: 这个办法的目的是：最小化uncertainty。
: parse csv不是trivial 的任务。自己写不划算。必须用第三方。
: 然而第三方csv parse根据个人经验，对大文件的表现是未知的。
: 中间未必不会出错。所以分成小文件，一个一个读是最可预测结果的办法。
: 这个设计把大文件处理，和parse文件分成两个任务。也符合divide and
: conquer的原则。
|
|
|
n******t
发帖数: 4406 | 11 。。。。。。。。。
这事情就叫parse。
【在 a********c 的大作中提到】
:
: 笨。既然是csv，肯定是数据file。那当然是先convert to binary file,比csv快百倍
: 。
|
g*******u
发帖数: 3948 | 12 pandas不行吗。dask不行吗
都不行在自己写呗。 |
g****t
发帖数: 31659 | 13 哪个格式最后不是垃圾堆？你从html算起。
: csv的痛苦就是有人把乱七八糟的东西往里扔，一个简单的东西搞成垃圾堆。 按
照简单
: 规矩来，谁改坏了谁去fix
【在 C*****l 的大作中提到】
: csv的痛苦就是有人把乱七八糟的东西往里扔，一个简单的东西搞成垃圾堆。 按照简单
: 规矩来，谁改坏了谁去fix
|
g****t
发帖数: 31659 | 14 Python 的deploy问题弄进来没多大意思。一天可用cpp搞好，何必加别的语言。
: pandas不行吗。dask不行吗
: 都不行在自己写呗。
【在 g*******u 的大作中提到】
: pandas不行吗。dask不行吗
: 都不行在自己写呗。
|
g****t
发帖数: 31659 | 15 目测本版Qualified 马工数量大幅下降。
: 。。。。。。。。。
: 这事情就叫parse。
【在 n******t 的大作中提到】
: 。。。。。。。。。
: 这事情就叫parse。
|
g*******u
发帖数: 3948 | 16 可能你的问题有你的特定用途。我是坚决不写这种东西的。
一定找现成的。我不信我的问题别人没有过。
我也不信你一天写出来的能别别人的强。
【在 g****t 的大作中提到】
: Python 的deploy问题弄进来没多大意思。一天可用cpp搞好，何必加别的语言。
:
:
: pandas不行吗。dask不行吗
:
: 都不行在自己写呗。
:
|
g****t
发帖数: 31659 | 17 Pandas速度和性能可靠。但是有别的不确定性。我指的是deploy和今后的维护。
我写的是不是比pandas好，这要看你做项目看重哪方面。
前面一个贴写了，带测试一天搞好c或者cpp。
Cost不算高。c或者cpp写的，只用一个成熟的csv parse作为依赖，加上os给的fseek等
几个函数。deploy和维护当然比python based silution好。
再者，主贴最后一句话比较拗口，仍然请再读一遍：
最小化未来出现surprise 的概率。
按此指标，python之前有个csv的库，也许都比pandas强。
这类软件设计，我的办法就是几个决策树放权重。但要了解软件的几个不同方面的要求
。一个字的“好”或者“不好”，能描述的东西太少了。
: 可能你的问题有你的特定用途。我是坚决不写这种东西的。
: 一定找现成的。我不信我的问题别人没有过。
: 我也不信你一天写出来的能别别人的强。
【在 g*******u 的大作中提到】
: 可能你的问题有你的特定用途。我是坚决不写这种东西的。
: 一定找现成的。我不信我的问题别人没有过。
: 我也不信你一天写出来的能别别人的强。
|
n******t
发帖数: 4406 | 18 這又是不會parse一個csv的。
【在 g*******u 的大作中提到】
: 可能你的问题有你的特定用途。我是坚决不写这种东西的。
: 一定找现成的。我不信我的问题别人没有过。
: 我也不信你一天写出来的能别别人的强。
|
y****w
发帖数: 3747 | 19 1. (多线程)分段处理是并发的自然选择。考虑效率，按字节操作，需要处理保证读取
完整行且不多读不少读。 用不了几行代码但必须想清楚。 多核，读取解析分开，这
任务严肃起来必须多线程或进程。
2. parse是大问题。 我写过一次某数据库的csv导出文件处理。引号，特殊符号还好，
更坑爹的是允许字串中允许换行。 这对写正则表达式是个挑战。尽可能不要自己写，
多找找现成的库。
3. 如果没什么特殊情况且单机可容忍，考虑用数据库来做。简单粗暴有效方便重复利
用。查询也方便多了。本地sqlite表现都未必差。 |
y****w
发帖数: 3747 | 20 一点细节 （在不同线程进程里）分段读取大文件的不同片就行了 千万别真正把文件给
撕开成一堆小文件。这个开销可不小 。 |
|
|
d******c
发帖数: 2407 | 21 R data.table fread，底层用C写的，久经考验。
Hadley搞了个readr想挑战，最终还是比fread慢一倍。
第一步先把能放进内存的放进内存再说，不要小文件IO。 |
g*******u
发帖数: 3948 | 22 如果你本来的东西没有python确实引入新的库很烦人网上应该有现成的吧你稍微改改就
是了吧。你说的大csv文件 到底多大？
多少行记录 多少咧 多大的文件。
太大的csv pandas 也慢啊。
【在 g****t 的大作中提到】
: Pandas速度和性能可靠。但是有别的不确定性。我指的是deploy和今后的维护。
: 我写的是不是比pandas好，这要看你做项目看重哪方面。
: 前面一个贴写了，带测试一天搞好c或者cpp。
: Cost不算高。c或者cpp写的，只用一个成熟的csv parse作为依赖，加上os给的fseek等
: 几个函数。deploy和维护当然比python based silution好。
: 再者，主贴最后一句话比较拗口，仍然请再读一遍：
: 最小化未来出现surprise 的概率。
: 按此指标，python之前有个csv的库，也许都比pandas强。
: 这类软件设计，我的办法就是几个决策树放权重。但要了解软件的几个不同方面的要求
: 。一个字的“好”或者“不好”，能描述的东西太少了。
|
g****t
发帖数: 31659 | 23 本帖目的是和大家交流软件设计思路，原则和方法。
【在 g*******u 的大作中提到】
: 如果你本来的东西没有python确实引入新的库很烦人网上应该有现成的吧你稍微改改就
: 是了吧。你说的大csv文件 到底多大？
: 多少行记录 多少咧 多大的文件。
: 太大的csv pandas 也慢啊。
|
g****t
发帖数: 31659 | 24 R那个为什么快？优化思路是什么？放内存肯定是基本策略。放多少呢？buffsize怎么
定的？
: R data.table fread，底层用C写的，久经考验。
: Hadley搞了个readr想挑战，最终还是比fread慢一倍。
: 第一步先把能放进内存的放进内存再说，不要小文件IO。
【在 d******c 的大作中提到】
: R data.table fread，底层用C写的，久经考验。
: Hadley搞了个readr想挑战，最终还是比fread慢一倍。
: 第一步先把能放进内存的放进内存再说，不要小文件IO。
|
n******t
发帖数: 4406 | 25 不缺內存的情況下這麼搞無可厚非，但是這件事情並不是需要10G內存才能幹好的。
當然有內存的時候，知道先放進去，比很多人來說是個進步了。
【在 d******c 的大作中提到】
: R data.table fread，底层用C写的，久经考验。
: Hadley搞了个readr想挑战，最终还是比fread慢一倍。
: 第一步先把能放进内存的放进内存再说，不要小文件IO。
|
A**********l
发帖数: 49 | 26 没看懂你到底担心的是什么，是读取过程出现exception还是数据读错，后者概率很低
如果是critical data担心出错加校验，如果担心格式等parser的exception那先做
clean up然后再读，如果担心文件太大ram可能不够那先做长度检查然后分小块是好办
法 |
g****t
发帖数: 31659 | 27 第一，常见的csv parse tool的performance对大文件是未知的。即使是最简单的csv,
也常用来作为测试语言性能的benchmark 。
第二，自己写csv parse不可行。
既然要用常见的csv parse,又要减少不确定性。那就分成小文件，存起来再用csv
parse在小文件上。这样肯定比较慢。但是最小化了不确定性。
: 没看懂你到底担心的是什么，是读取过程出现exception还是数据读错，后者概
率很低
: 如果是critical data担心出错加校验，如果担心格式等parser的exception那先做
: clean up然后再读，如果担心文件太大ram可能不够那先做长度检查然后分小块
是好办
: 法
【在 A**********l 的大作中提到】
: 没看懂你到底担心的是什么，是读取过程出现exception还是数据读错，后者概率很低
: 如果是critical data担心出错加校验，如果担心格式等parser的exception那先做
: clean up然后再读，如果担心文件太大ram可能不够那先做长度检查然后分小块是好办
: 法
|
s****r
发帖数: 68 | 28 要讲性能，就得考虑平台了。
以linux为例，这个任务其实很简单。两个考虑：
1. File io要能readahead，and for memory copy, batch read to application
memory for good memory copy performance.
2. Application level: existing parser to directly parse application memory.
For 2. getline什么的都可以。
For 1. 如果想用流输入输出函数（比如getline）batch read可以用setvbuf（）（
https://en.cppreference.com/w/c/io/setvbuf）；
readahead，直接call同名的system call就可以（https://man7.org/linux/man-
pages/man2/readahead.2.html）。这个call是异步的，对application的blocking几乎
没有。
当然getline其实就是按换行符分割。csv parser要做的事情比那个多不少。好的设计
要separate concerns（https://en.wikipedia.org/wiki/Separation_of_concerns）
。上面的方法把IO性能和parser设计基本分开。写application logic的人可以开发各
种parser而不用再考虑IO的性能。
【在 g****t 的大作中提到】
: 如果是实战，要把大csv文件读入数组。
: 我会这样做：
: 1. 先用fseek ...写一个文件分割器。将其分为n个小文件。
: 2.用常用的读，parse csv第三方软件，依次读取。
: 这个办法的目的是：最小化uncertainty。
: parse csv不是trivial 的任务。自己写不划算。必须用第三方。
: 然而第三方csv parse根据个人经验，对大文件的表现是未知的。
: 中间未必不会出错。所以分成小文件，一个一个读是最可预测结果的办法。
: 这个设计把大文件处理，和parse文件分成两个任务。也符合divide and
: conquer的原则。
|
a****l
发帖数: 8211 | 29 分成一堆小文件可能不见得有用，反而可能会更糟糕。如果程序有一堆线程同时读这些
小文件的话，文件又如果是在机械硬盘上的，那恐怕会是很可怕的，运行的好是锯硬盘
，运行的不好直接就报销了硬盘，然后就不需要担心了...
【在 g****t 的大作中提到】
: 如果是实战，要把大csv文件读入数组。
: 我会这样做：
: 1. 先用fseek ...写一个文件分割器。将其分为n个小文件。
: 2.用常用的读，parse csv第三方软件，依次读取。
: 这个办法的目的是：最小化uncertainty。
: parse csv不是trivial 的任务。自己写不划算。必须用第三方。
: 然而第三方csv parse根据个人经验，对大文件的表现是未知的。
: 中间未必不会出错。所以分成小文件，一个一个读是最可预测结果的办法。
: 这个设计把大文件处理，和parse文件分成两个任务。也符合divide and
: conquer的原则。
|
g*******u
发帖数: 3948 | 30 感觉1，2个g差不多吧。s3上传普通限制好像是5g左右。
【在 g****t 的大作中提到】
: R那个为什么快？优化思路是什么？放内存肯定是基本策略。放多少呢？buffsize怎么
: 定的？
:
:
: R data.table fread，底层用C写的，久经考验。
:
: Hadley搞了个readr想挑战，最终还是比fread慢一倍。
:
: 第一步先把能放进内存的放进内存再说，不要小文件IO。
:
|
|
|
g****t
发帖数: 31659 | 31 能妥善处理1G的库非常多，这被我的假设。
当然不能分成20k的文件。
: 分成一堆小文件可能不见得有用，反而可能会更糟糕。如果程序有一堆线程同时
读这些
: 小文件的话，文件又如果是在机械硬盘上的，那恐怕会是很可怕的，运行的好是
锯硬盘
: ，运行的不好直接就报销了硬盘，然后就不需要担心了...
【在 a****l 的大作中提到】
: 分成一堆小文件可能不见得有用，反而可能会更糟糕。如果程序有一堆线程同时读这些
: 小文件的话，文件又如果是在机械硬盘上的，那恐怕会是很可怕的，运行的好是锯硬盘
: ，运行的不好直接就报销了硬盘，然后就不需要担心了...
|
g****t
发帖数: 31659 | 32 c标准库应该比cpp库快，对环境依赖也更少，这个假设对不对？
: 要讲性能，就得考虑平台了。
: 以linux为例，这个任务其实很简单。两个考虑：
: 1. File io要能readahead，and for memory copy, batch read to
application
: memory for good memory copy performance.
: 2. Application level: existing parser to directly parse application
memory.
: For 2. getline什么的都可以。
: For 1. 如果想用流输入输出函数（比如getline）batch read可以用setvbuf（
）（
: https://en.cppreference.com/w/c/io/setvbuf）；
: readahead，直接call同名的system call就可以（https://man7.org/linux/
man-
: pages/man2/readahead.2.html）。这个call是异步的，对application的
blocking几乎
【在 s****r 的大作中提到】
: 要讲性能，就得考虑平台了。
: 以linux为例，这个任务其实很简单。两个考虑：
: 1. File io要能readahead，and for memory copy, batch read to application
: memory for good memory copy performance.
: 2. Application level: existing parser to directly parse application memory.
: For 2. getline什么的都可以。
: For 1. 如果想用流输入输出函数（比如getline）batch read可以用setvbuf（）（
: https://en.cppreference.com/w/c/io/setvbuf）；
: readahead，直接call同名的system call就可以（https://man7.org/linux/man-
: pages/man2/readahead.2.html）。这个call是异步的，对application的blocking几乎
|
l*******m
发帖数: 1096 | 33 我的确是从非技术角度讲。protobuf的最大好处是选择了格式就定了实现。json也不错
，有几个过硬的实现。csv最乱了。
码工不能化大部分时间吵架。要做一系列决定是要命的，最好做一个bundle的决定
：我这是有一说一。没学过protobuf。
：会用的人，这可能是个捷径。 |
g****t
发帖数: 31659 | 34 谢谢推荐。今晚学一下protobuf，也许可以引入使用。
csv好处是人人都觉得自己懂。坏处也是如此。
前面有个id说当年写csv parser,他搞了一个月。
: 我的确是从非技术角度讲。protobuf的最大好处是选择了格式就定了实现
。json
也不错
: ，有几个过硬的实现。csv最乱了。
: 码工不能化大部分时间吵架。要做一系列决定是要命的，最好做一个
bundle的决定
: ：我这是有一说一。没学过protobuf。
: ：会用的人，这可能是个捷径。
【在 l*******m 的大作中提到】
: 我的确是从非技术角度讲。protobuf的最大好处是选择了格式就定了实现。json也不错
: ，有几个过硬的实现。csv最乱了。
: 码工不能化大部分时间吵架。要做一系列决定是要命的，最好做一个bundle的决定
:
: ：我这是有一说一。没学过protobuf。
: ：会用的人，这可能是个捷径。
|
b*******s
发帖数: 5216 | |
h****e
发帖数: 2125 | 36 把csv变成binary file不是serialize加save吗？
【在 g****t 的大作中提到】
: 目测本版Qualified 马工数量大幅下降。
:
:
: 。。。。。。。。。
:
: 这事情就叫parse。
:
|
g****t
发帖数: 31659 | 37 csv是带格式纯文本文件。0的数据是48 (ascii). 变成数组然后序列化什么的，再存储
是可以
的。
【在 h****e 的大作中提到】
: 把csv变成binary file不是serialize加save吗？
|
l****r
发帖数: 119 | 38 按行存储不如按列存储快
存字符不如存成二进制
csv 按行，字符
protobuf 按行，二进制
parquet 按列，二进制 |
