我的天

今天我终于看完了一本Power Query的教程。其实我也不知道叫不叫做看完了，因为最后的部分，我是囫囵吞枣的过的，因为那些功能我用不着。最后一章说的是函数，但是，每个函数都没有仔细说要怎么着，只是把函数列举了出来，大概说一下什么意思，但函数里面到底有什么具体参数，没说。看完那本书以后，我回去看那条我搞不懂的题目，结果发现，之前我卡在的那个地方其实不是难点，而是因为我没有仔细观察数据源，所以犯了一个错误。真正的难点，我没有意识到。因为我用的最多的是数据透视表，要做汇总计算，根本不是问题，任何类型都可以。Power Query非常擅长数据清洗。当然这个东西也可以用作汇总计算，但当一个表里，明细跟汇总都放在一起，感觉就不太靠谱了，作为Power BI的两剑客。我个人觉得Power Query更擅长于处理原始数据，让那更容易用于后续的Power Pivot分析使用。高手用了一个高级的公式，解决了某个汇总问题。我有主动了解那个东西到底是干嘛的。之后，我大概知道那要做什么，那里内置了一个循环功能，又或者说是迭代的功能。让我摸不着头脑的是，在使用那个公式之前，又套用了好几层东西，然后我就彻底蒙圈了，那简直就是连环套，就像俄罗斯套娃一样。有时我真的想不懂那些高手到底是怎么写那些脚本的。公式一层套一层，他们怎么就搞得清那些小括号、中括号和大括号呢？同样是引用一个列名，有用双引号的，用中括号的，也有用大括号加双引号的。貌似暂时我还没有看到纯粹小括号的。Power Query实际上就是搞清几种数据类型，在那几种东西之间来回变换，其中就包括表格，列表，记录和值。一个个说，貌似都能明白，但问题是，要把它们套用起来的时候，情况就比较复杂了。要表达一个表，用的是大括号，要表达一堆列表，也是用大括号。如果要表达某个表里面的一些记录，那得用3层的大括号，列表只是两层。这是纯粹用大括号的，你也可以在大括号里面嵌套中括号来定位某些记录。这些层层套套的关系，简直要把人逼疯。但实际上复杂的结构有哪个不是这种关系呢？只怪Power Query这个东西把这些关系放在表格里，而其它地方用的几层的缩进。Power Query不存在单元格这个概念，那个东西用的是上面说的那几种东西。

回到一开始那个难题，我觉得要解答那个东西，最简便的方式应该是用Power Query实现多表合并抓取数据，然后把抓取到的东西放到Power Pivot里面建立一个大表和一个索引表的关系。这样一来，就完全不需要考虑那种必须得用高端函数才能解决的汇总问题了。为什么我们非得吊死在一棵树上呢？当然，之所以不这么干，是因为做表那个人想一次性搞定所有。在没有Power BI两剑客之前，要实现这个功能，肯定会有高手用VBA解决问题。如果用的是VBA，那又是一个怎么样的思路呢？

我觉得Power Query现在对我来说很无解，这是因为我对这个东西的了解还不够深入。

Excel的一般公式，我比较熟练，一些高级公式的叠加，我需要找教程套用，但起码我知道那是可以做到的。一般的数据透视表，是我一直以来用得相对来说最顺溜的东西，至于高级的数据透视表，也就是超级数据透视表我几乎不了解它的高级用法。在数据的筛选查询方面，之前我用的是公式，而近期，我知道了有Power Query这种神器。在这之前，我已经知道可以SQL语言查询。去年我开始系统学习了Excel VBA。这让我大大提升了某些工作的效率。当然这是非常有针对性的。对我来说，要开发一个VBA脚本需要好些时间，并不是一写就能用的那种类型，期间要经过不少修改。所以其实总的来说，对Excel的了解我还是比较全面的。

