Especialista em bases de dados lista quais áreas da indústria da computação seriam positivamente impactadas pelas padronizações
Rohit Jain, especialista em bases de dados, comentou recentemente sobre a importância de padrões para a indústria da computação. A padronização é o que permite com que aprendizados sejam utilizados em diferentes soluções, permite o trabalho conjunto de diferentes tecnologias, aumenta as aplicabilidades e oferece subcomponentes que aceleram a construção de soluções.
No entanto, Jain afirma que pouco foi feito para padronizar as tecnologias do big data até o momento. Logo, ele sugere quais áreas seriam positivamente impactadas por padronizações: streaming, interfaces do mecanismo de armazenamento, query, benchmarking, segurança e governança, administração dos metadados, implantação e, por fim, integração com outras tecnologias emergentes. Confira em detalhes a seguir.
Streaming
O big data surgiu com a chegada de dados de streaming em alto volume e alta velocidade. Vários produtos, proprietários e open source, oferecem soluções para processar dados de streaming. Amazon Web Services, Azure, Kafka, Pulsar, Storm, Spark, Samza e inúmeras outras ferramentas contribuíram com a Apache Foundation. No entanto, cada produto tem sua própria interface. Diferente do SQL, não há padrões de API ou interface para lidar com esses dados – ainda que o Apache esteja promovendo uma meta-interface chamada Beam.
Além disso, desenvolvedores de aplicativos da Internet das Coisas (Internet of Things) têm dificuldade em alavancar essas tecnologias de maneira intercambiável e portátil, de maneira que não fiquem presas por interfaces proprietárias. São essencialmente os mesmos princípios orientadores que estavam por trás dos padrões ANSI SQL.
Interfaces do mecanismo de armazenamento
A proliferação de um grande número de mecanismos de armazenamento NoSQL – tais como CouchDB, Cassandra, HBase e MongoDB – trouxe uma infinidade de APIs incompatíveis. Além disso, novos tipos de aplicação requerem uma mudança de mentalidade radical sobre o processamento de dados. Por exemplo, em relação ao armazenamento de documentos (JSON deve se tornar o formato predominante de troca de dados) e bancos de dados gráficos (tais como Gremlin, SPARQL e Cypher, interfaces para Neo4J, JanusGraph e outros). Sistemas GIS fornecem um modelo muito diferente para interação com sua forma complexa de dados. Apache Lucene e mecanismos de pesquisa relacionados também são únicos no que tange suas capacidades abrangentes.
Outro problema é que as aplicações não conseguem mudar seus mecanismos de armazenamento, caso necessário. Além disso, máquinas de query SQL, como Apache Trafodion, EsgynDB, Apache Spark, Apache Hive e Apache Impala deveriam interagir independentemente com cada máquina de armazenamento.
Assim como ODBC e JDBC facilitaram o desenvolvimento de muitas ferramentas de BI e ETL que trabalham com qualquer banco de dados, uma interface padrão facilitaria o acesso em qualquer uma dessas máquinas de armazenamento. Ainda por cima, isso expandiria substancialmente o ecossistema de soluções que poderia ser utilizado.
Por fim, embora o paralelismo seja importante para o fluxo de dados entre query e armazenamento, ele ainda não foi facilitado por nenhuma interface padrão. O particionamento pode variar durante esses fluxos.
Query
Os modelos de dados suportados por bancos NoSQL diferem tanto quanto suas interfaces. O principal padrão com alguma aplicabilidade para big data é o ANSI SQL. Embora tenha sido explicitamente rejeitado na primeira década dos anos 2000 por muitos dos bancos de dados NoSQL, ele tem sido adotado por muitos deles como uma API alternativa. Isso por causa de sua prevalência, sua familiaridade entre os desenvolvedores e por todo o ecossistema que o suporta.
O SQL ainda está evoluindo e está fazendo um trabalho confiável ao lidar com os desafios do big data. Por exemplo, o acréscimo do suporte para JSON e funções Table Valued no padrão 2016. Porém, mesmo o SQL não é capaz de acompanhar todas as mudanças do big data, uma vez que padronizações exigem muita colaboração, deliberação e esforço em prol de acertos e definições.
Dois outros padrões familiares no mundo dos bancos de dados relacionais – ODBC e JDBC – não sofrem grandes mudanças há algum tempo. Especialmente em razão das necessidades do big data em relação ao paralelismo de grandes volumes de dados, a variedade das estruturas e modelos e a mudança de paradigma da velocidade de transmissão.
O padrão SQL precisa evoluir para suportar:
-
Dados de streaming;
-
Interfaces de publicação/assinatura;
-
Funções window nos streams;
-
Gatilhos de tempo, contagem e conteúdo;
-
Janelas de queda, deslizamento e sessão;
-
Processamentos de evento versus tempo;
-
Regras para unir streaming de dados;
-
Interfaces para soluções sofisticadas de pesquisa;
-
Interfaces para sistemas GIS;
-
Interfaces para bancos de dados gráficos, para que os usuários possam enviar queries padrão e mapear os resultados em um formato tabular, semelhante ao elegante mapeamento JSON-para-relacional do padrão ANSI SQL 2016 para JSON.
Benchmarks
Os workloads para big data abrangem streaming, operacional, relatórios, queries ad hoc e análises. Muitos deles têm características de tempo real, quase tempo real, batch e interatividade. Atualmente, nenhum benchmarking avalia a relação de preço e desempenho desses processamentos de workload híbridos – operacionais e analíticos. Muitos fornecedores alegam oferecer suporte para essas cargas de trabalho variadas, mas faltam definições e não há benchmarking para testá-las.
Para avaliar produtos de big data potenciais, a maioria dos clientes recorre aos benchmarkings criados pelo Transaction Processing Performance Council (TPC). O padrão TPC-DS, criado para avaliar workloads de análise e de BI, ofereceu uma promessa considerável. No entanto, essa promessa foi subvertida de duas maneiras. Primeiro, os fornecedores apresentam aos clientes versões alteradas do benchmarking, distorcidas para favorecer o produto do fornecedor. Muitos dos resultados do TPC-DS compartilhados pelos fornecedores não levam em consideração o uso comum, incluindo queries e outros workloads executados com diferentes níveis de simultaneidade, na escala do big data, conforme descrito na especificação. Em segundo lugar, ao contrário da maioria dos padrões TPC, o TPC-DS nunca foi reforçado por resultados auditados, que permitam aos clientes avaliar a relação de preço e desempenho.
Segurança e governança
Há várias infraestruturas de segurança e governança para implantações de big data. Por exemplo, o ambiente do Hadoop tem o Apache Ranger e o Apache Sentry. Cada provedor de nuvem tem informações de segurança e sistemas de gerenciamento de eventos. A integração desses ambientes com aplicações e provedores de soluções é difícil porque, novamente, cada implementação tem uma API diferente.
Padronizar a API para administração e monitoramento da segurança seria muito benéfico. Isso permitiria com que empresas usassem mecanismos padrão para configurar e reforçar a segurança. Esses padrões permitiriam com que mais soluções fossem usadas nesses sistemas de segurança. Pense na integração de eventos cruciais de segurança através de várias fontes de dados corporativos. Se os produtos de segurança usassem uma API padrão, seria muito mais fácil para eles interagirem com qualquer fonte de dados, e o cliente teria mais opções e flexibilidade. O mesmo se aplica à implantação de privilégios de função e de usuário de fontes de dados corporativas.
Ainda mais conveniente seria o cenário no qual os dados são movidos para outro sistema de armazenamento ou são acessados por outro subsistema. Os direitos de acesso poderiam ser movidos automaticamente e sem esforços do SysAdmin, de maneira que as mesmas pessoas ainda tivessem acesso aos mesmos campos e linhas, independentemente das ferramentas que foram usadas para acessar os dados.
Administração dos metadados
Com a proliferação de dados por vários mecanismos de armazenamento, os metadados precisam de um repositório central. Não importa se uma tabela está em HBase, ORC, Parquet ou Trafodion, se ela fosse registrada em um conjunto de tabelas de metadados, o acesso para as ferramentas clientes seria muito mais fácil. Seria um grande avanço em relação à situação atual, na qual clientes precisam se conectar com diferentes tabelas de metadados.
O objetivo aqui é padronizar o esquema de informações para essas ferramentas clientes e centralizar toda a administração de segurança. Isso apresentaria uma visão generalizada de todos os objetos do banco de dados.
Ampliar esses metadados com informações de negócios nos objetos facilitaria a governança e a linhagem de dados e substituiria a necessidade de fornecer esses serviços repetidamente em diferentes repositórios de metadados. Isso facilitaria o gerenciamento de metadados e de dados mestres.
Implantação
Atualmente, cada provedor de nuvem exige uma maneira própria para provisionar, configurar, monitorar e gerenciar um banco de dados e seus recursos. Assim, caso um cliente queira alterar provedores de nuvem ou queira fazer com que bancos de dados de provedores diferentes trabalhem juntos, ele deve alterar todos os procedimentos e scripts. Aliás, talvez tenha que alterar muito mais.
Um conjunto padrão de APIs facilitaria essa tarefa, não importa se o cliente estivesse implantando o banco de dados em uma nuvem pública, privada ou híbrida. Embora padrões já tenham sido propostos, ainda não foram bem-sucedidos no mercado. Por exemplo, o OpenStack tem interfaces de código aberto, orientadas para a comunidade, para muitas dessas tarefas, mas elas não obtiveram adoção entre os serviços escolhidos pela maioria dos clientes (Amazon.com, Google, Microsoft Azure). O VMware definiu um padrão para vSphere há alguns anos, mas é quase completamente ignorado.
Serviços comparáveis de provedores de nuvem também deveriam ser padronizados. Por exemplo, uma aplicação que precisa de armazenamento de objetos, como AWS S3 ou Azure Blob, deveria conseguir acesso por meio de uma interface padrão.
Integração com outras tecnologias emergentes
Também é importante pensar em como padronizar a integração entre bancos de dados e novas tecnologias. Por exemplo, algoritmos de machine learning, ferramentas como TensorFlow e R, bibliotecas Python, análise de dados não estruturados como análise de sentimento, processamento de imagens, processamento de linguagem natural (NLP), blockchain etc. Hoje, cada solução nessas áreas tem uma interface única. Portanto, integrá-las ao banco de dados é sempre um esforço customizado.
Enquanto funções definidas pelo usuário e pelo usuário da tabela não possuírem bons padrões, não será possível que um banco de dados chame funções definidas pelo usuário – ou mesmo procedimentos armazenados – que tenham sido escritas para outro banco de dados. Seria muito mais eficaz se os usuários pudessem usar uma grande biblioteca de UDFs, desenvolvida para qualquer banco de dados, como uma tecnologia plug-and-play. Essa biblioteca também forneceria aos desenvolvedores dessas funções uma grande base de clientes onde suas funções poderiam ser implantadas.
Conclusão
Segundo Rohit Jain, a implantação de ferramentas de big data está sendo retida pela falta de padrões nas áreas listadas. O desenvolvimento desses padrões não impediria a inovação ou que fornecedores oferecessem soluções exclusivas. Pelo contrário, o caso do ANSI SQL mostra como uma padronização facilitou o crescimento substancial de um grande número de soluções de banco de dados.
Um aspecto importante dos padrões é garantir compliance. O Instituto Nacional de Padrões e Tecnologia (NIST) do Departamento de Comércio dos EUA fez isso com o SQL. Embora o padrão SQL tenha uma adoção admiravelmente ampla, isso não garante uma interoperabilidade tranquila. Em primeiro lugar, o SQL evoluiu e os fornecedores podem escolher qual versão do padrão querem seguir. Mesmo assim, o quanto da versão eles aderem não é claro sem uma certificação. Em segundo lugar, são oferecidos vários aprimoramentos fora do padrão.
Algumas das áreas listadas podem fornecer mais valor para usuários e provedores. Uma definição de prioridades para determinar qual padrão forneceria o maior valor, com base na contribuição de usuários e da comunidade de fornecedores, poderia ajudar na orientação dos esforços para desenvolver padrões.
Esses esforços poderiam ser facilitados por meio de novos órgãos de padronização ou com cooperação e tutela de órgãos existentes – ANSI, ISO, TPC e W3C. Os membros do comitê dessas organizações têm uma tremenda experiência no desenvolvimento de excelentes padrões. Eles sabem lidar habilidosamente com a obtenção de consenso entre participantes que, de outra forma, competiriam. Entretanto, Jain afirma que usuários finais e fornecedores são figuras centrais na pressão que pode culminar no estabelecimento dessas padronizações.
