🥇Usando low-code em plataformas analíticas

Caros leitores, bom dia!

A tarefa de construir plataformas de TI para coletar e analisar dados, mais cedo ou mais tarde, surge para qualquer empresa cujo negócio se baseia em um modelo de prestação de serviços carregado de inteligência ou na criação de produtos tecnicamente complexos. Construir plataformas analíticas é uma tarefa complexa e demorada. No entanto, qualquer tarefa pode ser simplificada. Neste artigo quero compartilhar minha experiência no uso de ferramentas de low-code para ajudar a criar soluções analíticas. Essa experiência foi adquirida durante a implantação de diversos projetos na direção de Big Data Solutions da empresa Neoflex. Desde 2005, a direção de Big Data Solutions da Neoflex vem tratando das questões de construção de data warehouses e lagos, resolvendo problemas de otimização da velocidade de processamento da informação e trabalhando em uma metodologia de gestão da qualidade dos dados.

Ninguém será capaz de evitar a acumulação consciente de dados fracamente e/ou fortemente estruturados. Talvez até mesmo se estivermos falando de pequenas empresas. Afinal, ao escalar um negócio, um empreendedor promissor se deparará com as questões de desenvolver um programa de fidelidade, desejará analisar a eficácia dos pontos de venda, pensará em publicidade direcionada e ficará intrigado com a demanda por produtos acompanhantes. . Numa primeira aproximação, o problema pode ser resolvido “na altura do joelho”. Mas à medida que o negócio cresce, chegar a uma plataforma analítica ainda é inevitável.

No entanto, em que caso as tarefas de análise de dados podem evoluir para problemas de classe “Rocket Science”? Talvez no momento em que estamos falando de big data.
Para facilitar a Rocket Science, você pode comer o elefante pedaço por pedaço.

Quanto mais discretos e autônomos forem seus aplicativos/serviços/microsserviços, mais fácil será para você, seus colegas e toda a empresa digerir o elefante.

Quase todos os nossos clientes chegaram a esse postulado, tendo reconstruído o cenário com base nas práticas de engenharia das equipes DevOps.

Mas mesmo com uma dieta “separada e elefantina”, temos boas chances de “saturação excessiva” do cenário de TI. Nesse momento vale parar, expirar e olhar para o lado plataforma de engenharia de baixo código.

Muitos desenvolvedores ficam assustados com a perspectiva de um beco sem saída em suas carreiras ao deixar de escrever código diretamente e passar a “arrastar” setas nas interfaces de UI de sistemas de baixo código. Mas o advento das máquinas-ferramentas não levou ao desaparecimento dos engenheiros, mas elevou o seu trabalho a um novo patamar!

Vamos descobrir o porquê.

A análise de dados na área de logística, indústria de telecomunicações, pesquisa de mídia, setor financeiro está sempre associada às seguintes questões:

Velocidade de análise automatizada;
Capacidade de realizar experimentos sem afetar o fluxo principal de produção de dados;
Confiabilidade dos dados preparados;
Rastreamento de alterações e versionamento;
Proveniência de dados, linhagem de dados, CDC;
Entrega rápida de novas funcionalidades ao ambiente de produção;
E o notório: o custo de desenvolvimento e suporte.

Ou seja, os engenheiros têm um grande número de tarefas de alto nível, que só podem ser concluídas com eficiência suficiente limpando sua consciência das tarefas de desenvolvimento de baixo nível.

Os pré-requisitos para que os desenvolvedores passassem para um novo patamar eram a evolução e a digitalização dos negócios. O valor do desenvolvedor também está mudando: há uma escassez significativa de desenvolvedores que possam mergulhar nos conceitos do negócio que está sendo automatizado.

