Caros amigos da comunidade, temos o prazer de anunciar que a versão beta do Apache Doris 2.0 foi lançada oficialmente em 3 de julho de 2023! Na versão 2.0-beta, mais de 255 colaboradores enviaram mais de 3.500 otimizações e correções para o Apache Doris. Bem-vindo ao download e uso!

Link para download: https://doris.apache.org/download

Código-fonte do GitHub: https://github.com/apache/doris/tree/branch-2.0

No Doris Summit anual realizado no início deste ano, lançamos o Roteiro Apache Doris para 2023 e propusemos uma nova visão:

Esperamos que os usuários possam criar serviços de análise de dados em vários cenários com base no Apache Doris, suporte a cargas de negócios online e offline, análise interativa de alto rendimento e consultas pontuais de alta simultaneidade; realizar a unificação de lagos e armazéns por meio de um conjunto de arquiteturas, Fornece serviços de análise contínuos e extremamente rápidos com base em data lakes e vários armazenamentos heterogêneos; também pode atender a necessidades mais diversas por meio de gerenciamento e análise unificados de dados multimodais semiestruturados ou mesmo não estruturados, como demanda de logs/texto para análise de dados.

Este é o valor que esperamos que o Apache Doris possa trazer para os usuários. Em vez de permitir que os usuários ponderem entre vários sistemas, apenas um sistema pode resolver a maioria dos problemas e reduzir os custos de desenvolvimento, operação, manutenção e uso trazidos por pilhas de tecnologia complexas. Maximize a produtividade .

Diante da análise em tempo real de dados massivos, a concretização dessa visão, sem dúvida, precisa superar muitas dificuldades, principalmente ao lidar com as demandas reais dos cenários reais de negócios:

Como garantir que os dados upstream sejam gravados em tempo real e em alta frequência, garantindo a estabilidade das consultas do usuário;
Como garantir a continuidade dos serviços online enquanto atualiza os dados upstream e altera as estruturas das tabelas;
Como obter armazenamento unificado e análise eficiente de dados estruturados e semiestruturados;
Como lidar com diferentes cargas de consulta, como consulta pontual, análise de relatório, consulta ad hoc, ETL/ELT, etc. ao mesmo tempo e garantir que as cargas sejam isoladas umas das outras?
Como garantir a alta eficiência da execução de instruções SQL complexas, a estabilidade de grandes consultas e a observabilidade do processo de execução?
Como integrar e acessar data lakes e várias fontes de dados heterogêneas de forma mais conveniente?
Como levar em consideração consultas de alto desempenho e reduzir muito o custo de armazenamento de dados e recursos de computação?
……

Aderindo ao princípio de " deixar a facilidade de uso para os usuários e a complexidade para nós mesmos ", a fim de superar a série de desafios acima, desde a base teórica até a implementação de engenharia, desde cenários de negócios ideais até casos extremos anormais, passando por testes internos até grandes A produção em larga escala está disponível e gastamos mais tempo e energia no desenvolvimento de funções, verificação, iteração contínua e excelência. Vale a pena comemorar que, após quase meio ano de desenvolvimento, teste e ajuste de estabilidade, o Apache Doris finalmente lançou o lançamento oficial da versão 2.0-beta! E o lançamento bem-sucedido desta versão trouxe nossa visão um passo mais perto da realidade!

O desempenho do teste cego melhorou em mais de 10 vezes!

Novo otimizador de consultas

Alta performance é a busca constante da Apache Doris. O excelente desempenho em conjuntos de dados de teste públicos, como Clickbench e TPC-H no ano passado, provou que alcançou desempenho líder do setor na camada de execução e otimização do operador, mas ainda há uma certa distância entre Benchmark e cenários de negócios reais :

Benchmark é mais sobre a abstração, refinamento e simplificação de cenários de negócios reais, e os cenários reais podem muitas vezes enfrentar declarações de consulta mais complexas, que não podem ser cobertas por testes;
As instruções de consulta de referência podem ser enumeradas e ajustadas de maneira direcionada, enquanto o ajuste de cenários de negócios reais é extremamente dependente do custo mental dos engenheiros, e a eficiência do ajuste geralmente é relativamente baixa e consome muita mão de obra dos engenheiros;

Com base nisso, começamos a desenvolver um novo otimizador de consulta para arquitetura moderna e o habilitamos totalmente na versão Apache Doris 2.0-beta. O novo otimizador de consulta adota uma estrutura Cascades mais avançada, usa informações estatísticas mais ricas e realiza um ajuste adaptativo mais inteligente. SQL e pode suportar totalmente todos os 99 SQLs do TPC-DS.

