我的天

到底我自己有多强大？即便我自己也不知道。

在对账这个问题上，貌似我的手上已经有不少的武器。那种东西是我不知道该如何积累回来的，已经成为了我的条件反射。该用什么方式才可以快捷方便而且全面，最好是扩展性也很强的。什么时候应该用搜索或者索引，什么时候应该用数据透视表，什么时候必须得上数据清洗……数据的高级应用，我很多还不知道，但现在，我已经不像从前那样只是蛮力复制粘贴了。

回想起来，10多年前当我第1次接触统计数据的时候，我用的是老员工留下的人工透视法。显然在手抄账的年代，那个东西非常直观。当时，李大姐的那个东西用了好几页纸打印出来，然后粘贴成一大张，我简直震惊了。上面的所有数据都是手填，万一我手贱了呢？每年的日期就那么多了，我们的仓会不断增加，我怎么能保证每个都不错？当时我没有想过可以用什么其他方法可以实现同样的事，我也没想到可以不用那样。怎么才能不人工？

那个时候我还不认识数据透视表。现在我觉得，数据透视表大概是Excel里面性价比最高的东西，那个东西是用来快速得出汇总数据的，但如果原始数据不规范，数据透视表就无从谈起。近些日子我又认识了Power Query。那个东西最擅长的是数据清洗，当然也可以把汇总数据一步到位，但是汇总数据这个活儿，我觉得PQ在处理不规范数据上用处更大，至于汇总数据这种事情，交给数据透视表就挺好，毕竟数据透视表可以随心所欲各种变换，而PQ一定程度上是在做脚本编写。如果只需要某个固定的最终结果，PQ一步到位，但是如果不确定需要的汇总结果，数据透视表更省事。因为数据透视表建立了，低手也能得出结果，但PQ这东西，高手写出来的嵌套公式，低手绝大多数时候都无法参透，即便你耗费很多时间奢望理解。没有一定的基础，PQ就是天书。现在，我仍然需要10年前那种用手工透视的效果，但我用的方法肯定不是人工透视。一年365或366天是固定下来的，但是随着仓数的增多，那将是一个无底洞。万一平房仓需要分堆垛了呢？那更加复杂，别说一张A4纸，即便是10张A4纸拼接起来也未必能表达得了。换句话说，如果10张A4纸拼接起来，我看完前面，再看后面，确定我在填写某一行的时候会不出错吗？

有些人只会延续前人的方法，埋头继续做。一开始的时候，我也是用前人的方法，但做着做着，在不知不觉之中我就改进了，最后得出了一套我自己的方法，我不知道这是不是最优，但我的方法可以让我得心应手，在提升质量的前提下，大大简化之前的操作。当我想让某个固定程序更方便的时候，我会直接写个脚本。现在我用的是VBA，或许以后我会用python。VBA是所有office软件都具备的功能，但python这种东西必须得电脑装软件支持。如果只是一个人使用，完全没问题，但如果数据需要多人协作，显然这样就有点不方便了，因为不同软件的版本可能会有一些意想不到的小插曲。

我在五行之中过日子，但我也必须跳出五行提高境界。

渐渐地我越发有点明白自己想要的到底是什么。之所以让我纠结了半天，不知道该如何计算的某些数据，实际上是因为两种性质的东西混搭在一起了。我不知道别人是否真的搞得清，他们是有意糊弄我们的吗？是因为他们知道我们算不清这个，所以这么搞吗？这个问题很困扰我，是因为那个东西把正常的批次跟没有写明批次但要先进先出的混搭在一起。有明确批次的数量计算是不分仓号的，因为通常那意味着好几个仓进同一批货，开始计费的日期定在第1个仓刚开始进货的那天。所以，如果同批次还有其他仓，最后一个仓进货的时候可能已经是3天后，那个仓的免堆期等于要减去三天。如果某个客户所有东西都这么弄，不会有烦恼，因为无论进货还是出货，肯定会带入批次。

