Но вы правы, рынок очень узкий, перегретый и искать приходится от 4 до 8 месяцев. И вообще поиск - это non stop процесс, за последние три года ни разу не было ситуации, чтобы все вакансии аналитиков удалось закрыть...
Да, мы страемся прокачивать сотрудников и на внешнем обучении, но там уже более узкие темы, касающиеся, например, повышения навыков владения sql. Внутренне обучение у нас как правило касается управленческих навыков и оно для уровня team lead и выше
ТОП 10 по объемам таблицы в размере 5-10 млрд строк, хотя большинство конечно сильно меньше, но никто не жалуется на производительность
Говоря о SparkSQL или аналогах для Hadoop мы можем перейти на топик, что лучше Sparl или Hadoop- а это тема для отдельной большой статьи В любом случае соглашусь с вашим тезисом, что существуют надстройки , которые позволяют и к данным (структурированным) в DL применять SQL после небольших усилий, но я остаюсь на своем мнении, что удобнее/быстрее аналитикам это делать в DRMS/DWH. Правда, если речь идет о супер массивных разовых вычислениях, тут Spark конечно рулит, но когда аналитиков сотни, тут уже возикают другие проблемы...
Я знаю несколько реальных кейсов функционирующих DWH на GP. Там получается экономия на софте и железе, но как и с каждым OpenSource решение, чуть сложнее реализовывать и поддерживать относительно эталонных Oracle и Informatica. Если фактор стоимости не менее важен, чем скорость, надежность, производительность. В текущий момент. принимая решение о построении DWH, я бы очень сильно рекомендовал посмотреть в сторону GreenPlum
А вот что касается успешно реализованных до конца промышленных DWH (нормализованный детальный слой, слой общих агрегатов и т.п.) на основе Hadoop/Cloudera, то я их не знаю. Конечно, гигантам вроде Сбера и ВТБ некуда деваться и они вынуждены вымучивать такие решение , т.к. решений на RDBMS для их объемов простоя не существует, либо они (Teradata) начинают стоить совершено непотребных (даже для них) денег
А по поводу рук - и у Сбера и у ВТБ их много, и они платят очень большие деньги, чтобы они были "прямые". Многие ли это могут себе позволить?
Это тоже возможный вариант, когда DataLake может использоваться как слой для построение реплик состояния систем источников. Но при этом возникают свои минусы, когда в рамках сквозного очень жесткого по таймингу регламента формирования витрин, используются две различные системы, что неизбежно влечет снижение SLA
Кроме того, уже писал выше, что стандартный, привычный аналитикам sql в DataLake становится недоступен, проблемно делать элементарные джойны. Как следствие, adhoc не "гоняется", а мучительно рождается, с соответствующими пожеданиями здоровья со стороны аналитиков:( Когда аналитиков сотни, здоровья надолго не хватит:)
Для ЦБ в отличии от нас в масштабе всей банковской системы РФ, особенно принимая во внимание их планы получать raw data от банков, а не агрегаты как сейчас, это вполне по объемам потянет на термин BigData:)
Если вы говорите о доступе к данным через виртуализацию в рамках единого каталога данных, то это все же надстройка над DWH и DataLake в попытке унифицировать понимание, какие данные доступны в организации. Это хороший следующий шаг, но под капотом должны быть все те же хранилище и озеро данных и без них надстройка бессмыслена. Ну и опять таки, все те преимущества и недостатки, которые изначально присущи последним, остаются:)
Нет DS - это про других людей:)
Но вы правы, рынок очень узкий, перегретый и искать приходится от 4 до 8 месяцев. И вообще поиск - это non stop процесс, за последние три года ни разу не было ситуации, чтобы все вакансии аналитиков удалось закрыть...
Да, мы страемся прокачивать сотрудников и на внешнем обучении, но там уже более узкие темы, касающиеся, например, повышения навыков владения sql. Внутренне обучение у нас как правило касается управленческих навыков и оно для уровня team lead и выше
Спасибо!.
:)))
ТОП 10 по объемам таблицы в размере 5-10 млрд строк, хотя большинство конечно сильно меньше, но никто не жалуется на производительность
Говоря о SparkSQL или аналогах для Hadoop мы можем перейти на топик, что лучше Sparl или Hadoop- а это тема для отдельной большой статьи В любом случае соглашусь с вашим тезисом, что существуют надстройки , которые позволяют и к данным (структурированным) в DL применять SQL после небольших усилий, но я остаюсь на своем мнении, что удобнее/быстрее аналитикам это делать в DRMS/DWH. Правда, если речь идет о супер массивных разовых вычислениях, тут Spark конечно рулит, но когда аналитиков сотни, тут уже возикают другие проблемы...
Я знаю несколько реальных кейсов функционирующих DWH на GP. Там получается экономия на софте и железе, но как и с каждым OpenSource решение, чуть сложнее реализовывать и поддерживать относительно эталонных Oracle и Informatica. Если фактор стоимости не менее важен, чем скорость, надежность, производительность. В текущий момент. принимая решение о построении DWH, я бы очень сильно рекомендовал посмотреть в сторону GreenPlum
А вот что касается успешно реализованных до конца промышленных DWH (нормализованный детальный слой, слой общих агрегатов и т.п.) на основе Hadoop/Cloudera, то я их не знаю. Конечно, гигантам вроде Сбера и ВТБ некуда деваться и они вынуждены вымучивать такие решение , т.к. решений на RDBMS для их объемов простоя не существует, либо они (Teradata) начинают стоить совершено непотребных (даже для них) денег
А по поводу рук - и у Сбера и у ВТБ их много, и они платят очень большие деньги, чтобы они были "прямые". Многие ли это могут себе позволить?
Это тоже возможный вариант, когда DataLake может использоваться как слой для построение реплик состояния систем источников. Но при этом возникают свои минусы, когда в рамках сквозного очень жесткого по таймингу регламента формирования витрин, используются две различные системы, что неизбежно влечет снижение SLA
Кроме того, уже писал выше, что стандартный, привычный аналитикам sql в DataLake становится недоступен, проблемно делать элементарные джойны. Как следствие, adhoc не "гоняется", а мучительно рождается, с соответствующими пожеданиями здоровья со стороны аналитиков:( Когда аналитиков сотни, здоровья надолго не хватит:)
Подпишусь под каждым словом уточнения! Спасибо!
Для ЦБ в отличии от нас в масштабе всей банковской системы РФ, особенно принимая во внимание их планы получать raw data от банков, а не агрегаты как сейчас, это вполне по объемам потянет на термин BigData:)
У нас пруденциальная отчетность формируется на основе данных Хранилища, ведь речь идет о структурированных и отнюдь не big data
Если вы говорите о доступе к данным через виртуализацию в рамках единого каталога данных, то это все же надстройка над DWH и DataLake в попытке унифицировать понимание, какие данные доступны в организации. Это хороший следующий шаг, но под капотом должны быть все те же хранилище и озеро данных и без них надстройка бессмыслена. Ну и опять таки, все те преимущества и недостатки, которые изначально присущи последним, остаются:)