Passar para o conteúdo principal

Como funcionam os pipelines de dados? (Beta)

Pipeline de dados da Linkana — exportação recorrente (CSV ou Parquet) para bucket GCS ou Azure, com dicionário de dados completo, para alimentar ferramentas de BI e Analytics.

Escrito por Leo Cavalcanti

Atenção: este recurso está em fase beta. O funcionamento, schema e cadência podem sofrer ajustes durante o período de validação. Clientes interessados em ativar devem alinhar previamente com o time da Linkana.

Os pipelines de dados são a forma da Linkana entregar dados de fornecedores de maneira recorrente e estruturada para os sistemas de BI, dashboards ou data warehouses do cliente. Em vez de depender de extrações manuais, o pipeline exporta automaticamente os dados para um bucket ou container na cloud do cliente (Google Cloud Storage ou Azure Blob Storage), de onde o time de dados consome com a ferramenta que preferir — BigQuery, Databricks, Power BI, Synapse, Python, entre outras.

O objetivo é que os dados da Linkana estejam disponíveis de forma confiável e padronizada dentro dos fluxos analíticos que já existem na empresa, sem trabalho manual recorrente.


Como funciona

O fluxo de um pipeline tem três etapas:

  1. Extração — a Linkana extrai os dados da base, filtrados pelo cliente

  2. Exportação — o arquivo CSV ou Parquet é depositado no bucket GCS do cliente

  3. Consumo — o cliente acessa o bucket e integra os dados aos seus sistemas

Cada pipeline é executado automaticamente na recorrência acordada. A cada execução, a Linkana substitui o conteúdo da pasta de cada tabela pelo retrato completo do dia — não há carga incremental nem histórico, o que está no bucket é sempre o estado atual. Se precisar de histórico, copie os dados para o seu lado antes da execução seguinte.


Tabelas disponíveis

Atualmente, os pipelines cobrem as tabelas abaixo, que representam as principais dimensões da gestão de fornecedores:

Tabela

O que contém

suppliers

Fornecedores cadastrados

documents

Documentos dos fornecedores (formulários, bases públicas e consultas)

form_fields

Respostas de perguntas de formulários

buyer_documents

Campos personalizados preenchidos internamente associados ao fornecedor ou homologação

setting_risks

Configurações de risco dos documentos por categoria

qualifications

Homologações do fornecedor por categoria

approval_steps

Níveis de aprovadores das etapas de aprovação

performances

Respostas de avaliações de performance por ciclo

cnpj_records

Dados cadastrais do CNPJ do fornecedor (base pública da Receita)

tags

Marcadores aplicados ao fornecedor pelo comprador

supplier_users

Usuários com conta na Linkana vinculados ao fornecedor

O cliente contrata as tabelas de acordo com o caso de uso. Novas tabelas são comunicadas conforme forem disponibilizadas.


Formato e schema

Os arquivos são entregues em CSV ou Parquet, conforme a preferência do cliente definida na ativação. Nos arquivos CSV: encoding UTF-8, vírgula como delimitador, datas no padrão ISO 8601 e a primeira linha com os nomes dos campos.

Os dados refletem os valores originais do sistema — campos de estado, por exemplo, aparecem como clear, not_clear, in_progress. Não são aplicadas transformações de negócio customizadas, agregações ou cálculos derivados. O pipeline entrega os dados granulares da Linkana no nível mais detalhado disponível.

Cada tabela é exportada como uma pasta (exports/<tabela>/), não como um arquivo único. Leia a pasta inteira: tabelas maiores são fatiadas automaticamente em vários arquivos, e o nome de cada arquivo muda a cada execução. Todos os arquivos de uma pasta pertencem à mesma tabela e devem ser lidos em conjunto.

Os arquivos de uma mesma pasta podem ter colunas diferentes: quando uma coluna está vazia em todos os registros de um arquivo, ela não é escrita naquele arquivo. Por isso, una os arquivos pelo nome da coluna, nunca pela posição — unir por posição desalinha as colunas silenciosamente, sem erro. O dicionário de dados abaixo traz o conjunto completo de colunas de cada tabela; trate qualquer coluna ausente num arquivo como nula.

Leia os campos como texto primeiro e converta depois pelos tipos do dicionário. Campos como cnpj, cep e ddd1 têm zeros à esquerda que se perdem se a coluna for interpretada como número.


Dicionário de dados

Cada tabela tem um schema fixo. O dicionário abaixo descreve cada campo, seu tipo e os valores possíveis para campos enumerados.

