Falha épica linguística ou Como empinar o dicionário inteiro do idioma russo no Power BI

De alguma forma, resolvendo o problema da análise linguística no Power BI e, ao mesmo tempo, procurando exemplos para o meu artigo anterior , lembrei-me do problema que tentei resolver no Excel há vários anos: era necessário implementar um dicionário de idioma russo no sistema analítico para análise linguística de um grande número de consultas em linguagem natural. E era desejável usar ferramentas de escritório padrão. A grande maioria das pessoas executaria imediatamente essa tarefa no Excel, e uma vez eu fui pelo mesmo caminho. Eu usei o caso aberto do idioma russo ( http://opencorpora.org/ ) como um dicionário.

Mas a decepção me esperava - o dicionário consistia em 300 mil formulários de palavras, mais de 5 milhões de entradas, e para o Excel é, em princípio, uma quantia impossível. Mesmo se você pressionar "apenas" 1 milhão de linhas, apenas uma pessoa muito paciente, que nunca estará com pressa, poderá realizar qualquer manipulação com elas ou, se Deus não permitir, cálculos. Mas desta vez, decidi definir uma ferramenta mais adequada para a tarefa - Power BI.

O que é o Power BI?

Acho este produto amplamente subestimado pela comunidade profissional. O Power BI é um conjunto de ferramentas de análise de negócios que foi criado para usuários que possuem o Excel em um nível um pouco mais alto do que "dividir o valor em colunas". Se uma pessoa conseguir escrever fórmulas de média complexidade no Excel, ela dominará o Power BI em algumas noites.

Este não é um produto único com algum tipo de lógica de programação interna, mas um sistema de três componentes:

• Consulta de energia Este é um ETL, no qual é necessário escrever consultas usando sua própria linguagem de programação totalmente funcional - M. Para ser justo, deve-se notar que, muito provavelmente, é improvável que um usuário comum precise programá-lo: a maioria das funções está disponível diretamente através do menu ou do assistente na interface do componente. A linguagem M é completamente diferente da linguagem de consulta DAX (PowerPivot). No entanto, a Microsoft os reuniu. Isso faz algum sentido do ponto de vista do desenvolvimento: o ETL foi projetado para receber e saturação inicial de dados (não rápida) e o DAX - para cálculos que nos ajudam a visualizar esses dados (rapidamente). Ou seja, o DAX é para o front-end e o Power Query para o back-end, para o processo de extração e formatação de dados.
• PowerPivot . Um módulo de processamento na memória baseado no mecanismo xVelocity. Usa a linguagem de consulta DAX, muito semelhante à linguagem de fórmula do Excel.
• Componente de visualização . É muito útil para aplicativos em sistemas nos quais você precisa visualizar dados: no site de uma empresa ou em um portal de suporte técnico (por exemplo, uma nuvem de solicitação) ou em um recurso corporativo interno. Existem ferramentas que podem fazer isso sem o Power BI, mas muitas delas não ajudarão quando o número de registros estiver na casa dos milhões e os dados precisarem ser agregados de alguma forma. E com outras ferramentas desse tipo, o Power BI concorre devido à sua simplicidade e baixo custo de processamento na memória. É claro que, se estamos falando de terabytes de dados, será necessária uma abordagem diferente. E, nesses casos, a Microsoft já tem algo a oferecer, mas este é um tópico para um artigo separado.

A curva de aprendizado no primeiro estágio aumenta muito: se você é bom no Excel, 80% dos recursos do Power BI serão revelados a você após um breve estudo. Esta é uma ferramenta muito poderosa, bastante fácil de usar, mas - até um certo ponto. Para usá-lo em plena capacidade, você já precisará de experiência e conhecimento profundo das linguagens M e DAX.

Para que serve o Power BI Desktop?

Para quem pode ser útil? Antes de tudo, qualquer usuário de negócios que precise processar e analisar grandes quantidades de dados quando o Excel não for mais capaz de lidar ou estourar até o limite. Eu enfatizo - o Power BI Desktop foi projetado para uma ampla variedade de usuários que resolvem uma gama muito diversificada de tarefas . Por exemplo, no meu caso, tratava-se de normalizar 5 milhões de entradas de texto para a determinação subsequente da frequência das palavras-chave.

Isso está em demanda no processamento de questionários, consultas de mecanismos de pesquisa, anúncios, ditados / ensaios, algum tipo de matriz estatística, etc. Ou na solução de palavras cruzadas ...

Outro caso e opção de implementação é considerado em um artigo sobre o “reconhecedor” de Dmitry Tumaikin. Implementado no Excel clássico, mas usando macros ...

Outro cenário popular para esse aplicativo do Power BI é calcular a proporção de indicadores para o período atual e o anterior. Por exemplo, temos dados de receita pré-agregados e você precisa compará-los por dias com o trimestre anterior, ano ou período similar. E eu quero / preciso inserir o resultado da comparação na próxima coluna na forma de valores, não em fórmulas. Parece que, para o Excel, a tarefa mais simples é escrever uma fórmula de comparação simples e esticá-la por todas as células da coluna. Mas não se você tiver vários milhões de linhas na tabela. No próprio DAX, essa tarefa é ainda mais fácil do que no Excel, mas também apenas com a ajuda de pós-cálculos.

Muitos outros cenários práticos para o uso do Power BI podem ser fornecidos, mas você, eu acho, já entendeu a essência. Obviamente, todas essas tarefas não são um problema para um programador que possui, por exemplo, Python ou R, mas esses especialistas são a priori menores em ordens de grandeza do que os especialistas em Excel. O Excel tem apenas possibilidades limitadas, mas não o ocorre com o Power BI, que usa a linguagem de fórmula DAX, que é muito semelhante à linguagem de fórmula do Excel e é capaz de processar milhões e dezenas de milhões de registros em tempo real. E então você precisa aumentar a RAM (pelo menos até 100, pelo menos até 300 GB).

Ajudamos as solicitações de processos de suporte técnico

Mas voltando à minha tarefa. Era necessário apresentar como a linha zero do suporte técnico avaliaria automaticamente o tópico de solicitações do usuário. Para começar, decidi isolar certas formas de palavras e determinar os tópicos mais importantes que os usuários abordam com mais frequência pela frequência em que aparecem nas mensagens.

O dicionário de origem é um arquivo de texto simples que possui uma estrutura regular e se parece com isso:



Para fins estatísticos, foi necessário determinar a forma inicial para cada forma de palavra: para substantivos - um único número do caso nominativo, para verbos - uma forma indefinida, etc. Para programadores, essa tarefa era mais simples que simples: para cada palavra na coluna da esquerda, encontre a correspondência com o formulário que segue imediatamente o número dessa palavra no dicionário.

Esse é apenas o usuário médio de negócios que não possui Python, ferramentas especializadas e habilidades de desenvolvimento, não será capaz de resolver esse problema sem usar o BI de auto-analítica ou ferramentas semelhantes amigáveis ​​ao usuário. Além disso, se os dados precisarem ser processados ​​para suas necessidades internas ou se não houver informações confidenciais que exijam proteção, o Power BI também será gratuito *.


Para analisar os dados, eu precisava no Power Query, em uma tabela de 5 milhões de registros, adicionar uma nova coluna, deslocada por uma posição. Inicialmente, tentei aplicar a abordagem clássica usando o Power Query, descrito no portal da comunidade do Power BI por Marcel Beug, autor do guia de referência on-line original do Power Query (também escrito em Power Query). Dois algoritmos diferentes são propostos no artigo: um é inspirado nas idéias de Matt Elington, um famoso guru e instrutor do Power BI, e a segunda abordagem é a ideia original do próprio Marcel, usando uma função adicional. Apesar do fato de que, para aumentar a produtividade, eu armazenei em cache completamente os dados de origem, as duas abordagens exigiram uma quantidade gigantesca de tempo - elas já haviam passado o oitavo dia e o processo não havia sido concluído. O tamanho do arquivo de origem era 270 MB e o tamanho atual dos dados processados ​​era próximo a 17 TB. Tenho certeza de que poucos usuários do Power BI viram esses números na janela para carregar dados de uma fonte de arquivo.



Por que o volume está tão inchado, não está claro; até o produto cartesiano de todos os registros é muito inferior a 16 TB. Aqui, o otimizador interno claramente não estava à altura. E, por exemplo, o DAX-Studio não permite rastrear consultas do Power Query, apenas o DAX. Talvez alguém compartilhe sua experiência com o PQ Troubleshipping?

Sem esperar pela conclusão do primeiro processo, decidi em outra máquina tentar resolver o problema usando o DAX por meio de uma consulta auto-escrita. A solicitação foi atendida ... em cerca de 180 segundos e o consumo de memória aumentou ligeiramente.



Código-fonte para uma solicitação DAX:

KeyWord =
CALCULATE(
TOPN(1;
CALCULATETABLE(
VALUES(ShiftedList[Word])
;ALLEXCEPT(ShiftedList;ShiftedList[Word Nr])
)
)//TOPN
)//CALCULATE



Ou seja, para cada linha na nova coluna [KeyWord], é pesquisado o primeiro valor da coluna [Word], contendo todas as variantes de formas de palavras com o mesmo número básico de formas de palavras (coluna [Word Nr]). Enquanto o formato do arquivo de origem permanecer inalterado, a solicitação deverá ser atendida sem erros em todas as versões subseqüentes do dicionário.

O código de consulta no Power Query, que forma a tabela de origem no formato necessário, foi gerado "automaticamente" e concluído em menos de um minuto:



Após a formação de uma coluna de palavras-chave na interface do PowerPivot em três minutos, a pesquisa de quaisquer formulários de palavras na interface do Power BI leva não mais que 4 segundos. Além disso, uma pesquisa de controle pelos mesmos dados no seu Notepad ++ x64 favorito pode levar 20 segundos ou mais. Mas isso não é uma pedra no jardim da NPP - é mais difícil (e mais longo) pesquisar em toda a matriz de dados do que de acordo com os dados já marcados.

A propósito, a solicitação DAX acima não nasceu da primeira vez e as opções intermediárias consumiram toda a memória disponível, funcionaram por um longo tempo e terminaram com um erro de dados ou um resultado irrelevante.



Como resultado, o tamanho do arquivo PBIX salvo ficou 60% (112 MB) menor que o dicionário de texto original, mas mais de 4 vezes o tamanho do arquivo ZIP com o mesmo dicionário.

Voltando à batalha entre o Power Query e o DAX: a diferença na duração da mesma operação em diferentes componentes sugere que o Power BI não é um pé de cabra contra o qual não há recepção. Ele tem seu próprio caráter e características do aplicativo, que devem ser levados em consideração em seu trabalho. Na verdade, como qualquer ferramenta. E as recomendações de até gurus reconhecidos devem ser tratadas com cautela.

Parece que Richard Smalley, ganhador do Prêmio Nobel, costumava dizer, parafraseando a primeira lei de Clark: “Quando os especialistas dizem que algo é viável, provavelmente estão certos (eles simplesmente não sabem quando). Quando eles dizem que isso é impossível, provavelmente estão enganados. "

Características da máquina de teste:
Processador: Intel Core i7 4770 a 3,4 GHz (4 núcleos)
RAM: 16 GB
SO: Windows 7 Enterprise SP1 x64

O dicionário pronto no formato do Power BI pode ser baixado aqui .

E aqui está disponível uma versão online modificada do dicionário. Você pode resolver palavras cruzadas como quiser :)



... Aliás, há vários anos, a tarefa foi resolvida no Excel, embora não 100%. Apenas para a análise dos textos, não foi utilizado todo o corpus da língua russa, mas o dicionário de frequências. Para a limpeza básica de texto, qualquer uma das listas de frequências top100 disponíveis aqui para várias dezenas de kilobytes é bastante adequada.

Yuri Kolmakov, Especialista, Departamento de Sistemas de Consolidação e Visualização de Dados, Jet Infosystems ( McCow )