我的天

昨天在设计某个Power Query查询的时候，我遇到了个问题。只需要做一个非常简单的IF判断，但貌似是不能直接用IF处理步骤。那些不过是非常简单的东西而已，如果符合这个条件，用这个步骤，如果不符合这个条件，用另外的步骤。我之所以被拦在那里，大概是因为我还没搞清IF使用的场景关系。判断步骤从理论上说再普通不过了。我该怎么做到这个呢？之所以有这个困惑，因为IF的判断，在举例子的时候，大都用在添加列这个功能里面。如果符合这个条件，就添加这种，否则就是另外一种，当然你也可以添加一大堆筛选。我正在开始构思这篇东西的时候，突然意识到，我要处理的实际上是一个列表。既然是一个列表，在后面引用的时候我就没必要把所有东西都摊开，我在前面就做好判断，后面直接一个判断好的列表扔过去就可以了。有些步骤我进行了排序，但是实际上排不排都无所谓，因为最后这些东西会到达数据透视表。月份参数必须排序，理论上那个参数不仅仅要排序，而且还应该以日期的数据格式展示出来。昨晚上我发现同样引用同一个数据表，如果我在展开的时候，不加以说明，反而会得出正确的东西。如果纯粹用可视化的操作，会有画蛇添足的效果。我的数据必须得用我想要的方式表达出来，如果默认的东西不对，我应该改到对为止。这一次我运气好，我没有解释某一列到底是什么东西，系统读对了，但有些时候情况不是这样的。当然，也会有我昨天下午遇到的那种情况，系统默认的不太靠谱。最终，我忍耐了那个不太靠谱，但是。既然有了晚上的的经历，系统默认画蛇添足的部分根本不应该存在。

一开始我只想实现某个功能，但在实现某个功能的过程中，我发现以前我的那种分类有点想太多了，因为根本没有必要。那些东西都是独立的存在。与其进行二级分类，不如多做几个一级分类。一级分类的非重复计算实际上用的都是一个模板。既然是模板，我当然可以用外部引入数据的方式实现动态筛选。关于非重复计算这种东西，加入了模型的数据透视表能轻而易举地做到，但经过这段时间的摸索以后，我发现Power Query只要能打开，基本上不会出错，但是Power Pivot我搞不懂为什么会出错，为什么会卡机。那个东西卡机的概率我感觉太高了，之所以有这么高的概率，也可能因为我用得比较少。有时我只是写了个非常简单的度量值，出来了以后，度量值不知道为什么选不上，不知道为什么选上了以后电脑就弹出了某些界面，关掉了以后Power Pivot的选项卡就消失了，但是你依然可以进入。关掉Excel，再次打开，Power Pivot的选项卡没有了，你得在加载项那里把那勾去掉，再重新加回去。实在说不准为什么会这样。如果不把那个曾经导致问题的文件的模型删掉，打开那个工作簿的时候永远存在这种问题，其它工作簿不也会被连累。删掉那个错误后，还得重启电脑才能解决问题。很久以前Power Query也是Excel的插件，但后来，那个东西已经不再是独立的选项卡，而直接内嵌到软件了，而Power Pivot在Microsoft 365里依然是个选项卡，依然要借助COM加载下。这就意味着这个东西还没有到非常成熟的地步。所以或许某一天我要玩Power Pivot的时候，我不在Excel里面玩，而会跑到Power BI里折腾。因为起码那样的话，我就不用烦恼Excel的加载项老是消失这个问题了。

越研究就越知道自己什么都不知道。

追加查询这种事，2句话搞定，这实在让人太震惊了，但实际上，两句话里其实暗藏了许多玄机，高手用一句话完成了几个步骤的事。能做到这样，绝对是因为对函数这种东西了如指掌。

source = Table.SelectRows(Excel.CurrentWorkbook(), each List.Contains({“表1″,”表2″,”表3”},[Name]))[Content],
result = Table.Combine(source)