Vamos fazer uma analogia com linguagens de programação de baixo e alto nível. A transição de linguagens de baixo nível para linguagens de alto nível é uma transição da escrita de “diretivas diretas na linguagem do hardware” para “diretivas na linguagem das pessoas”. Ou seja, adicionando alguma camada de abstração. Neste caso, a transição para plataformas de baixo código a partir de linguagens de programação de alto nível é uma transição de “diretivas na linguagem das pessoas” para “diretivas na linguagem dos negócios”. Se há desenvolvedores que estão tristes com esse fato, então eles estão tristes, talvez, desde o momento em que nasceu o Java Script, que usa funções de classificação de array. E essas funções, é claro, têm implementação de software subjacente por outros meios da mesma programação de alto nível.

Portanto, low-code é apenas a aparência de outro nível de abstração.

Experiência aplicada usando low-code

O tema low-code é bastante amplo, mas agora gostaria de falar sobre a aplicação prática dos “conceitos de low-code” usando o exemplo de um de nossos projetos.

A divisão Big Data Solutions da Neoflex é mais especializada no setor financeiro de negócios, construindo data warehouses e lagos e automatizando diversos relatórios. Nesse nicho, o uso de low-code já se tornou um padrão. Entre outras ferramentas de low-code, podemos citar ferramentas para organização de processos ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Ou o Oracle Apex, que atua como ambiente para o rápido desenvolvimento de interfaces de acesso e edição de dados. No entanto, a utilização de ferramentas de desenvolvimento low-code nem sempre envolve a construção de aplicações altamente direcionadas numa pilha de tecnologia comercial com uma clara dependência do fornecedor.

Usando plataformas low-code, você também pode organizar a orquestração de fluxos de dados, criar plataformas de ciência de dados ou, por exemplo, módulos para verificação de qualidade de dados.

Um dos exemplos aplicados de experiência no uso de ferramentas de desenvolvimento low-code é a colaboração entre a Neoflex e a Mediascope, uma das líderes no mercado russo de pesquisa de mídia. Um dos objetivos de negócio desta empresa é a produção de dados com base nos quais anunciantes, plataformas de Internet, canais de televisão, estações de rádio, agências de publicidade e marcas tomam decisões sobre a compra de publicidade e planeiam as suas comunicações de marketing.

A pesquisa de mídia é uma área de negócios carregada de tecnologia. Reconhecer sequências de vídeo, coletar dados de dispositivos que analisam a visualização, medir a atividade em recursos web - tudo isso implica que a empresa possua uma grande equipe de TI e enorme experiência na construção de soluções analíticas. Mas o crescimento exponencial da quantidade de informação, do número e da variedade das suas fontes obriga a indústria de dados de TI a progredir constantemente. A solução mais simples para dimensionar a plataforma analítica Mediascope já em funcionamento poderia ser aumentar a equipe de TI. Mas uma solução muito mais eficaz é acelerar o processo de desenvolvimento. Um dos passos nessa direção pode ser o uso de plataformas de baixo código.

No momento do início do projeto, a empresa já tinha uma solução de produto funcional. No entanto, a implementação da solução em MSSQL não conseguiu satisfazer plenamente as expectativas de dimensionamento da funcionalidade, mantendo ao mesmo tempo um custo de desenvolvimento aceitável.

A tarefa que tínhamos diante de nós era verdadeiramente ambiciosa - a Neoflex e a Mediascope tiveram que criar uma solução industrial em menos de um ano, sujeita ao lançamento do MVP no primeiro trimestre da data de início.

A pilha de tecnologia Hadoop foi escolhida como base para a construção de uma nova plataforma de dados baseada em computação low-code. O HDFS se tornou o padrão para armazenamento de dados usando arquivos parquet. Para acessar os dados localizados na plataforma foi utilizado o Hive, no qual todas as vitrines disponíveis são apresentadas em forma de tabelas externas. O carregamento de dados no armazenamento foi implementado usando Kafka e Apache NiFi.

A ferramenta Lowe-code neste conceito foi usada para otimizar a tarefa mais trabalhosa na construção de uma plataforma analítica - a tarefa de cálculo de dados.

