我的天

每天都在论坛解决别人的问题。一定程度上，我是在磨练自己，当自己的工作好像没什么新思路的时候，就需要一些刺激。有些非常弱智的问题，我会懒得去回答，但很高深的问题，又不是我能解决得了的。所以这其中也挺纠结，到底什么类型的问题才最适合让我去练手呢？我自己有问题，尤其是案例类的东西、跟数据直接相关的东西，我就没想过要放在论坛里问高手。通常我都是四处寻找答案，再不行，我就截图问身边的人，但无论如何，我都不会把数据发上去，尤其是工作类的。如果只是我个人的blog，所谓，反正都写了这么多年，根本没有秘密。但其他东西。不能这么随意公开，而我也没有真的遇到一个我自己解决不了的问题。有些时候，我想实现某些功能，但经过一番操作之后发现，即便能做到也很麻烦，所以我就直接绕过去了，因为不一定非得那样做。这条路不通，我就走别的路，直接放弃这条路。这也是我的快乐之处。在别的单位，可能领导会要求你必须得这么干，就要这样的格式，就要这样的数据。不管你用什么方式，但实际上那样的格式、那种模式数据实际上是很逆天的。我运气好，暂时还没遇到这种事。当然我也遇到过类似差不多的事情，比如应该写0的地方他们要写杠。把格式设定为逆天，实在让人觉得非常无语，但幸好我的领导是一些挺懒的人，某些格式一旦定下来就不怎么改，而且因为他们懒，所以定下来的固定格式也不多。

蹲在论坛解决别人问题的时候，我发现自己是一个很没有耐心的人。当别人提出某个要求，我又实现了以后，我觉得就大功告成。但之后那些人居然会在之前的基础上，不断加新要求进去。如果你有很多要求，为什么不一开始就说清楚呢？哪怕可能你根本没想到有人真的能做到你想象中的那样，如果做不到的话，别人会直接告诉你这个思路是错误的。绕了好大一个圈，解决了问题，但事后说这个问题只是开胃菜，还有后续那些。一次两次加料之后，我会觉得那人好烦，这完全是他自己的东西，为什么不一开始就摊出来说呢？遮遮掩掩到最后还是要慢慢的托出，简直在浪费大家的时间。当东西整出来以后，我发现有些时候他们一开始那个思路是错的，一开始因为无法全盘考虑，我就被他们默认带错路了，绕了好多个死胡同。他们自己的数据，他们最清楚其中的来龙去脉。但显然当他们把数据拿出来求助的时候可以看出，其实他们完全是蒙圈的。这些操作对我来说最大的好处是那些教程上面的东西经过一次又一次使用后，我开始有点行云流水了，虽然有些时候还是会很迷糊，但现在总算是有点头绪。之前我觉得，同样是列名，有时用中括号，有时用双引号，莫名其妙，但现在我几乎搞得清是一个什么状况。虽然在使用函数和引用数据的时候我还得不停琢磨。

你们不安排我培训，我就自寻培训的途径。

数据本身没有问题，如果我们不能让它们确立某种关系，只是因为我们对那个东西还不够了解而已。在Excel里做一件事，你可以通过很多方法，比如说函数，比如说VBA，比如说SQL查询，又或者Power Query或Power Pivot。当然，我这里所说的，主要是针对查询，或者说数据清洗类的东西。如果纯粹是针对单元格的格式化，函数以及Power BI系列以及SQL是没办法做到的。

同样一个数据，用不同的方法都可以得出目标答案，但是哪个会更简便快捷一些呢？函数我觉得挺被动的，尤其是在处理大量数据的时候，效率非常低。因为在处理一些复杂东西的时候通常要用到数组函数，即便不需要用到数据函数本身，其实也在运用着数组函数的变体。而且函数这种东西受Excel本身版本的限制，越是低版本的Excel越是没办法轻而易举地实现某些逼格的功能。于是就出现了你不得不为了某个功能升级Excel，又或者因为你的伙伴升级了Excel，用了一些高端的函数，但是你却看不到，工作就没办法继续下去了。SQL和VBA是两个大杀器，很早以前Excel就已经支持。与其说他们是Office软件的一部分，不如说这两个东西更接近于编程语言。我对Excel里面的SQL不是十分熟悉，因为至今为止，虽然已经折腾了不少网站，但是我从未试过操作数据库。SQL在Excel可以用，但我觉得可能在Access里SQL会用得更顺手一些。比如说如果改变数据源，比如移动文件之后，SQL需要重新连接。若没有VBA的帮助，这是无解的。我不喜欢用SQL的其中一个原因是它会在硬盘的某个位置生成某个数据库。

VBA这个东西强大到任何你想到想不到的东西都可以控制，无论是数据本身还是说单元格的格式，一律通杀，它甚至可以让Excel自杀，又或者让你的系统自杀。VBA用得好不好直接决定了某个脚本的运行效率。是对初级用户来说，VBA的学习成本实在是高，除非你从来不打算要建立自己的规则而纯粹只是用别人的东西。

至于Power BI系列的Power Query和Power Pivot现在我仍然处在甚至还不能说入门的阶段，我只是稍微了解了一点这两个东西。在数据清洗和建立关系的时候，它们实在太强大了。但是要使用这两个东西，Excel的版本就必须有要求。所以这也导致了不少免费用户直接绕过这两个强大的东西。我也不知道为什么自己在使用Excel高级函数几乎还没入门的情况下，我就去折腾M语言。我觉得那个东西一定程度上颠覆了我对数据的理解。Power Query对数据的处理方式就像通过各种蹂躏就能得出你想要的东西，其间你没有修改原数据，所以实际上在写M语言的时候就像是手工编写一个宏，而那个宏要比一般的VBA简洁很多。之所以简洁，一定程度是因为那是在高级套用的前提下。Power Query里玩的数据转换实际上是在折叠、删除以及扩充，一定程度上就像是在用类似于递归或者迭代的方式。

别人把时间耗在应付考试上，我把时间耗在折腾自己上。

昨天在设计某个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现在对我来说很无解，这是因为我对这个东西的了解还不够深入。