求教Analytics DS经验和常用套路学习渠道

想问下大家网上有没有更偏向于关于数据分析使用经验的常见套路常用模型归纳总结的资源？LZ的情况是入职的小公司小DS组，没经验，每个人SUPPORT不同的业务部门， 所以拿到手的活没人带，怎么分析都自己摸索。常见的任务就是用历史数据做以前某些改变的影响分析或者是预测如果未来改变哪个政策能带来多大影响，或者拿历史数据分析下怎么optimize现有政策（不用AB TEST那种， 有其他组专门做AB TEST）。感觉大方向就是observational causal inference, statistical tests,和少数opportunity sizing的活，但是实际干起来总是有各种问题不知道怎么解决。由于都得自己摸索总是进展很慢，现在这个市场，感觉跳槽也不现实，还是先苟着吧。

想问问大家有没有DS ANALYTICS/DA 偏策略经验类或者很好的知识类总结的课程和学籍呢，或者经验分享，谢谢！！
我先来一个我自己看过的 ‘Machine Learning Yearning Technical Strastegy for AI Engineers, In the Era of Deep Learning’ - by Andrew NG. 不长的一本书，里面有一些实操的经验分享，新手的我看了感觉还是很有帮助的。

平时都是潜水，这个贴蹲了几天也没有回应，那我注册一个账号来抛砖引玉吧。

先介绍背景，本人文科PhD毕业，现在在某中厂做AS，平时的工作比较杂，但是也做不少和楼主的类似工作（用历史数据做以前某些改变的影响分析或者是预测如果未来改变哪个政策能带来多大影响，或者拿历史数据分析下怎么optimize现有政策）。教不敢讲，算是分享一下自以为是的经验总结吧。着重点在“自以为是”：以下只是我觉得，并不见得多有道理或者多有帮助性。

本人 analytics 工作流程中按照重要程度依次排序的能力大概是：
1. 把 open ended 的问题拆成一个个 working definition 和 measuable metric 的能力
2. observational causal inference & statistical tests
3. Data engineering like writing adhoc ETL, query optimization, etc
4. Code quality & reusability

第一个点大概是最重要的也是最难教的。我只能说文科PhD的经历对第一点帮助很大。我之前读的经济政治历史社会学里头的数量文章最重要的步骤都是在做把一个 real world open ended question 转化成 working definition 以及 measuable metric。数量历史的文章算是个人最爱，又有很有意思的奇闻逸事，又因为数据限制经常有统计上的骚操作，很多很好读也很有收获。当然读 paper 如果太沉重了的话，找一些有经验做分析做得好的同事，看看TA是如何 handle 问题的应该也会很有帮助。但是缺点就是工作中写的 notebook 一般没有 paper 那么事无巨细经常读的一头雾水啦。

第二点 observational causal inference, statistical tests。由于本人文科转码，因此我更熟悉一本叫做 Mostly harmless econometrics 的书。里边涵盖了各种各样的 causal inference 技巧以及应用。这本书写的非常偏应用，个人认为比较好读也比较好直接应用在工作上。更重要的是里边引用了很多实际的研究，读这些研究对上一条也很有帮助。EconML 的文档写的也还不错，也可以经常读读。

另一方面很重要但经常不在 analytics DS 视野内的技术则是 DE 方向的。当你知道要算什么 measuable metric 后，当然下一步就是把它算出来啦。算出来经常意味着需要 join 一大堆不同的 table 到一起做 aggregation。由于是历史数据，因此经常需要一个很长窗口的数据，数据量往往会很大。这个时候 query optimization 就变得无比重要，各种 DE 的概念也纷纷向你走来。比如这个 join 要不要 broadcast 呀，如何管理cluster memory 不爆内存啊等等等等。这方面的话和你用的 tool 高度相关，又经常有现成的答案。因此贵司 DE 的培训教程可以认真一读。另外当你变得更 senior 一点需要去挖掘处女地了以后经常还会遇到没有现成的 table 可以用，需要去 parse backend log 自己生成自己要用的 data. 敝司以 spark 为主，这种情况偶尔还需要写 rdd 版本的 spark code. 贵司的情况不同，但这也是一个关注点。

最后一点不直接影响工作质量，但往往能决定你几点下班。根据本人经验，分析半路经常会有一些新的发现和想法、PM 经常会要你做补充分析看看其他 segment 等等。因此如果你的代码一开始就设计的比较容易接受新的 segment、新的 metric，那么就比较容易做这些额外的分析。举个例子就是做同样的额外分析，我一般2-4小时能出活，但隔壁 code 想到哪写到哪的 analytics DS 小姐姐经常需要 2 天。本人由于经常还需要写 production code 因此代码设计方面我都是在一次一次 code review 中被怼学的。如果楼主不写 production code，也建议稍微考虑一下 code 的通用性。比如如果 join 比较 expensive，是不是可以先把 join 的结果存在哪下次直接用。写 aggregation 是不是可以设计的更通用一些，等等。有空看看贵司 ML 以及 DE repo 里边 production code 怎么写的可能会有帮助。

顶一下一起学习

mark一下求大神share

马克zszszszszszs

mark 一下

🐎
zszszs

skurry 发表于 2022-12-20 12:23
平时都是潜水，这个贴蹲了几天也没有回应，那我注册一个账号来抛砖引玉吧。

先介绍背景，本人文科PhD毕 ...

感谢！很有价值的总结啊！
欢迎其他大佬继续分享！！！

Mark学习一下 谢谢分享

马克！！学习！！