两部分
- 最近学习数据分析的书籍资料
- 从tableau进阶引发的思考
▉ 数据可视化方面：
Tableau的入门的确非常“容易”，在B站搜索一个入门视频，跟着做即可。这个阶段需要的是：保持热度，能体会到图表生成的成就感，但也会疲惫于此。
《数据可视化分析·tableau原理与实践》 进阶
▉ SQL学习:
在SQL学习阶段，遇到不少坑。我的目标工作是数据分析师，但目前市面上的SQL教学视频基本都是“大而全”，感觉更面向DBA。另一方面，长时间在最基本的几个概念和用法中转圈子。
入门
《SQL基础教程》
其实入门阶段随便哪本书和视频都可以，在入门阶段需要了解SQL语法规则，增删改查，表连接等等。
进阶
《SQL进阶教程》
《Microsoft SQL Server 2008技术内幕》
SQL的进阶知识点：自连接，派生表，关联子查询，case when，窗口函数，SQL优化
SQL实战
SQL经典50题
网上很多，在学习完基础教程，略看一遍进阶教程后，就可以去刷题了。
《数据分析技术 使用SQL和Excel工具》
在上面的教程，一般都使用student表，高级一点用order表，缺乏实际工作背景和需求，比如如何用SQL写FRM，如何做会员生命周期计算？这本书正好补足这个空挡，写出复杂的有实际业务背景的SQL查询语句。只可惜这本书翻译有点难以接受，也是花了很久才能明白书本的意思。目前在还学习中。
我一直低强度地学习python，保持在工具利用的阶段。因为网上python热潮有些“缺乏理智”，有些机构是为了赚培训费，有些因为焦虑。目前的工具足够我完成现在的任务，如果是提高效率，其实我可以用VBA，或者学习复杂的SQL技术。如果是为了学习机器学习，数据挖掘，我更觉得没必要纠结在语言上，先学背后的数理统计，而不是花费时间在编程上，因此在spss上倒是一直投入时间。
从tableau返回SQL学习
我最早学的是SQL，断断续续学了挺久。在最近开始学tableau，被方便和多样化的图表所吸引，花40块钱买了共享账号，虽然网上破解版满天飞，但在早期学python&MySQL的时候，我花费了很多时间在确定软件版本，安装过程，选择和安装IDE，半年过去了还停留在要学哪个版本的纠结上，因此这次直接买了一个最新的版本。
入门阶段都是被tableau的可视化图表吸引，遇到了第一件事情：看哪个教材？是看视频还是书籍？现在想，不需要这么纠结，还没入门，哪本教材都是可以的。同时tableau的入门书籍太多了，同质化的侧重于做出酷炫的图表，的确能满足刚上手的新奇，沉迷于做出一个好看图表的成就感。大家都觉得tableau的图表基本都是拖拽，没有什么难度，技能学习的阶段并不需太久，把最常见的图表独立做一遍，就大概掌握了。学了一些基本概念后，就进入了迷茫期，新图表不再有吸引力，发现浮夸图表如果不能带来实际收益。忘掉了图表是为了表达，如果没有确定需要表达什么，图表的学习就变成了技能的学习。
《数据可视化分析·tableau原理与实践》这本是一个很好的转折点：从图表转入对数据的探讨。
详细字段计算、表计算、LOD
学习路线
不像数据挖掘，普通的数据分析师，每天要做的数据分析远没有那么高大上，在基础数据上摸爬滚打，还天天被数据挖掘、机器学习PUA。两头都没做好。
很多都像ETL的后半段：从原始数据中，整理字段，转换形式，关联（表）补充，聚合，二次聚合，最后形成报表所需要的数据形式。最典型的不就是做RFM，在原始的Order(orderid为主键，时间序列)表中，聚合计算出三个维度。
我之前会泾渭分明的把SQL和tableau归到两个不同的工具中。但回归对数据本身好像重叠部分要远多于差异。正是如此，对比SQL和tableau，发现彼此的优缺点/学习的重点
在学习这本书的过程中，对数据的加工计算理解的更深入些。比如，作者将数据的加工计算分为三个层次：行级别，当前视图汇总（表计算），高于（低于）当前视图（LOD），另外还可以在加入一个独立于当前视图计算（独立维度的LOD，但这个SQL的确无法做到，在图表中可以用什么方法表示额外的维度：累积百分比，颜色，形状大小等等）。可以理解为针对原始行级别数据的计算，在此基础上的汇总计算，在汇总级别上的再次聚合。
这一套理论完美框住了我们常见的数据维度的调整，计算同比，环比，转化率等等。
也正是如此，我对SQL的理解就像打通了任通二脉一样，比如我之前虽然会用窗口函数，但不理解，无法灵活使用。在这套理论下，sum（）over（）其实就是当前视图下的汇总计算，即计算高于/低于在当前层级级别下数据并返回到当前视图内。比如，我想在源数据order表中，每一个订单orderID后追加该订单所属地区的总销量。如果使用groupby 地区，返回的结果将是地区级别汇总，不符合要求的order级别，因此可以使用sum（销量）over（partition by 地区）的方式，在每一个orderID下追加一列该order所属地区的总销量。
每个数据需求背后都在思考数据维度、层级、聚合。
不过最大的作用是让我重新审视自己学SQL的偏差。脑海中都是主键，关联，groupby，同时觉得拆解复杂SQL是学好SQL的捷径。wrong！
重新开始学习SQL的最基本的概念，比如join，然后就发现自己对join的误解如此之大：SQL在做表的关联时，一般分为三步：①做cross join笛卡尔积②根据on对数据行做真假值判定，并返回值为真的数据行③最后根据join类型（left，right，full）做数据的增补。如果是cross则只需要第一步，如果是inner 则只到第二步。这背后是SQL是基于集合做运算（SQL处理数据的两大理论基础：集合论和谓词逻辑）
我很早就知道SQL查询语句的执行逻辑，也一度以为知道这个就能更从容了解SQL，但对表连接之间发生了什么混沌无知，脑海中有概念也都是初次接触SQL的偏见：比如on后面连接的是主键和外键。left join的逻辑是以左表的主键为基础，在右表中筛选存在的行，并入左表。
后知后觉是一个痛苦与快乐并存的事情，懊恼时间的浪费，欣喜自己有所进步。但在这个快速竞争的环境下，需要的是“保持快速的思考”
Tips:
复杂技巧是即可能为了效率，也可能是弥补工具的局限，背后是最基本原理的运用。
练习是有用的，但前提是要基本的理论基础和认知，不然通过犯错来总结前人已经总结过的经验，得不偿失。
每个数据需求背后都在思考数据维度、层级、聚合。
切勿沉迷在工具学习中