斯坦福 IT

科长开讲:SQL,Python 和 R 语言,20年老兵三分钟给你讲明白,超越一切大学教授和网络博主

最大赞力
0.00
当前赞力
100.00%
20年一线老兵,只说干货:

1. 有数据库的时候,就只用SQL;

2. 没有数据库的时候,也没有条件建库的时候,1G以下的CSV可以勉强用EXCEL手工处理,1G以上的就必须用Python或者R等语言了;

3. 5个G的CSV巨型文件,如果只是统计,那么就用R。如果除了统计之外,还需要重新处理排序和归纳数据列表,那就用Python;

4. SQL是查询语言,R是统计语言,Python是多功能编程语言(可以兼任查询和统计的功能,当然也可以像JAVE和C一样编程序);

5. 为什么会没有数据库呢?大型互联网和金融分析,需要当天或者2-3个小时内出结果,客户出于安全等考虑,不会授权给乙方数据库操作权限。所以,你只有一个SFTP上面导出的CSV文件,或者AWS CLOUD直接Read Only文件,10G数据量,2个小时内出结果,你的IT DBA不可能给你资源建库,导入数据,然后慢慢用SQL和BI工具处理,你也没有那么多时间。所以Python和R就是你的好朋友了;

6. 即使是甲方自己的人员,出于Production服务器的运行效率,也不会允许BI或者DA等人员,直接在后台数据库上跑SQL,而且很多最新的Apps后台用的也不是传统的SQL服务器,根本无法用SQL+BI的传统方法;

7. 但是对于一个数据科学家或者Data Engineer,90%还是需要SQL,毕竟那种极端案例不多,不是天天都需要996,711去处理10个G的CSV文件,90%的企业,包括亚麻厂,鸽厂,窗户厂,平时也还是在用SQL+BI+PPT去汇报;

8. SQL是九阳神功,Python和R是倚天剑和屠龙刀,没有SQL,任何人在大数据分析这个行业里,走不长,也走不远,很多大学毕业的小孩,尤其是财务背景的文科生转到BI或者DA,总想弯道超车绕过SQL,那是走不通的,SQL无法被超越和替代,SQL是一切万物的基础体能,3000米都跑不下来,还学踢足球?
 
最后编辑: 2019-12-28
最大赞力
0.00
当前赞力
100.00%
第二课:ETL 和 Data Pipeline

程序员是把鱼苗投入大海(湖泊),BI数据科学家是渔民,把长大的鱼苗从大海里面捞出来。这干工作分三步:

1. 数据准备(传统客户端:ETL,云端:Data Pipeline)
2. 数据分析(传统客户端:SAP BO,Power BI,云端:Python写脚本,AWS自带工具等)
3. 数据可视化(Tableau,Qlikview,PPT等)

传统环境下,分析企业内部数据,进销存ERP,CRM,SCM,财务人事Workday,销售和市场,这些都是企业局域网内部的,相当于淡水湖泊,这时候渔民成为BI,做报表的叫BI Developer,底层数据处理的叫做ETL Developer,核心工具SQL + SSIS + 各种前端BI软件(SAP BO,MS Power BI,Tableau,Qlikview),数据接口叫ODBC,JDBC,数据分析前的准备工作叫做ETL,鱼塘成为数据仓库Date Warehouse(Data Mart)。这个阶段的数据大部分都是结构化的,数据量可控,报告周期:周报,月报,季报,年报。传统环境的数据分析,相当于肉少(数据小),刺多(维度多)。做好了,并不简单。

互联网环境下,目前和未来,数据都向云端转移,从淡水湖泊向大海进军,做报表的叫数据科学家,底层数据处理的叫做Data Engineer,数据接口是各种网络端口和API程序。肉多(数据大),刺小(维度少)。看着复杂,其实相对传统环境反而简单,但是消耗时间,因为数据量不可控,报告周期:日报,6小时报,1小时报。

淡水:ETL,萃取,转移,录入,将不同内部业务系统的各种数据,各种离线的CSV,TXT,PDF,通过清理,整合到数据仓库(鱼塘)的过程。前端的BI人员只需要在数据仓库内就可以轻松找到所需要的所有数据和维度,而且由于重新整合了数据结构,所以BI人员的报表应该不用担心效率问题。

深海:Data Pipeline = 传统ETL + SUM (互联网上各种非结构化数据,赞转评,跳转,点击,Review,下单付款信息,后台仓库的ERP,上传附件,库存数据的毫秒级更新,等等)。最大的特点是,支持公有云上面的各种数据处理整合。亚马逊和微软的公有云业务上都有自己的Data Pipeline产品,其实就是云端的ETL工具。