Realizamos um teste cego sobre o desempenho de execução do novo otimizador de consulta. Tomando o TPC-H 22 SQL como exemplo, o novo otimizador demorou muito para consultar sem qualquer ajuste manual e reescrita SQL , e o desempenho do teste cego melhorou mais de 10 vezes! No entanto, nos cenários de negócios reais de dezenas de usuários da versão 2.0, a maior parte da eficiência de execução do SQL original foi bastante aprimorada, o que realmente resolve o ponto problemático do ajuste manual!

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/query-acceleration/nereids

Como ativar: SET enable_nereids_planner=trueNa versão Apache Doris 2.0-beta, o novo otimizador de consulta foi ativado por padrão e as informações estatísticas são coletadas chamando o comando Analyze.

Mecanismo de execução de pipeline adaptável

No passado, o mecanismo de execução do Apache Doris era construído com base no modelo tradicional do vulcão. Para fazer melhor uso dos recursos de simultaneidade de várias máquinas e vários núcleos, no passado, precisávamos definir manualmente a simultaneidade de execução (por exemplo, defina manualmente este parâmetro do valor padrão de 1 a 8 ou 16 parallel_fragment_exec_instance_num), há uma série de problemas quando há um grande número de tarefas de consulta:

Consultas grandes e pequenas precisam definir diferentes simultaneidades de instância e o sistema não pode fazer ajustes adaptativos;
Os operadores de instância ocupam threads para bloquear a execução e um grande número de tarefas de consulta fará com que o pool de threads de execução fique cheio, incapaz de responder a solicitações subsequentes ou até mesmo um impasse lógico;
O escalonamento entre threads de instância depende do mecanismo de escalonamento do sistema, e a troca repetida de encadeamentos gerará sobrecarga de desempenho adicional;
Quando diferentes cargas de análise coexistem, pode haver contenção de recursos de CPU entre threads de instância, o que pode causar consultas grandes e pequenas e afetar umas às outras entre diferentes locatários;

Em resposta aos problemas acima, o Apache Doris 2.0 introduziu o modelo de execução Pipeline como o mecanismo de execução de consultas. No mecanismo de execução do Pipeline, a execução da consulta é conduzida por dados para alterar o fluxo de controle. O operador de bloqueio em cada processo de execução da consulta é dividido em diferentes Pipelines. Se cada Pipeline pode obter a execução do agendamento do thread de execução depende dos pré-dados está pronto, então os seguintes efeitos são alcançados:

O modelo de execução do Pipeline desmonta o plano de execução em tarefas do pipeline por meio da lógica de bloqueio e agenda as tarefas do pipeline no pool de threads de maneira compartilhada, realizando a assincronização das operações de bloqueio e resolvendo o problema de que as instâncias ocupam um único thread por um longo tempo tempo.
Diferentes estratégias de agendamento podem ser usadas para realizar a alocação de recursos da CPU entre consultas grandes e pequenas e diferentes inquilinos, de modo a gerenciar os recursos do sistema com mais flexibilidade.
O modelo de execução do Pipeline também adota a tecnologia de pool de dados para agrupar os dados em um único bucket de dados, removendo assim a limitação do número de buckets no número de instâncias, melhorando a capacidade do Apache Doris de utilizar sistemas multi-core e evitando frequentes criação de threads e problemas de destruição.

Por meio do mecanismo de execução do Pipeline, o desempenho da consulta e a estabilidade do Apache Doris em cenários de carga mista são aprimorados ainda mais .

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/query-acceleration/pipeline-execution-engine

Como habilitar: Set enable_pipeline_engine = trueEsta função será habilitada por padrão no Apache Doris 2.0, e o BE mudará o modelo de execução SQL para o modo de execução Pipeline por padrão ao executar a consulta. parallel_pipeline_task_numEle representa o número de tarefas de pipeline simultâneas para consultas SQL. O Apache Doris é configurado por padrão 0. Neste momento, o Apache Doris perceberá automaticamente o número de núcleos de CPU de cada BE e definirá a simultaneidade para metade do número de núcleos de CPU. Os usuários também podem ajustá-lo de acordo com sua situação real. Para usuários atualizando de versões mais antigas, é recomendável que os usuários definam esse parâmetro com parallel_fragment_exec_instance_numo valor da versão mais antiga.

A estabilidade da consulta foi aprimorada ainda mais

Isolamento de recursos multisserviço

Com a rápida expansão da escala do usuário, mais e mais usuários usam o Apache Doris para construir uma plataforma de análise unificada dentro da empresa. Por um lado, o Apache Doris é necessário para realizar processamento e análise de dados em larga escala. Por outro lado, o Apache Doris também é necessário para lidar com mais desafios de cargas de análise. A chave está em como garantir que diferentes cargas possam ser executadas de forma estável em um sistema.

