本章是本书的特色。很多书籍很快就进入讲具体的技巧，而本书不慌不忙，定位高远，先告诉读者重要真相：你未来的成功是基于良好的架构思维，而本章内容正是向读者展示这一工程化思维，它有别与其他图书。这就是为何推崇本书的重要原因之一。 BI佐罗
在深入到 Power Query 数据转换的广阔世界之前，最好先确保为将来的成功做好准备。从实际来说，往往一开始的项目或案例都很小，但随着时间的推移，最终会变得越来越复杂。本章描述的方法将有助于确保随着问题的规模变大和复杂性增加，也可以应对。
2.1 使用多查询体系结构
正如在前面所讲，Power Query 可以理解为一种 ETL 工具。正如第 1 章所示，Power Query 实际上在它所创建的每个查询中都执行了这个完整的 ETL 过程。现在的问题是如何更好地进行维护以及当问题规模扩大时仍然可控。出于这个原因，将一个查询分拆或设计一些辅助的查询就非常重要。
2.1.1 对 ETL 进行分层
可以在一个查询中执行所有的查询步骤，也可以将一个查询分拆成多层查询。例如，考虑以下多层结构。
- 用于提取 “原始数据” 的查询层：这层查询是用来从数据源中提取数据的。这里只做了很少的转换。事实上，在这个步骤中，通常只删除不使用的列或行。最终的目标是得到一个干净的数据集的所有记录表，无论后续是否打算使用它们，都这么做。这就提供了一个操作 “原始数据” 的统一位置，在这里可以查看哪些表是可以使用的。
- 用于 “暂存” 的查询层：这层查询专门用来处理 ETL 过程中大多数的转换部分。包括：筛选数据，并进行任何需要的清洗或转换，创建干净的表供以后使用。虽然 “暂存” 层应该至少由一个查询组成，当然根据需要也可以将它分解成多个查询。
- 用于 “数据模型” 的查询层：这层查询是 ETL 过程中加载阶段之前的最后一步。这层的查询首先应该设置为希望在 Excel 工作表或数据模型中表的名称，它主要功能是在加载前执行任何最后步骤。例如：追加或合并 “暂存” 层中的查询，以及为表中的每一列设置最终的数据类型。
也有人认为这有些矫枉过正，真的需要三个独立的查询层来获取、转换和加载一个 Excel 表的数据吗？Ken 和 Miguel 对此也有不同的看法。
2.1.2 单个查询的好处
Miguel 倾向于在单个查询或尽可能少的查询中构建所有步骤。这与其他编程语言中使用的最小化概念相同，即通过删除解决方案中任何不必要的部分来优化代码及其结果，尽可能地保持简单。以下是这种方法的一些好处。
- 当查询列表中只有几个查询时，很容易找到需要的查询。由于查询区域的窗口没有搜索功能，一个巨大的列表会使用户难以找到所需要的特定查询。
- 当拥有的查询越多，就越难追踪它们的沿袭（译者注：互相引用依赖的关系），因为 Power Query 没有一个很好的工具来做这个。
- 有的时候，拆分查询会引发 “Formula Firewall（公式防火墙）” 错误。这可能超级令人沮丧，在某些特别情况下，必须在一个查询中声明所有数据源才能克服这个问题。
- 在其他使用 Power Query 的工具中，如 SSIS 和 Azure Data Factory ，只支持单个查询。如果未来需要将解决方案移植到这些平台之一，那么使用单个查询是一个更好的选择。
- 总是可以看到所有的东西是如何在一个单一的视图中联系在一起的，并对查询进行最小修改，从而使转换过程处于最理想的状态。
当使用查询诊断工具和检查更高级的特性（如查询折叠和检查查询计划）时，这非常有用。
2.1.3 分拆查询的好处
Ken 更倾向于每个查询都使用 “暂存” 查询，他认为 “暂存” 查询这步的设计有如下几个好处。其好处包括但不限于以下这些。
- 选择原始数据查询是非常容易的，看看数据源有哪些数据是可以使用的，并在数据源发生变化时更新该查询。
- 可以多次重复使用之前的查询（从 “原始数据” 到 “暂存”），节省不必要的重复工作。
- 当数据源的文件路径发生变化时，解决方案的维护变得更加容易，因为在解决方案中只有一个文件路径需要更新，无论它被后面的查询引用了多少次。
- 可以很方便地切换为新的数据源，可以创建一个新的 “原始数据” 连接，与旧的数据源并行存在，只要确保列的命名相同，就可以用它来直接代替原来的连接。
- 虽然有些情况下需要将数据源保存在一个查询中，以避免 “公式防火墙” 问题，但也有一些情况下必须将查询分开来绕过它。
同样，Ken 认为这种设置还有很多好处。当开始使用 Power Query 为 Power Pivot 或 Power BI 中的维度模型提供数据时，使得建立良好的事实表和维度表变得更加自然。正是由于这种设计的适配性，讲授相关维度建模课程时，从一开始就说明了 Power Query 的这种设计方式。
【注意】 Power Query 和 Power Pivot 最大的好处之一是能够快速建立商业智能解决方案的原型，而不必让 IT 部门参与。即使用户从 Excel 表作为基础开始，只要采用这种分拆查询的方式，可以很容易地支持在未来切换为链接到 SQL 数据库。
（译者注：软件工程中的一个重要课题就是：可复用。分拆查询的设计思维正是这一原则的充分体现。作者 Ken 是技术背景，这样的设计符合资深技术专家的思维模式；而作者 Miguel 是纯业务背景，单一查询的本质是结果导向，这样的设计符合资深业务专家的思维模式。在本书中展开了两种思维的碰撞，体现了现实中需要一种平衡，深度融入业务的技术方案设计要在直接结果和可复用扩展之间平衡，它并非科学，也非艺术，而是一种深度实践。）
2.1.4 关于暂存查询的性能
对于 “暂存” 查询，可能会有一个与性能相关的问题：这种设置由于后续查询多次引用 “暂存” 查询，会不会导致刷新速度变慢。
在 Power BI 和 Excel 2019 及更高版本（包括 Microsoft 365 ）中，答案都是否定的。这些版本的 Power Query 利用了一种叫做 “节点缓存（Node caching）” 的技术，在一次刷新会话中，同一查询第一次执行会被缓存，后续同一查询会复用这个缓存的内容。
假设有一个查询设置，从 “CSV 文件” 中检索数据，如图 2-1 所示。
图 2-1 一个简单的查询链，“暂存” 查询的结果被重复使用
Raw Data：原始数据 Staging：暂存 Sales：销售 Clients：客户
假设在 “原始数据” 查询中发生的事情很少，但有需要一个复杂的多步骤的转换，“暂存” 查询完成转换为干净格式的任务。从这里开始，“销售” 表和 “客户” 表查询都很简短，只是从 “暂存” 查询中提取数据，然后删除与它们输出无关的列和行。
当刷新时，“暂存” 查询将执行一次并被缓存。“销售” 表查询将引用这个缓存，执行所需要的任何其他转换，并将该数据加载到最终目的地。接下来，“客户” 表查询将也将引用 “暂存” 查询的缓存，基于这个缓存再执行它自己的任何转换，然后将 “客户” 表加载到目的地。这里需要认识的关键是，因为 “暂存” 查询的结果被多个查询所使用，所以它实际上只执行了一次。
可以将其与使用相同数据源的分别设置的方案进行比较，如图 2-2 所示。
图 2-2 尽管从同一数据源调用，但仍有暂存的查询链
Raw Data：原始数据 Staging：暂存 Sales：销售 Clients：客户
在这种情况下，当 “销售” 表被加载时，它必须从 “CSV” 中调用数据，在 “暂存” 查询中执行复杂的转换，然后在被加载之前完成 “销售” 表查询中的步骤。
接下来是 “客户” 表，因为它完全独立于 “销售” 查询链，所以执行相同的工作流程。Power Query 不仅需要从 “CSV” 文件中调用相同的数据，而且还必须处理 “暂存” 查询的所有步骤，然后才能处理和加载 “客户” 查询的结果。
正如你所看到的，【引用】查询并重新使用它们实际上可以提高性能，而不是减缓性能。
【警告】 在上述情况下，“原始数据” 查询和 “暂存” 查询都不应该设置为可加载的，它们存在的目的就是为了后续被引用的，而不是直接加载，否则，如果这些查询载到一个表或数据模型中，不但没有意义，还会消耗更长的加载时间来处理。
2.2 查询的引用
如何设置查询以实现可以被缓存再复用呢？这可以通过重新创建第一章的查询来完成这个过程。
2.2.1 创建基础查询
首先，打开一个新的 Excel 工作簿或 Power BI 文件，如下所示。
- 创建一个新的查询，转到【数据】选项卡【从文本 / CSV】。
- 浏览并选择：“第 01 章 示例文件 Basic Import.csv”【导入】。
- 单击【转换数据】，进入 Power Query 查询编辑器。
- 通过查询设置窗格将查询重命名为 “Raw Data（原始数据）”。此时，查询看起来应该类似于如图 2-3 所示。
图 2-3 在 Power Query 编辑器中 “Basic Import.csv” 文件的预览效果
很多用户有过这样的经验：建立了一个表，但在几个月后，业务变更导致需要调整表的列，如何确保在查询中用到的表是否包含需要的列？这就是本查询的目标之一：在这步预览所需的数据。
碰巧的是，连接到这个数据集时所记录的默认步骤集将达到这个目的。现在有一个干净的表，显示了数据集中的所有列，以及适合数据预览的所有行。
【注意】 对于每个查询中所涉及的 “原始” 数据查询，都需要根据具体情况进行逐一检查。每一个随着场景需求不同，需要区别对待，有时候可以直接接受 Power Query 的默认查询，但有的时候，需要删除 “Changed Type” 步骤，筛选数据，或者扩展列等。本书后续的学习会涉及这些案例。
2.2.2 创建查询的引用
当原始 “Raw Data” 数据查询的建立好之后，现在是时候【引用】它并创建第一个 “暂存” 查询了。要做到这一点，需要将【查询】导航窗格展开。这在 Power BI 中很容易，因为这是默认状态，但在 Excel 中，这个窗格总是一开始就被折叠起来。需要进行如下操作就可以做到这一点。
- 确保【查询】窗格是展开的（如果需要，单击【查询】上面的 “>”），如图 2-4 所示。
图 2-4 展开 Excel 中的【查询】导航器
打开【查询】导航器面板后，就可以看到解决方案中的所有查询，并进行创建查询的工作。
- 右击 “Raw Data” 查询，单击【引用】。
这将创建一个名为 “Raw Data (2)（原始数据 (2)）” 的新查询。想把它重命名为 “Staging（暂存）”，这里有如下三个不同的方法可以完成这个需求。
- 在【查询】导航器中右击 “Raw Data (2)” 查询【重命名】。
- 在【查询】导航器中双击 “Raw Data (2)” 查询名称。
- 在【查询设置】窗格的【属性】区域中更改 “Raw Data (2)” 查询名称。
上述任意操作都会使得查询被重新命名。
此时，继续创建最后的查询，将数据加载到最终目的地。
- 右击查询导航器中的 “Staging” 查询，单击【引用】。
- 将新的 “Staging (2)” 查询重命名为 “Sales（销售）”。
现在，来看看到目前为止所做的整体效果，如图 2-5 所示。
- 【查询】导航器显示，现在有三个查询，其中当前选择的查询是 “Sales”。
- 与原始的 “Raw Data” 查询不同，“Raw Data” 查询有三个步骤，而 “Sales” 只有一个名为 “Source” 的步骤。
- 公式栏显示了 “Source” 步骤的内容，即 “Source” 步骤等于 “Staging” 查询的输出。
图 2-5 解决方案的当前状态
在这里，理解公式栏的含义是非常重要的。“Staging” 查询中发生的任何事情都将流向 “Sales” 查询。进行如下操作来证明这一点。
- 选择 “Staging” 查询。
- 选择 “POS Hour” 列并按 DEL 键（或右击它并选择【删除】）。
- 双击 “Item Name” 列，将其重命名为 “Item”。
- 双击 “Units Sold” 列，将其重命名为 “Units”，“Staging” 查询的结果现在应该如图 2-6 所示。
图 2-6 清洗完数据后的 “Staging” 查询
现在，到【查询】导航器中选择 “Sales” 查询，返回如图 2-7 所示的查询。
图 2-7 “Sales” 查询中有什么变化吗
如果仔细观察，可以看到 “Sales” 查询的结构并没有改变：它仍然只有一个步骤（ “Source”）。
公式栏中的公式仍然调用 “Staging” 查询的结果（就像之前修改 “Staging” 查询那样）。
但是有一个变化，不是吗？现在的数据完全反映了在 “Staging” 查询中看到的内容。最初在 “Sales” 查询中显示的 “POS Hour” 列已经不存在了。此外，以前的 “Item Name” 和 “Units Sold” 列也采用了在 “Staging” 查询中定义的名称。
尽管没有对 “Sales” 查询进行修改，但在这里却看到了不同的数据。这实际上是符合预期的，因为对 “Sales” 所引用的查询进行了修改。“Staging” 查询中发生的任何更改都必须流向 “Sales” 查询，因为 “Sales” 查询的 “Source” 是 “Staging” 查询。
给 “Sales” 查询添加一个新的步骤，在最终完成这个查询链之前锁定数据类型。
- 选择 “[Item]” 列，按 “CTRL A（选择所有列）”。
- 转到【转换】选项卡【检测数据类型】。
那么，至此就完成将 ETL 过程重新构建为三个独立的查询，它们的工作如图 2-8 所示。
图 2-8 一个单一的 ETL 过程分布在三个查询中
Raw Data：原始数据 Source: CSV File：源：CSV 文件 Promote Headers：提升的标题 Changed Type：更改的类型 Staging：暂存 Source: Raw Data：源：原始数据 Removed Columns：删除的列 Renamed Columns：重命名的列 Sales：销售 Source: Staging：源：暂存 Changed Type：更改的类型
再次强调，虽然对于一个非常简单的查询来说，这看起来可能是一项艰巨的工作，但为每个阶段创建具有不同步骤的查询链，将使的开发人员在未来可以轻松地扩展解决方案。
【注意】 这里的问题是：“应该把哪些转换放在哪个查询中？” 这个问题的答案是主观的，随着时间的推移，会形成对这个问题的经验。
2.2.3 查询依赖关系树的可视化
还应该知道 Power Query 有一个内置的工具：查询依赖项查看器。这样就可以看到查询是如何被串联起来的，一起来看看吧。
- 转到【视图】选项卡【查询依赖项】。
对于这个解决方案，结果将如图 2-9 所示。
图 2-9 【查询依赖项】查看器
为了更好地利用这个工具，需要单击右下角有四个箭头的方框。这个缩放功能会缩放查询链以适应窗口。然后用户可以使用缩放控制旁边的缩放滑块来进行视图放大或缩小。
【警告】 尽管【查询依赖项】工具乍一看非常有用，但是 Power Query 发布时附带的版本缺少有用的功能。虽然这些功能在简单的模型中并不非常重要，但对于有许多依赖关系的大型模型来说是非常的重要，现在这个视图几乎没有用处。微软已经开始在 Power Query 在线版中解决这个问题，提供了一个更具交互性和更详细的依赖关系查看器，叫做 “Diagram View（图示视图）”。
（译者注：图示视图是 Power Query 在线版中的功能，可以更清晰地显示不同查询的引用关系，并提供更丰富的信息。）
2.2.4 使用 Monkey 工具查看依赖关系
如果遇到了一个这样的问题，即有一个复杂的查询结构，并需要工具来跟踪和了解它，用户可能会用到 Monkey 工具：一个 Excel 插件，Ken 开发它的部分原因是为了解决这个查看器的一些问题。虽然它为创建和检查查询提供了许多功能，但一个关键的功能是 “Query Sleuth（查询探测器）”，它提供了一个强大的查询追踪器，如图 2-10 所示。
图 2-10 Monkey 工具的 QuerySleuth 显示了 “Calendar（日期）” 查询背后的依赖树和 M 代码
【待修正】截图待替换。
可以了解更多关于这个插件的信息，并在 Ken 的网站上下载此工具的免费试用版体验。
（译者注：该工具是作者设计开发的 Excel 插件，可以辅助用户使用 Power Query，但对本书的学习不是必须的。）
2.3 选择查询加载目的地
随着全部查询的正确创建，现在是加载它们的时候了。但事实上，只需要将其询中的一个查询加载到 Excel 工作簿或 Power BI 模型中，那就是 “Sales” 查询。“Raw Data” 和 “Staging” 查询只是为了获得最终结果的辅助查询，但用户并不希望或需要在他们的解决方案中存储它们的数据。
好消息是，Power Query 有一个方法来处理这个问题。在 Power BI 中，通过禁用查询的加载来实现这一点，而在 Excel 中，告诉查询以仅连接的方式存在。这些术语的效果是一样的，除非被查询链中的另一个查询调用，否则 Power Query 将永远不会执行这些仅以连接形式存在的查询。在本书中，也称任何 “仅限连接” 的查询都为 “暂存” 查询，因为这就是 “暂存” 查询的意义所在：“暂存” 数据供另一个查询使用。
2.3.1 在 Power BI 中选择加载目的地
默认情况下，所有的 Power BI 查询将加载到数据模型中。如果想改变这一点，需要进行如下操作。
- 右击【查询】导航器中的 “Staging” 取消勾选【启用加载】选项。
正如在如图 2-11 中看到的，没有被标记为加载的查询是以斜体字显示。
图 2-11 取消对 “Staging” 查询的【启用加载】选项的勾选，把它作为一个 “暂存” 查询
请记住，【启用加载】的术语并不表明查询是否会被刷新。当单击【关闭并应用（或随后选择刷新查询）】，“Sales“查询将调用 “Staging” 查询，而 “Staging” 查询将调用 “Raw Data” 查询。但是在这个过程结束时，只有 “Sales“查询会在 Power BI 数据模型中保存。
2.3.2 在 Excel 中选择加载目的地
虽然 Power BI 很容易操作，但 Excel 中却略有复杂。
在 Power BI 中可以单独配置每个查询，而 Excel 只允许用户在一个 Power Query 会话中创建的所有查询选择一个加载目的地（自 Power Query 编辑器可以在 Excel 中使用以来）。但因为现在有三个查询，而且只想把其中一个加载到工作表中，另外两个是 “暂存” 查询。所以，就需要稍微复杂的操作。
【注意】 可以通过创建每个查询，在完成时将其加载到适当的目的地，然后再创建下一个查询来避免这个问题。但是挑战在于，这将迫使用户在每次查询之后不得不关闭 Power Query 编辑器，从而有可能打乱用户的思维流程。
既然只能选择一个目的地，就需要做出一个明智的选择，即想使用哪一个加载目的地。
【警告】 现在可能做出的最糟糕的决定就是直接进入 Power Query 的【主页】选项卡，然后单击【关闭并上载】按钮。原因是它将把每个新查询加载到新工作表中的一个新表中。换句话说，会生成三组新的工作表以及置于其中的表，用于存放 “Raw Data”、“Staging” 和 “Sales” 的全部内容。
为了避免上述的问题，可以选择 Power Query 的非默认加载行为，如图 2-12 所示。
- 进入【主页】选项卡，单击【关闭并上载】按钮的文本部分（而不是图标部分）【关闭并上载至】。
图 2-12 此时需要单击【关闭并上载至】按钮
此时将弹出 Excel 的【导入数据】对话框，它将让你选择查询加载目的地，如图 2-13 所示。
图 2-13 在 Excel 中选择查询的加载目的地
来分析一下这几个选项。
- 【表】：将三个查询加载到新工作表的新表中。
- 【数据透视表】：如果有一个单独的查询，这个选项将把数据加载到 “数据透视表” 中，并在新的工作表中创建一个新的 “数据透视表”，在这个案例中，有三个查询，它会将三个表加载到数据模型中，然后在一个新的工作表上创建一个新的 “数据透视表”。
- 【数据透视图】： 遵循与 “数据透视表” 报告相同的方法，但创建一个 “数据透视图” 而不是 “数据透视表”。
- 【仅创建连接】：禁用每个查询的加载，直到更改这个设置（或通过另一个查询的引用，调用这个查询）。
【注意】 上面列出的四个选项是互斥的，但却可以在使用其中的任何一个选项的同时勾选【将此数据添加到数据模型】的功能。通常不推荐：在添加到【表】的这个选项时，同时勾选【将此数据添加到数据模型】复选框的这个组合。推荐的是：在添加到【仅创建连接】的这个选项中，同时勾选【将此数据添加到数据模型】复选框的这个组合。
（译者注：不推荐的方案是同时将加载到 Excel 的表和数据模型，这显得有所多余；推荐的方案是将 Power Query 数据清洗以及数据模型的强大特性相结合，例如：Power Query 无法将一个超过 110 万行的表加载到 Excel 的表中，因为这超过了 Excel 的表容量限制，而数据模型则不受限，甚至可以加载 1 亿行数据，如果的确需要的话，当然，需要一定的加载时间。）
现在是提交查询的时候了。
- 选择【仅创建连接】。
- 单击【确定】。
查询都将被创建为【仅限连接】查询，如图 2-14 所示。
图 2-14 三个查询都是以【仅限连接】的方式载入的
那么，当有多个查询时，为什么要选择【仅创建连接】呢？考虑一下，如果选择将三个查询加载到工作表或数据模型中会发生什么情况。不仅每个查询要被创建，而且 Excel 还需要为它们建立新的工作表或数据模型表。而在这些任务完成后，对于这三个查询中的每一个，仍然需要等待所有的数据加载。最后，在所有的加载完成后，又要回去，指出那两个本应只是连接的表，然后等待 Excel 再次更新，因为它删除了不必要的数据。
（译者注：这里清楚地解释了各种操作之间的差异，而给出的最好选择是实际中的最佳实践，也就是默认选择【仅创建连接】再后续更改加载的方式是最高效的选择。）
选择【仅创建连接】的原因纯粹是操作效率和速度问题。【仅限连接】的查询几乎是即时创建的。宁愿把所有的查询都快速创建为连接，然后只更新那些确实需要加载的查询。事实上，可以更改 Power Query 的默认设置，将新的基于 Excel 的 Power Query 查询默认设置为只加载连接。如果想这样做，可以通过如下步骤进行设置，结果将如图 2-15 所示。
- 进入【获取数据】【查询选项】【数据加载】【默认查询加载设置】。
- 选择【指定自定义默认加载设置】。
- 取消勾选【加载到工作表】的复选框，你会认为这里会有一个叫做 “只创建连接” 的选项，但是当不勾选这两个选项时，实际上是选择只创建一个连接。
图 2-15 配置默认查询加载设置，只作为连接加载
【警告】 不要忘记取消勾选【加载到工作表】的复选框，如果不这样做，就意味着使用了一个自定义的设置来复制默认的加载设置。
2.3.3 更改加载目的地
现在要处理的问题是 “Sales” 表被加载为 “仅限连接” 的查询，但希望把它加载到工作表中。那么，该怎么做呢？
遇到的几乎所有 Excel 用户的第一反应都是在 Power Query 编辑器中 “编辑查询” 并更改加载目的地。当看到【关闭并上载至】按钮时，通常会感到非常困惑，因为此时他们发现这个按钮是灰色的，无法使用。事实证明，一旦创建了一个 Power Query 查询，就不能在 Power Query 编辑器中更改加载目的地。
要重新配置 “Sales”（或任何其他查询）的加载目的地的方法如下所示，结果图 2-16 所示。
- 进入 Excel 的【查询 & 连接】窗格。
- 右击想更改的查询（ “Sales” ）【加载到】。
图 2-16 更改 Excel 中的现有查询的目的地的方法是右击查询选择【加载到】
现在可以从【导入数据】菜单中选择另一个选项。在这种情况下，将选择与在第 1 章中的一致做法。
- 选择【表】。
- 单击【确定】。
最终的结果是与在第 1 章中看到的输出相同，但使用的是更强大和可扩展的查询结构，如图 2-17 所示。
图 2-17 从数据到工作表通过一个查询链
【注意】 虽然展示了如何从【仅限连接】查询中更改加载目的地，但请注意，可以使用这个功能将任何查询从一个加载目的地更改为另一个。
【注意】 专业提示：如果不小心把一个查询加载到工作表的表中时，而不是将它加载为【仅限连接】。与其更改加载目的地，然后再删除工作表，不如先删除工作表。当工作表被删除后，查询将自动改为【仅限连接】，这将节省一个步骤。
2.4 保持查询的条理性
对 Power Query（特别是本章所解释的方法）越熟悉，最终创建的查询就会越多。不久就会需要一种方法来保持它们的条理性。
Power Query 允许创建文件夹（和子文件夹），以便根据需要对查询进行分组。可以在 Power Query 编辑器中的 【查询】导航器窗格找到这个功能，也可以在 Excel 中的【查询 & 连接】窗格中找到这个功能。
2.4.1 查询文件夹
当创建新的文件夹时，无论是在【查询】导航器窗格中，还是在 Excel 中的【查询 & 连接】窗格中，都有两种不同的选择。
要创建一个新的（空）文件夹。
- 右击任何空白区域【新建组】。
要把查询移到一个新的组中，动态创建组。
- 选择【查询】（或在单击【查询】时按住 CTRL 键选择多个查询）。
- 右击任何选定的查询【新建组】。
然后会被提示输入【新建组】的名称，以及输入（可选择）该组的描述，如图 2-18 所示。
图 2-18 创建一个新组来保持查询的条理性
在这种情况下，将总共创建如下三个新组。
- “Raw Data Sources（原始数据源）”。
- “Staging Queries（暂存查询）”。
- “Data Model（数据模型）”。
一旦完成，【查询 & 连接】窗格将看起来如图 2-19 所示。
图 2-19 三个新的文件夹已准备好供查询使用
【注意】 在 Power Query 编辑器中，将鼠标悬停在组名上时，会显示组的描述。
2.4.2 将查询分配到文件夹
当然，如果在创建查询时选择将其移入一个特定的文件夹中，那么它们将已经嵌套在该文件夹中。另一方面，如果是为以后使用而预先设置的组，现有查询将被默认放置在名为 “其他查询” 的组中。
将查询分配到一个组中，应该像把它们拖放到适当的文件夹中一样容易。不幸的是，虽然在 Power Query 编辑器中的【查询】导航器窗格中是这样的，但在【查询 & 连接】窗格中并不支持拖放操作。要在这个窗格中分配查询，需要执行以下操作。
- 右击查询【移至组】选择要放置查询的文件夹。
【注意】 如果使用的是 Excel ，可以通过双击任何查询轻松跳转回 Power Query 编辑器。一旦到了那里，展开【查询】导航窗格，就可以完全使用拖放功能，使工作变得简单。
2.4.3 排列查询和文件夹
查询组是按照创建的顺序显示的。虽然这样做有一定的逻辑，但实际情况是，需要将查询重新组织成另一种顺序。同样，和移动文件夹一样，只有在 Power Query 编辑器的【查询】导航窗格中才支持拖放。如果在 Excel 的 【查询 & 连接】窗格中工作，需要采取的步骤如下。
- 右击查询或组【上移（下移）】。
- 根据需要多次重复这个动作，以使的项目获得的正确的顺序。
在这种情况下，想重新为文件夹排序，把最重要的查询放在顶部，而把审查最少的放在底部。换句话说，希望看到的顺序是 “数据模型”、“暂存查询”，最后是 “原始数据”。虽然上面的右击步骤是可行的，但使用 Power Query 编辑器中的拖放功能感觉更自然，如图 2-20 所示。
图 2-20 在 Power Query 编辑器中通过拖放更改文件夹顺序
（译者注：在原书的示例文件中，其排列顺序是：Data Model，Staging Queries，Raw Data Sources。而从 ETL 的角度，其顺序正好的相反的，读者可以根据自己的使用习惯来编排这个结构，这只是一种逻辑上的习惯，并无对错之分。）
2.4.4 查询子文件夹
要创建子文件夹来将查询进行分组，需要进行如下操作，结果如图 2-21 所示。
- 右击现有文件夹【新建组】。
【注意】 虽然可以将查询分配给动态创建的新文件夹，但不能动态创建子文件夹层次结构并将查询移动到其中。需要先创建子文件夹，然后再移动查询。
图 2-21 完整的文件夹结构，用于保存维度模型的查询
2.5 拆分现有查询
当然，许多人刚开始接触 Power Query 的时候，从来没有用过在本章中介绍的方法来整理查询。事实上，大部分用户更可能在一个查询中完成所有的工作。那么如何解决这个问题呢？难道必须从头开始重新构建整个解决方案才行吗？
当然不需要那样。回顾在第 1 章中构建的查询，其中 “Transactions” 查询【应用的步骤】窗口最后的步骤以如图 2-22 所示结束。
图 2-22 第 1 章中 “Transactions” 的最终查询
为了使这个查询在结构上等同于本章中创建的查询结构，需要进行如下操作。
- 选择 “Transactions” 查询。
- 右击 “Lock in Data Types” 步骤【提取之前的步骤】。
- 输入 “Staging” 作为【新查询名称】。
- 选择 “Staging” 查询。
- 右击 “Removed Columns” 步骤【提取之前的步骤】。
- 输入 “Raw Data” 作为【新查询名称】。
最终的结果是一个与之前构建的几乎相同的查询链，如图 2-23 所示。
图 2-23 将第 1 章的解决方案拆分成三个独立的查询的结果
Raw Data：原始数据 Source: CSV File：源：CSV 文件 Promote Headers：提升的标题 Changed Type：更改的类型 Staging：暂存 Source: Raw Data：源：原始数据 Removed Columns：删除的列 Renamed Columns：重命名的列 Transactions：转换 Source: Staging：源：暂存 Changed Type：更改的类型
这个操作的难点在于，要清楚在哪个步骤把查询拆开。当然，其本质技巧在于理解所选择的步骤之前的所有步骤都将被重新打包拆分成一个新的查询。
【注意】 现实情况是，在创建查询链的时候，并不总是能知道到什么时应该停止增加一个查询中的步骤，并通过【引用】这个查询，再启动一个新的查询进行进一步的转换。一个可用的解决方法是，可以先做一个不考虑拆分的完整查询，当发现需要拆分时，通过【提取之前的步骤】功能再进行拆分即可。
2.6 关于查询体系结构的最后思考
很明显，将一个查询拆分成多个查询比在一个查询中完成所有工作要花费更多的精力。这样做值得吗？还是说应该坚持使用单一的查询？这个问题的答案取决于项目实际情况。
Ken 认为，这为重构数据以满足数据模型提供了最终的灵活性。Miguel 更倾向于在他的解决方案中保持尽可能少的查询数量。当使用 Power Query 时，每个人会发现适合自己最佳方案，因为这只是一个风格问题。有时可能会认为，为每个查询配置一个查询、两个查询甚至八个查询都有可能是合理的解决方案。不同的场景，需要用不同的方式区别对待。
由于本书的目的是关注于数据转换技术本身，处于教学目的，大多数案例使用单个查询的方式，以保持简洁。但当进入现实世界构建解决方案时，应该考虑本章的内容。
有多种选择和灵活性总是好事，可以根据需要以最合适的方式构建每个解决方案。
正在学习 Power Query 吗？可以加入本主题的交流群一些交流分享。