Os tipos descritos são os da origem — no CSV, todo valor chega como texto, e a coluna Tipo indica como interpretá-lo. Todo campo datetime está em UTC, sem timezone explícito. Além das colunas listadas, cada tabela traz _dlt_load_id e _dlt_id (texto), identificadores técnicos da carga que podem ser descartados.

suppliers (Fornecedores cadastrados)

Campo

Tipo

Descrição

id

uuid

ID único do fornecedor

name

string

Razão Social

identifier

string

CNPJ, CPF ou TIN

legal_entity

string

Tipo de pessoa. Valores: pj (Pessoa Jurídica / CNPJ), pf (Pessoa Física / CPF), internacional (pessoa ou empresa internacional)

country

string

País do fornecedor

state

string

Estado do fornecedor no fluxo. Valores: pending_docs (Aguardando fornecedor), on_review (Aguardando revisão), no_pending_issues (Sem pendências)

monitored

boolean

Se o fornecedor está sendo monitorado (conectado à base ativa do comprador)

regularization

boolean

Se o fornecedor está em processo de regularização interna pelo comprador

blocked_at

datetime

Data em que o fornecedor foi bloqueado (vazio se não bloqueado)

blocked_by

string

Nome do usuário que realizou o bloqueio

blocked_reason

string

Motivo do bloqueio

created_at

datetime

Data de criação do registro

updated_at

datetime

Data da última atualização do registro

documents (Documentos dos fornecedores)

A tabela contém todo o histórico de documentos armazenados nos fornecedores cadastrados.

Campo

Tipo

Descrição

id

uuid

ID único do documento

documentable_id

uuid

ID do objeto associado (ver documentable_type para o tipo)

documentable_type

string

Tipo do objeto associado. Valores: FormGroup (formulário), Certificate (consulta), Check (base pública), BankInformation (dados bancários)

expires_on

date

Data de validade do documento

renew_at

datetime

Data da próxima renovação

reviewed_at

datetime

Data de revisão

reviewed_by

string

E-mail do revisor

reviewer_comment

string

Comentário do revisor

reviewer_refusal_reason

string

Motivo da reprovação

sender_email

string

E-mail de quem enviou o documento

sent_at

datetime

Data de envio/geração

setting_document_id

uuid

Referência às configurações do documento

state

string

Situação do documento. Valores: processing (Pendente), clear (Aprovado), not_clear (Reprovado), pending_review (Aguardando revisão), informative (Informativo)

supplier_id

uuid

ID do fornecedor

display_name

string

Nome de exibição do documento

grouper_display_name

string

Grupo de revisão

current

boolean

Indica se é a versão vigente do documento. Filtre por current = true para o mais atual e current = false para versões anteriores

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

form_fields (Respostas de perguntas de formulários)

Campo

Tipo

Descrição

id

uuid

ID único

answer

string

Resposta da pergunta. Quando field_type é currency, o valor vem em centavos (dividir por 100 para reais)

form_group_id

uuid

Referência ao grupo de formulário. Para cruzar com documents, usar form_group_id = documentable_id

setting_form_field_id

uuid

Referência à configuração da pergunta — chave estável para identificar a mesma pergunta entre exportações e fornecedores

display_name

string

Nome da pergunta

field_type

string

Tipo de resposta (ex.: currency para valores monetários, entregues em centavos)

hint

string

Dica para a resposta

optional

boolean

Se a resposta é opcional

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

buyer_documents (Campos personalizados dos fornecedores)

Campos personalizados preenchidos internamente associados ao fornecedor ou homologação.

Campo

Tipo

Descrição

id

uuid

ID único do campo preenchido

supplier_id

uuid

ID do fornecedor

setting_buyer_document_id

uuid

Referência à configuração do campo personalizado

display_name

string

Nome do campo

value

string

Valor preenchido

qualification_id

uuid

Homologação associada ao campo (vazio = campo associado diretamente ao fornecedor)

active

boolean

Se o campo está ativo

disabled

boolean

Se o campo foi arquivado

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

setting_risks (Configurações de risco do documento por categoria)

Campo

Tipo

Descrição

id

uuid

ID único

risk

integer

Pontuação de risco do documento

category_id

uuid

Referência à categoria

setting_document_id

uuid

Referência às configurações do documento

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

qualifications (Homologações do fornecedor por categoria)

Campo

Tipo

Descrição

id

uuid

ID único da homologação

decision_at

datetime

Data da decisão

decision_score

integer

Score de risco no momento da decisão

initiated_by_email

string

E-mail do usuário que iniciou a homologação

renew_at

datetime

