不知何故，解决了Power BI中的语言分析问题，同时在寻找
上一篇文章的示例时，我想起了几年前我试图在Excel中解决的问题：有必要在分析系统中实现俄语词典以对大量查询进行语言分析用自然语言。 并且希望使用标准的办公工具。 绝大多数人会立即在Excel中执行此任务，而我曾经采用相同的方式。 我使用俄语的开放语料库（
http://opencorpora.org/ ）作为字典。
但是令我失望的是-词典包含30万个单词形式，超过500万个条目，从原则上讲，对于Excel来说，这是一个不可能的数目。 即使您将“仅”一百万行插入其中，也只有非常耐心的人永远不会着急，才能对它们执行任何操作，或者，上帝禁止，计算。 但是这次我决定为该任务设置一个更合适的工具-Power BI。
什么是Power BI？
我发现该产品在很大程度上被专业人士低估了。 Power BI是一组业务分析工具，是为拥有Excel的用户创建的，其水平比“破坏列数”略高。 如果一个人能够在Excel中编写中等复杂度的公式，那么他将在几个晚上掌握Power BI。
这不是具有某种内部编程逻辑的单个产品，而是由三个部分组成的系统：
- 功率查询 这是一个ETL，在其中必须使用其自身的完整功能编程语言-M编写查询。公平地说，应该指出，最有可能的是，普通用户不太可能必须在其上进行编程：大多数功能都可以通过组件界面中的菜单或向导直接使用。 M语言与DAX查询语言（PowerPivot）完全不同。 但是，微软将它们整合在一起。 从开发的角度来看，这是有道理的：ETL是为接收和初始饱和数据（不是很快）而设计的，而DAX是为帮助我们（快速）可视化数据的计算而设计的。 也就是说，DAX用于前端，Power Query用于后端，用于提取和格式化数据的过程。
- PowerPivot 。 基于xVelocity引擎的内存中处理模块。 使用DAX查询语言，与Excel公式语言非常相似。
- 可视化组件 。 对于需要可视化数据的系统中的应用程序来说，它非常有用：公司网站上，技术支持门户网站（例如，请求云）上或内部公司资源上。 有一些工具可以在没有Power BI的情况下执行此操作，但是当记录数达到数百万并且需要以某种方式汇总数据时，其中许多工具将无济于事。 凭借其简单性和低成本的内存处理能力，Power BI与其他同类工具竞争。 显然，如果我们谈论的是TB级数据，那么将需要一种不同的方法。 在这种情况下，Microsoft已经提供了一些东西，但这是另一篇文章的主题。
第一阶段的学习曲线会急剧增加：如果您擅长Excel，那么经过短暂的学习后，您将发现80％的Power BI功能。 这是一个非常强大的工具，非常易于使用，但是-直到某个时候。 要充分利用它，您已经需要M和DAX语言的经验和深入的知识。
Power BI Desktop的用途是什么？
对谁有用？ 首先，当Excel不再能够应付或限制时，必须处理和分析大量数据的所有业务用户。 我强调-Power BI Desktop是
为解决各种各样任务的广泛用户设计的。 例如，在我的案例中，这是为了规范500万个文本条目，以便随后确定关键字的频率。
在处理问卷，搜索引擎查询，广告，听写/文章，某种统计数组等时，这是必需的。或者用于解决填字游戏...
关于德米特里·图迈金（Dmitry Tumaikin）的“认可者”的
文章中考虑了另一种情况和实施方案。 在经典Excel上实现，但使用宏...
对于Power BI的这种应用，另一种流行的方案是计算当前时期和上一个时期的指标比率。 例如，我们已经预先汇总了收入数据，您需要按天数与上一季度，上一年或类似时期进行比较。 我想/需要将比较结果以值而不是公式的形式插入下一列。 对于Excel来说，似乎最简单的任务是编写一个简单的比较公式并将其拉伸到列中的所有单元格上。 但是如果表中有几百万行，则不会。 在DAX本身中，此任务甚至比Excel中更容易，但也只能借助后期计算。
可以提供使用Power BI的许多其他实际方案，但是我想您已经了解了本质。 当然，对于拥有例如Python或R的程序员来说，所有这些任务都不是问题，但是与Excel专家相比，这些专家的先验程度要小几个数量级。 Excel仅具有有限的可能性，而Power BI使用的不是DAX公式语言，它与Excel公式语言非常相似，并且能够即时处理数百万个记录，而Power BI则不是。 然后，您需要增加RAM（至少最多100 GB，至少最多300 GB）。
我们帮助技术支持流程请求
但是回到我的任务。 有必要提出技术支持零线将如何自动评估用户请求的主题。 首先，我决定隔离某些单词形式，并根据用户出现在消息中的频率来确定用户最常提出的最重要的主题。
源词典是一个简单的文本文件，具有规则的结构，如下所示：
出于统计目的，有必要确定每种单词形式的初始形式：对于名词-主格的单个数字，对于动词-不定形式等。 对于程序员而言，此任务比简单要简单：对于左列中的每个单词，找到与字典中该单词编号紧随其后的形式的对应关系。
这只是不具备Python，专业工具和开发技能的普通业务用户，如果不使用自我分析BI或类似的用户友好工具，将无法解决此问题。 此外，如果需要根据内部需求处理数据，或者没有需要保护的机密信息，那么Power BI在这种情况下也将是免费的*。
隐藏文字*）这是指以免费价格供个人使用的Power BI Desktop版本和Power BI Services版本。
为了分析数据，我需要在Power Query中以500万条记录的表形式添加一个新列，该列移动一个位置。 最初，我尝试使用Power Query应用经典方法，该方法在原始Power Query在线参考指南（也用Power Query编写）的作者Marcel Beug的Power BI社区门户上进行了
描述 。 本文提出了两种不同的算法：一种是受著名大师兼Power BI培训师Matt Elington的思想启发，另一种是使用附加功能的Marcel本人的原始思想。 尽管事实上为了提高生产率，我完全缓存了源数据，但这两种方法都需要大量时间-它们已经过去了第八天，而且过程尚未完成。 源文件的大小为270 MB，当前已处理数据的大小接近17 TB。 我确信很少有Power BI用户在从文件源加载数据的窗口中看到过这样的数字。
为什么体积如此肿胀，尚不清楚； 即使是所有记录的笛卡尔乘积也远小于16 Tb。 在这里，内部优化器显然达不到标准。 并且，例如，DAX-Studio不允许跟踪Power Query查询，仅允许跟踪DAX。 也许有人会分享他们在PQ故障排除方面的经验？
不用等待第一个过程的完成，我决定在另一台机器上尝试通过自写查询使用DAX解决问题。 大约180秒后，该请求已得到满足。内存消耗略有增加。
DAX请求的源代码：
KeyWord =
CALCULATE(
TOPN(1;
CALCULATETABLE(
VALUES(ShiftedList[Word])
;ALLEXCEPT(ShiftedList;ShiftedList[Word Nr])
)
)//TOPN
)//CALCULATE
也就是说，对于新的[KeyWord]列中的每一行，将搜索[Word]列的第一个值，其中包含具有相同基本单词格式编号（[Word Nr]列）的单词格式的所有变体。 只要源文件的格式保持不变，该请求就应在字典的所有后续发行版本中得到正确执行。
Power Query中的查询代码以所需的格式构成了源表，是“自动”生成的，并且在不到一分钟的时间内完成：
在三分钟之内在PowerPivot界面中形成一列关键字之后，在Power BI界面中搜索任何单词形式都不会超过4秒。 此外，控件在您喜欢的记事本++ x64中搜索相同数据可能需要20秒或更长时间。 但这不是NPP花园中的一块石头-搜索整个数据数组比根据已经标记的数据更困难（也更长）。
顺便说一句，上面的DAX请求不是第一次生成，并且中间选项消耗了所有可用内存，工作了很长时间，并以数据错误或无关紧要的结果结束。
结果，所保存的PBIX文件的大小比原始文本字典小60％（112 MB），但比具有相同字典的ZIP归档文件大4倍以上。
回到Power Query和DAX之间的斗争：在不同组件中同一操作的持续时间有所不同，这表明Power BI并不是一个没有信号的撬棍。 他具有自己的应用程序特征和功能，在工作中必须予以考虑。 实际上，就像任何工具一样。 甚至公认的大师的建议也应谨慎对待。
似乎诺贝尔奖获得者理查德·史密利（Richard Smalley）曾说过，克拉克的第一定律是这样解释的：“当专家说某事可行时，那么他们可能是对的（他们只是不知道何时）。 当他们说这是不可能的时候，那么很可能是他们弄错了。”
试验机特点：
处理器：Intel Core i7 4770 @ 3.4 GHz（4核）
内存：16 GB
操作系统：Windows 7 Enterprise SP1 x64可
从此处下载Power BI格式的现成词典。
在这里 ，可以使用该词典的修改后的在线版本。 您可以使用它来随意解决填字游戏:)
...顺便说一句，几年前，尽管不是100％，但还是在Excel中解决了该任务。 仅出于文本分析的目的，不是使用整个俄语的语料库，而是使用频率词典。 对于基本的文本清理，
这里可用的几十个千字节的前100个
频率列表都非常合适。
Jet信息系统（ McCow ）整合和数据可视化系统部专家Yuri Kolmakov