Apache Polaris Dev List Digest (1 a 5 de setembro 2025)

Apache Polaris Dev listar a votação no candidato de lançamento em 1.1.0 que a comunidade se concentrou em testes e votar no RC0 que incubatam o Polaris 1.1.0. Jean -Baptiste Onofré compartilhou o candidato Tarball, Commit ID, Helm Chart, Keys File e Maven Repository URLs e pediu a todos que verificassem assinaturas, realizassem testes e votassem dentro de 72 horas. Os colaboradores passaram por scripts de construção e testes de integração: Alexandre Dutra e Pierre LaPorte votaram +1 votos após a verificação de somas de cheques, assinaturas e realização de benchmarks de leitura/gravação. Russell Spitzer encontrou inicialmente uma falha relacionada ao DNS no RestCatalogKeyCloakfileit no macOS; Jean -Baptiste reproduziu o problema e sugeriu que era um problema de ambiente local, e não um bloqueador de liberação, propondo uma correção de acompanhamento, se necessário. Yufei Gu e Dmitri Bourlatchkov completaram seus próprios testes (incluindo testes de fumaça contra o Iceberg) e deram +1 votos. Com várias aprovações vinculativas e não vinculativas e sem bloqueadores críticos, a votação prosseguiu com sucesso. (Thread: G3MQHOVVX3670SPDPW25HC84D7JB1FJD) Adicionando um índice de metase JDBC Artur Rakhmatulin propôs adicionar um índice IDX_ENTITIDADES_LOOKUP ao Metastore JDBC Polaris. Ele explicou que o esquema existente apenas indexou as chaves primárias e as chaves estrangeiras, o que resultou em varreduras caras ao listar entidades. Seu benchmark no PostgreSQL mostrou que a adição de um índice de várias colunas em (Realm, Namespace, Name, Type) melhorou drasticamente o desempenho. Ele forneceu o SQL para o Postgres e o H2 e solicitou feedback sobre o Índice deve incluir o índice por padrão ou documentar -o como uma otimização opcional de desempenho. (Thread: TBXKJVMVQ3D62SXRR8M0Q88O79BV5P) A proposta de métricas operacionais Pierre LaPorte abriu uma discussão sobre a adição de métricas operacionais de dados a Polaris. Ele sugeriu criar um componente que agregue métricas de alto nível (por exemplo, arquivos totais, contagens de leitura/gravação, último tempo modificado) para mesas e vistas de iceberg. Pierre observou que apenas algumas métricas (número de arquivos, registros de data e hora das primeiras/últimas leitura/gravação) poderiam ser derivadas das métricas de iceberg existentes; O resto exigiria eventos da API de eventos futuros. Prashant Singh apoiou a idéia, apontando que métricas como a ScanMetrics são úteis para otimizar o layout e a compactação da tabela e que outros catálogos (como o gravitino) os expõem. O grupo concordou que a captura e as métricas persistentes em Polaris ajudaria os operadores a entender como os dados são usados. (Thread: 3R6KX6KXKV71NSM1H3P0C6N1) As alterações propuseram as respostas do OpenAPI Adnan Hemani propuseram a atualização da especificação Polaris OpenAPI, para que criem* os endpoints retornam o recurso recém -criado em vez de um corpo vazio. Ele argumentou que o retorno do recurso (como a RFC 9110 recomenda) melhora a usabilidade do cliente e facilita a geração de eventos. A proposta abrange APIs como CreateCatalog, CreatePrincipalRole, CreateCatalogrol, CreateNamesPace e terminais de integração/permissão. Adnan convidou feedback e disse que iniciaria uma votação se houvesse consenso da comunidade. (Tópico: K8KP3BB4P6XZ4HFFBJRVKCW3TOJY) A UI e as melhorias de integração Jean -Baptiste Onoofré retomaram o trabalho na interface do usuário Polaris e na experiência de integração. Ele compartilhou que os componentes iniciais estavam trabalhando contra o back -end e que planejava abrir uma solicitação de tração no repositório Polaris -Tools para obter feedback. Yufei Gu agradeceu pela atualização. (Thread: k8kp3bb4p6xz4hffbjrvkcw3tojy#ui) Fonte da tabela e API de tabela comum API Jean -Baptiste e Laurent revisitaram sua fonte de tabela Polaris e proposta de API da tabela comum. O design permite que o Polaris registre fontes de dados externas – arquivos estruturados (parquet, json, csv), blobs não estruturados (vídeo, imagens) e tabelas existentes – e envolvam -as em tabelas de iceberg enquanto reforçam a governança. Em 4 de setembro, a JB agradeceu aos colaboradores por suas perguntas e propôs uma reunião dedicada em 11 de setembro para discutir o relacionamento com a API da tabela genérica. Yufei Gu observou que várias negociações de Polaris estavam agendadas para 11 de setembro na Conferência do Conselho de Comitês e pediram para mudar a reunião para a semana seguinte. JB concordou em reagendar após a conferência. (Tópico: 95FB75Y25J9RNTZCGKIBJDVIBT) Preparando o relatório da incubadora de setembro Finalmente, Jean -Baptiste lembrou a todos que o relatório trimestral de incubador da Polaris foi previsto para o dia 25 de setembro. (Tópico: K8KP3BB4P6XZ4HFFBJRVKCW3TOJY#Incubator) Takeaway Durante a primeira semana de setembro de 2025, a comunidade Polaris Dev concentrou -se na finalização do candidato a release 1.1.0, melhorando o desempenho do Open Atranging através do novo JDBC Índice e projetar recursos como como o Metrics Operational Metrics e o Richer Richer. O trabalho na interface do usuário e na integração continuou, e a equipe agendou reuniões de acompanhamento para refinar a proposta de fonte de tabela enquanto coordenava a conferência do Conselho de Comitês da ASF. A semana também marcou o início dos preparativos para o relatório da incubadora de setembro.

Fonte