Комментарии 5
Гладко было на бумаге… А не было ли цифр, сколько они собираются обрабатывать? Что-то со Спарком у нас складывается не всё так радостно и весело, как обещают такие доклады.
Их целевая архитектура соответствует современным тенденциям в проектировании систем обработки данных, этакая смесь Data Lake + Lambda Architecture. Но вот сделана она не совсем так как надо, да и возможно человек, читавший этот доклад, не является автором предлагаемой архитектуры
По проблемам (последний слайд с архитектурой):
1. Продюссер «P» должен находиться перед OLTP системой, а не после нее. После OLTP уже можно делать стандартную выгрузку в хранилище или же CDC
2. Архитектура с Spark Streaming не имеет особых преимуществ при отсутствии потребителя real-time данных, вроде каких-либо real-time отчетов или других аналогичных систем
3. Стрелка между HDFS и Spark Streaming двухсторонняя, это вообще непонятно зачем. Данные тут должны идти только в одну сторону — от источника в виде Kafka в HDFS
4. Непонятно, зачем сюда запихнули Tachyon — для быстрой отчетности есть OLAP в виде какой-нибудь MPP RDBMS, зачем поднимать данные в память из HDFS и получать к ним доступ через Hive — непонятно, все равно ведь быстрее MPP не получится, да и дорого. Тут скорее нужна еще стрелка из ETL, работающего на Hadoop, в их OLAP-хранилище
В целом же можно реализовать подобную архитектуру и более красиво,
Проблема только в том, что подобный дизайн нужно закладывать изначально, иначе миграция будет по сути равносильна переписыванию всего с нуля, чему бизнес явно не обрадуется. Скоро должен выйти подкаст от Pivotal, где я буду рассказывать об этой архитектуре
По проблемам (последний слайд с архитектурой):
1. Продюссер «P» должен находиться перед OLTP системой, а не после нее. После OLTP уже можно делать стандартную выгрузку в хранилище или же CDC
2. Архитектура с Spark Streaming не имеет особых преимуществ при отсутствии потребителя real-time данных, вроде каких-либо real-time отчетов или других аналогичных систем
3. Стрелка между HDFS и Spark Streaming двухсторонняя, это вообще непонятно зачем. Данные тут должны идти только в одну сторону — от источника в виде Kafka в HDFS
4. Непонятно, зачем сюда запихнули Tachyon — для быстрой отчетности есть OLAP в виде какой-нибудь MPP RDBMS, зачем поднимать данные в память из HDFS и получать к ним доступ через Hive — непонятно, все равно ведь быстрее MPP не получится, да и дорого. Тут скорее нужна еще стрелка из ETL, работающего на Hadoop, в их OLAP-хранилище
В целом же можно реализовать подобную архитектуру и более красиво,
как-то так
RTI — real-time intelligence, STG — staging, FE — front-end, BE — back-end, SP — stored procedure, ES — Event Store, Srv — Web Service
RTI — real-time intelligence, STG — staging, FE — front-end, BE — back-end, SP — stored procedure, ES — Event Store, Srv — Web Service
Проблема только в том, что подобный дизайн нужно закладывать изначально, иначе миграция будет по сути равносильна переписыванию всего с нуля, чему бизнес явно не обрадуется. Скоро должен выйти подкаст от Pivotal, где я буду рассказывать об этой архитектуре
Спасибо за развернутый коммент!
1 — Да, наверное это правильно, чтобы продюсер был до OLTP, но это или UI переписывать или (если есть) App Layer.
Все-таки читать логи как-то проще звучит. И продать легче.
2 — Докладчик говорил что некоторые ETL-и длятся часами, я не очень понял на каком участке происходил затык, но может архитектура со Spark Streaming поможет убрать (сгладить) пиковые нагрузки. Т.е. эти часы распределятся на весь день. Тогда конечно что-то другое просядет…
3 — возможно двусторонняя связь Kafka — HDFS, вернее Spark — HDFS, означает что данные приходят из обоих источников, а результаты идут в HDFS.
4 — Tachyon — похоже что это просто кэш.
Было бы интересно послушать доклад о Вашей архитектуре. Не для применения, а развития для :)
1 — Да, наверное это правильно, чтобы продюсер был до OLTP, но это или UI переписывать или (если есть) App Layer.
Все-таки читать логи как-то проще звучит. И продать легче.
2 — Докладчик говорил что некоторые ETL-и длятся часами, я не очень понял на каком участке происходил затык, но может архитектура со Spark Streaming поможет убрать (сгладить) пиковые нагрузки. Т.е. эти часы распределятся на весь день. Тогда конечно что-то другое просядет…
3 — возможно двусторонняя связь Kafka — HDFS, вернее Spark — HDFS, означает что данные приходят из обоих источников, а результаты идут в HDFS.
4 — Tachyon — похоже что это просто кэш.
Было бы интересно послушать доклад о Вашей архитектуре. Не для применения, а развития для :)
1 — Читать логи СУБД CDC умеет уже 10 лет, и никаких модных Kafka и Spark Streaming для этого не нужно
2 — Тут вопрос в том, что real-time обработка данных зачастую дороже в плане ресурсов CPU и IO, чем batch-обработка (если имеется в виду именно одинаковая обработка). То есть растянуть нагрузку на весь день — плохой вариант. А хороший — это оставить процесс ETL для OLTP системы в покое, пусть он собирает данные из Kafka и раз в день запускает ту же логику на 4 часа. Другой же процесс, читающий те же самые данные, производит агрегацию в реальном времени. Допустим, пример из телекома: с предбиллинга сыпятся данные о вызовах, в real-time системе производится их агрегация по базовым станциям для показа статистики обрывов соединений в реальном времени на карте, а в batch-систему данные складываются «as is» и обрабатываются ночными ETL-процессами, строящими разные витрины и считающими KPI
3 — Конкретно на последней картинке двухсторонняя связь означает, что данные загружаются в HDFS, после чего кем-то пушатся в Spark Streaming, который их затем складывает в OLTP систему. Вопрос в том, что между HDFS и OLTP системами Spark Streaming не нужен: какой смысл в real-time системе, находящейся между двумя batch-системами?
4 — Я о том, что «горячие» данные должны лежать в OLTP, а «холодные» — в HDFS. Tachyon здесь — попытка работать с «горячими» данными в HDFS, где их по определению быть не должно. Уверяю вас, Tachyon + Hive будет в разы медленнее среднего MPP, а так как данные лежат только в памяти, эта связка будет еще и дороже и сложнее в управлении
2 — Тут вопрос в том, что real-time обработка данных зачастую дороже в плане ресурсов CPU и IO, чем batch-обработка (если имеется в виду именно одинаковая обработка). То есть растянуть нагрузку на весь день — плохой вариант. А хороший — это оставить процесс ETL для OLTP системы в покое, пусть он собирает данные из Kafka и раз в день запускает ту же логику на 4 часа. Другой же процесс, читающий те же самые данные, производит агрегацию в реальном времени. Допустим, пример из телекома: с предбиллинга сыпятся данные о вызовах, в real-time системе производится их агрегация по базовым станциям для показа статистики обрывов соединений в реальном времени на карте, а в batch-систему данные складываются «as is» и обрабатываются ночными ETL-процессами, строящими разные витрины и считающими KPI
3 — Конкретно на последней картинке двухсторонняя связь означает, что данные загружаются в HDFS, после чего кем-то пушатся в Spark Streaming, который их затем складывает в OLTP систему. Вопрос в том, что между HDFS и OLTP системами Spark Streaming не нужен: какой смысл в real-time системе, находящейся между двумя batch-системами?
4 — Я о том, что «горячие» данные должны лежать в OLTP, а «холодные» — в HDFS. Tachyon здесь — попытка работать с «горячими» данными в HDFS, где их по определению быть не должно. Уверяю вас, Tachyon + Hive будет в разы медленнее среднего MPP, а так как данные лежат только в памяти, эта связка будет еще и дороже и сложнее в управлении
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Разрывая ETL барьеры с помощью Spark Streaming» от Concur. Отчет о встрече