A ferramenta low-code Datagram foi escolhida como principal mecanismo de mapeamento de dados. Datagrama Neoflex é uma ferramenta para desenvolver transformações e fluxos de dados.
Usando esta ferramenta, você pode fazer isso sem escrever o código Scala manualmente. O código Scala é gerado automaticamente usando a abordagem Model Driven Architecture.

Uma vantagem óbvia desta abordagem é acelerar o processo de desenvolvimento. Porém, além da rapidez, também existem as seguintes vantagens:

Visualização do conteúdo e estrutura das fontes/receptores;
Rastrear a origem dos objetos de fluxo de dados até campos individuais (linhagem);
Execução parcial de transformações com visualização de resultados intermediários;
Revisar o código fonte e ajustá-lo antes da execução;
Validação automática de transformações;
Download automático de dados 1 em 1.

A barreira de entrada em soluções low-code para geração de transformações é bastante baixa: o desenvolvedor precisa conhecer SQL e ter experiência em trabalhar com ferramentas ETL. Vale ressaltar que os geradores de transformação orientados por código não são ferramentas ETL no sentido amplo da palavra. As ferramentas de baixo código podem não ter seu próprio ambiente de execução de código. Ou seja, o código gerado será executado no ambiente que existia no cluster antes mesmo da instalação da solução low-code. E esta é talvez outra vantagem para o carma de baixo código. Pois, paralelamente a uma equipe de low-code, pode trabalhar uma equipe “clássica” que implementa funcionalidades, por exemplo, em código Scala puro. Trazer melhorias de ambas as equipes para a produção será simples e contínuo.

Talvez valha a pena notar que, além do low-code, também existem soluções sem código. E, no fundo, são coisas diferentes. O low-code permite que o desenvolvedor interfira mais no código gerado. No caso do Datagrama, é possível visualizar e editar o código Scala gerado; no-code pode não fornecer tal oportunidade. Esta diferença é muito significativa não só em termos de flexibilidade da solução, mas também em termos de conforto e motivação no trabalho dos engenheiros de dados.

Arquitetura da solução

Vamos tentar descobrir exatamente como uma ferramenta de baixo código ajuda a resolver o problema de otimização da velocidade de desenvolvimento da funcionalidade de cálculo de dados. Primeiro, vejamos a arquitetura funcional do sistema. Um exemplo neste caso é o modelo de produção de dados para pesquisa de mídia.

As fontes de dados no nosso caso são muito heterogêneas e diversas:

Os medidores de pessoas (medidores de TV) são dispositivos de software e hardware que leem o comportamento do usuário dos entrevistados do painel de televisão - quem, quando e qual canal de TV foi assistido no domicílio que participa do estudo. A informação fornecida é um fluxo de intervalos de visualização de transmissão vinculados ao pacote de mídia e ao produto de mídia. Os dados na fase de carregamento no Data Lake podem ser enriquecidos com atributos demográficos, geoestratificação, fuso horário e outras informações necessárias para analisar a visualização televisiva de um determinado produto de mídia. As medições realizadas podem ser utilizadas para analisar ou planejar campanhas publicitárias, avaliar a atividade e preferências do público e compilar a rede de transmissão;
Os dados podem vir de sistemas de monitoramento de streaming de transmissões televisivas e de medição da visualização de conteúdo de recursos de vídeo na Internet;
Ferramentas de medição no ambiente web, incluindo medidores centrados no site e centrados no usuário. O provedor de dados para o Data Lake pode ser um complemento do navegador da barra de pesquisa e um aplicativo móvel com VPN integrada.
Os dados também podem vir de sites que consolidam os resultados do preenchimento de questionários online e dos resultados de entrevistas telefônicas em pesquisas empresariais;
O enriquecimento adicional do data lake pode ocorrer através do download de informações de logs de empresas parceiras.

