Спасибо за вопросы, постараюсь ответить) Первое что хотелось бы сразу написать, что код в статье - без пяти минут "псевдо код", начиная от SQL, заканчивая скриптами. Хотелось сделать акцент на подходе, а не на коде для ентерпрайза, поэтому осталось только сутевая часть, которая конечно же далека от идеала. В статье описан подход близкий к лямбда-архитектуре, на это и был сделан упор.
Ответы
Основной, про s3) ну что есть, то есть))) Дешевое хранилище, его и используем. Куда еще складывать террабайты и петабайты данных
Второй вопрос. Про базу. Да можно и взять вторую, не вопрос. Только надолго ли хватит. Ну не запихаешь же ж всё на свете в базу данных. Не террабайты ж там держать. И дорого и смысла нет. Зачем там хранить сырые старые данные, которые можно сгрузить в дешевую хранилку и пользоваться раз в неделю. А то что есть возможность поверх s3 делать sql запросы, это опция. Кому не нужно, тот не пользуется. В описанном кейсе просто это мне было удобно для объединения данных из s3 + бд (горячие). Как по мне, прикольная фича
Третий вопрос. Абсолютно верно. В статье эта логика не указана, но в прод решении без этого никак. И метку временную надо отмечать, и watermark делать, и переносить данные в диапазоне времени, чтобы не потерять данные за время выполнения скрипта. И контролировать транзакционность, и партицировать данные спарком нужно и логику обработки битых данных делать за заданное число (или за интервал времени). Конечно же это всё вынесено за скобки.
Четвёртый вопрос. "Данных не уменьшилось, а работы увеличилось" - и данных не уменьшилось, и работы увеличилось. НО! Теперь все данные на своих местах и решена проблема масштабируемости данных. Теперь хоть удвой, хоть утрой их кол-во, s3 все примет, как и спарк всё обработает. Агрегаты по этим данным считаются спарком очень быстро. Быстрее чем на стороне БД
"в чём ускорение работы отчётов то получилось" так теперь отчет строится из пред-агрегатов, выполненных спарком (которые весят копейки) и горячих данных в базе за последние пару дней (также копейки). Другими словами, всё самую сложную работу, которая до этого выполняла БД, теперь в зоне ответсвенности спарка + s3. Ему на входе террабайты, на выходе мегабайты (это ж свертка данных). Ну и юнион свертки данных по факту и ускорил работу
Я очень надеюсь что ответил на вопросы) может не так подробно как хотелось бы, но я старался)
Добрый день!
Спасибо за вопросы, постараюсь ответить)
Первое что хотелось бы сразу написать, что код в статье - без пяти минут "псевдо код", начиная от SQL, заканчивая скриптами. Хотелось сделать акцент на подходе, а не на коде для ентерпрайза, поэтому осталось только сутевая часть, которая конечно же далека от идеала. В статье описан подход близкий к лямбда-архитектуре, на это и был сделан упор.
Ответы
Основной, про s3) ну что есть, то есть))) Дешевое хранилище, его и используем. Куда еще складывать террабайты и петабайты данных
Второй вопрос. Про базу. Да можно и взять вторую, не вопрос. Только надолго ли хватит. Ну не запихаешь же ж всё на свете в базу данных. Не террабайты ж там держать. И дорого и смысла нет. Зачем там хранить сырые старые данные, которые можно сгрузить в дешевую хранилку и пользоваться раз в неделю. А то что есть возможность поверх s3 делать sql запросы, это опция. Кому не нужно, тот не пользуется. В описанном кейсе просто это мне было удобно для объединения данных из s3 + бд (горячие). Как по мне, прикольная фича
Третий вопрос. Абсолютно верно. В статье эта логика не указана, но в прод решении без этого никак. И метку временную надо отмечать, и watermark делать, и переносить данные в диапазоне времени, чтобы не потерять данные за время выполнения скрипта. И контролировать транзакционность, и партицировать данные спарком нужно и логику обработки битых данных делать за заданное число (или за интервал времени). Конечно же это всё вынесено за скобки.
Четвёртый вопрос. "Данных не уменьшилось, а работы увеличилось" - и данных не уменьшилось, и работы увеличилось. НО! Теперь все данные на своих местах и решена проблема масштабируемости данных. Теперь хоть удвой, хоть утрой их кол-во, s3 все примет, как и спарк всё обработает. Агрегаты по этим данным считаются спарком очень быстро. Быстрее чем на стороне БД
"в чём ускорение работы отчётов то получилось" так теперь отчет строится из пред-агрегатов, выполненных спарком (которые весят копейки) и горячих данных в базе за последние пару дней (также копейки). Другими словами, всё самую сложную работу, которая до этого выполняла БД, теперь в зоне ответсвенности спарка + s3. Ему на входе террабайты, на выходе мегабайты (это ж свертка данных). Ну и юнион свертки данных по факту и ускорил работу
Я очень надеюсь что ответил на вопросы) может не так подробно как хотелось бы, но я старался)