O Apache Doris versão 2.0 adiciona um gerenciador de carga de trabalho baseado no mecanismo de execução Pipeline e gerencia as cargas de trabalho em grupos para garantir um controle refinado da memória e dos recursos da CPU.

Nas versões anteriores, o Apache Doris implementou o isolamento de recursos multilocatário por meio de tags de recursos, o que pode evitar interferência mútua entre diferentes serviços por meio da divisão de recursos de nó, e o Workload Group implementou um método de gerenciamento e controle de recursos mais refinado. O grupo está associado, você pode limitar a porcentagem de recursos de CPU e memória de uma única Consulta no nó BE e você pode configurar o limite flexível de memória do grupo de recursos. Quando os recursos do cluster estiverem apertados, várias tarefas de consulta que ocupam a maior memória do grupo serão eliminadas automaticamente para reduzir a pressão no cluster. Quando os recursos do cluster estão ociosos, uma vez que os recursos usados pelo grupo de carga de trabalho excedem o valor predefinido, várias cargas de trabalho compartilharão os recursos ociosos disponíveis do cluster e excederão automaticamente o limite e continuarão a usar a memória do sistema para garantir a execução estável de tarefas de consulta.

create workload group if not exists etl_group
properties (
  "cpu_share"="10",
  "memory_limit"="30%",
  "max_concurrency" = "10",
  "max_queue_size" = "20",
  "queue_timeout" = "3000"
);

Você pode Showvisualizar o Workload Group criado com o comando, por exemplo:

fila de trabalho

Ao mesmo tempo, também introduzimos a função de enfileiramento de consultas no Workload Group. Ao criar um Workload Group, você pode definir o número máximo de consultas. As consultas que excederem a simultaneidade máxima serão enfileiradas para execução.

max_concurrencyO número máximo de consultas permitidas pelo Grupo atual e as consultas que excederem a simultaneidade máxima entrarão na lógica de enfileiramento;
max_queue_sizeConsultar o comprimento da fila. Quando a fila estiver cheia, novas consultas serão rejeitadas;
queue_timeoutO tempo de espera da consulta na fila. Se o tempo de espera da consulta exceder o tempo de espera, a consulta será rejeitada e a unidade de tempo é milissegundos;

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/admin-manual/workload-group/

Diga adeus ao OOM completamente

Quando a memória é suficiente, o gerenciamento de memória geralmente é insensível aos usuários, mas em cenários reais, muitas vezes existem vários casos extremos, que trarão desafios para o desempenho e estabilidade da memória, especialmente diante do grande consumo de recursos de memória. Para cálculos complexos e trabalhos de grande escala, a falha na consulta devido à OOM de memória pode até causar a queda do processo BE.

Portanto, unificamos gradualmente a estrutura de dados da memória, refatoramos o MemTracker, começamos a oferecer suporte ao limite flexível de memória de consulta, introduzimos o mecanismo GC depois que a memória do processo excede o limite e otimizamos o desempenho da consulta de alta simultaneidade. Na versão 2.0, introduzimos uma estrutura de gerenciamento de memória totalmente nova. Por meio de alocação de memória, estatísticas e controle eficazes, basicamente eliminamos pontos de acesso de memória e problemas de tempo de inatividade BE induzidos por OOM no Benchmark, teste de estresse e feedback de cenários de negócios reais do usuário. , mesmo que ocorra OOM, o local da memória geralmente pode ser localizado e ajustado de acordo com o log, para que o cluster possa ser restaurado à estabilidade, e o limite de memória para consulta e importação também é mais flexível, para que os usuários não precisem perceber o uso da memória quando a memória é suficiente.

Por meio da série de otimizações acima, o Apache Doris versão 2.0 pode efetivamente controlar os recursos de memória ao lidar com cálculos complexos e operações ETL/ELT em larga escala, e a estabilidade do sistema foi aprimorada para um nível superior.

Introdução detalhada: https://mp.weixin.qq.com/s/Z5N-uZrFE3Qhn5zTyEDomQ

Gravação de dados eficiente e estável

Maior eficiência de gravação de dados em tempo real

O desempenho de importação foi aprimorado ainda mais

Com foco na análise em tempo real, aprimoramos continuamente os recursos de análise em tempo real nas últimas versões. A capacidade de gravação de dados em tempo real de ponta a ponta é uma direção importante para a otimização. No Apache Doris 2.0, fortalecemos ainda mais esta capacidade. Por meio de otimizações como Memtable não usando Skiplist, download paralelo e importação de cópia única, o desempenho da importação foi bastante aprimorado:

Use o Stream Load para fazer três cópias dos dados originais da tabela de itens de linha TPC-H 144G e importe-os para a tabela Duplicate com 48 buckets, e a taxa de transferência é aumentada em 100%.
Use o Stream Load para fazer três cópias dos dados originais da tabela de itens de linha TPC-H 144G e importe-os para a tabela Unique Key com 48 buckets, aumentando a taxa de transferência em 200%.
Use insert into select para importar a tabela Duplicate de 48 buckets para a tabela de itens de linha TPC-H 144G e a taxa de transferência aumenta em 50%.
Usando insert into select para importar a tabela de itens de linha TPC-H 144G para a tabela Unique Key com 48 buckets, o throughput aumentou em 150%.

A gravação de dados de alta frequência é mais estável

No processo de gravação de dados de alta frequência, os problemas de fusão de arquivos pequenos e amplificação de gravação, bem como a subsequente E/S de disco e sobrecarga de recursos da CPU são a chave para restringir a estabilidade do sistema. Portanto, na versão 2.0, introduzimos o Vertical Compactação e compactação de segmento é usada para resolver completamente o problema de memória de compactação e muitos arquivos de segmento no processo de gravação. O consumo de recursos é reduzido em 90%, a velocidade é aumentada em 50% e o uso de memória é de apenas 10% do o original.

Introdução detalhada: https://mp.weixin.qq.com/s/BqiMXRJ2sh4jxKdJyEgM4A

Sincronização automática da estrutura da tabela de dados

Nas versões anteriores, introduzimos alterações de esquema no nível de milissegundos, mas na versão mais recente do Flink-Doris-Connector, conseguimos sincronização com um clique de todo o banco de dados de bancos de dados relacionais, como MySQL para Apache Doris. No teste real, uma única tarefa de sincronização pode realizar a gravação paralela em tempo real de milhares de tabelas, que se despede completamente do tedioso e complicado processo de sincronização do passado, e a estrutura da tabela e a sincronização de dados do banco de dados de negócios upstream podem ser realizado através de comandos simples. Ao mesmo tempo, quando a estrutura de dados upstream muda, ela também pode capturar automaticamente a alteração do esquema e sincronizar dinamicamente o DDL com Doris para garantir a operação perfeita dos negócios.

Introdução detalhada: https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw

O modelo de chave primária oferece suporte a atualizações parciais de coluna

No Apache Doris versão 1.2, introduzimos o modo Merg-on-Write do modelo Unique Key, que pode garantir uma consulta eficiente e estável de negócios downstream enquanto os dados upstream são frequentemente gravados e atualizados, realizando gravação em tempo real e unificação extremamente rápida de consultas. Na versão 2.0, aprimoramos totalmente o modelo de chave exclusiva. Em termos de função, ele suporta o novo recurso de atualização de coluna parcial. Quando várias tabelas de origem upstream são gravadas ao mesmo tempo, elas não precisam ser processadas em uma tabela ampla com antecedência. Ele pode concluir diretamente a junção por meio da atualização de coluna parcial no momento da escrita, o que simplifica muito o processo de escrita de tabelas largas. .

Em termos de desempenho, a versão 2.0 melhorou muito o desempenho de gravação de grandes volumes de dados e a capacidade de gravação simultânea do modelo de chave exclusiva Merge-on-Write. Em comparação com a versão 1.2, a importação de grandes volumes de dados tem uma melhoria de desempenho de mais de 50% , e a importação simultânea alta tem mais de 50% de melhoria de desempenho. 10 vezes a melhoria de desempenho e por meio do mecanismo de processamento simultâneo eficiente para resolver completamente o problema de tempo limite de publicação (erro -3115) e por causa do mecanismo de compactação eficiente de Doris 2.0 , não haverá problema de muitas versões (Error-235). Isso permite que o Merge-on-Write substitua o Merge-on-Read em uma ampla gama de cenários. Ao mesmo tempo, também usamos o recurso de atualização de coluna parcial para reduzir o custo de cálculo das instruções UPDATE e DELETE, e o desempenho geral é melhorou cerca de 50%.

Exemplo de uso de atualização de coluna parcial (Stream Load):

Por exemplo, a estrutura da tabela é a seguinte

mysql> desc user_profile;
+------------------+-----------------+------+-------+---------+-------+
| Field           | Type           | Null | Key   | Default | Extra |
+------------------+-----------------+------+-------+---------+-------+
| id               | INT             | Yes | true | NULL   |       |
| name             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| age             | INT             | Yes | false | NULL   | NONE |
| city             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| balance         | DECIMALV3(9, 0) | Yes | false | NULL   | NONE |
| last_access_time | DATETIME       | Yes | false | NULL   | NONE |
+------------------+-----------------+------+-------+---------+-------+

