600 万行 tsv 打开方式

klogg

直接进数据库？

主要得看业务部门会啥，他们要是会 SQL ，那可以转换成 parquet 或者直接导入数据库，把 parquet 或者数据库的地址给他们，让他们自己写 SQL 分析(duckdb 可以读取到 parquet)。
要是只会 Excel ，那有点麻烦，建议把数据拆分一下，按日期拆分成每个 20 万行的 Excel 或者 csv 。
还可以在导入数据库之后，搭建一个 metabase ，让他们用可视化的方式分析，meta 上手难度高于 Excel ，跟 Excel 透视表类似，但低于 SQL 。
不过有时候吧，这帮业务部门人员 Excel 能力不太敢恭维，只是很基础的 Excel 操作。。。

试试 emeditor 这个还不行别的也不用试了 除非换硬件

放到 hdfs 集群，走 spark 或 hive 分析

直接给业务部门啊 他们打不开关你什么事

业务人员的确超喜欢用 Excel 自己分析数据，我前家公司的业务就这么干的，不过，后来我劝说他们改用 superset 来处理几十万以上的数据。而且，还不需要导出。

另外，正经的做法是单独建立 BI 数据仓库，避免业务库受影响。

Emeditot ，应该只有这个兜底了

sqlite ，轻量，单文件。excel 能做的 sql 都能做

如果只会 office 那就给 access 建数据源

sqlite or duckdb? 一般 raw data 大于 10w 行业务都不会一行行看，聚合计算啥的，不如 sql 方便啊。

emeditor 小 case ，我经常用。

Dask

这个数据量建议做成 sql 服务，反正 power query 也能读 sql 。标准解决方案应该是搭 BI ，但几百万行数据量又太少了，而且业务部门不一定肯出钱。

如果一定要用 tsv/csv ，先检查 Excel 一定用 64 位，内存至少 16G （多多益善）。
Power Query 默认预读 1000 行，如果只是读取 csv 这类顺序文件就算读全表也只是慢一些，不应该卡死，除非做了其他操作，或者内存瓶颈导致缓存到了硬盘。

如果业务部门还不满意，让他们提方案，比如聚合掉一些不需要的字段，很多时候业务并不需要看每一笔 transaction 。

AI 可以拆分处理

@tsvico #1 真的好用

emeditor 试试吧

600w 行的规模，早就应该上数据库了，Excel 不是用来对付这种级别规模的。

专业的需求，请上专业的方案。

按照跟业务部分打交道的经验，就拆分成多个 csv 给他们，其中一个文件小一些，几万行左右。他们会根据这个文件再提具体需求的，然后再用 SQL 或 pandas 处理好。

@snw #14
这个是比较好的，就是成本高一些。要不看看有没有免费工具可以读取 sqllite 的。