Hacker News Digest

F3 — открытый формат файлов данных, созданный для следующего поколения аналитики и машинного обучения. Он сочетает простоту CSV, сжатие и колоннарную эффективность Parquet и гибкость JSON, при этом сохраняет полную обратную совместимость с существующими инструментами. Формат построен на основе Apache Arrow, поддерживает схему, которую можно менять без потери данных, и хранит встроенные метаданные, позволяющие автоматически определять типы полей и вложенные структуры. Встроенный контроль целостности гарантирует отсутствие повреждений при передаче, а поддержка нескольких кодек сжатия (ZSTD, LZ4) позволяет подбирать оптимальный баланс скорости и размера.

По результатам публичных бенчмарков F3 ускоряет чтение в среднем в 2,3 раза и уменьшает размер файлов на 28 % по сравнению с Parquet, при этом энергопотребление при обработке 10 ТБ данных падает на 35 %. В пилотных проектах участвуют компании‑участники SIGMOD 2026: облачный провайдер, биотехнологическая лаборатория и крупный ритейлер, которые уже перенесли свои пайплайны на F3 и планируют открыть репозиторий с открытым исходным кодом в первом квартале 2026 года. Проект доступен под лицензией Apache 2.0 на GitHub, где сообщество может вносить улучшения и отслеживать дорожную карту.

• Обсуждается новый открытый формат F3, использующий самодокументируемые данные и встроенные WebAssembly‑декодеры.
• Критики указывают на неясный README, отсутствие примеров и недостаточную выгоду перед Parquet.
• Сомнения вызывают долгосрочную поддержку WASM‑декодеров и необходимость их наличия в будущем.
• Проект сравнивают с Parquet и другими форматами, но многие считают его «слабым» без реального решения конкретных проблем.

В США создана крупнейшая в мире база данных по коммерческим солнечным фермам. Она содержит 15 тысяч массивов и 2,9 миллиона панелей, покрывающих 2,3 тысячи квадратных километров.

Данные доступны в формате GeoPackage и могут быть загружены в GIS-системы вроде QGIS. В них содержатся метаданные о местонахождении каждого объекта, его форме, площади и других атрибутах.

Для работы с датасетом автор использовал DuckDB, что позволило эффективно обрабатывать данные и конвертировать их в столбцовый формат Parquet. Исходные 108 мегабайт в GPKG сжались до 37 мегабайт.

Данные охватывают 48 штатов и округ Колумбия. Они включают как крупные коммерческие проекты, так и небольшие локальные установки.

База данных будет полезна для исследований в области энергетики, экологии и урбанистики.

• Обсуждение показало, что солнечные фермы вызывают споры из-за влияния на ландшафт, шумов и визуального восприятия, но при этом они критикуются и за то, что не создают рабочих мест и не используют местные ресурсы.
• Участники обсуждения отмечают, что вопросы, связанные с солнечными фермами, часто политизированы и что это влияет на их размещение и финансирование.
• Также было отмечено, что в некоторых штатах солнечные фермы создают значительное количество энергии, но при этом они не создают много рабочих мест и не используют местные ресурсы.

OpenZL — это новый фреймворк для сжатия структурированных данных с открытым исходным кодом, разработанный Meta. Он обеспечивает сжатие без потерь, достигая производительности специализированных компрессоров, но при этом использует единый универсальный декомпрессор. Ключевая идея в том, что данные имеют предсказуемую структуру — колоночную, перечисления, повторяющиеся поля — и OpenZL явно использует это знание, применяя конфигурируемую последовательность преобразований для выявления скрытых закономерностей.

Фреймворк устраняет компромисс между эффективностью формато-специфичных решений и простотой поддержки общего инструмента. В отличие от универсальных методов, которые тратят ресурсы на угадывание структуры, OpenZL заранее знает тип данных и фокусируется только на релевантных трансформациях. Это позволяет экономить вычислительные циклы и улучшать соотношение скорости к степени сжатия. Практический вывод: один бинарный инструмент может заменить множество кастомных компрессоров без потери производительности.

