Комментарии 11
Не понятно, какие задачи в итоге решаются, и для чего :)
Никакие. Сайт «Пятёрочки» один из самых глючных, тормозных и неудобных среди всех ритейлеров. Не меняется годами. Баги там не переводятся и большинство прям детские, а с тех пор как они перешли на «x5 id» без слёз этим поделием пользоваться практически нет возможности.
Зато приятно узнать, что в их ИТ-отделе люди выучили много модных терминов.
Задача - предоставить данные всем подразделениям компании "по потребностям", а именно с требуемой детализацией, актуальностью и в нужной степени нормализации. Классические подходы складывания всего и вся в DataLake уже не удовлетворяют потребностям бизнеса, поэтому рождаются разнообразные решения, о которых идёт речь в статье.
В части данных речь не идёт о регулярном взаимодействии система-система, централизованное хранилище предоставляет данные для анализа и использования в экосистемах доменов/продуктов в сценариях: различного рода прогнозы (товаров на полках, загруженности тех же касс и много другого), ML, BI-отчётность для многих задач от анализа вчерашнего дня/недели до оперативного воздействия при задержке выполнения какой-то задачи сотрудником (тут как раз нужна высокая актуальность данных) и любые другие сценарии использования данных.
Ну, смотря что именно работает. Данные собираются и раздаются условно для всех 18 тысяч магазинов (на самом деле для проектов над ними в разных конфигурация по сетям, локации и пр.), в рамках этих проектов могут быть реализованы и вопрощены в жизнь разные модели. Ну думаю, что факт наличия данных в DWH как-то связан с оценкой единичной точкой сети, но уверен, что в рамках развития всей сети улучшение сервисов централизации корпоративных данных и улучшение качества, актуальности и пр. данных в будущем исключительно положительно скажется на пользовательского опыте. DWH - не готовая рыбка, а удочка, которую можно использовать в меру своих возможностей.
А что в данном контексте подразумевается под СИ? Средства интеграции, сервисная инфраструктура, совокупность инструментов, etc?
Заканчивался 2021 год, а люди продолжали ссылать на "тестирование in-memory" от 2016 года имени Димы Павлова :) :)
И дело даже не в сроках (хотя автор понимает что ситуация могла сильно измениться за такой срок). Дело в методике. Вы же не думаете что в реальной жизни в вашей системе будет работать 1 запрос? Системы тестируют под большой конкурентной нагрузкой в десятки с сотни запросов на входе.
"Тиньки" тестировали для узкой аналитической(!) задачи, а в вашем архитектурном подходе in-mem для других целей предполагается. И на самом деле он вам не нужен для задач online загрузки. Эту задачу решает time series хранилище. In-mem нужен тогда и только тогда когда нужен общий кэш с сервисами данных. Для всех остальных задача - это за уши притянутая история
Как внимательный читатель я конечно же не мог не заметить магическое число 3. Число это выбрано вами не потому что они магическое, а потому что изначальная платформа вокруг которой стали проектировать ландшафт не может решить все задачи "в одной коробке". Вот и приходится обрастать соседями. Это нормальная история когда есть легаси вокруг которого нужно строить.
Но когда вы проектируете с нуля и предлагаете гетерогенную архитектуру - это очень плохо! Каждая точка интеграции - потенциальная точка отказа. Каждая система - отдельное железо, отдельная команда и экспертиза, отдельная ролевая модель доступа и пляски с информационной безопасностью и тд. Минусов много больше чем плюсов.
Если бы была система, способная решать все задачи, вами обозначенные, вы бы пошли в историю с множеством систем?
Характер использования: конечно не 1 запрос, и даже не тысячи и их характер сильно различается.
Типы DWH: да, есть Time series и много других типов хранилищ, которые хорошо решают некий круг задач и плохо - другой. В извложенной выше концепции Streaming покрывает не только супер-актуальные данные продаж (которые нужны не только в онлайн-режиме), а также много другой информации, которая требуется например в режиме t-10m, какая-то для моментальной реакции, а какая-то для аналитики и пр. Что-то грузится в режиме Streaming только ввиду колоссального объёма данных и технической невозможности одноразово вытащить подобный объём в Batch-режиме.
Приведённое сравнение in-memory действительно не самое удачное, но ничего более подходящего не нашёл. Отдельно отмечу, что на цветной архитектуре TO-BE с 3 уровнями платформ темпорально-ориентированные БД условно есть, точнее некоторые можно использовать подобным образом (ClickHouse например: https://clickhouse.com/docs/en/single/#can-i-use-clickhouse-as-a-time-series-database).Один за всех: К сожалению подобной платформы, удовлетворяющей всем потребностям, на горизонте не видится (особенно с учётом п.1). Насчёт проектирования "с нуля" не совсем согласен, т.к. есть понимание текущих процессов, потоков данных и запросов к ним, откуда вытекает ряд потребностей, не покрываемых (особенно в перспективе ближайших лет) "золотой рыбкой" где оперативные данные и архив, аналитические запросы и high-load, оптимальная стоимость по лицензиям, железу (и его доступности во времена кризиса микросхем), сопровождению, наличию специалистов на рынке и т.д.
Задачи потоковой аналитики - это задачи анализа данных во временном окне. Для удержания окна на глубину анализа in-memory не нужен. С этим справляется k-v. Под ногами той же kafka streams лежит банальный rocks который разруливает очень высокую нагрузку в онлайн оконной аналитике.
Такая платформа как ни странно существует. Имя ей Cloudera Data Platform. Попробуйте назвать задачу с которой она не справится. Спойлер - под high load нагрузкой система ведет себя лучше чем большинство традиционных mpp систем, включая упомянутые вами ранее.
Посмотрите на snowflake За ними будушее.
ЗаETLье или Особенности рыбалки в Озере данных