Se o usuário deseja atualizar em lote o saldo do usuário e o tempo de acesso que foram alterados nos últimos 10s, os dados podem ser organizados no seguinte arquivo csv

1,500,2023-07-03 12:00:01
3,23,2023-07-03 12:00:02
18,9999999,2023-07-03 12:00:03

Em seguida, através do Stream Load, adicione Header partial_columns:truee especifique o nome da coluna a ser importada para concluir a atualização

curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H 
"columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

Extrema flexibilidade e separação de armazenamento e cálculo

No passado, o Apache Doris ajudou os usuários a economizar muito o custo de recursos de computação e armazenamento com muitos projetos em termos de facilidade de uso, e demos um passo sólido à frente na arquitetura nativa da nuvem orientada para o futuro.

Partindo da tendência de redução de custos e aumento de eficiência, os requisitos do usuário para recursos de computação e armazenamento podem ser resumidos da seguinte forma:

Elasticidade dos recursos de computação: diante dos picos de computação de negócios, os recursos podem ser rapidamente expandidos para melhorar a eficiência e, em computação de baixo, podem ser rapidamente reduzidos para reduzir custos;
Custos de armazenamento mais baixos: Diante de dados massivos, mídias de armazenamento mais baratas podem ser introduzidas para reduzir custos, enquanto o armazenamento e a computação são definidos separadamente sem interferir um no outro;
Isolamento de carga de negócios: Diferentes cargas de negócios podem usar recursos de computação independentes para evitar a preempção mútua de recursos;
Gerenciamento e controle de dados unificados: o catálogo unificado e o gerenciamento de dados unificado permitem uma análise de dados mais conveniente.

A arquitetura integrada de computação de armazenamento tem as vantagens de ser simples e fácil de manter em cenários com baixos requisitos elásticos, mas apresenta algumas limitações em cenários com fortes requisitos elásticos. A essência da arquitetura de separação de computação de armazenamento é um meio técnico para resolver a elasticidade de recursos. Possui vantagens mais óbvias na elasticidade de recursos, mas possui requisitos de estabilidade mais altos para armazenamento, e a estabilidade do armazenamento afetará ainda mais a estabilidade do OLAP. Portanto , uma série de mecanismos como gerenciamento de cache, gerenciamento de recursos de computação e coleta de dados de lixo foram introduzidos.

Na comunicação com os usuários da comunidade Apache Doris, descobrimos que as necessidades dos usuários para separação de armazenamento e cálculo podem ser divididas nas três categorias a seguir:

Atualmente, a arquitetura integrada de armazenamento e computação simples e fácil de usar é selecionada e não há demanda por flexibilidade de recursos por enquanto;
A falta de armazenamento estável em larga escala requer elasticidade, isolamento de carga e baixo custo com base no Apache Doris;
Com armazenamento estável em grande escala, uma arquitetura extremamente flexível é necessária para resolver o problema de escalonamento rápido de recursos, portanto, também é necessária uma arquitetura de separação de computação de armazenamento mais completa;

Para atender às necessidades dos dois primeiros tipos de usuários, o Apache Doris 2.0 oferece uma solução de separação de computação de armazenamento compatível com atualizações:

O primeiro tipo são os nós de computação. Na versão 2.0, introduzimos o nó de computação sem estado Compute Node, que é usado especialmente para análise de data lake. Comparado com o nó híbrido original que integra armazenamento e computação, o Compute Node não salva nenhum dado e não precisa executar o balanceamento de carga da fragmentação de dados quando o cluster se expande ou diminui. Portanto, em cenários com picos óbvios, como análise de data lake , pode ser expandido de forma flexível e rápida Junte-se ao cluster para compartilhar a pressão de computação. Ao mesmo tempo, como os dados do usuário geralmente são armazenados em armazenamento remoto, como HDFS/S3, a tarefa de consulta será preferencialmente despachada para o nó de computação para execução durante a execução da consulta para evitar a preempção de recursos de computação entre consultas internas e externas.

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/advanced/compute_node