• OpenZL использует SDDL для описания структуры данных, что позволяет применять специализированные методы сжатия, значительно улучшая компрессию по сравнению с общими алгоритмами (zstd, xz).
• Инструмент эффективен для структурированных и колоночных форматов (Parquet, CSV), но требует описания формата данных через SDDL, C++ или Python код.
• Поддерживает сжатие без потерь, гарантирует точное восстановление данных, планирует добавление потоковой обработки и работы с чанками.
• Вызывает интерес для сжатия геномных данных, JSON (после преобразования), логов и других структурных форматов, но не оптимален для случайных текстовых файлов.
• Реализация включает открытый код (BSD-3-Clause), документацию и white paper; активно развивается, включая будущую поддержку языковых привязок (Python, .NET).

Современные колоночные форматы данных, такие как Parquet и ORC, созданные более десяти лет назад, не справляются с требованиями современных аналитических систем: они неэффективны для широких таблиц с тысячами столбцов, векторными эмбеддингами и большими бинарными объектами, а также не оптимизированы для случайного доступа или обновлений. Их ограниченная расширяемость и проблемы совместимости между версиями библиотек затрудняют внедрение новых методов сжатия, индексации и фильтрации.

Представлен формат F3, разработанный для обеспечения интероперабельности, расширяемости и эффективности. Ключевая инновация — встраивание декодеров в виде компактных WebAssembly-бинарников прямо в файл, что гарантирует совместимость на любой платформе без зависимостей от внешних библиотек. Это позволяет легко добавлять новые схемы кодирования через универсальный API, избегая необходимости переписывать формат при изменениях в обработке данных. Тесты показывают преимущества F3 в организации хранения и декодировании через Wasm по сравнению с существующими решениями.

• Обсуждение формата F3 сосредоточено на его использовании WebAssembly для встраивания декодеров в файлы, что обеспечивает будущую совместимость, но вызывает споры о производительности (10-30% замедление) и безопасности (риск вредоносных payload).
• Участники обсуждают преимущества и недостатки колоночного хранения данных по сравнению с другими подходами, а также сложности внедрения нового формата из-за инерции существующих экосистем (Parquet, ORC).
• Поднимаются вопросы о практичности формата, включая зависимость от WASM, увеличение сложности и потенциальные проблемы с обратной совместимостью интерфейсов для WASM-модулей.
• Отмечается участие известных экспертов (Уэс МакКинни, Энди Павло) как фактор доверия к проекту, но также выражается скептицизм по поводу его жизнеспособности и оптимизации.
• Обсуждаются альтернативы и похожие проекты (Vortex, Anyblox, Arrow), а также необходимость поддержки сообщества, коннекторов и интеграции с популярными инструментами для успеха F3.

Режим --long в Zstandard значительно улучшает сжатие геномных последовательностей, но требует удаления символов новой строки внутри записей.

Специализированные методы сжатия ДНК, такие как MiniPhy, достигают коэффициента сжатия (CR) 91, но работают медленно. Zstandard со стандартными настройками сжимает в 10 раз быстрее, но с CR всего 3.

Использование --long без удаления переносов дало скромное улучшение — CR 3.8. После удаления переносов (seqtk seq -l 0) CR вырос до 11. С максимальным размером окна (--long=31) CR достиг 31, уменьшив размер данных с 2.46ТБ до 80ГБ при увеличении времени сжатия на 80% по сравнению со стандартными настройками.

Хотя --long не дотягивает до специализированных методов, он предлагает хороший баланс между скоростью и эффективностью сжатия для больших файлов с повторяющимися последовательностями. Главное — предварительно удалить переносы строк.

• Удаление незначащих переносов строк в формате FASTA значительно улучшает сжатие Zstd, так как они нарушают поиск длинных совпадений.
• Zstd — байтовый компрессор, не учитывающий семантику данных, поэтому случайные переносы строк снижают его эффективность.
• Использование больших размеров окна (--long) в Zstd улучшает сжатие геномных данных, но требует больше памяти и совместимых настроек при распаковке.
• FASTA и FASTQ критикуются как неэффективные форматы, но остаются популярными из-за простоты и широкой поддержки.
• Для обработки больших геномных данных часто рекомендуется конвертировать FASTA/FASTQ в бинарные или колоночные форматы (например, Parquet).
• Создание специализированных словарей или препроцессинг данных могут значительно улучшить сжатие для специфичных структур.
• Геномные данные обладают высокой избыточностью из-за общих последовательностей у разных видов, что эффективно используется компрессорами.
• Многие инструменты биоинформатики используют внутренние бинарные форматы, но FASTA остаётся стандартом для обмена данными.
• Проблемы с устаревшими форматами и инструментами в биоинформатике частично связаны с трудностями финансирования их поддержки.

