Hacker News Digest

Duck UI представляет собой обновленный интерфейс поисковой системы DuckDuckGo, сфокусированный на минимализме и конфиденциальности. Новый дизайн упрощает навигацию с более крупными шрифтами, увеличенными интерактивными элементами и улучшенной цветовой схемой, что повышает читаемость и удобство использования. Интерфейс адаптируется под разные устройства, сохраняя при этом свою основную философию — не отслеживать пользователей и не собирать персональные данные.

Ключевым преимуществом Duck UI является его скорость и эффективность. Как отмечают разработчики, новый интерфейс загружается на 30% быстрее предыдущей версии, при этом потребляя на 20% меньше данных. Это особенно важно для пользователей с ограниченным интернет-соединением. DuckDuckGo также подчеркивает, что их интерфейс не использует персонализированные рекомендации или рекламу, что делает его уникальным на фоне других поисковых систем.

• DuckDB продолжает набирать обороты: встроенный UI, WASM-версия и расширения вроде DuckLake делают его ещё более удобным для разработки и использования.
• Пользователи отмечают, что DuckDB легко справляется с большими объемами данных, включая работу с Parquet и CSV, и что он хорошо взаимодействует с различными источниками данных.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что UI DuckDB не является open-source, и что это может ограничивать вносимые улучшения.
• Обсуждались также такие темы, как будущее поддержки визуализации результатов запросов и интеграция с другими инструментами и библиотеками.

В США создана крупнейшая в мире база данных по коммерческим солнечным фермам. Она содержит 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 остаётся стандартом для обмена данными.
• Проблемы с устаревшими форматами и инструментами в биоинформатике частично связаны с трудностями финансирования их поддержки.

Формат файла SQLite

SQLite хранит всё состояние БД в одном файле.
Размер страницы — степень двойки 512–65 536 байт; номера страниц начинаются с 1, максимум 2³²-2.
Первая страница (512–100 байт) — заголовок:

• 16 байт: «SQLite format 3\000»
• 2 байт: размер страницы
• 1 байт: версия формата, 1 байт: версия для записи
• 1 байт: резервировано под расширения
• 1 байт: макс. доля переполнения
• 4 байт: счётчик изменений
• 4 байт: размер БД (страниц)
• 4 байт: свободные страницы
• 4 байт: схема-cookie
• 4 байт: формат схемы
• 4 байт: рекомендованный кэш
• 4 байт: vacuum-настройки
• 4 байт: кодировка текста
• 4 байт: пользовательская версия
• 4 байт: ID приложения
• 4 байт: версия библиотеки, 4 байт: «valid-for»
• 20 байт: резерв

Страницы бывают:

• b-tree (таблица/индекс, внутр./лист)
• freelist (trunk/leaf)
• переполнение payload
• pointer-map (ptrmap)

Схема
SQL-таблицы → b-tree, строки — последовательность записей (varint длина + payload).
WITHOUT ROWID → ключ в b-tree, дубли в PK убираются.
Индексы → отдельный b-tree, ключи с rowid.
Системные таблицы: sqlite_master (DDL), sqlite_sequence, sqlite_stat1-4.

Журналы
Rollback-journal: старая страница + заголовок.
WAL: кадры с новыми страницами, контрольная сумма, индекс в памяти.

• SQLite хвалят за идею «один файл = база» — она перекрывает недостатки форматов и SQL.
• Формат задокументирован до байта, работает по HTTP-диапазонам и читается с NFS, если только чтение.
• Предел 281 ТБ пока недостижим; реальные ограничения — файловая система и сбои железа.
• Повреждение страницы убивает весь файл, починить нельзя — нужна обратная совместимость.
• Для «пишем один раз» советуют Parquet + DuckDB: колонковый, неизменяемый, читается любым движком.

Две версии Parquet

DuckDB недавно описали, как SQL-движки, не реализовав полностью спецификацию Parquet, тормозят её развитие. То же происходит в экосистеме: после выхода моей библиотеки Carpet я включил v2 по умолчанию, но быстро откатил изменение — устаревший Pandas не читал такие файлы.

Почему v2 не внедрён

Спецификация готова, но нет согласия, какие именно фичи считать «ядром» v2. Обсуждение в apache/parquet-format длится четвёртый год. Смешиваются два независимых направления:

• новые кодировки (RLE_DICTIONARY, DELTA_BYTE_ARRAY) — ломают только столбец;
• новая структура страниц (Data Page V2) — ломает весь файл.

Логические типы (например, VARIANT) не привязаны к версии формата.

Альтернативы

В ML-среде Parquet и ORC стали тесны, поэтому появились форматы Nimble (Facebook) и LV2 (LanceDB), но в data-engineering Parquet остаётся королём.

Производительность v2

Достаточно выставить WriterVersion.PARQUET_2_0.

Датасет	Алгоритм	v1, МБ	v2, МБ	Δ
Италия	без сжатия	564	355	–37 %
Италия	SNAPPY	220	198	–10 %
NYC	без сжатия	760	511	–33 %
NYC	SNAPPY	542	480	–11 %

Новые кодировки лучше уплотняют данные до компрессии, поэтому выигрыш больше у несжатых файлов, а у ZSTD размер даже немного вырос.

• Parquet разделён на две версии: v2 экономит место и ускоряет чтение, но экосистема (Spark, Iceberg, Delta Lake и др.) всё ещё в основном на v1.
• Справочная реализация — гигантская Java-библиотека с 74 000 строк кода на каждую комбинацию кодировки, что вызывает сомнения в оптимальности.
• Совместимость между библиотеками (PyArrow, Fastparquet, Spark) долго была проблемой, как и разные версии Scala в Spark.
• Даже простые оптимизации (мета-данные о сортировке) фактически не используются, а многие разработчики не знали о существовании v2.
• Несмотря на критику, Parquet всё равно крупный шаг вперёд по сравнению с предыдущими форматами, и вопросы скорее в медленной эволюции стандарта, чем в самой идее.

• Самая быстрая и надежная 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), но общий тон — трезвый: дисциплина риск-менеджмента важнее «волшебных» моделей, а охота за стратегиями — глубокая и дорогостоящая нора.