在Power Query的世界里，这就意味着要以批次和日期分组。各种仓号数据可以全部加在一起，无所谓。但同时，这个客户又有另外一种情况。如果他进货不是用船，而是用车，每天几千几千吨进货的话，我们跟他们签订的合同是按每天为一个批次。一个批次到达免堆期以后开始计费。现在我们的系统总的来说，根本没分清这种批次，计费完全是人肉计算的。但实际上，这种没有批次的批次，理论上也应该自动带入，入库的时候以日期为批次。所以有可能发生同一个批次有几个仓出库的时候，要以先进先出进行批次划分。进货的时候，一个批次可能有几个仓，但是出货的时候肯定是指定的。所以在这里要以仓好为分类，然后在对入库批次分割数量。比如某一个仓里第1个日期批次用完了再开始用第2个，第2个没用完，就留到以后继续分割。据说用SQL和Power Pivot能解决这个先进先出的问题。但貌似，我看到的Power Pivot的例子没有看到我想要的最终结果，也就是把那个出库数量自动分割成入库批次。先进先出是非常经典的会计问题，只不过我们的人从来都是我觉得我要指定这个，没有用过这些规则，当然也就没有思考该怎么自己动手去计算。一开始没有批次，用先进先出的规则，入库的时候自动添加批次，出库的时候按照入库的批次风格，最终得出来的数据，跟之前一开始就已经有批次的东西可以用同样的规则继续演算。

对我来说，有两个点我没想明白。首先，要怎么在PQ里以先进先出的规则，对出库数量进行批次分割呢？第二，因为实际上我们得到的信息是一个入库日期和出库日期。而这些日期通常都是不连续的，在不连续的日子里也要计算每天库存，到达一定时间之后，要每天计算堆存费。所以，该怎么在不连续的日子里插入一些日期，然后向下填充信息呢？之前我想到的办法是先建立一个日期索引。然后把有数据的东西合并到索引里，这就意味着有些日期可能是没有数据的。接着，把这些东西透视展开，把数据为空的那一列删掉，余下的东西向下填充，然后再把零数据替换为空，接下来再用一个逆透视恢复。这个方法比较笨。但可以一次性实现N个批次的插入和填充，至于速度如何，估计跟电脑的性能有关。我总觉得高手一定不需要用到这种先透视再逆透视的方法。他们是怎么插入日期，然后向下填充数据的呢？

想清楚了这些，离我想要的最终结果就会又近了一些。

当我终于把功能做出来以后，我却嫌弃出结果太慢了，居然要好几分钟。明明最终我想要的是一个表的合并，为了更快，我不得不拆分为两个查询。第2个查询以第1个查询的结果为基础。其实这么操作，无非我是想利用第1个查询已经得到的缓存结果。那个结果已经被我用表格输出。之前我试过从零开始弄第2个查询，结果发现实在太慢了。如果没有那么多的分组，速度还会那么慢吗？如果只是一个求和，根本无需分组，但问题是，每个批次的东西必须分开计算，然后才可以出现分段的结果。说白了，让我纠结的是一个累计求和。

累计求和这种东西的思路在PQ里通常都意味着新增一列，参数设定匹配某行的某些东西，符合条件就把某列的数据求和。所以实际上这是一个筛选的过程。如果数据很多，筛选肯定会很慢，但除了这样，还能有什么方法吗？据说可以用索引的方法。据说索引的方法比筛选的方法快非常多。如果用python的思路去考虑，我觉得筛选是一个列表的操作，而另外一个是字典的操作。如果不用二分法。历遍列表是非常慢的，但如果要立片字典，历遍是轻而易举的事，而且字典的效率比二分法还要高。所以我应该如何建立索引呢？如果筛选的是多条件，索引大法还能继续管用吗？我觉得现在我遇到的问题那些经常接触数据库的人估计已经纠结过了。这不仅仅是Power Query的问题，这是如何运用数据进行弯曲折叠的问题。只要是数据库，无论是SQL还是其他形式，都会有这种烦恼。

