pandas和sql各自擅长的领域

[magagop]

Raw data 在database里怎么读csv.

DL訓練數據集一般不放進database，因為不需要頻繁改動。SQL只對頻繁改動的熱數據有用，如果數據量特別大（訓練數據幾個TB），而且對性能極其敏感（要求用滿硬件帶寬），又完全不需要在線改動（沒有transaction需求），那SQL就沒有優勢，這時候能用的只有pandas和numpy，或者自己寫的data loader。

[cangyoujiacuo]

你这是不用造好的轮子，非要自己再造。。。pandas是c写的，可比c#,java快多了

我自己的东西，为了追求速度，几乎不用其它轮子，都是自己造。
公司的东西，图快，尽量用轮子，那些所谓的轮子大多都是为了追求通用性，转了好几道弯弯，速度上要差很多，无论他们怎么吹。就算有些轮子特别优秀，你把idea借鉴过来自己写，也绝对要强一些。

[wokao]

SQL主要的问题是和python接口不方便。

我用了这么长时间, 没感觉duckdb接口比dataframe接口有啥不方便, 多了一个import?

[TheMatrix]

我用了这么长时间, 没感觉duckdb接口比dataframe接口有啥不方便, 多了一个import?

嗯。我看看DuckDB。

[fantasist]

pandas语法处理快速数据方便，可读性也高
df_filtered = df[df['age'] > 30]
df_grouped = df_filtered.groupby('city')['salary'].mean()
final_result = df_grouped.sort_values(ascending=False).reset_index()

在notebook里还能直接visualize
df['salary'].hist(bins=20)
df.plot.scatter(x='age', y='salary')

尤其在ML行业，数据能load进内存，各种手工操作试验频繁的，肯定用pandas，基本没有直接用sql的。倒是有面向non technical analyst的UI工具，通过选项构建query，背后可能是sql但基本transparent了。
做数据分析时，对million以上row的ad hoc query，或者对freshness有要求的data pipeline，才会在data warehouse上用sql。

[wokao]

仅仅是可读，而不是可写。最适合没学过数据库的，比如统计出身。

如果已经学过sql，duckdb最适合。你可以想象成用sql交流的dataframe

需要画图，一个duck db的表可以内存里映射成pandas，效率极高。

pandas语法处理快速数据方便，可读性也高
df_filtered = df[df['age'] > 30]
df_grouped = df_filtered.groupby('city')['salary'].mean()
final_result = df_grouped.sort_values(ascending=False).reset_index()

在notebook里还能直接visualize
df['salary'].hist(bins=20)
df.plot.scatter(x='age', y='salary')

尤其在ML行业，数据能load进内存，各种手工操作试验频繁的，肯定用pandas，基本没有直接用sql的。倒是有面向non technical analyst的UI工具，通过选项构建query，背后可能是sql但基本transparent了。
做数据分析时，对million以上row的ad hoc query，或者对freshness有要求的data pipeline，才会在data warehouse上用sql。

[fantasist]

仅仅是可读，而不是可写。最适合没学过数据库的，比如统计出身。

如果已经学过sql，duckdb最适合。你可以想象成用sql交流的dataframe

需要画图，一个duck db的表可以内存里映射成pandas，效率极高。

不知道你在说什么。
df_filtered = df[df['age'] > 30]
df_grouped = df_filtered.groupby('city')['salary'].mean()
final_result = df_grouped.sort_values(ascending=False).reset_index()
难道不比
SELECT city, avg(salary) as avg_salary
FROM table
WHERE age > 30
GROUP BY city
ORDER BY city DESC
不仅可读性强，可写性也更好？除了一些高级IDE能较好地提示syntax error，比如拼错的column不存在，想不出其它用sql的优势。