R语言,SAS软件,SPSS软件,是个人版桌面统计工具(家里的鱼缸),不是企业版的BI工具,更不是互联网公有云上的数据科学分析工具,这里不讨论。SAS应用场景局限在一些金融机构,比如基金经理下面都会带几个助理,这几个助理会有人用SAS类似的统计软件处理数据。大学研究所里,做实验,在个人电脑上用SPSS分析一下实验数据,其实就是超大号的EXCEL。
 
最后编辑: 2019-12-28
最大赞力
0.00
当前赞力
100.00%
第三课:Data Warehouse (Data Mart) 和 Data Lake,Data Ocean

这个内容,我在第一课 课后答疑 1.2 简单概述了一点。

Database 数据库:封闭的有大门的,里面有整齐货架的标准仓库。

Data Warehouse 数据仓库:为了解决数据库的查询效率缺陷而设计,分区域设计的仓库,将大仓库里的数据按照类型重新在依照同类型分区域摆放。从数据库导入数据仓库的过程叫做ETL。

业务系统运行在数据库上,报表系统运行在数据仓库上。

互联网时代的又出现了,露天堆放的货场,货场的优势就是存数据快,货场可以成为:文本数据库和图数据库。图数据库不是存图片的,图数据库没有表,只有线(列,Column),每条线上都可以堆放不同类似的数据,这是传统数据库上的Column不可思议的,抓数据的时候,不是表和表之间的关联,而是把每条线上所需的点构成软连接,从而形成一个虚拟的临时网络图,故谓之“图数据库”。人类的大脑就是“图数据库”,这种又称为,神经网络。

Data Lake:Database + Data Warehouse + 露天堆放场 (文件数据库)+ 各种离线数据

Data Ocean:Data Lake + 其它任何没有包括的内容

阿里巴巴的所谓自研数据库,叫 Ali Data Ocean,其实是个伪科学。

淘宝和天猫,其实后台的科技含量很低,甚至低于京东,和亚马逊无法比,整体访问量惊人,存储量巨大,但是这都毫无意义。因为天猫上百万商家,都是独立的系统,后面就是一个个开源的MySQL,只是简单的网页页面串联起来。用户在NIKE店下单,只影响NIKE店家的后台进销存系统,不会影响三只松鼠。NIKE,三只松鼠,这些店家都是一个小的MySQL系统,蚂蚁雄兵,聚沙成塔。阿里的模式,可以无穷扩大,而不需要技术突破。阿里的最大科技含量在于他的蚂蚁金服,广告系统,会员系统。蚂蚁金服的数据量不及VISA和万事达信用卡,甚至数据量不及工商银行等,广告系统不及Google的十分之一,FB的五分之一。会员店家系统,确实是他的特长,网络上的万达商城,小商品城嘛。

但是,京东和亚马逊这些直营电商,后面是一个总的大库,不可能像阿里一样,构建几百万个小MySQL来处理。所以,亚麻厂研发出来了云计算AWS,用新型的文本数据库技术突破解决了问题。京东还是要依靠甲骨文,IBM这些传统大厂来用老方法不断优化,开发自营平台,不仅仅是财务,业务和成本的必须,也是技术上的必须,所有都自营,IT后台不好消化。

阿里玩的是机海模式,亚麻是技术突破后的降维打击。
 
最后编辑: 2019-12-29
最大赞力
0.00
当前赞力
100.00%
第五课:BI developer 和 Data Scientist

给大家看一道笔试题吧,多伦多温哥华的行情

能做出SQL解法的,可以进入初级BI开发人员的面试,起薪7万加刀
能做出Python和R的解法,可以进入初级Data Scientist的面试,起薪10万加刀
如果都能做出来,可以考虑应聘Data Engineer Level I,起薪11万加刀

Problem: Member can make purchase via either mobile or desktop platform. Using the following data table to determine the total number of member and revenue for mobile-only, desktop_only and mobile_desktop.
The input spending table is
member_id date channel spend
1001 1/1/2018 mobile 100
1001 1/1/2018 desktop 100
1002 1/1/2018 mobile 100
1002 1/2/2018 mobile 100
1003 1/1/2018 desktop 100
1003 1/2/2018 desktop 100

The output data is
date channel total_spend total_members
1/1/2018 desktop 100 1
1/1/2018 mobile 100 1
1/1/2018 both 200 1
1/2/2018 desktop 100 1
1/2/2018 mobile 100 1
1/2/2018 both 0 0


SQL solution:

CREATE VIEW member_spend AS
SELECT
date,
member_id,
SUM(CASE WHEN channel == ‘mobile’ THEN spend ELSE 0 END) AS mobile_spend,
SUM(CASE WHEN channel == ‘desktop’ THEN spend ELSE 0 END) AS desktop_spend
FROM
spending
GROUP BY date, member_id;


SELECT
date,
CASE WHEN mobile_spend > 0 AND desktop_spend = 0 THEN ‘mobile’
WHEN mobile_spend = 0 AND desktop_spend > 0 THEN ‘desktop’
WHEN mobile_spend > 0 AND desktop_spend > 0 THEN ‘both’
END AS channel,
SUM(mobile_spend + desktop_spend) AS total_spend,
COUNT(*) AS total_members
FROM member_spend
GROUP BY
date,
CASE WHEN mobile_spend > 0 AND desktop_spend = 0 THEN ‘mobile’
WHEN mobile_spend = 0 AND desktop_spend > 0 THEN ‘desktop’
WHEN mobile_spend > 0 AND desktop_spend > 0 THEN ‘both’
END;

Python pandas:

spending[‘mobile_spend’] = spending[spending.channel == ‘mobile’].spend
spending[‘desktop_spend’] = spending[spending.channel == ‘desktop’].spend
member_spend = spending.group_by([‘date’, ‘member_id’]).sum([‘mobile_spend’, ‘desktop_spend’]).to_frame([‘mobile_spend’, ‘desktop_spend’].reset_index()

SQL

SELECT
date,
CASE WHEN mobile_spend > 0 AND desktop_spend = 0 THEN ‘mobile’
WHEN mobile_spend = 0 AND desktop_spend > 0 THEN ‘desktop’
WHEN mobile_spend > 0 AND desktop_spend > 0 THEN ‘both’
END AS channel,
SUM(mobile_spend + desktop_spend) AS total_spend,
COUNT(*) AS total_members
FROM member_spend
GROUP BY
date,
CASE WHEN mobile_spend > 0 AND desktop_spend = 0 THEN ‘mobile’
WHEN mobile_spend = 0 AND desktop_spend > 0 THEN ‘desktop’
WHEN mobile_spend > 0 AND desktop_spend > 0 THEN ‘both’
END;

Python pandas

member_spend[member_spend.mobile_spend>0 & member_spend.desktop_spend==0], ‘channel’] = ‘mobile’
member_spend[member_spend.mobile_spend==0 & member_spend.desktop_spend>0], ‘channel’] = ‘desktop’
member_spend[member_spend.mobile_spend>0 & member_spend.desktop_spend>0], ‘channel’] = ‘both’