Data da próxima renovação da homologação

state

string

Situação da homologação. Valores: approved (Aprovada), in_progress (Em andamento), refused (Reprovada)

category_id

uuid

Referência à categoria

category_display_name

string

Categoria

category_score

integer

Score de risco da categoria da homologação, do último cálculo consolidado (não é em tempo real). Sem risco configurado vem 100. NULL só quando a categoria ainda não entrou no cálculo mais recente (situação transitória)

supplier_id

uuid

ID do fornecedor

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

approval_steps (Níveis de aprovadores das etapas de aprovação)

Campo

Tipo

Descrição

id

uuid

ID único

approver_user_email

string

E-mail do usuário aprovador

decision_at

datetime

Data da decisão

decision_reason

string

Motivo padronizado (opcional para aprovação, obrigatório para reprovação)

display_name

string

Nome do nível de aprovação

state

string

Situação do nível. Valores: pending (Pendente), approved (Aprovado), refused (Reprovado)

approval_step_last_decision_at

datetime

Data da última decisão tomada na etapa

qualification_id

uuid

Referência à homologação

approval_step_requester_user_email

string

E-mail do usuário que acionou a etapa, se condição de aprovação por exceção

approval_step_skipped

boolean

Se a etapa foi substituída por uma de aprovação por exceção

approval_step_state

string

Situação da etapa. Valores: pending (Pendente), approved (Aprovado), refused (Reprovado)

approval_step_display_name

string

Nome da etapa

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

performances (Respostas de avaliações de performance por ciclo)

Campo

Tipo

Descrição

id

uuid

ID único

answer

string

Resposta da pergunta

comment

string

Comentário textual do respondente junto com a resposta. Vem vazio (não NULL) quando não há comentário

criterion

string

Critério. Valores: scale_1_to_5 (Escala de 1 a 5), yes_or_no (Sim ou Não)

display_name

string

Nome da pergunta

score

integer

Score calculado

skipped

boolean

Se a pergunta foi ignorada

weight

integer

Peso da pergunta

pillar_display_name

string

Nome do pilar

pillar_score

integer

Score do pilar

pillar_weight

integer

Peso do pilar

evaluation_display_name

string

Nome da avaliação

evaluation_finished_at

datetime

Data em que a avaliação foi finalizada (vazio se ainda não finalizada)

evaluation_identifier

string

Identificador único interno do cliente

evaluation_score

integer

Score da avaliação

evaluation_state

string

Situação da avaliação. Valores: pending (Pendente), answering (Parcialmente respondida), answered (Respondida)

supplier_id

uuid

ID do fornecedor

evaluation_user_email

string

E-mail do usuário que iniciou a avaliação

cycle_active

boolean

Se é o ciclo atual do cliente

cycle_display_name

string

Nome do ciclo

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

cnpj_records (Dados cadastrais do CNPJ)

Informações consultadas em dados públicos da Receita Federal. Fornecedores Pessoa Física ou internacionais não têm registro nesta tabela.

Campo

Tipo

Descrição

id

uuid

ID único do registro

supplier_id

uuid

ID do fornecedor

cnpj

string

CNPJ do fornecedor (texto — preserva zeros à esquerda e acomoda o CNPJ alfanumérico; trate como string em qualquer cruzamento)

razao_social

string

Razão social

nome_fantasia

string

Nome fantasia

mf

string

Indicador matriz/filial (1 = matriz)

cod_situacao_cadastral

string

Código da situação cadastral

data_situacao_cadastral

date

Data da situação cadastral

cod_porte_empresa

integer

Código do porte da empresa

cod_natureza_juridica

integer

Código da natureza jurídica

cnae_fiscal

string

CNAE fiscal principal

cnaes_secundarios

string

CNAEs secundários, separados por vírgula

data_inicio_atividade

date

Data de início de atividade

capital_social

integer

Capital social em centavos (dividir por 100 para reais)

forma_tributacao

string

Regime tributário da empresa. Valores: simples_nacional (Simples Nacional), simei (Simples Nacional / MEI), lucro_presumido (Lucro Presumido), lucro_real (Lucro Real), lucro_arbitrado (Lucro Arbitrado), imune (Imune), isento (Isento), null (Não identificado)

desc_tipo_logradouro

string

Tipo de logradouro (Rua, Avenida, etc.)

logradouro

string

Logradouro

numero

string

Número do endereço

complemento

string

Complemento do endereço

bairro

string

Bairro

descricao_municipio

string

Município

uf

string

Unidade federativa

cep

string

CEP

correio_eletronico