"一个duck db的表可以内存里映射成pandas，效率极高" 搞数据的工作很多就几百几千条反复折腾，当然是直接往jupyter notebook里load一个pandas dataframe方便。不否认肯定有运行效率更高的framework，但即使1 million rows的dataset上某个操作可能也只是1秒vs 5秒，实际区别几乎为0，得先根据use case看是不是over engineering。

[hci]

公平的讲，你这个例子还是SQL这个可读性更强，python这个太多语法和符号噪音了。不说别的，你数一数，比较一下字符数量吧。python各种符号，括号，还他妈嵌套着，这叫可读性强？

比如，df[df['age'] > 30] <- WTF is this?

同学们要有点自我意识，客观一点。

不知道你在说什么。
df_filtered = df[df['age'] > 30]
df_grouped = df_filtered.groupby('city')['salary'].mean()
final_result = df_grouped.sort_values(ascending=False).reset_index()
难道不比
SELECT city, avg(salary) as avg_salary
FROM table
WHERE age > 30
GROUP BY city
ORDER BY city DESC
不仅可读性强，可写性也更好？除了一些高级IDE能较好地提示syntax error，比如拼错的column不存在，想不出其它用sql的优势。

"一个duck db的表可以内存里映射成pandas，效率极高" 搞数据的工作很多就几百几千条反复折腾，当然是直接往jupyter notebook里load一个pandas dataframe方便。不否认肯定有运行效率更高的framework，但即使1 million rows的dataset上某个操作可能也只是1秒vs 5秒，实际区别几乎为0，得先根据use case看是不是over engineering。

[fantasist]

公平的讲，你这个例子还是SQL这个可读性更强，python这个太多语法和符号噪音了。不说别的，你数一数，比较一下字符数量吧。python各种符号，括号，还他妈嵌套着，这叫可读性强？

比如，df[df['age'] > 30] <- WTF is this?

同学们要有点自我意识，客观一点。

pandas还支持其它写法，比如
df.query("age > 30")
df[df.age > 30]
搞数据的人用上个回复里的写法最多，因为label based location indexer强大好用。非要说这样得额外学一些不是python native的DSL，也确实，但不管怎样比学习SQL里边乱七八糟的别扭语法强太多了。
我知道你所谓做AI时只调用过chatgpt api，没静下心来搞过数据。一个门外汉连最基本的loc都看不明白就别来凑热闹了。

[wokao]

你那些熊猫语句对应的duckdb如下, 当然, 我觉得仍然可以合并一下, 比如前两个, 甚至全都合并, 仍然不影响可读性, 甚至更可读

你为了增加可读性, 把步骤分拆了, 导致的问题是无用的中间结果和效率低下
而duckdb里分拆却毫无问题. 因为duckdb是懒惰处理的, 熊猫是及时处理

对于学过数据库的, 当然直接写sql容易了.

python的变量可以直接用在duckdb的sql里边
而且duckdb到 北极熊是内存中零拷贝映射, 就是在筛选数据的时候用duckdb, 最后需要北极熊或者熊猫了, 可以方便变身.

r_filtered = con.sql("""
SELECT * FROM df
WHERE age > 30
""")

r_grouped = con.sql("""
SELECT city, AVG(salary) AS avg_salary
FROM r_filtered
GROUP BY city
""")

final_result_r = con.sql("""
SELECT city, avg_salary
FROM r_grouped
ORDER BY avg_salary DESC
""")

final_result_df = final_result_r.df()

不知道你在说什么。
df_filtered = df[df['age'] > 30]
df_grouped = df_filtered.groupby('city')['salary'].mean()
final_result = df_grouped.sort_values(ascending=False).reset_index()
难道不比
SELECT city, avg(salary) as avg_salary
FROM table
WHERE age > 30
GROUP BY city
ORDER BY city DESC
不仅可读性强，可写性也更好？除了一些高级IDE能较好地提示syntax error，比如拼错的column不存在，想不出其它用sql的优势。