A implementação do carregamento conforme está dos sistemas de origem na preparação primária de dados brutos pode ser organizada de várias maneiras. Se low-code for usado para esses fins, é possível a geração automática de scripts de carregamento com base em metadados. Neste caso, não há necessidade de descer ao nível de desenvolvimento de mapeamentos de origem para destino. Para implementar o carregamento automático, precisamos estabelecer uma conexão com a fonte, e então definir na interface de carregamento a lista de entidades a serem carregadas. A estrutura de diretórios no HDFS será criada automaticamente e corresponderá à estrutura de armazenamento de dados no sistema de origem.

No entanto, no contexto deste projeto, decidimos não utilizar esta funcionalidade da plataforma low-code devido ao facto de a empresa Mediascope já ter começado a trabalhar de forma independente na produção de um serviço semelhante utilizando a combinação Nifi + Kafka.

Vale ressaltar desde já que essas ferramentas não são intercambiáveis, mas sim complementares. Nifi e Kafka são capazes de trabalhar tanto em conexão direta (Nifi -> Kafka) quanto reversa (Kafka -> Nifi). Para a plataforma de pesquisa de mídia, foi utilizada a primeira versão do pacote.

No nosso caso, a NayFi precisava processar vários tipos de dados dos sistemas de origem e enviá-los ao corretor Kafka. Nesse caso, as mensagens foram enviadas para um tópico específico do Kafka usando processadores PublishKafka Nifi. A orquestração e manutenção desses pipelines são realizadas em uma interface visual. A ferramenta Nifi e o uso da combinação Nifi + Kafka também podem ser chamados de abordagem de desenvolvimento low-code, que apresenta baixa barreira de entrada em tecnologias de Big Data e acelera o processo de desenvolvimento de aplicações.

A próxima etapa da implementação do projeto foi trazer dados detalhados para um formato de camada semântica única. Se uma entidade possuir atributos históricos, o cálculo é realizado no contexto da partição em questão. Se a entidade não for histórica, então é opcionalmente possível recalcular todo o conteúdo do objeto ou recusar completamente o recálculo deste objeto (devido à falta de alterações). Nesta fase, são geradas chaves para todas as entidades. As chaves são armazenadas nos diretórios Hbase correspondentes aos objetos mestres, que contêm uma correspondência entre as chaves da plataforma analítica e as chaves dos sistemas de origem. A consolidação das entidades atômicas é acompanhada pelo enriquecimento com os resultados do cálculo preliminar dos dados analíticos. A estrutura para cálculo de dados foi o Spark. A funcionalidade descrita para trazer dados para uma única semântica também foi implementada com base em mapeamentos da ferramenta Datagrama de baixo código.

A arquitetura de destino exigia acesso SQL aos dados para usuários corporativos. O Hive foi usado para esta opção. Os objetos são registrados no Hive automaticamente quando você habilita a opção “Registr Hive Table” na ferramenta de low-code.

Controle de fluxo de cálculo

Datagram possui uma interface para criar designs de fluxo de fluxo de trabalho. Os mapeamentos podem ser iniciados usando o agendador Oozie. Na interface do desenvolvedor de fluxo, é possível criar esquemas para transformações de dados paralelas, sequenciais ou dependentes de execução. Há suporte para scripts shell e programas java. Também é possível usar o servidor Apache Livy. Apache Livy é usado para executar aplicativos diretamente do ambiente de desenvolvimento.

Caso a empresa já possua seu próprio orquestrador de processos, é possível utilizar a API REST para incorporar mapeamentos em um fluxo existente. Por exemplo, tivemos uma experiência bastante bem-sucedida na incorporação de mapeamentos em Scala em orquestradores escritos em PLSQL e Kotlin. A API REST da ferramenta de baixo código inclui operações como gerar um ano executável com base no design do mapeamento, chamar um mapeamento, chamar uma sequência de mapeamentos e, é claro, passar parâmetros para a URL para executar mapeamentos.