昨天我终于经历了一个Excel要跑好几分钟甚至十几分钟才能出结果的东西，我感觉那没多少数据。我曾经试过把那些东西输出，结果发现输出速度非常慢，每秒钟只处理了不到100个。那些数据粗略计算了一下，可能有超过2万条。为什么加载2万条数据会这么慢呢？这是一个令我纠结的结果，如果把最后的分组都做了，输出的数据只有365条，但如果不做最后的分组，有超过2万条。不做分组的话，那个结果可以在软件里直接展示出来，顶多只需要几秒的运算时间，但是不做分组，把数据输出却有超过2万条，即便我不输出表格只输出数据透视表，依然在输出的时候速度非常慢。为什么对2万条数据进行分组会这么慢呢？除了分组，还有其他快速的方式可以对某条件进行求和吗？整个操作之所以这么慢，除了因为分组，还有排序，还有一些，null转化为0，或者把0转化为null的操作，最后，还有一条我自己都觉得应该会很作死的向下填充。那个结果我花了好几分钟才计算出来，如果让高手去解答，估计运行时间会会是毫秒级的，顶多不会超过三秒钟。

一方面，我很想知道如何提升运行速度，直接拿去问人显然是最显而易见的办法，但在这之前，我想自己先思考一下，毕竟走到这一步已经很不容易，我不想在最后一步认输。这让我想起了高中数学老师的某句经典语录，学习数学几个境界里的最后一句——全而不好（前几句是“不懂不会，会而不对，对而不全”）。

晚上洗澡的时候我一直在想着某个Power Query的问题。某个功能我曾经试过用别的步骤去实现，但是到了最后一步的时候，发现某个东西算不出来，所以我就放弃了那个方法，文件也被我删掉了。晚上，当我遇到一个新问题的时候，我觉得用下午的那种方法才最容易实现。晚上洗澡的时候，我突然意识到，实际上下午的时候我几乎成功了，只剩下最后一步。当时我没想到，其实可以用一个以退为进。我可以做一个判断，如果if的判断等于空，就计算，如果不等于空，就是继续保留某数据。我并不知道如何修改PQ里某一列的数据，于是我的实现方法是新增一列对旧的那一列判断，然后把旧的那个删掉，新的那个重命名。这样就解决了下午我最后我没解决的问题。虽然这样做有点笨。高手一定不会这样做的，高手一定会有一些暂时我还无法参透的各种套叠解决问题。

要实现某个功能，最终我用了31行，更之前我用某个其它方法做出来的那个一样多，但后来的方法显然更容易理解。因为整个代码都是我手写出来的，命名也更加人性化。当然其实我也可以对系统自动生成的名字做修改，达到类似的颜值，但是某些自定义函数光靠系统的可视化窗口无法做到。经过这一番折腾以后，我更进一步地明白到之前我已经模仿做到的模糊查询到底做了什么操作。和之前我模仿回来的模糊查询比起来，这一次我实现的功能要麻烦一点。一开始的操作二者挺相似，模糊查询做完第1步以后，基本上就只剩下删除列和排序了，而我做的那个在完成的那一步以后，只不过是刚入门。我也不知道这一次摸索我到底是怎么折腾出来的，那显然，如果没有看见星光的M语言课程，我会继续迷糊。也正是因为第4节里说到了上下文，说到了新增列判断条件以及上下文的使用，才可以让我顺利流畅地通过第1步，也正是因为经过这一次练习，我觉得我已经略微掌握了上下文那个东西。

软件这种东西，光是看教程、听课，而不于实际操作，是没有用的，因为那个东西不会入脑。要形成条件反射，要让那些技能成为自己的东西，只有通过思考和练习。高手和低手的区别，我觉得大概在于高手的思考时间远远不需要那么长，所以他们可以有更多时间练习，而我这种低手，要在思考那里花好些时间，后来的练习当然比不上人家。基础的了练习尚且不够，就更不用说读懂练习中的异同。这种东西，在我高中的时候特别明显。高手在刷题的时候，我还在理解，至于为什么高手可以理解得那么快，至今，我都想不明白。大概这个东西不是想就能明白的。

经历过纠结以后，我觉得自己的脑洞又大了不少，在遇到问题的时候，我奇怪的思路又增加了一些。就是这些旁门左道的扩展，让我在处理正统问题上，貌似又更进了一步。

数据本身没有问题，如果我们不能让它们确立某种关系，只是因为我们对那个东西还不够了解而已。在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里玩的数据转换实际上是在折叠、删除以及扩充，一定程度上就像是在用类似于递归或者迭代的方式。

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