也正是因为有这样的经历，所以当我遇到某些综合性的问题的时候，当别人把目光主要集中在某个他们很熟悉的版块的时候，我会凭借我的直觉找问题，而不局限于他们觉得出问题的那个地方。比如在把SQL查询跟VBA结合的时候，别人会把精力放在SQL查询有没有写错上面。SQL有没有写错，其实我根本没看，对我来说那些东西太长了，看不懂，而且那个人写的VBA脚本缩进很有问题，看得我很郁闷，所以我就更加没有心情在那里琢磨。那既然能计算出一个正确答案，说明那个查询语句应该没什么问题。也正是因为写脚本的人的那堆东西格式比较混乱，所以我有理由怀疑那是拼凑起来的脚本，因为居然在脚本的开头连变量的定义都没有。为什么VBA里没有进行规范的变量定义，后面也居然可以照样使用呢？这让我有点惊讶，毕竟这是个VBA，不是python。C语言里，如果不先进性变量定义，后面根本用不了。在我记忆之中，VBA的变量在使用之前是需要先定义的。最终我发现是那个人的脚本之所以出错，是因为某些语句的套用搞错了，为什么他会把那个东西放在里？我觉得大概是因为他没有明白他一开始做的那个with是什么意思。但如果你问我为什么他把那堆东西套在里面会出错，而且是某些地方出错，不是全部出错，我回答不出来。理论上这种错误能在恰当的调试中体现出来，但实际上，VBA的调试句子我还用得不算很熟练。或者你会说，这是因为我的VBA学习还不够系统化，但我觉得我已经用了学习VBA最靠谱的那本书了。可以肯定的是，一些很基础的调试方式我还没掌握，如果我学会了那些东西，我可以大大提升我的调试效率，把错误定位得更精准。VBA脚本这种东西，我觉得最根本的是必须得理解。如果纯粹是各种套用，基础功能的确可以快速实现，但是当遇到的问题比较综合的时候，就会出现一些他们完全料想不到的状况。那种状况有可能与脚本本身的内容无关，与脚本的结构有关。

相对来说，Excel里我用得最弱的是高级公式的套用。如何用一个非常复杂的公式解决一些高端的问题是我一直以来都不大上心，或者说记得不够好的部分。非常复杂的公式，尤其是数组公式，虽然能解决一些神一般的问题，但问题是，其实那些公式需要耗费大量资源，所以在处理大数据的时候，非常有可能出状况。我是一个实用主义者，能做到某个功能，但是做起来的效率不高不好，我为什么要选择那种只是看上去很炫酷的方式呢？情况就像用VBA解决同一问题的时候，如果只是在工作表层面处理和先用内存数组处理再在工作表层面表达，效率千差万别。

Excel对我来说，除了要最终结果，过程也得追求高效和方便。

在开始这篇东西之前，我突然意识到，原来一直以来，在网上我都通常不是在论坛之类的地方求助的那个。绝大多数情况之下，我的是去帮忙的那一个，又或者是发布某些信息的那个。我的确是有发过求助的帖子，但是，相对于其它来说，那非常的少，而且通常我是那种还没等到别人回复，我自己就已经找到答案的人。某些东西，靠我一个人的力量没办法找出答案，那个时候，我会求助于身边的网友。但网友不一定直接就能给出我答案，但是他们会给我个方向，让我明白我纠结的那个东西到底有没有找到答案的可能性。在一些根本就错误的命题上，也就不需要继续费神了。但是，在我纠结得死去活来之前，我不会找别人。当然，这也会有例外情况，比如电脑坏了，直接开不了机，或者能开机，但无论如何进入不了系统界面，又或者是电脑用得好好的突然就蓝屏。这些东西相比于软件上的纠结，又或者是习题上的误解会让我很慌。在电脑都开不了的时候，我也就无法找解决问题的方法了，因为绝大多数情况下，我的自学是搭配搜索引擎的。搜索引擎的答案是网友们的集思广益，众人是我最好的老师。暂时，我只是个低级的用户，所以答案可能难找一点，但通常都会有现成的答案，虽然可能不是一步就能上岸，要通过多种答案组合才能得出我想要的结果。