O segundo tipo é a estratificação quente e fria. Em termos de armazenamento, os dados quentes e frios geralmente enfrentam diferentes requisitos de frequência de consulta e velocidade de resposta, portanto, os dados frios geralmente podem ser armazenados em mídia de armazenamento de custo mais baixo. Nas versões anteriores, o Apache Doris oferece suporte ao gerenciamento do ciclo de vida das partições da tabela e resfria automaticamente os dados quentes do SSD para o HDD por meio de tarefas em segundo plano, mas os dados no HDD são armazenados em várias cópias, o que não maximiza a economia de custos, portanto, ainda há um muito espaço para otimização de custos de armazenamento de dados frios. A função de hierarquização de dados quentes e frios foi introduzida no Apache Doris 2.0 . A função de hierarquização de dados quentes e frios permite que o Apache Doris transfira dados frios para o armazenamento de objetos com custos de armazenamento mais baixos. Ao mesmo tempo, o método de armazenamento de dados frios no armazenamento de objetos Ele também mudou de cópia múltipla para cópia única, e o custo de armazenamento foi reduzido para um terço do original. Ao mesmo tempo, o custo adicional de recursos de computação e o custo indireto da rede devido ao armazenamento também foram reduzidos. De acordo com cálculos reais, os custos de armazenamento podem ser reduzidos em até 70%!

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/advanced/cold_hot_separation

Os nós de computação subseqüentes suportarão a consulta de dados frios e dados de nós de armazenamento, de modo a realizar uma solução de separação de computação de armazenamento que seja compatível com atualizações.

foto

A fim de atender às necessidades do terceiro tipo de usuários, também contribuiremos com a solução de separação de computação e armazenamento SelectDB Cloud de volta à comunidade. Esta solução passou pelo teste do ambiente de produção de centenas de empresas em termos de desempenho, maturidade funcional e estabilidade do sistema. Também sincronizaremos o progresso real da integração subsequente de funções no tempo.

Uma solução de análise de log que é mais de 10 vezes mais econômica

De cenários OLAP típicos, como relatórios em tempo real e Ad-hoc no passado, a mais cenários de negócios, como ELT/ETL, recuperação e análise de log, o Apache Doris está constantemente expandindo os limites dos cenários de aplicativos e o armazenamento e análise unificados de dados de log é exatamente o que estamos fazendo Um avanço importante na versão 2.0.

No passado, a arquitetura típica de armazenamento e análise de logs do setor era difícil de equilibrar gravação em tempo real de alto rendimento, armazenamento em grande escala de baixo custo e recuperação e análise de texto de alto desempenho ao mesmo tempo, e só podia fazer trade-offs em um ou vários aspectos. Na versão 2.0 do Apache Doris, introduzimos um novo índice invertido para atender a pesquisa de texto completo do tipo string e a pesquisa equivalente e de intervalo de tipos numéricos/data comuns. Ao mesmo tempo, otimizamos ainda mais o desempenho da consulta do invertido índice para torná-lo Está mais alinhado com os requisitos do cenário de análise de dados de log e combinado com as vantagens anteriores na gravação de dados em grande escala e armazenamento de baixo custo, ele realiza uma solução de análise de log mais econômica.

No desempenho de teste da mesma configuração de hardware e conjunto de dados, o Apache Doris alcançou um aumento de 4 vezes na velocidade de gravação de dados de log, uma redução de 80% no espaço de armazenamento e um aumento de 2 vezes no desempenho de consulta em comparação com o ElasticSearch, combinado com o quente e o frio introduzidos pelo Apache Doris 2.0 O recurso de camada de dados melhora o desempenho de custo geral em mais de 10 vezes.

Além da otimização de cenários de análise de log, em termos de tipos de dados complexos, adicionamos um novo tipo de dados Map/Struct, incluindo suporte para funções eficientes de escrita, armazenamento e análise dos tipos acima, e aninhamento mútuo entre tipos para Conheça melhor o suporte da análise de dados multimodal.

Introdução detalhada: https://mp.weixin.qq.com/s/WJXKyudW8CJPqlUiAro_KQ

Recursos de análise de data lake mais abrangentes e de maior desempenho

Na versão 1.2 do Apache Doris, lançamos a função Multi-Catalog, que suporta mapeamento automático de metadados e sincronização de várias fontes de dados heterogêneas e realiza a conexão perfeita de data lakes. Baseando-se em muitas otimizações na leitura de dados, mecanismo de execução e otimizador de consulta, no cenário de conjunto de teste padrão, o desempenho de consulta do Apache Doris nos dados do lago é de 3 a 5 vezes maior que o do Presto/Trino.

Na versão 2.0, aprimoramos ainda mais os recursos de análise do data lake, não apenas suportando mais fontes de dados, mas também fazendo muitas otimizações para o ambiente de produção real dos usuários. Em comparação com a versão 1.2, ela pode ser usada em condições reais de carga de trabalho Desempenho significativamente melhorado .

Mais suporte de fonte de dados