Junto com o Oozie, é possível organizar um fluxo de cálculo usando o Airflow. Talvez eu não me demore muito na comparação entre Oozie e Airflow, mas simplesmente direi que no contexto de trabalho em um projeto de pesquisa de mídia, a escolha recaiu em favor do Airflow. Os principais argumentos desta vez foram uma comunidade mais ativa no desenvolvimento do produto e uma interface + API mais desenvolvida.

O Airflow também é bom porque usa o adorado Python para descrever processos de cálculo. E, em geral, não existem tantas plataformas de gerenciamento de fluxo de trabalho de código aberto. Lançar e monitorar a execução de processos (incluindo um gráfico de Gantt) apenas acrescenta pontos ao carma do Airflow.

O formato do arquivo de configuração para iniciar mapeamentos de soluções de baixo código tornou-se spark-submit. Isso aconteceu por dois motivos. Primeiro, o spark-submit permite executar diretamente um arquivo jar do console. Em segundo lugar, pode conter todas as informações necessárias para configurar o fluxo de trabalho (o que facilita a escrita de scripts que geram Dag).
O elemento mais comum do fluxo de trabalho do Airflow em nosso caso foi o SparkSubmitOperator.

SparkSubmitOperator permite que você execute mapeamentos de datagramas empacotados em jars com parâmetros de entrada pré-gerados para eles.

Vale ressaltar que cada tarefa do Airflow é executada em um thread separado e não sabe nada sobre outras tarefas. Portanto, a interação entre as tarefas é realizada por meio de operadores de controle, como DummyOperator ou BranchPythonOperator.

Em conjunto, a utilização da solução low-code Datagram em conjunto com a universalização dos arquivos de configuração (formando Dag) levou a uma significativa aceleração e simplificação do processo de desenvolvimento de fluxos de carregamento de dados.

Cálculo de vitrine

Talvez a etapa de maior carga intelectual na produção de dados analíticos seja a etapa de construção de vitrines. No âmbito de um dos fluxos de cálculo de dados da empresa de investigação, nesta fase, os dados são reduzidos a uma emissão de referência, tendo em conta correções de fuso horário e ligados à grelha de transmissão. Também é possível ajustar a rede de transmissão local (notícias e publicidade local). Entre outras coisas, esta etapa divide os intervalos de visualização contínua de produtos de mídia com base na análise dos intervalos de visualização. Imediatamente, os valores visualizados são “ponderados” com base nas informações sobre sua significância (cálculo de um fator de correção).

Uma etapa separada na preparação de vitrines é a validação de dados. O algoritmo de validação envolve o uso de vários modelos de ciências matemáticas. No entanto, o uso de uma plataforma de baixo código permite dividir um algoritmo complexo em vários mapeamentos separados e legíveis visualmente. Cada um dos mapeamentos executa uma tarefa restrita. Como resultado, são possíveis depuração intermediária, registro e visualização dos estágios de preparação de dados.

Decidiu-se discretizar o algoritmo de validação nas seguintes subetapas:

Construindo regressões de dependências de visualização de redes de TV em uma região com visualização de todas as redes da região por 60 dias.
Cálculo dos resíduos estudantis (desvios dos valores reais daqueles previstos pelo modelo de regressão) para todos os pontos de regressão e para o dia calculado.
Uma seleção de pares região-rede anômalos, onde o saldo estudantil do dia de liquidação excede a norma (especificada pelas configurações da operação).
Recálculo do resíduo estudantil corrigido para pares anômalos região-rede de TV para cada respondente que assistia à rede na região, determinando a contribuição desse respondente (o valor da variação do resíduo estudantil) ao excluir a visualização desse respondente da amostra .
Procure candidatos cuja exclusão faça com que o saldo estudantil do dia de pagamento volte ao normal.

O exemplo acima confirma a hipótese de que um engenheiro de dados já tem muita coisa em mente... E, se este for realmente um “engenheiro” e não um “codificador”, então o medo da degradação profissional ao usar ferramentas de low-code ele deve finalmente recuar.

O que mais o low-code pode fazer?

O escopo de aplicação de uma ferramenta de baixo código para processamento de dados em lote e fluxo sem a necessidade de escrever código manualmente em Scala não termina aí.