tot_members = member_spend.groupby([‘date’, ‘channel’]).size().to_frame(‘tot_members’).reset_index()
tot_spend = member_spend.groupby([‘date’, ‘channel’].agg({‘mobile_spend’:sum, ‘desktop_spend’:sum}).to_frame([‘mobile_spend’, ‘desktop_spend’])
tot_spend[‘tot_spend’] = tot_spend[‘mobile_spend’] + tot_spend[‘desktop_spend’]
output = tot_members.concat(tot_spend[‘tot_spend’])


R dplyr:

output <- spending %>%
group_by(member_id, date)%>%
summarise(mobile_spend = sum(spend[channel == 'mobile']),
desktop_spend = sum(spend[channel == 'desktop'])) %>%
mutate(channel = ifelse((mobile_spend>0 & desktop_spend>0), 'both',
ifelse(mobile_spend==0, 'desktop', 'mobile'))) %>%
group_by(date, channel)%>%
summarise(total_spend = mobile_spend + desktop_spend,
total_member = n())
 
最后编辑: 2019-12-29
最大赞力
0.00
当前赞力
100.00%
20年一线老兵,只说干货:

1. 有数据库的时候,就只用SQL;

2. 没有数据库的时候,也没有条件建库的时候,1G以下的CSV可以勉强用EXCEL手工处理,1G以上的就必须用Python或者R等语言了;

3. 5个G的CSV巨型文件,如果只是统计,那么就用R。如果除了统计之外,还需要重新处理排序和归纳数据列表,那就用Python;

4. SQL是查询语言,R是统计语言,Python是多功能编程语言(可以兼任查询和统计的功能,当然也可以像JAVE和C一样编程序);

5. 为什么会没有数据库呢?大型互联网和金融分析,需要当天或者2-3个小时内出结果,客户出于安全等考虑,不会授权给乙方数据库操作权限。所以,你只有一个SFTP上面导出的CSV文件,或者AWS CLOUD直接Read Only文件,10G数据量,2个小时内出结果,你的IT DBA不可能给你资源建库,导入数据,然后慢慢用SQL和BI工具处理,你也没有那么多时间。所以Python和R就是你的好朋友了;

6. 但是对于一个数据科学家或者Data Engineer,90%还是需要SQL,毕竟那种极端案例不多,不是天天都需要996,711去处理10个G的CSV文件。
谢谢。虽然是外行,但给了我大方向上的思路。很不错。
 
最大赞力
0.00
当前赞力
100.00%
20年一线老兵,只说干货:

1. 有数据库的时候,就只用SQL;

2. 没有数据库的时候,也没有条件建库的时候,1G以下的CSV可以勉强用EXCEL手工处理,1G以上的就必须用Python或者R等语言了;

3. 5个G的CSV巨型文件,如果只是统计,那么就用R。如果除了统计之外,还需要重新处理排序和归纳数据列表,那就用Python;

4. SQL是查询语言,R是统计语言,Python是多功能编程语言(可以兼任查询和统计的功能,当然也可以像JAVE和C一样编程序);

5. 为什么会没有数据库呢?大型互联网和金融分析,需要当天或者2-3个小时内出结果,客户出于安全等考虑,不会授权给乙方数据库操作权限。所以,你只有一个SFTP上面导出的CSV文件,或者AWS CLOUD直接Read Only文件,10G数据量,2个小时内出结果,你的IT DBA不可能给你资源建库,导入数据,然后慢慢用SQL和BI工具处理,你也没有那么多时间。所以Python和R就是你的好朋友了;

6. 但是对于一个数据科学家或者Data Engineer,90%还是需要SQL,毕竟那种极端案例不多,不是天天都需要996,711去处理10个G的CSV文件。
 
最大赞力
0.00
当前赞力
100.00%
20年一线老兵,只说干货:

1. 有数据库的时候,就只用SQL;

2. 没有数据库的时候,也没有条件建库的时候,1G以下的CSV可以勉强用EXCEL手工处理,1G以上的就必须用Python或者R等语言了;

3. 5个G的CSV巨型文件,如果只是统计,那么就用R。如果除了统计之外,还需要重新处理排序和归纳数据列表,那就用Python;

4. SQL是查询语言,R是统计语言,Python是多功能编程语言(可以兼任查询和统计的功能,当然也可以像JAVE和C一样编程序);

5. 为什么会没有数据库呢?大型互联网和金融分析,需要当天或者2-3个小时内出结果,客户出于安全等考虑,不会授权给乙方数据库操作权限。所以,你只有一个SFTP上面导出的CSV文件,或者AWS CLOUD直接Read Only文件,10G数据量,2个小时内出结果,你的IT DBA不可能给你资源建库,导入数据,然后慢慢用SQL和BI工具处理,你也没有那么多时间。所以Python和R就是你的好朋友了;

6. 即使是甲方自己的人员,出于Production服务器的运行效率,也不会允许BI或者DA等人员,直接在后台数据库上跑SQL,而且很多最新的Apps后台用的也不是传统的SQL服务器,根本无法用SQL+BI的传统方法;

7. 但是对于一个数据科学家或者Data Engineer,90%还是需要SQL,毕竟那种极端案例不多,不是天天都需要996,711去处理10个G的CSV文件,90%的企业,包括亚麻厂,鸽厂,窗户厂,平时也还是在用SQL+BI+PPT去汇报;

8. SQL是九阳神功,Python和R是倚天剑和屠龙刀,没有SQL,任何人在大数据分析这个行业里,走不长,也走不远,很多大学毕业的小孩,尤其是财务背景的文科生转到BI或者DA,总想弯道超车绕过SQL,那是走不通的,SQL无法被超越和替代,SQL是一切万物的基础体能,3000米都跑不下来,还学踢足球?

sql 能不能算这个,admin 设置了奖金求算法:)

 

Similar threads

家园推荐黄页

家园币系统数据

家园币池子报价
家园币最新成交价
家园币总发行量
加元现金总量
家园币总成交量
家园币总成交价值

池子家园币总量
池子加元现金总量
池子币总量
1池子币现价
池子家园币总手续费
池子加元总手续费
入池家园币年化收益率
入池加元年化收益率

微比特币最新报价
毫以太币最新报价
微比特币总量
毫以太币总量
家园币储备总净值
家园币比特币储备
家园币以太币储备
比特币的加元报价
以太币的加元报价
USDT的加元报价

交易币种/月度交易量
家园币
加元交易对(比特币等)
USDT交易对(比特币等)
顶部