Много разных техник можно придумать. ГГ упоминали, есть informatica cdc. Можно внедрить какие-то cdc техники в исходной базе, типа timestamp/id последнего изменения, где-то это встроено (version в ms sql), организовать индексный доступ, чтобы минимизировать нагрузку на дисковую систему. Можно делать копию вчерашнего дня аппаратными средствами (технология bcv, например). Если есть standby(типа Oracle adg) и его не очень жалко, можно его подзадрочить.

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

а новую delta lake еще никто не пробывал?
https://databricks.com/product/databricks-delta

Пока есть хотелка

В сбт вот как-то пытались затолкать конский поток cdc базы процессинга в ходуп, вроде, так ничего и не вышло. Уперлись в ddl и синхронизацию потоков с разных сетевых интерфейсов. Не знаю, чем кончилось.

Это не про атомарные апдейты, сразу скажу)

про delta - это действительно удобно, но подходит когда вы хотите делать прям МНОГО апдейтов за раз. Для realtime кейсов не подходит от слова "совсем".
А так, если вы раз в час делаете merge into - это да, это удобно

еще бонусом - она довольно медленная, если у вас небольшой кластер, настолько что мы отказались от нее и придумали свой велосипед вокруг паркета, назвав его merge-less approach. И да, дельтовые таблицы по непонятным причинам могут весить сильно больше, чем аналогичные снепшоты по времени в паркете

спасибо за ответ, вы ее использовали когда она еще не опенсорусная была, ее вроде выложили только на прошедшем саммите?

да, до опенсурса, за опенсурсную версию ничего сказать не могу.
У нас был такой юзкейс - есть табличка в 1ТБ, в ней нужно из стриминга делать апдейты - около 1000 вставок в минуту прилетает. Спарк стриминг приложение на 4 хостах xlarge выполняло merge этой тысячи строк за 40 минут, что в нашем юзкейсе совсем не подходит.
В связи с этим мы переписали подход на чистом паркете, без merge into и с множественными снепшотами, которые раз в день кладутся в память - это ускорило наш процесс в 3 раза, но все еще нехватает, поэтому мы сейчас думаем над тем чтобы вообще перестать писать в паркет промежуточные данные и все это в KV залить (тут встает вопрос в какой KV), туда апзертить объекты и потом результат апзерта писать дальше на потребителей

но у нас кейс довольно специфичный - у нас nested-структуры, и жесткие SLA на апдейты и размер кластера для стриминга. Если у вас свое собственное железо, и вам не жалко держать 60 ядер для стриминга - наверное delta подойдет.

привет

Народ, подскажите - есть ли возможность писать JavaDStream в  HDFS не генеря множество файлов? сейчас пишет вот такой код
       records.repartition(1).foreachRDD(rdd -> {
           if (!rdd.isEmpty()) {
               Dataset<Row> dataset = sqlContext.createDataFrame(rdd, LogLine.class);
               dataset
                   .write()
                   .partitionBy("year", "month", "day")
                   .mode(SaveMode.Append)
                   .format("orc")
                   .save("hdfs://cluster/tmp/some/folder");
           }
       });
который на каждый записанный датасет создает отдельный файл

может есть возможность писать стрим без итерации по rdd ?

Хочется апендить непосредственно в файл новый датафрейм ?

по сути да

Самим спарком никак, это и не выгодно было бы

OGG4BD доведённый до промышленного состояния собственными ручками, патченный своими же ручками Sqoop, собственная Spark-джоба с поддержкой партиционирования снэпшота в parquet с логикой обработки схлопки PK update (если применимо к источнику)

Больно наверное на джаве писать под спарк

Мы компактим раз в сутки