string

E-mail de contato

ddd1

string

DDD do telefone principal

telefone1

string

Telefone principal

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

tags (Marcadores do fornecedor)

Marcadores que o comprador aplica ao fornecedor para organização e segmentação da base.

Campo

Tipo

Descrição

id

uuid

ID único do marcador

supplier_id

uuid

ID do fornecedor

display_name

string

Nome do marcador

created_at

datetime

Data de criação

updated_at

datetime

Data de atualização

supplier_users (Usuários vinculados ao fornecedor)

Usuários com conta na Linkana que têm acesso a um fornecedor — diferente de contact_email (em suppliers), que é o contato declarado pelo fornecedor, não necessariamente alguém com login na plataforma. Só traz vínculos de usuários ativos: usuário removido da Linkana não aparece.

Campo

Tipo

Descrição

id

uuid

ID único do vínculo entre o usuário e o fornecedor

supplier_id

uuid

ID do fornecedor

email

string

E-mail do usuário vinculado ao fornecedor

created_at

datetime

Data em que o vínculo foi criado (não é a data de criação da conta do usuário)

updated_at

datetime

Data da última atualização do vínculo (não da conta)


Como cruzar as tabelas

As tabelas podem ser combinadas para responder perguntas de negócio mais completas. Alguns exemplos práticos:

  • Risco de um documento por categoria: cruzar documents com setting_risks pelo setting_document_id. O category_id em setting_risks indica a qual categoria a pontuação se aplica.

  • Resposta de um formulário e sua situação: cruzar documents com form_fields ligando documentable_id (de documents) a form_group_id (de form_fields). O answer traz a resposta e o state de documents a situação (ex.: clear = aprovado).

  • Quem aprovou ou reprovou na homologação: usar approval_stepsapprover_user_email, decision_at e decision_reason — ligando à homologação por qualification_id.

  • Desempenho de um fornecedor: agrupar performances por supplier_id; evaluation_score traz o score consolidado e pillar_score o score por pilar.

  • Dados cadastrais e marcadores: cruzar cnpj_records e tags com suppliers pelo supplier_id.

  • Campos personalizados do comprador: cruzar buyer_documents com suppliers pelo supplier_id; display_name traz o nome do campo e value o valor preenchido.

  • Usuários vinculados a um fornecedor: cruzar supplier_users com suppliers pelo supplier_id.


Links diretos para objetos na Linkana

Com os IDs dos dados exportados, é possível montar links diretos para os objetos na plataforma:

Objeto

URL

Campo utilizado

Fornecedor

https://app.linkana.com/srm/suppliers/{supplier_id}/panel

supplier_id (ou id de suppliers)

Documento

https://app.linkana.com/srm/documents/{document_id}

id de documents

Campo personalizado

https://app.linkana.com/srm/buyer_documents/{id}

id de buyer_documents


Recorrência

A recorrência padrão de atualização é diária para todas as tabelas.


Acesso aos dados

Os dados são disponibilizados num bucket ou container dedicado por cliente, na cloud de sua preferência (Google Cloud Storage ou Azure Blob Storage). O acesso é sempre somente leitura e permanece sob controle do cliente.

Google Cloud Storage

O acesso é controlado via Service Account do Google Cloud com permissão apenas de leitura, em duas opções:

Opção preferencial: o cliente fornece uma Service Account própria e a Linkana concede permissão de leitura (storage.objectViewer) ao bucket. Recomendada porque o cliente mantém controle total sobre as credenciais e pode integrá-las diretamente aos seus pipelines.

Opção alternativa: caso o cliente não possua uma Service Account própria, a Linkana cria uma dedicada e compartilha a chave (JSON) de forma segura por link temporário. Em caso de rotação ou perda da chave, o cliente solicita uma nova via suporte.

Microsoft Azure — Blob Storage

Os dados ficam num container do Azure Blob Storage. Para conceder acesso de forma segura, o cliente cria uma identidade no Microsoft Entra ID autorizada a ler o container — mantendo controle total para rotacionar credenciais ou revogar o acesso a qualquer momento, sem depender da Linkana.

Pré-requisitos: conta Azure com permissão para criar App Registrations no Entra ID do tenant do cliente e acesso a portal.azure.com.

