Na SciCrop temos trabalhado fundamentalmente com Python e Java no backend. Ambas linguagens também são usadas para Data Science, Machine Learning e Geo Analytics. Mas é claro que a prototipação em Python tem sido muito mais veloz. Em uma ocasião prototipamos uma solução com NLP que não teve comparativos, se fôssemos usar Java (o que não é nenhum demérito para o Java).
O louvor ao Pandas
Mas além da SciCrop, e bem antes dela, vimos eu e o David Kwast nosso CTO, a evolução do Python nos últimos 15 anos e percebemos como a adoção da linguagem cresceu, muito impulsionada por análise de dados, mesmo durante o hype do R. E ficou óbvio como o Pandas de Wes McKinney teve parte importantíssima em trazer pessoas para o Python.
Quando escutamos as experiências de pessoas como nosso cientista de dados Willian Wayn, que é Físico por formação, e como ele veio desde a universidade resolvendo suas demandas de dados com Python e muito Pandas, fica até difícil criticar o Pandas. Mas não podemos esconder o sol com a peneira:
Não é um algoritmo de analytics, é só mais um pedaço de software
Ao escrever algoritmos em Python, estamos escrevendo software. E todo software tem um ciclo de vida. Você pode escrever seu script no Jupyter Notebook apenas para refutar ou provar uma tese de dados, e fazê-lo temporariamente. Nesse caso você ingere os dados de entrada como data frames e faz toda sanitização, normalização e agrupamento usando as funções booleanas e condicionais que o Pandas oferece e vai adiante com sua análise até ser bem sucedido. Para esta situação o Pandas parece adequado, mesmo com problemas de documentação, performance e indexação. Afinal o resultado final é o objetivo. Mas o que acontece quando esse script no Jupyter prova sua tese e você percebe que o ideal seria rodá-lo recorrentemente?
Tudo tem um ciclo de vida
Nessa hipótese o ciclo de vida do seu software mudou. Não é mais algo temporário. E se é recorrente, o montante de dados aumentará pelo simples fato de ser rodado várias vezes. A performance poderá agora começar a se tornar um problema, além de que variações nos tipos de entrada de dados, farão que seu data frame seja revisitado. Aí o cientista de dados perderá cada vez mais tempo na complexidade das características do data frame, e isso afetará o resultado da análise de dados. Mas por que isso acontece? O Pandas é ruim?
A crítica
Não, o Pandas não é ruim. Ele é apenas imaturo. Sua versão atual é a 0.25, ele tem um longo caminho pela frente, e esperamos que seja de sucesso. Mas não é só isso, as funcionalidades do Pandas acabam por reinventar a roda de processos tradicionais de ETL, modelagem de dados, e objetos relacionais. Três disciplinas que infelizmente tem sido ignoradas pelos novos cientistas de dados, que se apaixonam pela “facilidade” que o Pandas traz. Essa “facilidade” acaba por representar verborragia no código, com difícil controle de exceções (dada a natureza ainda inicial do Pandas e de como ele executa suas funções internamente e como ele interpreta os erros). Não é incomum trocarmos os dataframes e seus merges e demais funções, por dicionários e até mesmo consultas SQL. Nesse sentido a crítica é simples, o Pandas não deve querer abraçar o mundo de estruturas de dados, já existentes e maduras, nem por seus criadores, nem por seus usuários.
Exemplo: Se você perceber que está muito difícil de usar dados de data frames no Numpy, já é um indicativo que a facilidade do Pandas não valeu a pena.
Liberdade em primeiro lugar
Na SciCrop, você resolve seu problema inicial na linguagem em que for mais eficiente (Desde que seja Python, o David Kwast diria). Brincadeiras à parte, o importante é resolver o problema de maneira autônoma. É a partir do momento que o problema de dados está resolvido que entramos com as questões arquiteturais. É aí que analisamos o ciclo de vida ideal que o software terá quando entregue. Na grande maioria dos casos toda tarefa de analytics, data science ou machine learning, entrará como parte de um engine, que rodará em um servidor indefinidamente. Então é preciso dividir o problema em componentes, um para coleta, normalização e armazenamento (e aí tem que escolher, será NO-SQL, SQL, Map Reduce?), essa parte deve ser isolada, após isso é necessário outro componente de pré-processamento de dados, responsável pela preparação dos dados que serão analisados em grupos e categorizações que se adequem melhor a um processamento eficiente. Posteriormente dois outros componentes são normalmente necessários o do processamento e análise propriamente dita, que não poderá ser condicionada pelo modelo de dados (o que comumente acontece com o Pandas) ou seja, o modelo de dados não poderá impedir técnicas de processamento distribuído e de alta performance como, por exemplo, de multi-threading. O último componente é o de pós-processamento, responsável pela entrega do resultado final, no modelo ou estrutura desejada, com acionamento de gatilhos lógicos, se necessário.
Acontece então que o protótipo inicial no Jupyter se transformou em um software robusto e resistente. Muitas vezes o software se aproveita de componentes já escritos, ou se transforma em um módulo ou biblioteca.
Na SciCrop nós não afastamos o cientista de dados de todos esse processo de arquitetura e componentização, inclusive a cada iteração, vemos que o cientista de dados amadurece nas escolhas iniciais do seu protótipo e ele mesmo passa logo de início a trazer uma conscientização de integração contínua e DevOps desde o início de um projeto, mesmo que ele seja temporário.
Conclusão
No fim das contas acreditamos que existam duas mensagens: O Pandas não é pra tudo, olhe ao redor e veja o que já existe, sua facilidade inicial pode custar caro, se sua solução for crescer e ser reutilizada; O cientista de dados, precisa entender e descer do salto, ele não deixa de ser um programador, e portanto, precisa entender que as disciplinas de engenharia de software são tão importantes quanto as de análise de dados.
É claro que podemos estar errados, mas talvez não haja saída para o pensamento de Wes McKinney: “Scientists unnecessarily dealing with the drudgery of simple data manipulation tasks makes me feel terrible“, Talvez ele se sentirá terrível e talvez os cientistas terão que aprender a trabalhar melhor com manipulação de dados. Ou talvez não exista mesmo “simple data manipulation“, e tudo cedo ou tarde será complexo.