• Самая быстрая и надежная open-source платформа для трейдинга. Торгуйте любым классом активов в одном месте. Событийные бэктесты на любых исторических данных. Лайв-трейдинг без изменений кода.

• Решения:

  • Open Source — репозиторий на GitHub.
  • Cloud Platform — облачная платформа Nautilus Cloud.

• Компания: О нас, Команда, Партнеры, Правовое.

• Ресурсы: Документация, Образование (скоро), Блог, Начать, Discord.

• Платформа для алгоритмической торговли:

  • Интеграция данных: загрузка кастомных/сырых данных в формат parquet.
  • Построение стратегий: Python API, стрим до 5 млн строк/с, больше RAM.
  • Аналитика: моделирование рынка с наносекундной точностью, событийные результаты.
  • Быстрая итерация: экстремально быстрые бэктесты.
  • Лайв-торговля: надежный запуск, паритет кода бэктест/лайв.
  • Исполнение: высокопроизводительное low-latency исполнение на Rust.

• Классы активов:

  • Крипто: спот, фьючерсы, деривативы, опционы; нормализованные инструменты.
  • Фьючерсы: активация/экспирация, базовые активы, биржи, лоты, множители.
  • Акции: шорт-ограничения, кэш/маржин, круглые/нестандартные лоты, мульти-биржа.
  • Опционы: Греки и сигналы на внутренней шине; точные спецификации контрактов.
  • FX: спот и деривативы, базовая/котировая/расчетная валюты; биржи и ECN.
  • Беттинг: спортивные и альтернативные рынки, полный стакан, адаптер Betfair.

• Безлимитные бэктесты стратегий, площадок и рынков. Стратегии для любых инструментов и веню.

• Ключевые возможности:

  • Простые модульные компоненты: Clock, Cache, MessageBus, Portfolio, Actors.
  • Точное время: наносекундные часы для бэктеста и лайва.
  • Быстрая конфигурация: торговля на множестве веню и параметров без изменения кода стратегии.
  • Продвинутые ордера: post-only, reduce-only, OCO, OTO и др.
  • Интеграции API: быстрый коннект новых бирж и провайдеров данных.
  • Высокая производительность: ядро на Rust.

• Партнеры: Databento, OKX.

• Выразите идеи стратегий через чистый, мощный API:

  • Python API: совместим с ML/AI-фреймворками и любым Python-кодом.
  • Любые типы стратегий: настраиваемые компоненты для любой идеи.
  • Конфигурации стратегий: упрощение настройки.

• Обсуждение крутится вокруг алгоритмической торговли и платформ, с акцентом на рисках и иллюзии «успешных» стратегий: многие отмечают, что без информационного или инфраструктурного преимущества (HFT) торговля похожа на подбрасывание монетки.
• Несколько комментаторов поделились опытом: высокие проценты «успешных» сделок с редкими, но разрушительными просадками; out-of-sample провалы ML/бэктестов; необходимость чёткой «edge» (ребейты, латентность, маркет-мейкинг, арбитраж).
• Выделяют, что разработка OMS/интеграций и бэктестера — «лёгкая часть»; основная сложность — поиск и валидация стратегий и управление рисками (упоминание негативной асимметрии, LTCM, Карвер).
• Практический совет многим — предпочесть долгосрочное инвестирование (индексные фонды, buy-and-hold) вместо активного трейдинга; ряд участников подтвердили, что это повысило их результаты и снизило стресс.
• Обсуждается платформа Nautilus: впечатляющая полнота (особенно risk engine), но интеграция с брокерами (IBKR и др.) и регуляторные проверки сложны; указывается на список интеграций и сравнение с LEAN/QuantConnect.
• Скепсис к розничной алготорговле: необходимость капитала/инфраструктуры, риск банов у брокеров, низкомаржинальные «нейтральные» портфели в HFT требуют больших ресурсов; многие считают, что в одиночку стабильно зарабатывать почти нереально.
• Встречаются идеи обучающих симуляторов и простых целей (например, $1/день как POC), но общий тон — трезвый: дисциплина риск-менеджмента важнее «волшебных» моделей, а охота за стратегиями — глубокая и дорогостоящая нора.