Passo a passo, do lado do cliente:

  1. Criar uma App Registration — no portal Azure, abra Microsoft Entra ID → App registrations → New registration. Preencha: Name linkana-data-access (ou outro de preferência); Supported account types = "Accounts in any organizational directory (Any Microsoft Entra ID tenant — Multitenant)" (sem isso a configuração não funciona); Redirect URI em branco. Clique em Register.

  2. Coletar IDs — na aba Overview da App Registration, copie o Application (client) ID e o Directory (tenant) ID.

  3. Gerar um Client Secret — em Certificates & secrets → New client secret, gere o segredo e guarde o valor com segurança.

  4. Enviar para a Linkana — envie apenas o Application (client) ID e o Tenant ID. Não envie o Client Secret: ele fica somente com o cliente. A Linkana nunca precisa do segredo, só dos dois identificadores.

Do lado da Linkana: fazemos o admin consent do app no nosso tenant (provisiona uma referência da identidade do cliente no nosso diretório) e atribuímos a role Storage Blob Data Reader sobre o container, concedendo acesso somente leitura.

Atenção: se vocês usam outro provedor de cloud, entrem em contato com o gestor de conta da Linkana para análise de viabilidade técnica.

Estrutura das pastas no bucket

gs://{bucket}/lk-{cliente}/exports/
    suppliers/
    documents/
    form_fields/
    buyer_documents/
    setting_risks/
    qualifications/
    approval_steps/
    performances/
    cnpj_records/
    tags/
    supplier_users/

A mesma estrutura de pastas se aplica ao container do Azure Blob Storage. As pastas com prefixo _dlt (como _dlt_loads, _dlt_pipeline_state, _dlt_version) são de controle interno do pipeline de exportação e podem ser ignoradas na integração.


Processo de ativação

A ativação é imediata: todas as tabelas são disponibilizadas assim que o cliente responder:

  1. Qual o provedor de cloud? (Google Cloud ou Microsoft Azure)

  2. Se for Google Cloud, o cliente fornece a Service Account ou precisa que a Linkana crie uma?

  3. Prefere receber os dados em CSV ou Parquet?

Com essas respostas e o acesso configurado (conforme a seção "Acesso aos dados"), o pipeline entra em operação.


Alterações de schema e SLA

A Linkana comunica alterações no schema com no mínimo 30 dias de antecedência, garantindo tempo hábil para que o time de dados ajuste suas integrações antes da aplicação.

Em caso de falha na exportação, o time da Linkana é notificado automaticamente. O pipeline é reprocessado e o cliente é informado sobre eventuais atrasos.


Perguntas frequentes

Os dados são incrementais ou full load?

Sempre full load. Cada exportação contém todos os registros válidos no momento da extração.

Posso pedir campos customizados?

Em geral, não. O schema de cada pipeline segue os campos padrão disponíveis na Linkana. Se um campo novo for adicionado à plataforma e for relevante para o seu caso de uso, ele pode ser incluído no pipeline mediante alinhamento prévio.

Posso usar com BigQuery, Databricks, Power BI ou ferramentas do Azure?

Sim. O bucket (Google Cloud Storage) ou o container (Azure Blob Storage) é acessível por qualquer ferramenta que suporte leitura desses storages. No Google Cloud, o BigQuery cria tabelas externas diretamente sobre os arquivos; no Azure, ferramentas como Synapse, Databricks e Power BI leem o container diretamente.

Como sei se o pipeline foi executado com sucesso?

A presença do arquivo atualizado no bucket indica que a execução foi bem-sucedida — a data de atualização do arquivo muda a cada rodada. Em caso de falha, o time da Linkana é notificado automaticamente e comunica o cliente sobre o status.

Uma tabela ou pasta está vazia ou não apareceu. É falha na integração ou ela não existe para o meu caso?

Na maioria dos casos, é ausência legítima — não falha. O pipeline é monitorado internamente pela nossa ferramenta de orquestração: quando uma exportação falha, o time da Linkana é notificado automaticamente e faz a correção, sem depender de você perceber.

Para confirmar do seu lado, verifique a data de atualização do arquivo: ela muda a cada execução bem-sucedida (o pipeline roda diariamente). Se a data mudou, o pipeline rodou.

Algumas tabelas dependem de recursos que o comprador pode não usar e, nesses casos, vêm vazias — sem que isso seja erro. Por exemplo: se você não usa o módulo de performance, a tabela performances vem vazia; o mesmo vale para tags se você não aplica marcadores. A forma mais simples de tirar a dúvida é entrar na Linkana e verificar se aquele dado existe na aplicação ou nos dashboards: se não existe lá, não existe no export.

Com quem eu falo sobre problemas no pipeline?

Pelo canal de suporte habitual da Linkana (e-mail ou plataforma), referenciando o nome do pipeline e a data do arquivo.

Respondeu à sua pergunta?