У него есть разные стратегии для таблиц. Есть copy on write когда он вмердживает все в паркет на этапе записи. Это для батча. А есть merge on read, когда новые данные наваливаются рядом в авро и периодически на этапе чтения вмердживаются. Это для стриминга. И есть ещё запросы оптимизированные на чтение и чтение по ключу.
по-моему Copy-on-Write это такой очень специальный мердж, там вроде свою логику (когда по пачке колонок, к примеру) нельзя поставить
вообще худи видно что работающее, батл-тестед, решение, но видно что оно писалось постепенно для каких-то очень практических задач.. и архитектура такая, патчворк, взять ту же синхронизацию с хайв
как показывает практика, отсутствие схемы есть серьёзное конкурентное преимущество, потому как позволяет консюмить любые датасеты. теоретически. но отсутствие схемы не позволяет юзать spark sql и похожие вещи. вот мне и интересно, не сделал ли уже кто-нить аналог linq чтобы самому его не писать.
как показывает практика, отсутствие схемы есть серьёзное конкурентное преимущество, потому как позволяет консюмить любые датасеты. теоретически. но отсутствие схемы не позволяет юзать spark sql и похожие вещи. вот мне и интересно, не сделал ли уже кто-нить аналог linq чтобы самому его не писать.
у меня тут чё. у меня тут разнородные датасеты с кучей полей, к которым хочется сделать SELECT, но схема ни фига не задана. известно, что в каждой записи есть штук пять более-менее одинаковых пропертей, и вот по ним хочется чё-нить выбрать для анализа