Suporta Snapshot Query para tabelas Hudi Copy-on-Write e Read Optimized Query para tabelas Merge-on-Read, e suportará Incremental Query e Time Trival posteriormente. Documento de referência: https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/hudi
O Catálogo JDBC adicionou recentemente suporte para Oceanbase e atualmente suporta quase dez bancos de dados relacionais, incluindo MySQL, PostgreSQL, Oracle, SQLServer, Doris, Clickhouse, SAP HANA, Trino/Presto e Oceanbase. Documento de referência: https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/jdbc

Controle de permissão de dados

Ele suporta a autenticação do Catálogo Hive por meio do Apache Range, que pode se conectar perfeitamente ao sistema de permissão existente do usuário. Ao mesmo tempo, ele também oferece suporte a plug-ins de autenticação extensíveis para implementar métodos de autenticação personalizados para qualquer Catálogo. Documento de referência: https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/hive

O desempenho é otimizado ainda mais e a melhoria máxima é dezenas de vezes

Otimizou o desempenho de leitura de um grande número de cenários de arquivos pequenos e cenários de tabelas amplas. Por meio de tecnologias como carregamento completo de pequenos arquivos, fusão de pequenos IOs e pré-leitura de dados, a sobrecarga de leitura do armazenamento remoto é significativamente reduzida.Nesses cenários, o desempenho da consulta pode ser melhorado em até dezenas de vezes.
Otimizou o desempenho de leitura de arquivos ORC/Parquet e dobrou o desempenho de consulta em comparação com a versão 1.2.

Suporta cache de arquivo local de dados no lago. Os discos locais podem ser usados para armazenar dados em cache em sistemas de armazenamento remoto, como HDFS ou armazenamento de objetos, e as consultas que acessam os mesmos dados podem ser aceleradas por meio do armazenamento em cache. No caso de acessar o cache de arquivo local, o desempenho da consulta de dados no lago por meio do Apache Doris pode ser igual ao das tabelas internas do Apache Doris. Essa função pode melhorar muito o desempenho da consulta de dados quentes no lago. Documento de referência: https://doris.apache.org/zh-CN/docs/dev/lakehouse/filecache
Suporta coleta de estatísticas para aparências. Como a tabela interna do Apache Doris, os usuários podem analisar e coletar informações estatísticas da tabela externa especificada por meio da instrução Analyze.Combinado com o novo otimizador de consulta Nereids, ele pode otimizar com mais precisão e inteligência o plano de consulta para SQL complexo. Tomando o conjunto de dados de teste padrão TPC-H como exemplo, o plano de consulta ideal e melhor desempenho podem ser obtidos sem reescrever SQL manualmente. Documento de referência: https://doris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/
Otimizou o desempenho de write-back de dados do Catálogo JDBC. Por meio do PrepareStmt e do modo em lote, o desempenho dos usuários que gravam dados de volta no MySQL, Oracle e outros bancos de dados relacionais por meio do comando INSERT INTO e do Catálogo JDBC é aprimorado dezenas de vezes.

Suporte a serviços de dados simultâneos altos

Diferentemente das operações complexas de SQL e ETL em grande escala, em cenários de Serviço de Dados, como consulta de número de comprovante de transação bancária, consulta de apólice de agente de seguros, consulta de histórico de pedidos de comércio eletrônico, consulta de número de carta de porte expresso, etc., haverá um grande número de o pessoal de negócios da linha de frente e os usuários C-end precisam recuperar toda a linha de dados com base no ID da chave primária. No passado, essas necessidades geralmente exigiam a introdução de sistemas KV, como Apache HBase para lidar com consultas pontuais e Redis como uma camada de cache para compartilhar a pressão do sistema causada pela alta simultaneidade.

Para Apache Doris construído em um mecanismo de armazenamento colunar, tais consultas pontuais amplificarão IO de leitura aleatória em tabelas com centenas de colunas de largura, e o mecanismo de execução também trará grandes benefícios para a análise e distribuição de SQL tão simples. requer um método de execução mais eficiente e conciso. Portanto, na nova versão, introduzimos um novo armazenamento híbrido linha-coluna e cache em nível de linha, o que torna mais eficiente a leitura de toda a linha de dados de uma só vez e reduz consideravelmente o número de acessos ao disco. tempo, introduz otimização de caminho curto para consultas de ponto e ignora o mecanismo de execução. E usa diretamente o caminho de leitura rápido e eficiente para recuperar os dados necessários e introduz a reutilização de instruções preparadas para executar a análise SQL para reduzir a sobrecarga FE.

