Hoje, tenho o prazer de compartilhar algumas atualizações de produtos nas quais estamos trabalhando relacionadas à captura de dados de alterações (CDC) em tempo actual, incluindo acesso antecipado a modelos populares e plataformas de CDC de terceiros. Nesta postagem destacaremos a nova funcionalidade, alguns exemplos para ajudar as equipes de dados a começar e por que o CDC em tempo actual se tornou muito mais acessível.
O que é CDC e por que é útil?
Primeiro, uma rápida visão geral do que CDC é e por que somos tão grandes fãs. Como todos os bancos de dados fazem compensações técnicas, é comum mover dados de uma origem para um destino com base em como os dados serão usados. Em termos gerais, existem três maneiras básicas de mover dados do ponto A para o ponto B:
- Um dump completo periódico, ou seja, copiando todos os dados da origem A para o destino B, substituindo completamente o dump anterior a cada vez.
- Atualizações periódicas em lote, ou seja, a cada 15 minutos, execute uma consulta em A para ver quais registros foram alterados desde a última execução (talvez usando sinalizador modificado, hora atualizada, and so on.) e insira-os em lote em seu destino.
- Atualizações incrementais (também conhecidas como CDC) – à medida que os registros mudam em A, emitem um fluxo de alterações que podem ser aplicadas de forma eficiente downstream em B.
O CDC aproveita o streaming para rastrear e transportar alterações de um sistema para outro. Este método oferece algumas vantagens enormes em relação às atualizações em lote. Primeiro, o CDC teoricamente permite que as empresas analisem e reajam aos dados em tempo actual, à medida que são gerados. Ele funciona com sistemas de streaming existentes, como Apache Kafka, Amazon Kinesis e Azure Occasions Hubs, tornando mais fácil do que nunca construir um pipeline de dados em tempo actual.
Um antipadrão comum: CDC em tempo actual em um knowledge warehouse em nuvem
Um dos padrões mais comuns para CDC é mover dados de um banco de dados transacional ou operacional para um knowledge warehouse em nuvem (CDW). Este método tem algumas desvantagens.
Primeiro, a maioria dos CDWs não suporta atualizações in-loco, o que significa que à medida que novos dados chegam, eles precisam alocar e gravar uma cópia inteiramente nova de cada micropartição através do MESCLAR comando, que também captura inserções e exclusões. O resultado? É mais caro (gravações grandes e frequentes) ou lento (gravações menos frequentes) usar um CDW como destino de CDC. Os knowledge warehouses foram criados para trabalhos em lote, portanto não devemos nos surpreender com isso. Mas então o que os usuários devem fazer quando surgirem casos de uso em tempo actual? Madison Schott da Airbyte escreve“Eu precisava de dados semi-temporais no Snowflake. Depois de aumentar a sincronização de dados no Airbyte para uma vez a cada 15 minutos, os custos do Snowflake dispararam. Como os dados eram ingeridos a cada 15 minutos, o knowledge warehouse estava quase sempre em execução.” Se seus custos explodirem com uma frequência de sincronização de 15 minutos, você simplesmente não conseguirá responder aos dados recentes, muito menos aos dados em tempo actual.
Uma e outra vezempresas de uma ampla variedade de setores aumentaram as receitas, aumentaram a produtividade e cortaram custos ao passarem da análise em lote para a análise em tempo actual. Dimona, uma empresa líder de vestuário da América Latina fundada há 55 anos no Brasil, disse o seguinte sobre seu banco de dados de gerenciamento de estoque: “À medida que colocamos mais armazéns e lojas on-line, o banco de dados começou a ficar atolado no lado analítico. Consultas que costumavam levar dezenas de segundos começaram a demorar mais de um minuto ou a atingir o tempo limite… usando o Database Migration Service (DMS) da Amazon, agora replicamos continuamente os dados do Aurora para o Rockset, que faz todo o processamento de dados, agregações e cálculos .” Os bancos de dados em tempo actual não são otimizados apenas para CDC em tempo actual – eles o tornam acessível e eficiente para organizações de qualquer tamanho. Ao contrário dos knowledge warehouses em nuvem, o Rockset foi desenvolvido especificamente para ingerir grandes quantidades de dados em segundos e executar consultas em menos de um segundo nesses dados.
CDC para análise em tempo actual
Na Rockset, vimos a adoção do CDC disparar. As equipes geralmente têm pipelines que geram deltas de CDC e precisam de um sistema que possa lidar com a ingestão desses deltas em tempo actual para permitir cargas de trabalho com baixa latência de ponta a ponta e alta escalabilidade de consulta. Rockset foi projetado exatamente para este caso de uso. Já construímos conectores de dados baseados em CDC para muitas fontes comuns: DynamoDB, MongoDB, e mais. Com o novo suporte CDC que estamos lançando hoje, o Rockset permite CDC em tempo actual perfeitamente proveniente de dezenas de fontes populares em vários formatos de CDC padrão do setor.
Para fins de informação, ao ingerir dados no Rockset, você pode especificar uma consulta SQL, chamada de transformação de ingestãoque é avaliado nos dados de origem. O resultado dessa consulta é o que persiste em sua coleção subjacente (o equivalente a uma tabela SQL). Isso lhe dá o poder do SQL para realizar tudo, desde renomear/descartar/combinar campos até filtrar linhas com base em condições complexas. Você pode até realizar agregações de tempo de gravação (acúmulos) e configure recursos avançados, como clustering de dados em sua coleção.
Os dados do CDC geralmente vêm em objetos profundamente aninhados com esquemas complexos e muitos dados que não são exigidos pelo destino. Com uma transformação de ingestão, você pode reestruturar facilmente os documentos recebidos, limpar nomes e mapear campos de origem para campos especiais do Rockset. Tudo isso acontece perfeitamente como parte da plataforma de ingestão gerenciada e em tempo actual da Rockset. Em contraste, outros sistemas exigem trabalhos/pipelines de ETL intermediários e complexos para obter manipulação de dados semelhante, o que adiciona complexidade operacional, latência de dados e custo.
Você pode ingerir dados CDC de praticamente qualquer fonte usando o poder e a flexibilidade das transformações de ingestão do Rockset. Para fazer isso, existem alguns campos especiais que você precisa preencher.
_eu ia
Este é o identificador exclusivo de um documento no Rockset. É importante que a chave primária da sua origem seja mapeada corretamente para _id para que as atualizações e exclusões de cada documento sejam aplicadas corretamente. Por exemplo:
-- easy single area mapping when `area` is already a string
SELECT area AS _id;
-- single area with casting required since `area` is not a string
SELECT CAST(area AS string) AS _id;
-- compound major key from supply mapping to _id utilizing SQL perform ID_HASH
SELECT ID_HASH(field1, field2) AS _id;
_hora_do_evento
Este é o carimbo de knowledge/hora de um documento no Rockset. Normalmente, os deltas do CDC incluem carimbos de knowledge/hora de sua origem, o que é útil para mapear o campo especial do Rockset para carimbos de knowledge/hora. Por exemplo:
-- Map supply area `ts_epoch` which is ms since epoch to timestamp sort for _event_time
SELECT TIMESTAMP_MILLIS(ts_epoch) AS _event_time
_op
Isto informa à plataforma de ingestão como interpretar um novo registro. Na maioria das vezes, os novos documentos são exatamente isso – novos documentos – e serão incluídos na coleção subjacente. No entanto, usando _op você também pode usar um documento para codificar uma operação de exclusão. Por exemplo:
{"_id": "123", "identify": "Ari", "metropolis": "San Mateo"} → insert a brand new doc with id 123
{"_id": "123", "_op": "DELETE"} → delete doc with id 123
Essa flexibilidade permite que os usuários mapeiem lógicas complexas a partir de suas fontes. Por exemplo:
SELECT area as _id, IF(sort="delete", 'DELETE', 'UPSERT') AS _op
Confira nossos documentos para mais informações.
Modelos e plataformas
A compreensão dos conceitos acima torna possível trazer os dados do CDC para o Rockset como estão. No entanto, construir a transformação correta nesses objetos profundamente aninhados e mapear corretamente todos os campos especiais pode, às vezes, ser complicado e sujeito a erros. Para enfrentar esses desafios, adicionamos suporte nativo e de acesso antecipado para uma variedade de modelos de transformação de ingestão. Isso ajudará os usuários a configurar mais facilmente as transformações corretas nos dados do CDC. Ao fazer parte da transformação de ingestão, você obtém o poder e a flexibilidade da plataforma de ingestão de dados da Rockset para trazer esses dados CDC de qualquer uma de nossas fontes suportadas, incluindo fluxos de eventos, diretamente por meio de nossa API de gravação, ou até mesmo por meio de knowledge lakes como S3, GCS, e Armazenamento de Blobs do Azure. A lista completa de modelos e plataformas para os quais estamos anunciando suporte inclui o seguinte:
Suporte a modelos
- Debézio: uma plataforma distribuída de código aberto para captura de dados alterados.
- Serviço de migração de dados AWS: serviço net da Amazon para migração de dados.
- Nuvem Confluente (by way of Debezium): Uma plataforma de streaming de dados nativa da nuvem.
- Arcion: uma plataforma CDC empresarial projetada para escalabilidade.
- Striim: Uma plataforma unificada de integração e streaming de dados.
Suporte de plataforma
- Byte aéreo: uma plataforma aberta que unifica pipelines de dados.
- Estuário: Uma plataforma de operações de dados em tempo actual.
- Decodificável: Uma plataforma de dados em tempo actual sem servidor.
Se desejar solicitar acesso antecipado ao suporte do modelo CDC, envie um e-mail para assist@rockset.com.
Como exemplo, aqui está uma mensagem modelo de que o Rockset suporta configuração automática para:
{
"knowledge": {
"ID": "1",
"NAME": "Consumer One"
},
"earlier than": null,
"metadata": {
"TABLENAME": "Worker",
"CommitTimestamp": "12-Dec-2016 19:13:01",
"OperationName": "INSERT"
}
}
E aqui está a transformação inferida:
SELECT
IF(
_input.metadata.OperationName="DELETE",
'DELETE',
'UPSERT'
) AS _op,
CAST(_input.knowledge.ID AS string) AS _id,
IF(
_input.metadata.OperationName="INSERT",
PARSE_TIMESTAMP(
'%d-%b-%Y %H:%M:%S',
_input.metadata.CommitTimestamp
),
UNDEFINED
) AS _event_time,
_input.knowledge.ID,
_input.knowledge.NAME
FROM
_input
WHERE
_input.metadata.OperationName IN ('INSERT', 'UPDATE', 'DELETE')
Essas tecnologias e produtos permitem criar pipelines de dados altamente seguros, escaláveis e em tempo actual em apenas alguns minutos. Cada uma dessas plataformas possui um conector integrado para Rockset, eliminando muitos requisitos de configuração guide, como aqueles para:
- PostgreSQL
- MySQL
- DB2
- Vites
- Cassandra
Do lote ao tempo actual
O CDC tem o potencial de tornar a análise em tempo actual acessível. Mas se sua equipe ou aplicativo precisar de acesso de baixa latência aos dados, depender de sistemas que armazenam dados em lote ou microlote explodirá seus custos. Os casos de uso em tempo actual exigem computação, mas as arquiteturas dos sistemas baseados em lote são otimizadas para armazenamento. Agora você tem uma opção nova e totalmente viável. Ferramentas de captura de dados alterados, como Airbyte, Striim, Debezium, et al, juntamente com bancos de dados analíticos em tempo actual, como Rockset, refletem uma arquitetura totalmente nova e são finalmente capazes de cumprir a promessa do CDC em tempo actual. Essas ferramentas são desenvolvidas especificamente para análises em escala de alto desempenho e baixa latência. O CDC é flexível, poderoso e padronizado de uma forma que garante que o suporte para fontes e destinos de dados continuará a crescer. Rockset e CDC são uma combinação perfeita, reduzindo o custo do CDC em tempo actual para que organizações de qualquer tamanho possam finalmente encaminhar lotes anteriores e obter análises em tempo actual.
Se quiser experimentar o Rockset + CDC, você pode iniciar um teste gratuito de duas semanas com US$ 300 em créditos aqui.