Excel.CurrentWorkbook()这种东西通常我们都是后面搭配{[Name=”某表”]}使用，那是点名使用，一次只能一个，但实际很多时候合并工作簿都是里面同型号的表全部合并，如果全部都用这种，得列多长的清单。高手的代码里，还可以把List.Contains变成Text.Contains，如果是list那就是点名要哪些或者不要哪些表，如果是text那就是直接筛选表的关键词，包含哪些关键词或者不包含，各有所长，都能实现。如果命名很规律，那是简单到爆炸的事，即便命名不规律，也能用排除的方式忽略某些不想合并的表。你或许会说，既然是合并工作簿，为什么不直接用从外部文件的工作簿获取呢，那样直接就到位了，选择的时候也很自由，因为那是可以可视化操作的，而且不需要实现把工作簿加入到表，我觉得最根本的区别在于移动文件的时候，外部获取你还得更换数据源，当然了，这个可以通过自动获取数据源地址的方式实现，但直接CurrentWorkbook是最没有烦恼的。要把工作簿里所有表都变成超级表，这在收集和整理表格的时候其实也是有难度的。所以这种一次性用CurrentWorkbook包揽工作簿的方式我觉得最好不要超过10个，3-5个是最合适的。通常，如果用追加合并，可视化系统生成的是Table.Combine{{“AA”,”BB”,”CC”}}类型的多个表格列表，而高手的代码里，source其实就是一个表格的列表。轻描淡写之前，处处暗含玄机。要做到这样得非常清楚每个函数需要什么数据，可以生成什么数据，玩弄的正是表格、列表、记录的互相转换。

同样是contains的功能，list的是后面跟前面对，对上就true，但text是前面跟后面对，对上就true。对我这种初学者来说，这是很迷糊的事，谁先谁后到底是最定义这些公式的，为什么要这么郁闷呢！有这种吐槽大概因为我不熟悉，对高手来说估计是没有疑问的。到底建立这些M函数的时候，他们是怎么分配工作的呢？类似的功能一个人负责？某个统领下的函数一个人负责？最后有没有对“.”以后相同，功能类似东西做比对呢？对我这种懒人来说，类似的函数能用复制粘帖修改就不会用重写这一招，但显然，他们的脑洞估计不是。

看书对照操作是一回事，融会贯通又是另一回事。

今天我终于看完了一本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现在对我来说很无解，这是因为我对这个东西的了解还不够深入。

我觉得我之所以对Power Query着迷，除了因为那东西的功能很强大，还因为有高级编辑器那种纯代码型的控制方式可以选用，这对我来说有极大的吸引力。因为这就像是在写网页，有可视化的界面，也可以纯代码控制。门面的事情，可视化界面所见即所得，但是高级的东西，都得用代码去控制。可视化界面的确能实现一些功能，但简洁高效的代码都不是可视化按钮生成的。完成静态的页面，可视化插入能做不少方便小白的东西，但是到了动态效果的年代，要控制特效显然就不是简单的插入就能完事，当然了，函数写好，预留设定参数其实就能实现功能，但问题是，那样的话就不自由了，只能用别人已经封装好的东西。方便和自由总是矛盾的。一键实现的东西非常方便，但可控的点必然少很多。可以调节的参数多了，人就晕了，要把握好所有参数才能做出某些效果，对小白来说很不方便。一定程度上，我一直都在纠结地取得某个平衡。需要合并浓缩的就应该聚合，但不是一整个过程都捆绑在一起，我还想给自己留下一些创作的空间。情况就像玩乐高积木那样，科技型的乐高积木基础零件就那些，但为了实现一些复杂的功能，他们会有一些特殊的零件，比如万向节，非直线的轴传动没有这个东西还真不行，但有些零件比如说车辆的备震装置，有自己拼凑的，也有现成的。什么类型的车配给你现成的备震，什么类型的车只配给你组合的零件这是设计者要纠结的事。他们当然可以完全只配给你零件或成品，但之所要选择，大概跟某辆模型车的结构以及结构要求的强度有关。

