J'utilise avec succès l'actualisation incrémentielle quotidienne de Power BI avec une source de données MySQL. Cependant, je ne peux pas configurer cela avec AWS Athena, car apparemment ce dernier interprète les valeurs des paramètres requis RangeStart et RangeEnd comme des chaînes. Étant donné que la source de données compte environ 50 millions de lignes, j'éviterais plutôt de l'interroger à partir de zéro chaque jour.
Dans cette vidéo de Guy in a Cube , vous pouvez clairement voir que la requête envoyée par Power BI à Azure a une fonction de conversion en datetime2 - quelque chose comme celui-ci est probablement manquant pour Athena / Presto, qui a besoin du constructeur de type TIMESTAMP pour faire les comparaisons datetime ( https://stackoverflow.com/a/38041684/3675679 ), et bien sûr l'actualisation incrémentielle doivent être basées sur les champs datetime. J'utilise le champ datetime adv_date pour la charge incrémentielle.
Voici à quoi ressemble la requête M dans Power Query Editor:
select "col1", "col2", "adv_date"
from "AwsDataCatalog"."test"."test_table"
where "adv_date" >= ? and "adv_date" < ?
Et voici le message d'erreur résultant dans Athena:
Your query has the following errors:SYNTAX_ERROR: line 1:1: Incorrect number of parameters: expected 2 but found 0
Alors que c'est ainsi qu'Athena interprète la requête:
= Table.SelectRows(#"Removed Columns1", each [adv_date] >= RangeStart and [adv_date] < RangeEnd)
J'ai contacté le support Power BI sans succès. Quelqu'un at-il une solution de contournement pour cela par hasard? Heureux de fournir plus d'informations si nécessaire.
3 Réponses :
J'ai donc une sorte de réponse - je ne pense pas qu'il soit actuellement possible de configurer Athena en tant que source incrémentielle dans Power BI, en utilisant une connexion standard.
Cependant, il est possible de le faire via un flux de données, avec la mise en garde que pour notre environnement, ce n'était pas particulièrement rapide. Cependant, cela fonctionne.
Un gars de Microsoft m'a demandé d'utiliser Odbc.Query plutôt que d'utiliser Odbc.Datasource. Voici un exemple de l' URL qu'il a envoyée:
let
Source = Odbc.Query("dsn=Google BigQuery", "SELECT line_of_business, category_group FROM masterdata.item_d WHERE line_of_business in ('" & LOB & "')")
in
Source
J'ai essayé cela et cela a fonctionné, peut-être que vous pouvez également l'utiliser.
La requête directe fonctionne également pour moi, mais j'ai finalement déplacé les filtres vers une vue dans Athena - on ne peut malheureusement pas faire confiance à PBI pour gérer des choses comme celle-ci.
Quoi qu'il en soit, il existe une (sorte de) solution de contournement pour les requêtes M, au cas où quelqu'un d'autre en aurait besoin: j'ai découvert que si vous ajoutez certaines étapes avant le filtre, Power BI n'essaiera aucun pliage de requête, donc ne gâchera pas le SQL. envoie à Athéna. Dans mon cas, j'ai ajouté une colonne dupliquée et l'ai renommée. Le PBI, bien sûr, chargera toujours toutes les données , car bien sûr il le fera, mais il les videra une fois que la requête aura fini de récupérer les données. De cette façon, au moins, nous pouvons économiser de l'espace sur le fichier, même si le temps de chargement reste le même.
Désolé si je semble frustré dans cette réponse - la raison en est que je suis incroyablement frustré par Power BI.
Des mises à jour à ce sujet? J'ai le même problème. D'une manière ou d'une autre, PowerBI ne comprend pas qu'il doit placer la valeur du paramètre sur la requête.
Salut @ 的 devrimbaris, voir ma réponse ci-dessous.