O uso de low-code no desenvolvimento do datalake já se tornou um padrão para nós. Provavelmente podemos dizer que as soluções baseadas na pilha Hadoop seguem o caminho de desenvolvimento dos DWHs clássicos baseados em RDBMS. As ferramentas de baixo código na pilha Hadoop podem resolver tarefas de processamento de dados e de construção de interfaces finais de BI. Além disso, importa referir que BI pode significar não só a representação de dados, mas também a sua edição pelos utilizadores empresariais. Frequentemente utilizamos esta funcionalidade ao construir plataformas analíticas para o setor financeiro.

Entre outras coisas, usando low-code e, em particular, Datagram, é possível resolver o problema de rastrear a origem de objetos de fluxo de dados com atomicidade até campos individuais (linhagem). Para fazer isso, a ferramenta low-code implementa interface com Apache Atlas e Cloudera Navigator. Essencialmente, o desenvolvedor precisa registrar um conjunto de objetos nos dicionários Atlas e referenciar os objetos registrados ao construir mapeamentos. O mecanismo de rastreamento da origem dos dados ou análise de dependências de objetos economiza muito tempo quando é necessário fazer melhorias nos algoritmos de cálculo. Por exemplo, na preparação de demonstrações financeiras, esta funcionalidade permite sobreviver com mais conforto ao período de alterações legislativas. Afinal, quanto melhor entendermos a dependência entre formas no contexto de objetos de uma camada detalhada, menos encontraremos defeitos “repentinos” e reduziremos o número de retrabalhos.

Qualidade de dados e baixo código

Outra tarefa implementada pela ferramenta low-code no projeto Mediascope foi a tarefa da classe Data Quality. Uma característica especial da implementação do pipeline de verificação de dados para o projeto da empresa de pesquisa foi a falta de impacto no desempenho e na velocidade do fluxo principal de cálculo de dados. Para poder orquestrar fluxos independentes de verificação de dados, foi utilizado o já familiar Apache Airflow. À medida que cada etapa da produção de dados ficava pronta, uma parte separada do pipeline DQ era lançada em paralelo.

É considerada uma boa prática monitorizar a qualidade dos dados desde o momento da sua criação na plataforma analítica. Tendo informações sobre os metadados, podemos verificar o cumprimento das condições básicas a partir do momento em que a informação entra na camada primária - não nula, restrições, chaves estrangeiras. Esta funcionalidade é implementada com base em mapeamentos gerados automaticamente da família de qualidade de dados no Datagram. A geração de código, neste caso, também é baseada nos metadados do modelo. No projeto Mediascope a interface foi realizada com os metadados do produto Enterprise Architect.

Ao emparelhar a ferramenta low-code com o Enterprise Architect, as seguintes verificações foram geradas automaticamente:

Verificar a presença de valores “nulos” em campos com o modificador “não nulo”;
Verificar a presença de duplicatas da chave primária;
Verificando a chave estrangeira de uma entidade;
Verificando a exclusividade de uma string com base em um conjunto de campos.

Para verificações mais complexas de disponibilidade e confiabilidade dos dados, foi criado um mapeamento com Scala Expression, que toma como entrada um código de verificação externo Spark SQL preparado por analistas da Zeppelin.

É claro que a geração automática de cheques deve ser alcançada gradualmente. No âmbito do projeto descrito, este foi precedido das seguintes etapas:

DQ implementado em notebooks Zeppelin;
DQ integrado ao mapeamento;
DQ na forma de mapeamentos massivos separados contendo todo um conjunto de verificações para uma entidade separada;
Mapeamentos DQ parametrizados universais que aceitam informações sobre metadados e verificações de negócios como entrada.

Talvez a principal vantagem de criar um serviço de verificação parametrizado seja a redução do tempo necessário para entregar funcionalidades ao ambiente de produção. Novas verificações de qualidade podem contornar o padrão clássico de entrega indireta de código por meio de ambientes de desenvolvimento e teste:

Todas as verificações de metadados são geradas automaticamente quando o modelo é modificado no EA;
As verificações de disponibilidade de dados (determinando a presença de quaisquer dados em um determinado momento) podem ser geradas com base em um diretório que armazena o momento esperado do aparecimento do próximo dado no contexto dos objetos;
As verificações de validação de dados comerciais são criadas por analistas em notebooks Zeppelin. A partir daí eles são enviados diretamente para as tabelas de configuração do módulo DQ no ambiente de produção.

Não há riscos de enviar scripts diretamente para produção. Mesmo com um erro de sintaxe, o máximo que nos ameaça é a falha na realização de uma verificação, pois o fluxo de cálculo dos dados e o fluxo de lançamento da verificação de qualidade estão separados um do outro.

Em essência, o serviço DQ está permanentemente em execução no ambiente de produção e está pronto para iniciar seu trabalho no momento em que o próximo dado aparecer.

Em vez de uma conclusão

A vantagem de usar low-code é óbvia. Os desenvolvedores não precisam desenvolver o aplicativo do zero. E um programador livre de tarefas adicionais produz resultados com mais rapidez. A velocidade, por sua vez, libera tempo adicional para resolver problemas de otimização. Portanto, neste caso, você pode contar com uma solução melhor e mais rápida.

É claro que o low-code não é uma panacéia e a mágica não acontecerá por si só:

A indústria de low-code está a passar por uma fase de “cada vez mais forte” e ainda não existem padrões industriais uniformes;
Muitas soluções de low-code não são gratuitas e adquiri-las deve ser um passo consciente, que deve ser feito com total confiança nos benefícios financeiros da sua utilização;
Muitas soluções de baixo código nem sempre funcionam bem com GIT/SVN. Ou são inconvenientes de usar se o código gerado estiver oculto;
Ao expandir a arquitetura, pode ser necessário refinar a solução low-code – o que, por sua vez, provoca o efeito de “apego e dependência” do fornecedor da solução low-code.
Um nível adequado de segurança é possível, mas é muito trabalhoso e difícil de implementar em mecanismos de sistema de baixo código. As plataformas de baixo código devem ser escolhidas não apenas com base no princípio de buscar benefícios com seu uso. Na hora de escolher, vale tirar dúvidas sobre a disponibilidade de funcionalidades para controle de acesso e delegação/escalonamento de dados de identificação ao nível de todo o cenário de TI da organização.

No entanto, se você conhece todas as deficiências do sistema escolhido e os benefícios de seu uso, no entanto, são a maioria dominante, passe para o código pequeno sem medo. Além disso, a transição para isso é inevitável – assim como qualquer evolução é inevitável.

Se um desenvolvedor em uma plataforma de baixo código fizer seu trabalho mais rápido do que dois desenvolvedores sem baixo código, isso dará à empresa uma vantagem em todos os aspectos. O limiar para a entrada em soluções de baixo código é inferior ao das tecnologias “tradicionais”, e isto tem um efeito positivo na questão da escassez de pessoal. Ao utilizar ferramentas de low-code, é possível agilizar a interação entre equipes funcionais e tomar decisões mais rápidas sobre o acerto do caminho escolhido de pesquisa em ciência de dados. As plataformas de baixo nível podem impulsionar a transformação digital de uma organização porque as soluções produzidas podem ser compreendidas por especialistas não técnicos (particularmente utilizadores empresariais).

Se você tem prazos apertados, lógica de negócios carregada, falta de conhecimento tecnológico e precisa acelerar seu tempo de lançamento no mercado, o low-code é uma maneira de atender às suas necessidades.

Não há como negar a importância das ferramentas de desenvolvimento tradicionais, mas em muitos casos, utilizar soluções de low-code é a melhor forma de aumentar a eficiência das tarefas que estão sendo resolvidas.

Fonte: habr.com

Aplicação de low-code em plataformas analíticas