"一个duck db的表可以内存里映射成pandas，效率极高" 搞数据的工作很多就几百几千条反复折腾，当然是直接往jupyter notebook里load一个pandas dataframe方便。不否认肯定有运行效率更高的framework，但即使1 million rows的dataset上某个操作可能也只是1秒vs 5秒，实际区别几乎为0，得先根据use case看是不是over engineering。

[wokao]

难道还需要学SQL?

我早说了, 熊猫适合没学过数据库的

pandas还支持其它写法，比如
df.query("age > 30")
df[df.age > 30]
搞数据的人用上个回复里的写法最多，因为label based location indexer强大好用。非要说这样得额外学一些不是python native的DSL，也确实，但不管怎样比学习SQL里边乱七八糟的别扭语法强太多了。
我知道你所谓做AI时只调用过chatgpt api，没静下心来搞过数据。一个门外汉连最基本的loc都看不明白就别来凑热闹了。

[hci]

客观的说，python就是一个一团乱麻的烂语言，缺乏一致性，大致就如英语一样，到处都是特例，需要背。比如说最简单的，去掉dict一个键，需要用del语句！真他妈烂。

SQL也不是啥好语言，但起码想要让manager能用，妄图declarative，设计思维就比python要强不少。

论数据处理，matlab比python要强不少，起码一致性不错。R也不错，毕竟有点Lisp设计底子。

只有见识短浅的小朋友才觉得python易读，还是多学几门语言再评价吧。

pandas还支持其它写法，比如
df.query("age > 30")
df[df.age > 30]
搞数据的人用上个回复里的写法最多，因为label based location indexer强大好用。非要说这样得额外学一些不是python native的DSL，也确实，但不管怎样比学习SQL里边乱七八糟的别扭语法强太多了。
我知道你所谓做AI时只调用过chatgpt api，没静下心来搞过数据。一个门外汉连最基本的loc都看不明白就别来凑热闹了。

[hci]

python本来就是给外行用的，一团乱麻，哪有什么编程口味。烂就一个字。

难道还需要学SQL?

我早说了, 熊猫适合没学过数据库的

[fantasist]

你那些熊猫语句对应的duckdb如下, 当然, 我觉得仍然可以合并一下, 比如前两个, 甚至全都合并, 仍然不影响可读性, 甚至更可读

你为了增加可读性, 把步骤分拆了, 导致的问题是无用的中间结果和效率低下
而duckdb里分拆却毫无问题. 因为duckdb是懒惰处理的, 熊猫是及时处理

对于学过数据库的, 当然直接写sql容易了.

python的变量可以直接用在duckdb的sql里边
而且duckdb到 北极熊是内存中零拷贝映射, 就是在筛选数据的时候用duckdb, 最后需要北极熊或者熊猫了, 可以方便变身.

r_filtered = con.sql("""
SELECT * FROM df
WHERE age > 30
""")

r_grouped = con.sql("""
SELECT city, AVG(salary) AS avg_salary
FROM r_filtered
GROUP BY city
""")

final_result_r = con.sql("""
SELECT city, avg_salary
FROM r_grouped
ORDER BY avg_salary DESC
""")

final_result_df = final_result_r.df()

我觉得lazy eval不是问题，普通的builder pattern实现而已，pandas不做可能是历史原因，不想引入不向后兼容的语法改动。你的代码里参杂sql的各种问题表现得很明显。首先再声明一下，正常数据工作时会用到中间变量，比如先filter 30岁以后研究一下，然后再filter salary看一下。这些中间变量可能被反复使用，而且数据量不大，所以效率问题很多情况下不存在。再次强调一遍，不要over engineering。回到代码，第一个问题，基于中间变量进一步filter直接调用一个函数即可，而你的写法还得重新select from，属于完全没必要的重复。第二个问题，两种语言混在一起，本身就是降低可读性的，一二十年前php java等语言的项目也容易受这类问题的困扰，小项目就算了，大项目里放一堆sql是典型的屎山。都2025年了别再抱着明显的糟粕。

