2024年企业数据平均散落在11个不同系统里——这是微软内部调研的数字。你的报表还在手动复制粘贴？
Power BI的数据架构像个三层过滤漏斗：数据源在左，Power Query（数据转换引擎）居中，数据模型和报表在右。所有数据必须经过中间这层"质检车间"，才能进入最终的分析环节。
文件型数据：Excel、CSV、PDF的入门路径
点击「主页」→「获取数据」，选文件类型。系统会弹出Navigator窗口预览数据，确认后进入Transform Data（转换数据）。
这里有个细节：PDF连接器是2020年后才成熟的，早期用户得先把PDF转成Excel再导入。现在直接解析表格结构，但复杂排版仍可能错位——建议预览时逐页核对。
CSV的坑在于编码格式。UTF-8和GBK混用会导致中文乱码，Power Query里可以在「源」步骤手动指定编码。这个选项藏得有点深，在齿轮图标的高级设置里。
数据库连接：Import和DirectQuery怎么选
SQL Server或MySQL的连接流程多了一道选择题：Import（导入）还是DirectQuery（直接查询）？
Import把数据缓存到Power BI文件里，查询速度快，适合百万行以下的静态分析。DirectQuery实时连数据库，数据量无上限，但每次交互都要发SQL请求，响应延迟明显。
微软官方建议：数据日增量超过1GB，或需要实时看板，选DirectQuery。否则Import更省心。混合模式也存在——部分表导入，部分实时，在「模型」视图里可以逐表设置。
凭证管理是个隐形痛点。Windows身份验证在企业内网顺畅，但跨域场景经常报错。这时得切到「数据库」认证，把账号密码写进连接字符串——记得配合网关（On-premises Data Gateway）使用，别直接暴露在云端。
云端和API：SharePoint、Azure、JSON的进阶玩法
Web类连接器的核心就一步：贴URL。但API接口往往需要认证头（Header）或OAuth令牌，Power Query的「高级编辑器」里可以写M语言手动构造请求。
SharePoint连接器有个反直觉的设计：选「SharePoint列表」还是「SharePoint文件夹」？前者抓的是List视图，后者遍历文档库。很多人混淆这两者，导致拿到的数据列不对。
JSON API的处理更考验功力。嵌套结构（Nested JSON）不会自动展开，需要在Power Query里手动点击「展开」按钮，或者写Table.ExpandRecordColumn函数。层级超过三层时，界面操作会很繁琐，建议直接上M代码。
Azure系列连接器（SQL数据库、Blob存储、Data Lake）的优势在于原生集成。身份验证走Azure AD，不用额外配密钥。但企业租户的管理员权限经常成为卡点——IT部门不给开Reader角色，报表就做不下去。
Power Query：被低估的数据清洗中枢
所有数据源最终都要汇入Power Query。这个ETL（提取-转换-加载）引擎的界面像Excel的进阶版，但功能更接近专业工具。
常用操作都有按钮：删除空行、拆分列、数据类型转换、合并查询。复杂场景得写M语言，比如按条件填充空值、递归解析树形结构、调用外部函数。
一个实用技巧：右键点击查询步骤，选「属性」可以重命名和加注释。步骤一多，默认的「已更改类型1」「已筛选行2」根本分不清用途。良好的命名习惯能省下大量返工时间。
数据刷新策略也在这里配置。定时刷新走Power BI Service的网关，增量刷新（Incremental Refresh）需要Premium或Pro许可，且数据源必须支持查询折叠（Query Folding）——简单说就是把过滤条件推回数据库执行，而不是把全表拖进内存再筛。
微软2023年加了「数据流」（Dataflow）功能，允许把清洗逻辑封装成可复用组件。多个报表共享同一个数据流，源头一改，下游全更新。这对中大型企业是刚需，否则同样的清洗代码要在十个文件里重复维护。
你的数据目前分散在几个系统？如果超过5个，Power BI的「组合查询」功能或许能帮你省下一半的整合时间——但前提是，你愿意先花两小时摸清Power Query的脾气。
热门跟贴