上周回家的路上，我在地铁上横着手机看PDF的PQ教程，时间很快就过去。如果我手机有pad那么大，竖着看也行，但扫描版的书竖着看字体实在太小了。如果那是一本电子书，应该不会有这种烦恼。在那一刻我意识到为什么那些通常用可视化界面操作的教程类书籍那么贵，因为上面几乎都是截图，没有截图真的挺难说清。那些书的更新换代很快，因为不同版本的软件界面和功能会有所不同，但如果真的认真学完一本以后，即便再出新版本，估计也不需要再入手了，因为八九不离十，但对新手来说，版本不一致瞎蒙是百分百的作死。程序语言类的书相对来说几乎不用截图，没什么好截图的，最关键的内容是代码本身，输入代码和输出结果也就那个地方了。所以相对来数，编程类的书籍电子转化会容易些。当然了，最容易转换的一定是纯文字类的书，比如小说。

回到家我就什么都不想干了，自学不想干是显然的，连blog也一拖再拖，唯一会准时搞定的只有每天都必须干的单位业务处理。看电视和睡觉是我回家之后干得最多的事，幸好我周末才回家。如果天天都这样的话，人必定废掉。

我又有点懒洋洋，什么都不想干的苗头了，真烦。

昨天我实现了前天还不能实现的功能，用起来果然很爽。Power Query拯救了用vlookup公式导致源数据界面输入卡顿的问题。关于vlookup的卡机，据说用Power Query或者Power Pivot都能实现，而且据说PP的效率比PQ还要高。PQ现在我知道应该在哪里写代码了，但PP的DAX到底在哪里写，至今我还没找到。相对来说，我觉得PQ界面的按钮多一些。PP的按钮感觉跟数据透视表很类似。这就意味着，厉害的功能就隐藏在普通的东西之中。PP跟PQ比起来，函数的数量少了很多。用过的人都说，PP要比PQ简单，PQ就像一个谜一样。

前几天当我搜索，PQ教程的时候，发现了里面居然有递归。在谈递归的时候，把迭代也放进去了。迭代跟递归有什么区别现在我还不知道，但我知道递归和循环有什么区别。当某个函数的控制可以把判断和循环都用上的话。再加上700多个已经事先设定好的系统函数。PQ要实现一些神一般的功能显然是理所当然的。只有你想不到，没有它做不到，但前提是，要做到某些功能，光靠可视化版面，根本不可能。要在高级编辑器里自行折腾，或者在自定义的地方选择性折腾。光靠鼠标点击按钮是没办法把PQ的函数层层套用的，没办法一次性套用多个函数，某些功能就比较难实现了。对小白来说，要掌握所有可视化的按钮，尚且没那么容易，但是真正的高手，是必须自己写码的。

PQ用的是M语言，貌似我在VSCode的插件里面没找到相关的东西。里面有DAX的插件，可以自动补全和语法高亮。M语言更需要这种插件，因为光是函数的大小写就会把人搞疯掉。英语输入默认全部都是半角，但是如果我们的脚本里面还有中文，那就意味着中文跟英文得不断切换。光是逗号这种东西就会搞死人。而且我们的脚本里面，还不可能不出现中文。的确，函数可以起英文名字，但是，要处理的数据的列名，必然有中文，因为表格的内容有中文。我不知道那些写码的人是如何克服这种中文英文切换标点符号的问题，反正我是觉得，双引号，逗号，小括号这种东西经常让我很烦恼。不过幸好，据说，Office 2016以后的PQ，在写码的时候有自动补全功能，的确现在我的Microsoft 365可以这样，不仅仅是函数可以自动补全，连变量也可以自动补全。我不知道其他人写码的时候是怎样的，反正自从我习惯了python以后，我实在不能接受没有规范缩进的脚本。也正是因为有了python的习惯，所以我也默认把缩进从tab换成了4个空格。习惯了在VSCode里4个空格是4个圆点，现在PQ里没有这种东西。总让我觉得很不智能。

所有office文件都可以修改后缀，变成一个压缩文件。里面你看得懂或者看不懂的东西实际上就是数据以及你执行的步骤，所以PQ虽然有可视化界面，但实际上，它的高级编辑器让我觉得，那东西还原出了office软件数据处理的本身。

今年我的计划是学R语言，但实际上，我迷上了python，接着现在，我又迷上了M语言。