Por meio da série de otimizações acima, a versão Apache Doris 2.0 alcançou uma melhoria de ordem de magnitude na simultaneidade ! No teste de benchmark YCSB padrão, um único servidor de nuvem com 16 núcleos de memória 64G e especificações de disco rígido de 4 * 1T alcançou um desempenho simultâneo de 30.000 QPS de nó único, que é mais de 20 vezes maior do que a simultaneidade de consulta de ponto de versão anterior! Com base nos recursos acima, o Apache Doris pode atender melhor às necessidades de cenários de serviço de dados de alta simultaneidade, substituir os recursos do HBase em tais cenários e reduzir os custos de manutenção e armazenamento redundante de dados causados por pilhas de tecnologia complexas.

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/query-acceleration/hight-concurrent-point-query

Introdução detalhada: https://mp.weixin.qq.com/s/Ow77-kFMWXFxugFXjOPHhg

Sincronização de dados entre clusters CCR

Para atender às necessidades do usuário de sincronização de dados entre vários clusters, antigamente era necessário fazer backup e restaurar dados periodicamente por meio do comando Backup/Restore. A operação era mais complicada, o atraso na sincronização de dados era alto e intermediário armazenamento era necessário. Para atender às necessidades do usuário de sincronização automática de tabelas de banco de dados em vários clusters, na versão 2.0-beta adicionamos a função de sincronização de dados entre clusters CCR, que pode sincronizar as alterações de dados do cluster de origem para o cluster de destino em o nível da biblioteca/tabela para melhorar os serviços online Disponibilidade de dados e melhor implementação da separação de carga de leitura/gravação e backup em várias salas.

Dê suporte à implantação em contêiner do Kubernetes

No passado, o Apache Doris era baseado em comunicação IP. Ao implantar no ambiente K8s, o deslocamento do IP do pod devido a falha do host faria com que o cluster ficasse indisponível. Na versão 2.0, oferecemos suporte a FQDN, para que o Apache Doris possa ser implementado sem intervenção manual Auto-recuperação do nó, para que ele possa lidar melhor com a implantação do ambiente K8s e expansão e contração flexíveis.

Documento de referência: https://doris.apache.org/zh-CN/docs/dev/install/k8s-deploy/

Outras considerações de atualização

1.2-lts pode ser convertido para 2.0-beta, 2.0-alpha pode ser atualizado para 2.0-beta com tempo de inatividade;
A opção do otimizador de consulta é habilitada por padrão enable_nereids_planner=true;
O código não vetorizado foi removido do sistema, portanto o parâmetro enable_vectorized_engine não será mais válido;
Novo parâmetro enable_single_replica_compaction;
Por padrão, datev2, datetimev2 e decimalv3 são usados para criar tabelas e datev1, datetimev1 e decimalv2 não são suportados para criar tabelas;
Decimalv3 é usado por padrão no JDBC e no Iceberg Catalog;
tipo de data adicionado AGG_STATE;
Remova a coluna de cluster da tabela de back-end;
Para melhor compatibilidade com ferramentas de BI, datev2 e datetimev2 são exibidos como data e datahora quando show create table é exibido.
Adicionado max_openfiles e verificações de troca no script de inicialização do BE, portanto, se a configuração do sistema não for razoável, pode falhar ao iniciar;
É proibido efetuar login sem senha ao acessar o FE no localhost;
Quando há um Multi-Catálogo no sistema, os dados do esquema de informações da consulta exibem apenas os dados do catálogo interno por padrão;
Limite a profundidade da árvore de expressão, o padrão é 200;
array string valor de retorno aspas simples tornam-se aspas duplas;
Renomeie o nome do processo de Doris para DorisFE e DorisBE;

Embarque em uma jornada 2.0

Já se passou um mês e meio desde o lançamento da versão Apache Doris 2.0-alpha. Durante esse período, enquanto aceleramos o desenvolvimento de funções e recursos principais, também ganhamos experiência pessoal e feedback real de centenas de empresas no nova versão. Estes vêm de empresas reais O feedback da cena é de grande ajuda para o polimento e melhoria da função. Portanto, a versão 2.0-beta já oferece uma melhor experiência do usuário em termos de integridade funcional e estabilidade do sistema. Todos os usuários que precisam dos novos recursos da versão 2.0 são bem-vindos para implantar e atualizar.

Se você tiver alguma dúvida durante o processo de pesquisa, teste, implantação e atualização da versão 2.0, envie as informações do questionário e os principais colaboradores da comunidade fornecerão suporte especial 1-1 naquele momento. Também esperamos que a versão 2.0 forneça a mais usuários da comunidade uma experiência de análise unificada em tempo real. Acreditamos que a versão 2.0 do Apache Doris se tornará sua escolha ideal em cenários de análise em tempo real.

Versão beta do Apache Doris 2.0: desempenho de teste cego 10 vezes melhor, experiência de análise multicenário unificada