我不知道其他人自学的时候是怎样的，反正当我在学习某样新东西的时候，自然而然我就会联想我曾经做过的事。如果运用了这个新知识，会不会有一些更好的效果。比如昨天我下载了一本Power Query的教程。那是一本pdf，2017年出版的书，京东卖50多。我没想过买，也没想过不买，但是这么老的书，肯定已经有了pdf版本，所以我就下载了一本回来看看。结果发现，那本书里面说的Power Query是基于Office，2013的，所以，已经没有购买的必要了。因为Office 2013版本的Power Query和Office 2016的有差别。倒不是功能上有一些翻天覆地的变化，但是在找按钮上会让人有点棘手。于是我就直接开始看这本书。之前我觉得自己很讨厌看pdf。这次的这本pdf是扫描版，我也不明白我为什么看得下去，因为书本其实挺模糊的。里面说到用合并查询的方式来实现vlookup的功能。vlookup这个东西，只有几行的时候，效果还行，但数据一多，那就是死机的节奏。之前我们打算一整个表都用vlookup出结果，后来发现那会死机，所以最终使用vlookup的地方我就只留下几行而已，但即便只有几行，当我在那个源表增加数据的时候，还是会有卡机的感觉。在8GB内存的台式机上，感觉还好，在8GB内存的笔记本电脑上，有时会看到右下角说有多少个线程正在计算，显然这就是卡机的征兆。我不知道为什么会这么慢，如果用Power Query可以快一些。那本书谈到这个问题的时候，说少量的可以用vlookup，但大量的索引，Power Query才是最佳选项。从前我打算千行数据都用vlookup，后来发现那会死机，所以后来我就把那减少为只有几行，所以在我的那套操作里，无论用不用Power Query查询都无所谓，但是，我要掌握这项技能，但暂时，我还没有摸索出个所以然。

在没有得出为什么不行的时候就要停下来做其他事，总会让我觉得耿耿于怀意犹未尽，但我又不得不这样。以后我还得更严格要求自己，到点了就必须按下暂停键。

从完全不用Power Query到天天都用那个东西，我感觉这实在太不可思议了。这种变化仅仅发生在一周之内。一周前我还在纠结，为什么我的Microsoft 365用不了Power Pivot和Power Query。自从我重新能用PP以后，我就在不断地探索，但是平时我处理的东西已经没什么可探索的了，因为那都是用了几年的成熟方案。我觉得已经很顺畅了。如果要再高效一点，就是把所有东西放进数据库，但我又不想真那样。并不是说我的确做不了，而是我还是想把这些东西用普通的office软件解决，毕竟实在说不准以后会怎样。会不会某一天我不续费365，又或者是我可以这么操作，但是和我搭档的人无法接受我的高端。如果我只是把软件交给他们用，这对他们来说学不到什么东西，他们只是用软件。当然这对我来说是很有好处的，因为无论是软件的使用还是软件的开发，我都了如指掌。这也正是我一直都很着迷的事。我不仅仅喜欢研究某一个部分，从某一个部分开始，我会快乐地发散开去，无论是纵向的还是横向的，最后全流程我都熟悉了。大概到了那个时候，我会换另一种东西开玩。

说回PQ这个东西。其实几年之前我已经听说这个强大的存在。Office 2003有个MS Query，但那个东西跟PQ其实是两回事，MS Query更类似于数据库的界面，PQ我觉得应该是Power BI的一个组成部分。Power BI除了PQ以外，还有Power Pivot和Power View。说是这么说，实际上我没用过Power BI。PV这个东西非常强大，动态展示数据，五颜六色，各种花式，但问题是，即便我能把那些东西放在网上，当我要交作业的时候，领导还是比较喜欢长篇大论。其实我更倾向于做个PPT，然后由我上去讲我的想法，而不只是写一篇纸上静态的东西说明问题。

PQ让我着迷的首先是逆透视。逆透视在从前的教学里，唯有通过数据透视表高级处理，现在貌似我已经不记得应该怎么用了，但是PQ非常简单，没有做不到，只有你想不到。二维表变一为表是秒杀的事。既然可以逆透视，当然也可以透视，所以你也可以把一维表变成二维的，为什么会有这种需要呢？之前我也不觉得要这么干，但昨天论坛里某个网友还真提出了这样的要求。他要合并两个表的数据，其中一个表的某两列得先进行透视处理。为什么会这么折腾呢？从原始数据看来，我不觉得他的表有什么问题。如果是我设计的原始表格，也就那样了。最终，他想做到的效果也很正常，因为那一大堆的数据，最后要得到的，其实也就是为了看那些东西。一开始，我想用PP连接两个表。结果发现连不上，说那不是唯一的ID，我有点理解为什么会连不上，因为实际上两个表除了某列数据有共同点以外，其他东西完全不相干，但是PQ却可以把他们用接近变态的方式粘合起来。从最后组成的大表结构看来，的确很乱来，但是要的不就是最后的数据吗？整合之后，一点问题都没有，当然，如果你要筛选两个表格，关联部分以外的字段肯定会出状况，而且这个状况是无法避免的，因为那些根本是不共有的信息。

