Prefácio
Em seguida, o último capítulo para construir um grande mapa de conhecimento de desenvolvimento de dados , este professor para continuar a compartilhar no estado de big data "off-line e em tempo real para desenvolver notas de estudo reais". Que tipo de plataforma pode ser considerada uma plataforma de big data? Com esta pergunta, começamos o conteúdo de hoje (• ̀ ω • ́) ✧
O que é uma plataforma de dados? Ou mais na moda, o que é uma plataforma de big data? Atualmente, a indústria não tem uma definição precisa da plataforma de dados, mas a comumente referida como plataforma de dados inclui principalmente as seguintes três partes:
- Ferramentas, produtos e tecnologias relacionadas a dados : como Sqoop para coleta e transmissão de dados em lote, Hadoop e Hive de processamento de dados offline, Storm de processamento de fluxo em tempo real, Spark e análise de dados R, etc .;
- Ativos de dados : incluem não apenas dados gerados e depositados pelo próprio negócio da empresa, mas também dados gerados pelas operações da empresa (como finanças, administração) e dados adquiridos, trocados ou rastreados de fora;
- Gerenciamento de dados : com ferramentas de dados, também existem ativos de dados, mas eles também devem ser gerenciados para maximizar o valor dos dados e minimizar os riscos. Portanto, as plataformas de dados geralmente também incluem conceitos e tecnologias relacionados ao gerenciamento de dados, como data warehouses e dados Modelagem, qualidade de dados, especificação de dados, segurança de dados e gerenciamento de metadados, etc.
O acima é uma divisão lógica das áreas de dados da plataforma, a plataforma é na verdade dados do ângulo de tempo de processamento de dados, ou geralmente dividida em dados da Internet e plataforma de dados em tempo real .
-
As plataformas de dados offline normalmente levam dias como um ciclo de processamento de dados típico, e os atrasos de dados também são baseados em dias. A aplicação de dados da plataforma de dados offline é baseada principalmente em "ver". Do estado de dados atual da indústria, a plataforma de dados offline ainda é o principal campo de batalha da plataforma de dados.
-
No entanto, com o aprofundamento da aplicação de big data e o surgimento da onda de inteligência artificial, a tendência de produtos inteligentes está se tornando cada vez mais óbvia. Os dados em tempo real e online também apresentam requisitos cada vez maiores para o desempenho em tempo real da plataforma de dados. Desde o início do atraso de um minuto até o atraso atual de segundo ou mesmo milissegundo, as plataformas de dados em tempo real estão recebendo cada vez mais atenção e os desafios estão cada vez maiores. Claro, eles estão se tornando cada vez mais populares. Com o desenvolvimento das tecnologias Spark, Flink e Beam, Um dia no futuro, a tecnologia e a arquitetura das plataformas de dados offline podem ser interrompidas.
A próxima etapa é introduzida a plataforma de dados para considerações lógicas e relacionadas à tecnologia claras, principalmente a partir da plataforma de dados offline, plataforma de dados em tempo real e conceitos e técnicas de gerenciamento de dados , três aspectos dos dados relacionados à plataforma são introduzidos.
1. Arquitetura, tecnologia e design de plataforma de dados offline
Para gerentes de empresa e pessoal de negócios da linha de frente, a pergunta que geralmente precisa ser respondida é: Qual é a tendência de vendas do mês ou do trimestre atual e anterior? Quais produtos estão vendendo bem? Quais produtos não estão vendendo bem? Quais clientes estão comprando nossos produtos? Os gerentes e o pessoal de negócios precisam monitorar constantemente esses indicadores de negócios e ajustar as estratégias de negócios e os métodos de jogo com base nesses indicadores de maneira direcionada, o que se repete para formar um ciclo fechado. Essa é a ideia básica da operação de dados.
E esse tipo de análise e "visão" das necessidades é o que as plataformas de dados offline são boas. Para esse tipo de necessidade analítica, a atualidade dos dados não é uma grande demanda. Não importa se os dados do dia estão disponíveis, mesmo que não estejam, o impacto será pequeno. , A tecnologia e as ferramentas de dados offline foram desenvolvidas por muitos anos e existem muitas soluções de código-fonte aberto e soluções comerciais que têm sido capazes de resolver esses problemas de forma muito madura.
A plataforma de dados offline é a base e a base para a construção da plataforma de dados corporativos e corporativos, e também é o principal campo de batalha da plataforma de dados atual.
1.1 A arquitetura geral da plataforma de dados offline
A plataforma de dados offline geralmente está conectada com Hadoop Hive, data warehouse, ETL, modelagem dimensional, camada comum de dados, etc.
Antes do advento do Hadoop, a principal tecnologia de processamento para data warehouses eram os bancos de dados comerciais, como o SQL Server da Microsoft, o Oracle da Oracle e o IBM DB2. Com a ascensão do big data e a explosão contínua e o crescimento exponencial do volume de dados, Hadoop, MapReduce, Hive e outras tecnologias de processamento de big data tornaram-se cada vez mais amplamente utilizadas e aceitas.
1.2 Tecnologia de data warehouse
1. OLTP 和 OLAP
O data warehouse é desenvolvido gradativamente com as necessidades de análise de dados.A análise de dados inicial e relatórios são baseados no banco de dados do sistema de negócios, que é o banco de dados OLTP, como comercial Oracle, MS SQL Server e open source MySQL. base de dados.
O nome completo do OLTP é Online Transaction Processing. Como o nome indica, o banco de dados OLTP é usado principalmente para o processamento de transações, como adicionar um pedido, modificar um pedido, consultar um pedido e cancelar um pedido. O principal requisito da base de dados OLTP é o processamento eficiente e rápido de um único registro.As demandas mais fundamentais como tecnologia de indexação, sub-banco de dados e subtabela são para resolver este problema.
- Isso é o oposto natural da demanda por análise de dados. A análise de dados geralmente requer acesso a uma grande quantidade de dados. A análise de uma única parte dos dados não significa nada. A análise de dados não requer apenas acesso a uma grande quantidade de dados, mas também estatísticas e consultas frequentes. O rápido administrador do banco de dados descobriu que essas solicitações de análise estatística consumiam muitos recursos do banco de dados, o que afetou seriamente o desempenho do sistema de produção.
- Portanto, é uma escolha natural isolar essas solicitações de análise de dados em um banco de dados de reserva separado ou copiar completamente um novo banco de dados para uso dos analistas de dados.
Depois de resolver o problema do impacto no banco de dados de produção, o administrador do banco de dados OLTP logo descobriu que o banco de dados standby e o banco de dados de replicação ainda não atendiam às necessidades dos analistas de dados, especialmente em termos de desempenho. Um grande número de acessos de dados geralmente requer varreduras de tabela completa. Varreduras de tabela completa frequentes e muitas vezes simultâneas farão com que o banco de dados OLTP responda de forma anormalmente lenta ou mesmo com tempo de inatividade. Novo suporte teórico e avanços tecnológicos são necessários para satisfazer essas solicitações de análise.
Assim surgiu a base de dados OLAP, uma base de dados analítica especializada desenvolvida para atender às necessidades de análise estatística dos analistas.
- O próprio banco de dados OLAP pode processar e contar uma grande quantidade de dados e, ao contrário do banco de dados OLTP, ele precisa considerar a adição, exclusão, modificação e verificação de dados e controle de bloqueio de simultaneidade. Os dados OLAP geralmente só precisam processar solicitações de consulta de dados e os dados são importados em lotes. Portanto, a velocidade de resposta às solicitações pode ser bastante acelerada por meio de tecnologias como armazenamento de coluna, compactação de coluna e indexação de bitmap.
2. Banco de dados analítico
Os bancos de dados analíticos enfrentam principalmente as operações estatísticas e de agregação de grandes conjuntos de dados por analistas e analistas de negócios. Sua arquitetura, design e princípios são completamente diferentes dos produtos de banco de dados tradicionais (bancos de dados OLTP). De modo geral, os produtos de data warehouse devem ser distribuídos, mas é obviamente diferente dos problemas a serem resolvidos por bancos de dados OLTP distribuídos. O banco de dados OLTP distribuído (como sub-banco de dados e tecnologia de subtabela) é principalmente para resolver a pressão de um grande número de solicitações de dados individuais. Seu objetivo principal é distribuir uniformemente todas as solicitações do usuário para cada nó, enquanto o OLTP distribuído é para dividir o usuário A tarefa de solicitar grandes conjuntos de dados é atribuída a cada nó para cálculo independente e, em seguida, agregada e devolvida ao usuário.
Além disso, os bancos de dados OLAP geralmente usam armazenamento colunar, enquanto OLTP geralmente usa armazenamento em linha.
- O chamado armazenamento de coluna serve para armazenar cada coluna da tabela junto, uma por uma, em vez de armazenar todos os campos juntos em linhas como o armazenamento de linhas.
- Para tabelas de banco de dados, o tipo de coluna é fixo, portanto, o armazenamento da coluna pode usar facilmente algoritmos de alta taxa de compactação para compactação e descompactação, e a E / S do disco será bastante reduzida.
- O armazenamento de coluna é muito adequado para cenários de aplicativos de consulta estatística de grande volume de dados. Como a análise e as estatísticas são frequentemente para uma determinada coluna ou certas colunas, os produtos de banco de dados de armazenamento de coluna só precisam ler a coluna correspondente e processá-la, em vez de ler toda a tabela Linha para processamento.
3. Armazém de dados Hadoop
Com a melhoria do Hadoop ao longo dos anos e a ascensão do ecossistema Hadoop, os data warehouses baseados no Hadoop ocuparam completamente o caminho principal em apenas alguns anos. Especialmente em empresas de Internet, os data warehouses baseados no Hadoop são basicamente padrão.
Os genes técnicos inerentes do Hadoop determinam a solução de data warehouse baseada no Hadoop (atualmente, principalmente o Hive é muito fácil de expandir (você pode facilmente adicionar nós e expandir a capacidade de processamento de dados de GB, TB para PB ou mesmo EB), e o custo também é muito baixo (sem comercial Servidores e armazenamento caros exigem apenas hardware comum, e a estrutura do Hadoop executará processamento tolerante a falhas.Estes dois pontos também são fatores-chave para a popularidade crescente do Hadoop nas empresas de Internet.
- As soluções de data warehouse baseadas em Hadoop, especialmente Hive, enfrentam o maior desafio de latência de consulta de dados (a latência do Hive é geralmente da ordem de minutos, dependendo da complexidade do Hive SQL e da carga de trabalho a ser processada. Em muitos casos, ele ainda precisa ser executado várias vezes. Horas. Claro, para Hive SQL de dados simples e pequenos, os resultados podem ser retornados em alguns segundos).
Mas big data e computação em nuvem são o futuro, e os sistemas de negócios futuros também serão executados na nuvem, seja ela privada, pública ou híbrida. A nuvem também determina que a arquitetura futura deve ser distribuída e pode ser expandida de forma aproximadamente linear. Com base nisso, o autor acredita que as soluções de armazenamento de dados do tipo Hadoop e Hadoop se tornarão mainstream e padrão no futuro, seja para empresas de Internet , Ou empresas tradicionais.
1.3 Tecnologia de modelagem de data warehouse
Desde o nascimento do conceito de data warehouse, no campo do data warehouse, existem dois métodos amplamente reconhecidos para construir o data warehouse. Os representantes dessas duas facções são Bill Inmon e Ralph Kimball. Bill Inmon é chamado de "pai dos armazéns de dados" e Ralph Kimball é chamado de "pai da inteligência de negócios".
Desde o nascimento desses dois pontos de vista, o debate sobre "qual arquitetura é a melhor" nunca parou. As pessoas expressaram suas opiniões, mas não conseguiram chegar a uma conclusão unificada, assim como "qual linguagem de programação é a melhor linguagem de programação". Pode ser chamada de "guerra religiosa" no campo de data warehouses.
1. Metodologia de Modelagem Ralph Kimball
As contribuições teóricas de Kimball para data warehouses estão todas relacionadas ao projeto dimensional e modelagem. A modelagem dimensional divide o mundo objetivo em medição e contexto.
- As métricas são capturadas pelo processo de negócios da organização e pelos sistemas de origem que as suportam. Freqüentemente, aparecem na forma numérica (como quantidade do pedido, quantidade do estoque etc.) e a teoria da modelagem dimensional chama isso de fato;
- Os fatos são cercados por um grande número de contextos textuais, e esses contextos são frequentemente divididos intuitivamente em vários blocos lógicos independentes. A modelagem dimensional é chamada de dimensão e a dimensão descreve os 5 W (quando, onde, o que, quem , Por que) informações, como quando fazer o pedido, como fazer o pedido, o que comprar, quem é o cliente, etc.
O data warehouse de Kimball modelado pela teoria da modelagem dimensional é freqüentemente apresentado em uma estrutura em forma de estrela. No meio da estrutura em forma de estrela está a tabela de fatos, e ao redor da tabela de fatos está a tabela dimensional de vários ângulos.
Na modelagem dimensional, como o padrão em estrela segue de perto o processo de negócios, é muito intuitivo e está em conformidade com a perspectiva do pessoal de negócios, é amplamente e amplamente utilizado.O padrão em estrela também é uma importante contribuição de Kimball para a modelagem de data warehouse.
A segunda maior contribuição de Kimball para a teoria da modelagem de data warehouse é a " arquitetura de barramento " baseada em dimensões . Em projetos reais, o processo de negócios de uma empresa é geralmente diverso e complexo e existe em vários tópicos de negócios.Juntos, a arquitetura do barramento e as dimensões de consistência garantem que as tabelas de fatos e tabelas de dimensão de vários tópicos possam ser finalmente integradas para fornecer consistência. E o único
calibre para o pessoal de negócios.
A arquitetura do sistema de data warehouse usando a teoria de modelagem Kimball é mostrada na figura:
Pode-se ver que o assunto da modelagem dimensional Kimball é baseado na arquitetura estrela, e a dimensão de consistência e a arquitetura de barramento empresarial são usadas entre assuntos e assuntos para garantir a integração e consistência do data warehouse.
2. Metodologia de Modelagem Bill Inmon
No campo do armazenamento de dados, Bill Inmon foi o primeiro a propor o conceito de OLAP e armazenamento de dados, então ele é chamado de pai do armazenamento de dados. Bill Inmon escreveu muitos artigos apresentando seus métodos de armazenamento de dados. Ele acredita que o armazenamento de dados é " Uma coleção de dados orientados para o assunto, integrados, relacionados com o tempo e não modificáveis na gestão empresarial e na tomada de decisões. "
Diferente de outros aplicativos de banco de dados, um data warehouse é mais parecido com um processo, um processo de integração, processamento e análise de dados de negócios distribuídos por toda a empresa, ao invés de um produto que pode ser adquirido. Isso é o que ele chama de "Empresa Fábrica de Informações Químicas ".
A fábrica de informações empresariais da Inmon inclui o sistema de origem, área de preparação, ETL, data warehouse empresarial, data mart, etc., e o data warehouse empresarial é o centro da fábrica de informações empresariais. Diferente de Kimball, o data warehouse Inmon que as empresas devem integrar o data warehouse atômico deve ser usado na terceira forma normal e na teoria ER para modelar, em vez de modelagem dimensional das tabelas de fatos e dimensões.
A planta de informações corporativas da Inmon envolve o conceito de "data mart", o chamado "mart" é um data warehouse de nível de departamento. Para o data mart, Inmon defende a extração dos dados necessários do data warehouse empresarial para garantir a consistência dos dados.O problema que isso traz é que o data warehouse empresarial deve ser estabelecido antes que o data mart de nível de departamento possa ser estabelecido. Esta é a segunda grande diferença entre a arquitetura do data warehouse Inmon e a arquitetura do data warehouse Kimball. Ao mesmo tempo, Inmon também acredita que a teoria de modelagem dimensional de Kimball deve ser usada para construir um data mart.
3. Prática de modelagem de data warehouse
A partir da introdução acima das duas arquiteturas de dados, pode-se ver que o método de Inmon é um método de construção de data warehouse de cima para baixo. Ele defende que o planejamento geral do data warehouse empresarial deve ser realizado primeiro, e as diferentes Os dados OLTP estão concentrados no data warehouse empresarial integrado, não volátil e com variação de tempo orientado para o assunto. O data mart deve ser um subconjunto do data warehouse, e cada data mart é projetado especificamente para um departamento independente.
O método Kimball é o oposto, que é de cima para baixo. Kimball acredita que um data warehouse é uma coleção de uma série de data marts. As empresas podem integrar de forma incremental vários data marts por meio de tabelas de dimensão consistentes e "arquitetura de barramento empresarial" para construir um data warehouse para toda a empresa.
Resuma suas diferenças em uma frase:
Kimball : deixe as pessoas construírem o que quiserem, quando quiserem, vamos
integrá-las quando e se precisarmos.
Inmon : não faça nada antes de projetar tudo.
O método de Inmon tem um longo ciclo de implantação e desenvolvimento, mas é fácil de manter e altamente integrado; enquanto o método de Kimball pode responder rapidamente às necessidades de negócios e construir rapidamente um data warehouse, mas integração e manutenção posteriores são mais problemáticas. Não há certo ou errado absoluto entre os dois, apenas os prós e os contras de diferentes estágios e diferentes cenários.
4. Projeto de arquitetura lógica de data warehouse
Os armazéns de dados offline são geralmente construídos com base na teoria da modelagem dimensional, mas, além disso, os armazéns de dados offline geralmente são em camadas lógicas. A estratificação lógica de data warehouses também é a melhor prática do setor.
A estratificação lógica de data warehouses offline é baseada principalmente nas seguintes considerações:
Isolamento : os usuários devem usar os dados cuidadosamente processados pela equipe de dados, em vez dos dados originais do sistema de negócios. Um dos benefícios disso é que os usuários usam dados cuidadosamente preparados, padronizados e limpos de uma perspectiva de negócios, o que é muito fácil de entender e usar; o segundo benefício é que se o sistema de negócios upstream mudar ou até mesmo refatorar (como Estrutura da tabela, significado do negócio do campo, etc.), a equipe de dados será responsável por lidar com todas essas mudanças para minimizar o impacto sobre os usuários downstream.
Desempenho e facilidade de manutenção : os profissionais fazem coisas profissionais, a estratificação de dados torna o processamento de dados basicamente na equipe de dados, então a mesma lógica de negócios não precisa ser repetida, economizando o armazenamento correspondente e sobrecarga de computação, afinal, big data não é Não tem custo. Além disso, a estratificação de dados também torna a manutenção do data warehouse clara e conveniente.Cada camada é responsável apenas por suas próprias tarefas. Se houver um problema com o processamento de dados de uma camada, você só precisa reparar a camada.
Normatividade : Para uma empresa e organização, o calibre dos dados é muito importante, quando falamos em um indicador, ele deve ser baseado em um calibre claro e reconhecido, além disso, tabelas, campos e indicadores também devem ser padronizados.
O data warehouse é geralmente dividido nas seguintes camadas:
Camada ODS: As tabelas de dados do sistema de origem do data warehouse são geralmente armazenadas intactas. Isso é chamado de camada ODS (Operation Data Store). A camada ODS é freqüentemente chamada de área de teste. Eles são os dados subsequentes. A camada de warehouse (ou seja, a tabela de fatos e a camada da tabela de dimensões geradas com base na modelagem dimensional Kimball e os dados da camada de resumo processados com base nessas tabelas de fatos e agendas) fonte de dados de processamento, e a camada ODS também armazena dados históricos incrementais ou completos .
Camada OWD e DWS: Detalhe do Data Warehouse (DWD) e Resumo do Data Warehouse (Resumo do Data Warehouse, DWS) são o conteúdo principal da plataforma de dados. Os dados de DWD e DWS são gerados por ETL de limpeza, conversão e carregamento de dados da camada ODS e são geralmente construídos com base na teoria de modelagem dimensional de Kimball, e as dimensões de cada subtópico são garantidas por meio de dimensões consistentes e barramentos de dados consistência.
Camada ADS: A camada de aplicativo é principalmente um data
mart (Data Mart, doravante denominado DM) estabelecido por várias partes comerciais ou departamentos com base em DWD e DWS . O data mart DM é um data warehouse (Data Warehouse, doravante denominado DW) em relação ao DWD / DWS. ) Para isso. De um modo geral, os dados da camada de aplicativo vêm da camada DW, mas, em princípio, o acesso direto à camada ODS não é permitido. Além disso, em comparação com a camada DW, a camada de aplicativo contém apenas a camada de detalhes e os dados da camada de resumo com os quais o departamento ou o lado comercial se preocupa.
A arquitetura em camadas lógicas do data warehouse usando a camada ODS acima → camada DW → camada de aplicação é mostrada na figura:
2. Arquitetura, tecnologia e design de plataforma de dados em tempo real
O ciclo de saída de dados por plataformas de dados off-line é geralmente de dias, ou seja, o que você vê hoje são os dados de ontem. Para a maioria dos cenários de análise e "visualização" de dados, esses dados off-line T + 1 podem satisfazer A análise de negócios precisa, mas à medida que as operações de negócios se tornam mais refinadas, os requisitos de oportunidade dos dados estão cada vez mais altos e mais e mais cenários de negócios precisam ver os efeitos de negócios imediatamente, especialmente em atividades de promoção de negócios (normalmente como Duplo 11 grande promoção, 618 grande promoção, etc.).
Mais importante, com o surgimento da onda de inteligência artificial, os dados em tempo real não são mais os melhores, mas sim indispensáveis. Dados não são apenas analisar e "ver", mas se tornam parte do sistema de negócios de produção junto com algoritmos.
2.1 A arquitetura geral da plataforma de dados em tempo real
A tecnologia de suporte da plataforma de dados em tempo real inclui principalmente quatro aspectos: coleta de dados em tempo real (como Flume), intermediário de mensagem (como Kafka), estrutura de computação em fluxo (como Strom, Spark, Flink, Beam, etc.) e armazenamento de dados em tempo real (como família de colunas) HBase armazenado). Atualmente, as principais plataformas de dados em tempo real também são construídas com base nessas quatro tecnologias relacionadas.
A plataforma de dados em tempo real deve primeiro garantir a natureza em tempo real da fonte de dados. As fontes de dados geralmente podem ser divididas em duas categorias: bancos de dados e arquivos de log. Para o primeiro, a melhor prática na indústria não é acessar diretamente o banco de dados para extrair dados, mas coletar diretamente os logs de mudança do banco de dados.
Para MySQL, é binlog, que é o log de alteração do banco de dados do MySQL, incluindo o status antes e depois da alteração dos dados.
A velocidade e frequência dos eventos binlog coletados por ferramentas de coleta de dados (como o Flume) geralmente dependem do sistema de origem. A velocidade de processamento de dados dele e as ferramentas de processamento de dados em tempo real downstream (como Storm, Spark, Flink e outras estruturas e plataformas de stream computing) geralmente não são combinadas. Além disso, o processamento de dados em tempo real geralmente tem a necessidade de reiniciar a partir de um determinado ponto histórico no tempo e usar os mesmos dados de origem para uma tarefa em tempo real. Portanto, o middleware de mensagem é geralmente usado como um buffer para obter a coleta e o processamento de dados em tempo real. Combine.
O armazenamento de dados em tempo real geralmente é colocado em diferentes armazenamentos de dados de acordo com as diferentes formas de uso de dados downstream. Para dados em serviço (ou seja, o consumidor de dados passa um determinado ID de negócio e, em seguida, obtém todos os campos relacionados a esse ID), geralmente é colocado no HBase ; Para telas grandes de dados em tempo real, geralmente é colocado em algum tipo de banco de dados relacional (como MySQL) e, às vezes, para melhorar o desempenho e reduzir a pressão sobre o banco de dados subjacente, um banco de dados de cache (como Redis) também é usado.
2.2 Tecnologia de streaming
A popularidade e a aceitação da computação em fluxo começaram com o Storm, que nasceu por volta de 2011. Stοrm foi rapidamente conhecido e aceito como um "Hadoop em tempo real".
Então, o que é a computação em fluxo? Qual é a diferença entre ele e o processamento em lote offline? Ao contrário do processamento em lote offline (como Hadoop Map Reduce), a computação em fluxo tem as seguintes características típicas:
Sem limites : a fonte de dados para a computação de fluxo é contínua, assim como a água do rio flui continuamente. Portanto, as tarefas de computação de fluxo precisam estar em execução o tempo todo.
Acionador : ao contrário das tarefas off-line do Hadoop, acionadas por agendamento agendado, cada cálculo de tarefas de stream computing é acionado pelos dados de origem. O acionamento é um conceito muito importante na computação em fluxo. Em alguns cenários de negócios, a lógica de acionamento de mensagens é mais complicada, o que representa um grande desafio para a computação em fluxo.
Latência : Obviamente, a computação em fluxo deve ser capaz de processar dados com eficiência e rapidez. Diferente do atraso de processamento de tarefas offline do Hadoop em pelo menos minutos ou mesmo horas, o atraso da computação de fluxo é geralmente em segundos ou até milissegundos, e atrasos em nível de minuto são aceitos apenas em algumas circunstâncias especiais.
Dados históricos : se uma tarefa Hadoop offline descobrir que há um problema com os dados de um determinado dia histórico, geralmente é fácil corrigir o problema e executar a tarefa novamente, mas é basicamente impossível ou muito caro para tarefas de computação de streaming, porque primeiro, as mensagens de streaming em tempo real geralmente não são salvas É muito tempo (geralmente alguns dias) e é basicamente impossível salvar o histórico completamente no local. Portanto, a computação de streaming em tempo real geralmente só pode reparar os dados a partir do momento em que o problema é descoberto. Os dados históricos não podem ser complementados por streaming.
A partir da causa raiz, o mecanismo de implementação da computação em fluxo atualmente tem dois métodos de processamento: um é imitar o processamento em lote offline, que é usar o processamento em lote micro (ou seja, minilote). O processamento de microlotes traz um aumento na taxa de transferência, mas o atraso de dados correspondente também aumentará, basicamente no nível de segundo e minuto.A tecnologia típica é Spark Streaming. O outro são os dados da mensagem nativa, ou seja, a unidade de processamento é uma única parte dos dados. A tecnologia de computação de stream nativa inicial tem baixa latência (geralmente dezenas de milissegundos), mas a taxa de transferência de dados é limitada. Normalmente, a estrutura nativa do Storm, mas com Flink Com o surgimento e o desenvolvimento de tecnologias, a taxa de transferência não é mais um problema.
2.3 A estrutura de código aberto de computação de fluxo principal
Três, gerenciamento de dados
Para uma empresa e organização, a tecnologia apenas de dados não é suficiente e os dados devem ser gerenciados. O escopo do gerenciamento de dados é muito amplo, mas inclui principalmente exploração de dados, integração de dados, qualidade de dados, gerenciamento de metadados e proteção de dados.
3.1 Exploração de dados
A exploração de dados, como o nome sugere, é analisar o conteúdo dos próprios dados e a relação, incluindo, mas não se limitando a se os dados necessários estão disponíveis, quais campos estão lá, se o significado dos campos é padronizado e claro e a distribuição e qualidade dos campos. Técnicas analíticas comumente usadas para exploração de dados incluem chaves primárias e estrangeiras, tipos de campo, comprimentos de campo, proporção de valores nulos, distribuição de valor de enumeração, mínimo, máximo, média, etc.
A exploração de dados é dividida em estratégica e tática.
- A exploração de dados estratégicos se refere à análise de dados leves da fonte de dados antes de usar os dados para determinar se eles estão disponíveis e a estabilidade dos dados para determinar se eles podem ser incorporados à plataforma de dados. A exploração estratégica de dados é a primeira tarefa a ser realizada antes de construir uma plataforma de dados. Fontes de dados não qualificadas devem ser eliminadas o mais rápido possível. Se a fonte de dados for considerada não qualificada em um estágio posterior, isso terá um grande impacto na construção da plataforma de dados.
- A exploração tática de dados se refere à análise detalhada dos dados por meios técnicos, descobrindo tantos problemas de qualidade de dados quanto possível e relatando-os ao pessoal de negócios ou notificando o sistema de origem para melhorias.
3.2 Integração de dados
A integração de dados do data warehouse também é chamada de ETL (extrair: extrair, transformar: transformar, carregar: carregar), que é o núcleo da construção da plataforma de dados, e também é a fase que consome mais tempo e energia no processo de construção da plataforma de dados.
ETL geralmente se refere ao processo de extração de dados da fonte de dados, passando por transformações como limpeza, conversão e associação e, finalmente, carregar os dados no data warehouse de acordo com um modelo de dados pré-projetado.
Para usuários de plataforma de dados e pessoal de negócios, eles geralmente não sabem ou se preocupam com quantas fontes de dados (como pedidos) são usadas, em quais bancos de dados e se as definições de campo são consistentes (como sistema de pedido 1 em nome do pedido) Sucesso, 0 significa falha do pedido e o sistema 2 usa o sucesso para representar o sucesso do pedido e falha para representar a falha do pedido), quais são as tabelas de dados relevantes (como as informações de retrato do cliente do pedido, a categoria do produto) e os dados que o usuário deseja O que você finalmente vê é uma tabela ampla padronizada e padronizada contendo todas as informações relevantes do pedido. Essa tabela ampla contém todas as informações do pedido que podem ser usadas e todas essas extrações de back-end, limpeza, conversão e associação, bem como o resumo final, Processos complexos, como associação, são todos concluídos por ETL, que também é um dos valores importantes que os data warehouses podem trazer aos usuários de dados.
3.3 Qualidade de dados
A qualidade dos dados é medida principalmente a partir dos seguintes quatro aspectos:
Integridade : A integridade refere-se à falta de dados e informações, podendo ser pela falta de todo o registro de dados, ou pode ser que esteja faltando o registro de um determinado campo dos dados. O valor com o qual os dados incompletos podem aprender será muito reduzido e também é o padrão de avaliação mais básico para a qualidade dos dados.
Consistência : Consistência refere-se a se os dados estão em conformidade com o padrão e se a coleta de dados mantém um formato uniforme. A consistência da qualidade dos dados reflete-se principalmente na especificação dos registros de dados e na conformidade dos dados com a lógica. Por exemplo, o endereço IP deve ser composto por 4 números de 0 a 255 mais ".".
Exatidão : a exatidão se refere a se há alguma anormalidade ou erro nas informações registradas nos dados e se elas atendem às expectativas do negócio.
Oportunidade : A oportunidade refere-se a se o tempo de saída dos dados é oportuno e pontual e está de acordo com as expectativas.
3.4 Máscara de dados
O data warehouse armazena todos os dados da empresa, alguns dos quais são muito sensíveis, como as informações do cartão de crédito do usuário e informações do cartão de identificação. Se essa informação vazar, isso trará consequências catastróficas para a empresa ou empresa, mas se essa informação for completamente excluída, terá um impacto no desenvolvimento, teste, análise e estatística.
O mascaramento de dados trata de como processar os dados de forma irreversível, de modo que os dados processados possam ser usados para desenvolvimento, teste, análise e estatística sem revelar nenhuma informação. Métodos comuns, como criptografia, substituição, exclusão / codificação, etc.
Quatro, resumo
Hoje, eu apresentei principalmente a categoria de conteúdo da plataforma de dados, aprendemos a arquitetura, os principais conceitos e tecnologias da plataforma de dados tanto em aspectos offline como em tempo real.
As plataformas de dados offline são atualmente o principal campo de batalha das plataformas de dados. As tecnologias conceituais relacionadas (como data warehouses, modelagem dimensional, camadas lógicas, Hadoop e Hive, etc.) são relativamente maduras e têm sido amplamente utilizadas em várias empresas.
Com o aumento da atualidade dos dados e da inteligência artificial, as plataformas de dados em tempo real estão recebendo cada vez mais atenção e colocadas em uma posição estratégica. As tecnologias relevantes das plataformas de dados em tempo real também estão em constante desenvolvimento e aprimoramento, como Storm, Flink e Beam. Nós É necessário manter um certo grau de atenção a esses aspectos negativos e abraçar ativamente essas tecnologias.
A vida não é superar os outros, mas superar a si mesmo.
Este é Yun Qi, até a próxima.