[hci]

你就是个senior的水平。

我觉得lazy eval不是问题，普通的builder pattern实现而已，pandas不做可能是历史原因，不想引入不向后兼容的语法改动。你的代码里参杂sql的各种问题表现得很明显。首先再声明一下，正常数据工作时会用到中间变量，比如先filter 30岁以后研究一下，然后再filter salary看一下。这些中间变量可能被反复使用，而且数据量不大，所以效率问题很多情况下不存在。再次强调一遍，不要over engineering。回到代码，第一个问题，基于中间变量进一步filter直接调用一个函数即可，而你的写法还得重新select from，属于完全没必要的重复。第二个问题，两种语言混在一起，本身就是降低可读性的，一二十年前php java等语言的项目也容易受这类问题的困扰，小项目就算了，大项目里放一堆sql是典型的屎山。都2025年了别再抱着明显的糟粕。

[fantasist]

难道还需要学SQL?

我早说了, 熊猫适合没学过数据库的

没有不会基本sql的吧，学校里不都教这个？
反正数据不大能load进pandas操作的话，就别想其它了。听我一句劝，可以节省无数时间。
如果公司非要在enterprise data warehouse上写sql，那就没办法了。sf spark flink每个都有自己的sql flavor，backend用的relational db比如postgres又是一套flavor。干过一次就知道为什么这些是狗屎了。

[wokao]

既然教了, 就可以直接用了. 不用学熊猫草创的玩意儿

没有不会基本sql的吧，学校里不都教这个？
反正数据不大能load进pandas操作的话，就别想其它了。听我一句劝，可以节省无数时间。
如果公司非要在enterprise data warehouse上写sql，那就没办法了。sf spark flink每个都有自己的sql flavor，backend用的relational db比如postgres又是一套flavor。干过一次就知道为什么这些是狗屎了。

[wokao]

julia
跟matlab及其相像, 改过一个matlab, 最主要的就是把矩阵索引的圆括弧改成方括弧

客观的说，python就是一个一团乱麻的烂语言，缺乏一致性，大致就如英语一样，到处都是特例，需要背。比如说最简单的，去掉dict一个键，需要用del语句！真他妈烂。

SQL也不是啥好语言，但起码想要让manager能用，妄图declarative，设计思维就比python要强不少。

论数据处理，matlab比python要强不少，起码一致性不错。R也不错，毕竟有点Lisp设计底子。

只有见识短浅的小朋友才觉得python易读，还是多学几门语言再评价吧。

[wokao]

你自己的贴子也是两种语言混一起, 很常见, 没问题

sql的可读性比熊猫草创的玩意儿还是强, 更何况是零学习成本

我觉得lazy eval不是问题，普通的builder pattern实现而已，pandas不做可能是历史原因，不想引入不向后兼容的语法改动。你的代码里参杂sql的各种问题表现得很明显。首先再声明一下，正常数据工作时会用到中间变量，比如先filter 30岁以后研究一下，然后再filter salary看一下。这些中间变量可能被反复使用，而且数据量不大，所以效率问题很多情况下不存在。再次强调一遍，不要over engineering。回到代码，第一个问题，基于中间变量进一步filter直接调用一个函数即可，而你的写法还得重新select from，属于完全没必要的重复。第二个问题，两种语言混在一起，本身就是降低可读性的，一二十年前php java等语言的项目也容易受这类问题的困扰，小项目就算了，大项目里放一堆sql是典型的屎山。都2025年了别再抱着明显的糟粕。

[Onlymoi]

感觉都差不多。以前什么framework数据多点都慢得要死。现在memory便宜，自然可行了。熊猫里数据揉来揉去方便。看到上面讲的步骤group， sort， select等等都是一样的，不同的是在哪里做的。以前有个公司提供的失去了sql server的drives全部用memory， 把sql弄得贼快.