我对PQ有好感的另外一个原因是那个东西有高级编辑器这种神奇之物。那种感觉就像PQ是一个可视化的网页制作软件，而它的高级编辑器就像是源代码。路人甲玩的是可视化，高手操控的是源代码。PQ的源代码用的是M语言。这是一种介乎于函数和编程语言之间的东西。能玩好这个的人没多少，能玩好这个的人绝对会让别人觉得是个神。数据的整理变成弹指间的东西，非常的伟大。几句代码就能解决平时我们只能靠努力，甚至非常努力都仍然解决不了的问题。

是网友们的问题，让我的脑洞又大了。

怎么才可以让自己遇到更多的问题呢？我选择的是猫在某个论坛里，解决别人提出的问题。我仅仅猫了几天，就得出了某些结论。比如通常逼着大家提问的原因在哪里，针对那些东西，我应该如何在表格里避免。某些东西，我们一定会遇到，即便暂时没有，所以在那之前先掌握技能很有必要。如果等到像他们提问题那样才去被动去学习，就比较烦恼了。

第一个让他们在用数据透视表的时候得不出应有的结果的原因是他们的原始数据格式有问题。数据汇总时碰的壁绝大多数都是原始数据记录时挖的坑。最经典的坑莫过于合并单元格。所以，当我看到某个同事给我的表每一个数据框都至少合并了两行两列单元格的时候。我立马拍桌子发飙了，这是处理数据吗？！如果你嫌那个单元格宽度和高度不够，完全可以对单元格进行调整啊，为什么要合并？之所以做出这种低能的单元格合并，唯一的理由就是，她根本不知道那些东西的宽度和高度是可以调整的。对她来说，Excel的表格就像十字绣一样的固定洞洞，就像Photoshop里的网格线。但实际上，根本不这样。面对这种人，我是完全无语的，因为她完全不了解她正在使用的那个软件。这些人应该从头去开始学习Excel，从最基础的学起。只有让她明白Excel是做什么的，可以怎么用它，她才不会犯这种超级低级的错误。这种空前弱智的单元格合并通常不会发生，更加不会在某个表的任何一个数据框里面发生。某些人会把平时手工汇总的表格拿出来求做成数据透视。准确来说，那是一个明细表和汇总表的混血儿，在实际工作中我们经常会碰到。从展示表的角度考虑，这非常正常，尤其当数据完全由人手工填写的年代。但这不是Excel处理数据的习惯，明细是一回事，汇总是另外一回事。当某个大项里有N个分项，大家非常习惯，把大项横跨的几行合并为一个单元格，然后分项的总和也合并为一个总数。这是人的处理习惯，但Excel的处理习惯是大项为一行，分项为余下的行。当你不想看明细的时候，直接把它收起来。之所以会出现这种人的思维和机器思维不一致的东西，完全是因为大家没有读Excel，而只是把我们人肉做的事要Excel去模仿。这绝对是搞死人的！处理这种事，只能把大项的单元格合并取消，向下填充同一个名字，最后的汇总数据，全部打散为小项的数据。如果一个明细表里有很多这种情况，又有很多类似的明细表需要合并，那可是清晰数据整死人的节奏。

另外一些数据透视表的问题发生在多表合并的时候，有时可能还得对表格的汇总数据进行一些运算。通常，这需要用SQL查询，但我觉得在Excel里用SQL有点麻烦。那个东西不适用于文件移动，一旦文件发生移动。数据将来难以刷新，因为实际上进行了SQL查询以后，电脑的某个位置会形成一个数据库。当你移动文件到别的电脑，引用的原文件仍然只是旧的那个。通过在文件里加个VBA，能解决更换数据源的问题，但要这么复杂才能做到，证明了SQL在Excel里实际是有点水土不服的。这种玩法根本不适合分享文件。SQL语法虽然很简单，但是标点符号的错误，哪怕是多了一个空格，也会出状况。在没有语法检查的编辑器里写那些句子，简直就是撞墙。新版本的Excel里内置了Power Query和Power Pivot，如果用的好的话，SQL基本可以丢一边了。我感觉应该可以这样，虽然我对这两个Power工具还非常陌生。我觉得，也正是因为Excel里面用SQL不太顺，最终才会让这两个Power成为新版Excel的标配。

把别人的烦恼当作是自己的烦恼，是一个让自己进步的方式。