Розробка · 22 лютого 2018, 23:43 3494

Нестор Иванович, експерт по жабам та гадюкам

Альтернативы Apache Spark

Ок давайте внезапно поговорим про программирование а не про габариты колбасы в разных странах.

Есть такая задача — гонять аналитику поверх некого количества json файлов разнообразных форматов.
Текущее решение — крайние несколько месяцев лежат в MongoDB, экспортиться в MS BI и там аналитики делают что хотят.

Есть сильное желание делать аналитику с более глубокой историей.
Пока думал о дубовом пайплайне в духе
взять json — перегнать в паркет, дать что то типа Apache Zeppelin аналитикам в руки и успокоиться.
Данных не сильно много пока, десятки-сотни гигабайт в день

Мой вопрос собственно — какие подводные камни и не излишнее ли старперство пологаться на Spark в этом вопросе

Теми: Apache Spark

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Tamara Koliada Community Lead в Facebook 02.02.2020 17:08

Привіт! Запрошуємо всіх, хто цікавиться Apache Flink та роботою з великими даними на 𝘿𝙖𝙩𝙖 𝙨𝙩𝙧𝙚𝙖𝙢𝙞𝙣𝙜 𝙬𝙞𝙩𝙝 𝘼𝙥𝙖𝙘𝙝𝙚 𝙁𝙡𝙞𝙣𝙠 6 лютого!

Подія є безкоштовною за умови попередньої реєстрації.

Більше інформації : www.facebook.com/events/1009261019432222

Реєстрація : apacheflink.splashthat.com

Відповісти

Підтримати

Valeriy Zamarayev (junior lisper) 01.03.2018 23:07

Могу чуть больше рассказать про BigQuery. Я пощупал, и по ощущениям, довольно сильно похоже на внутренний гугловский Dremel, с которым я дружу последние 4,5 года. У меня, конечно, сильный bias, но ... Проще, в использовании, чем dremel, я бы сам хотел посмотреть, что может быть. Масштабируемо практически бесконечно, Проверено уже почти десятком лет работы. При этом, думаю, BQ на десятки/сотни гиг в день скорее всего будет обходиться в копейки.

С джоинами есть проблема, они работают, но медленней и на больших объемах может не осилить. Но на десятки/сотни гиг можно спокойно пробовать. Обычно работаем с сильно денормализированными данными в иерархических древовидных записях (в protocol buffers, не знаю, почему в BigQuery не показали наружу protocol buffers, а все json, я бы сказал, что это бы многое упростило). Так джоинов нужно мало. Если очень надо джоины и никак по другому не получается, то решается разновидностями мап-редьюсов (их современными воплощениями вроде Google cloud dataflow).

Я бы кучу json’ов слил в одну или несколько (мало) денормализованных структур (каким-нибудь мапредьюсом, (а то и просто загрузив в BQ, и там уже «insert ... select ...», джоины на сотню гигов-то отработают) и потом гонял любые запросы в BQ.

Это без риалтайма. По риалтайму не скажу, решения есть, но лично не пробовал. Личный опыт, конечно, про внутренний инструмент, но BigQuery реально очень похож, просто огламурен для внешнего мира, как по мне, слишком :)

(Тот момент, когда работаешь в Гугле, лопатишь петабайты, но по теме «общепринятых» инструментов ничего толком по теме не можешь сказать, потому что внутренняя кухня только начинает отражаться во внешне доступных инструментах и их аналогах. Простота важна, самый большой шок был, что работать со всей этой бигдатой очень просто, когда за тебя все инструменты запилили, добились, чтобы они хорошо работали вместе, и дали тебе в руки).

Відповісти

Підтримати

Нестор Иванович 03.04.2018 04:47

спасибо, интересный взгляд ( я вообще гугло тулы не рассматривал по очевидным причинам )
попробую в свободное время потыкать палкой в BigQuery

Відповісти

Підтримати

Valeriy Zamarayev

Alex Nitavskyi Software Engineer 28.02.2018 11:25

Если вдруг надо шустро перегонять data и делать какой-то процессинг, то может интересно будет глянуть на стриминг решение: flink.apache.org. Сегодняшний хайп — Kappa Architecture и с такими вещамми как Flink она становится не сложной.
А так data в Parquet, и Spark + Spark SQL через Apache Zeppelin для сотен GB — отлично подходит.

Відповісти

Підтримати

Нестор Иванович 28.02.2018 22:22

уже используем flink — просто не для аналитики, для горячего дашборда которій пользователи видят :)

Відповісти

Підтримати

Vitaliy Fedorchenko Founder в SeekTable.com 23.02.2018 12:35

Если не смутит разработчик, еще есть Yandex ClickHouse. Бесплатный, точнее платить прийдется временем, чтобы развернуть кластер и все настроить (впрочем, как и в любом опенсорсе). Несмотря на некую сыроватость, перфоманс этой молотилки может очень приятно удивить, есть все что нужно для тру real-time аналитики. Кстати, в нашей штукенции есть нативный коннектор к CH для ad hoc репортинга.

Відповісти

Підтримати

Ivan Bondarenko Data Tech Lead в WorldQuant Predictive 23.02.2018 11:25

Посмотрите на Apache Drill, отличный SQL Engine — умеет работать с различными источниками данных, запускается в стиле распаковал и запустил. В общем это такая Impala но без Hadoop стека.

Відповісти

Підтримати

Нестор Иванович 23.02.2018 11:51

спасибо, гляну. айтишники это тоже вспоминали

Відповісти

Підтримати

Ivan Bondarenko

Ivan Bondarenko Data Tech Lead в WorldQuant Predictive 23.02.2018 12:35

Удобно что schema-free, но есть подводный камень — join операции не полностью поддерживаются на файлах с различными схемами.

Например, если файл А с колонками id, name и файл B с колонками id, name_2 в папке «source» и файл С в папке «meta» c колонками id, age то запрос вида

SELECT s.id, s.name, m.age FROM source s JOIN meta m ON s.id = m.id

упадет.

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 23.02.2018 13:04

аха понял, у нас как раз схем для json тьма — Спасибо!

Відповісти

Підтримати

Ivan Bondarenko

Grez 23.02.2018 04:26

Да вроде спарк все еще на подьеме, активно разрабатываеться, итд.

Відповісти

Підтримати

Нестор Иванович 23.02.2018 04:29

ну я спрашиваю тут что называеться в порядке reality check — что я в своем fintech не отстал от всей планеты ( а то там помню были всякие strom и прочие)

Відповісти

Підтримати

Grez

Grez 23.02.2018 04:34

Ну, к примеру у нас, много чего меняеться туда сюда. Базы RedShift-MemSql-Snowflake, очередя kafka-kinesis, форматы данных flatBuffer-json-avro, даже среда mesos-kubernetes-amazonEMR. И среди всего этого зоопарка, спарк покачто самое стабильное звено.

Відповісти

Підтримати

Нестор Иванович

Grez 23.02.2018 04:36

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

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 23.02.2018 04:41

ну я вот думаю о том что бы цепелин прикрутить для дата сайнтистов. Пока они ябуться на прямую с монгой — так что думаю возражать не будут

Відповісти

Підтримати

Grez

Alexander Makeev Магистр кофеварки 23.02.2018 12:57

Поделитесь пожалуйста конфигурацией кластера Монги, в который вливается 100Гб в сутки

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 23.02.2018 13:06

там сейчас огрызок от того что реально необходимо, пардон ( реально наверно до 20 гигов не больше)- но новый клиент может сильно увеличить нагрузку, от сюда и эти пляски

Відповісти

Підтримати

Alexander Makeev

Родіон Миронов Director, Big Data and Analytics в SoftServe 23.02.2018 08:46

Связка PySpark + MLLib вполне себе работает.

Відповісти

Підтримати

Grez

code monkey 23.02.2018 04:22

Cosmos в Ажуре?

docs.microsoft.com/...re/cosmos-db/introduction

Відповісти

Підтримати

Нестор Иванович 23.02.2018 04:28

спс гляну
мы ibm shop но сильно смотрим в сторону сейчас

Відповісти

Підтримати

Дмитро 23.02.2018 08:12

Cosmos это таже монга с более разнообразным апи, к тому же для таких объемов данных это будет очень медленно и вполне вероятно дорого — azure для аналитики предлагают тот же spark либо подобные инструменты на их стеке azure.microsoft.com/...n-us/solutions/data-lake
docs.microsoft.com/...alytics-u-sql-get-started

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 28.02.2018 22:25

Azure Data Lake предолжение очень похоже на то что нам надо в принципе.

Відповісти

Підтримати

Олексій Пєніє 23.02.2018 02:18

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

Сотни гигабайт в день хранимых данных? Ну, привет, Роскомнадзор.
Я конечно понимая, что сохранить столько данных не ахти какая задача, только вопрос бабла. Но что ты такого хочешь намыть из этих данных потом, чего не можешь намыть сейчас? И сколько это будет стоить?

Или решил данные Большого Адронного проэксплойтить? Мне казалось, он меньше плодит.

Если же речь просто о возможности аналитики за более серьёзный период — что мешает тебе взять вторую Монго, и лить старые данные в неё? Подключить к ней второй комплект софта, чтобы те же аналитики могли при желании влезть.

Вообще-то фундаментально в таких вопросах меняется мало что и за десяток лет, разве только по ценам хранения и передачи. Ну и если биткоин просрётся, сильно подешевеет вычислительный ресурс. В остальном же — чем тебе Спарк не угодил? И через 10 лет вероятнее всего просто апдейтишь тот же Спарк, вопреки «врагам хорошего».

Відповісти

Підтримати

Нестор Иванович 23.02.2018 04:14

да устраивает, я скорее пытаюсь понять что я не оторвался от реальности state of the art с такими очевидными решениями.
решение со второй монгой тоже на столе ибо так будет проще всего.

Відповісти

Підтримати

Олексій Пєніє

Dmytro Kuznetsov разработчик 23.02.2018 16:22

Олексій, это в фин. сфере business as usual. Имею дело с не самой большой бд для аналитики (самая большая, как я слышал, раз так в 5-7 больше) — около 200G сжатых данных в день. Это больше 1T несжатых данных. Retention 2 года, потом в архивах еще какое-то время. «Ведь, если звезды зажигают — значит — это кому-нибудь нужно?».

Відповісти

Підтримати

Олексій Пєніє

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 21:25

Хороший кейс.
Каким клауд провайдером/стеком пользуетесь, как процессите и где храните такой объем ?

Відповісти

Підтримати

Dmytro Kuznetsov

Dmytro Kuznetsov разработчик 23.02.2018 21:47

2 горячих идентичных Гринплам кластера в двух разных дата центрах в Северной Америке. 20+ хостов в каждом. «Провесить» — что значит?

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 21:54

сорри
«как процессите и где храните такой объем ?»

2 горячих идентичных Гринплам кластера

Оч интересно. MPP Postgres based. Redshift отстает на пару лет. ( 8.0.2 vs 8.4 )

Відповісти

Підтримати

Dmytro Kuznetsov

Dmytro Kuznetsov разработчик 23.02.2018 21:59

Специально написанные загрузчики, работающие с разных хостов параллельно. Каждый тоже работает в несколько потоков. Shared nothing архитектура. Данные распределяются весьма равномерно среди хостов кластеров.

Відповісти

Підтримати

Олексій Пєніє 24.02.2018 07:27

Количество ≠ качество. Финансовая сфера, говоришь? Что-то мне подсказывает, их даже в мировых объёмах столько нет по первичке.

Биржевые торги роботами я не беру, там дерьма действительно хватает. Но опять же, дерьма. Аналитическая ценность этого дерьма = 1/∞

Я не спорю, большие данные существуют. И даже полезны. Вот только без предсказательной модели толку в них никакого. Уже потому, что реальными данными всё равно придётся человеку пользоваться. А раз так — то мы говорим именно о хранении данных, а не о доступной аналитике. Аналитика должна выполняться на лету, в крайнем случае периодически. И уже по этой аналитике можно как-то связывать сырые данные.

Разумеется, холивары разводить тут не стану. Здесь тема выбора софта. И с большими данными правило «лучшее враг хорошего» ещё никогда не подводило. А вот гонка за state of art — фиаско гарантирует.

Простой вопрос — ты действительно считаешь, что в этих данных может быть глубинный смысл, о котором догадаются только через 2 года? Тогда почему через 2, а не через 20? Или тогда становится понятно, что это уже ни разу не финансовая сфера, а нечто иное?

Я просто знаю как работает реальная BI, которая работает: на псевдо-рандомно выбранных данных. Ровно ничто не мешает сократить первичку, зачастую даже до сотни тысяч раз, чтобы результат не сдвинулся даже на тысячную долю. Если результат достаточен с точностью до полпроцента, там и вовсе ограничивают выборку десятком тысяч сэмплов.

Відповісти

Підтримати

Dmytro Kuznetsov

Нестор Иванович 24.02.2018 07:33

Про требования регуляторов рынка ты не слышал судя по всему никогда.

Відповісти

Підтримати

Олексій Пєніє

Олексій Пєніє 26.02.2018 11:49

Ну, очень малая сфера применения, где требования регуляторов рынка именно такие. И тем более не слышал, чтобы к этим требованиям ставилась задача не только хранения, но и быстрого построения аналитики по сырым данным за большой период.

Відповісти

Підтримати

Нестор Иванович

Dmytro Kuznetsov разработчик 24.02.2018 15:01

Да, действительно, данные в реальном времени — самые ценные для аналитики. На втором месте — intraday. Дальше — чем старше — тем меньше ценность. Вчерашние, и чуть более старые данные могут использоваться для анализа эффективности других систем. Остальное — для пост-фактумного анализа трендов, для отчетов, в том числе регуляторных, и чтоб соответствовать регуляторным требованиям к удержанию данных.

Відповісти

Підтримати

Олексій Пєніє

trimm Developer/Independent contributor в IDAP 23.02.2018 20:33

И через 10 лет вероятнее всего просто апдейтишь тот же Спарк, вопреки «врагам хорошего».

Что странно, в треде до сих пор нет ни одного гошника. Заболели, штоле.

Відповісти

Підтримати

Олексій Пєніє

Нестор Иванович 23.02.2018 21:06

Они просто не знаю что в spark есть Scala, а то уже бы доказали нам как онив этой нише всех победили

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 02:00

Data Lake + Big Query.
Для AWS это может быть Stream Processing + Athena

Відповісти

Підтримати

Нестор Иванович 23.02.2018 04:15

Big Query предложили наши айти чуваки к стати, да
Спасибо гляну на Kinesis и Athena тк возможно что єто и будет на AWS

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 06:38

Муваем с MS SQL на AWS связку Lambda + Kinesis + Athena + Glue/EMR + Redshift один дейта феед — около 1TB/month сырых данных. Прототип показал себя неплохо. Иду этим путем.

Відповісти

Підтримати

Нестор Иванович

anonymous 23.02.2018 09:52

Поподробнее, пожалуйста :) Мне всем этим придется заниматься на следующем проекте :)

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 11:12

Поподробнее займет неделю ;) Было перепробовано c десяток архитектур....
Раз тема техническая то можно пофлудить!

Если кратко, то есть у нас один дейта фид из-за которого и началась вся свистопляска.
Получаем через S3 (сам бог велел стриминг прикрутить) файлы, рандомно упакованные, в каждой строке по документу. Сами по себе доки неинтересны, для извлечения нужна трансформация XSLT. Но чтоб ее применит нужно мержить XML доки между собой по принципу LastNonEmpty между частями доков.

Поскольку основной DWH на MS SQL то был нарисовал SSIS, XSLT, server side logic.
Первый год паровоз еще ехал, с оптимизацие и зажиманием гаек по всем фронтам — columnstored indexes, compression via clr, partitioning. Два раза менял дизайн схемы, сотни тюнинг индексов и в итоге я сдался. На том железе EC2 R3.8XL. 32/256 мы не скелебл. Основной боттленек был в IO который не мог в теории превышать 800 MB/S. Это в теории, а на практике я наблюдал 300-500 макс.
Как только фид вырос до 4TB мы попросту стали не в состоянии контролировать время на деливери данных. В случае репроцессинга — вообще хватались за голову.

Ок. Первый концепт был такой — стримить с максимальной скоростью
Lambda (decompress, batching, enqueue) -> Kinesis -> Lambda (dequeue, REST to ELB for XSLT) -> SQL Server.
Собственно этот наскоро сделанный прототип показал себя как нельзя лучше. Удалось достигнуть стриминга End to End 5-6тыс док/сек. Запас по масштабированию остался.

С поддержкой NetCore 2.0 in Lambda я опробовал XSLT in Lambda & Kinesis FireHose.
Однако все это стримминг. Мы серьезно замыслились на Lambda Architecture by Nathan Marz.
Ибо еще нужно мигрировать сотню других фидс.

Для Data Lake опробовал кверять данные через Athena/Presto. Мое впечатление отличный сервис. Тестовый дасет в 400GB секционированный и разбитый на 100к файлов кверялся < 3 мин.
Второй сейт из 500 тыс мелких nested/json/gz кверялся в рамках 10 мин. Я остался доволен ибо скан происходил в районе 3GB/s. Недавно Athena обновлена до v0.192 видно что продукт развивается (или Presto ;))

Под ETL опробовали Glue с его кравлером. Пока это явно сырой продукт, еще и неторопливый. его, альтернатива Spark on EMR.

Также крайне великолепно показал себя Redshift как платформа с интегрированной возможностью LOAD(COPY)/UNLOAD. Мигрированный фид из MySQL размером в 0.5TB/2B rows/week импортировался в течении 2ч. Performance SQL DML — неплохо. Сравнимо с column stored indexes in MS SQL, но при увеличении кол-ва нод разница есть.

Под мой фид у меня есть крейзи архитектура использовать S3 как key value database. В принципе это не ново, вот только мне надо сторить 250 миллионов файлов с PUT/GET rate up to 10k/s и подобный use cases не нашел пока. Однако удалось достичь рейта 2k/sec без проблем. На днях другая команда запросила данные в подобном формате для 10M файлов, буду больше знать о прочности такого солюшна.

Kinesis: Все просто — действительно простой и надежный компонент для ingesting. Проблем не увидел. Kinesis FireHose — ждала засада — во всех кейс стади — просто подключи и поливай данными в S3/DataLake, да вот беда — нет возможности «поливать» в нужную папку в зависимости от типа фида.

Lambda: На данный момент опробован POC распараллеливания дейта процессинг через запуск множества экземпляров Lambda (Fan Out). Это своеобразный Map/Reduce но лично мне этот подход понравился больше всего. В рамках POC процесcилось 50k файлов/2TB compressed. Поддерживался уровень параллелизма — 500 лямбд.
Весь сет был обработан за 2ч. С учетом что можно ранить 1000+ экземпляров ламбд в параллель — архитектура оч скелейбл.

Ну это так — кратко.

В целом финальная архитектура нашего DSC близка к классической Lambda Architecture.
Рекомендую: www.manning.com/books/big-data
Вдохновила презентация проекта Socrate from Attlasian www.slideshare.net/...ws-glue-and-amazon-athena

по тэгу AWS re:invent на ютюбе пара презентаций на тему BigData/DataLake

ЗЫ не эксперт в AWS, только учусь

Відповісти

Підтримати

anonymous 23.02.2018 11:42

Ооо, спасибо! Не ожидал, что будет настолько подробно :) На самом деле сейчас это очень горячая тема, многие интересуются \ пробуют миграцию монолитных бд в клауд, AWS мне кажется в этом плане — лучший выбор. В общем, чувствую, следующие лет пять точно скучать не придется :)

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 20:08

Это было кратко. Поверь
Тема точно интересная! Azure мы рассматривали в теории без серъезного прототипирования, ибо заполучить аккаунт с PDWH не удалось, зато с AWS у меня картбланш в плане ресурсов.
В целом в плане сервисов для BigData у AWS полный порядок , однако мигрировать MS SQL в клауд от Azure. Чего только стоит USQL в связке с C#....

Відповісти

Підтримати

anonymous 25.02.2018 02:50

Охотно верю :) Вот еще есть интересная статья с точки зрения «классического дба» на вещи происходящие сейчас на рынке (проводится параллель Oracle RAC — AWS Aurora). Автор работает в небольшой изральской компании, они достаточно долго занимались консалтингом в области реляционных баз данных, сейчас партнеры Амазона, занимаются миграцией в клауд и опенсорсные бд. Дела у них идут весьма неплохо, не так давно обсуждал сотрудничество с ними, ну а в целом надо сказать, что такой работы и таких проектов становится все больше и больше. Думаю может Оракл еще подогреет рынок немного в ближайшее время, но имхо Амазон пока что лидер в этой области со своими решениями.

aws.amazon.com/...lternative-to-oracle-rac

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 25.02.2018 13:37

Эээ, простите, с чего он вдруг решил что RAC имеет какое-то отношение к HA? Я бы сказал, что как раз наоборот и эффект домино там очень ярко выражен.
Аврора, безусловно, интересная штука. Особенно в части репликации и синхронизации нод в кластере без использования логов (которые в случае того же оракла обычно жрут примерно половину перфоманса, забивая I/O). Если у кого-то есть более подробная инфа по ней — был бы рад почитать.

Відповісти

Підтримати

anonymous 26.02.2018 11:43

У Оракла есть серия продуктов\решений, которые относятся к HA и RAC — один из этих компонентов, также как и Active Data Guard, который может использоваться в связке с RAC. Другое дело, что вся эта обвязка в виде Oracle Clusterware + RAC + ADG сложна в настройке и эксплуатации и весьма недешева, поэтому компаниями и рассматриваются различные более дешевые\доступные альтернативы. AWS Redshift\Aurora — весьма годные варианты, имхо. Кстати, в той статье стоит также почитать комментарии, там весьма интересная дискуссия получилась как раз насчет RACa в качестве решения для HA.

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 26.02.2018 12:42

относятся к HA и RAC — один из этих компонентов,

Нет. Маркетингом это может преподноситься как угодно, но суровая правда показывает что порча fusion cache на любой ноде всегда приводит к падению всего кластера. Проблемы с сихронизацией кеша между нодами — тоже. Проблемы с записью на сторадж с любой ноды — аналогично.
RAC — сугубо решение для повышения производительности путем размазывания монолита на несколько физических серверов. Надежность при этом пропорционально понижается. И только если выводить ноды graceful shutdown, он переживет это. Что удобно для штатных работ на оборудовании-софте, но никак не на нештатных инцидентах.

Active Data Guard

Вот это в полной мере HA решение. Но оно существовало и до RAC и без оного.

весьма недешева

Сейчас это один из ключевых моментов, особенно на местном рынке. С коммодизацией серверов цена лицензий оракла уже превосходит цену железа в несколько десятков раз и всякий, предложивший реально работающие и надежные альтернативы, может рассчитывать на успех.

AWS Redshift\Aurora — весьма годные варианты, имхо.

Безусловно. Жаль, что они не предполагают онсайт установки (но это и понятно), а большинству наших крупных контор регуляции не позволят вынести финансовые данные в публичное облако.
Все же жутко интересно — что амазон переписал в ядре постгре, что ускорило его в 3 раза?

интересная дискуссия получилась как раз насчет RACa в качестве решения для HA

Там в основном теоретические постулаты, у нас же реальная статистика с сотен железяк, на которых это крутится и кейсов по отказам.

Відповісти

Підтримати

anonymous 26.02.2018 13:07

Да, RAC — сложный продукт и мультиплицирует все имеющиеся проблемы с производительность во множество раз, однако нужно понимать, что не бывает хороших и эффективных решений, если мы говорим о распределенных системах. Могу судить по опыту работы с той же Кассандрой, всегда приходится чем-то жертвовать. Но в любом случае, позиции Оракла все эти решения здорово подвинули, смысл платить много, если есть множество интересных и более дешевых или даже бесплатных решений. Сдвиг в сознании бизнеса и в целом на рынке сейчас колоссальный!

Пострес вообще интересный продукт, там много эффективных форков — все те же Redshift\Aurora, Greenplum или PostgreXL, который используется в крупных китайских финансовых учреждениях и телекомах.

Оракл сейчас активно грозится приватным\гибридным клаудом, который по идее и будет решать проблемы с онпремис установками, разве у Амазона нет подобных решений? Мне кажется, что это очень перспективный рынок, где в ближайшие 5-10 лет развернется нешуточная борьба

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 26.02.2018 13:20

Абсолютно согласен.
Сейчас очень много кто пытается найти альтернативы Ораклу.
Аврора способна за год-два поглотить практически весь малый и средний бизнес, не прибитый требованиями регуляторов к онпремис. Сейчас это уже скорее вопрос компетенций по миграции-переделки софта.
Крупные уже тоже нехило стонут от оракловской лицензионной политики и начинают поглядывать на тот же PostgresXL, EDB етц. По попугаям (TPC-C) EDB 10 сейчас отстает от оракла примерно на 40% и если амазон смог его ускорить хотя бы в 2 раза — уже бьет. Есть еще вопрос некоторой нестабильности результатов, надо будет на Aurore постестить, кстати.

Вангую что скоро для DBA со знанием оракла и Postgres/EDB/XL будет много работы. ;)

Відповісти

Підтримати

Oleksandr Katykhin 26.02.2018 14:26

Последнее время это уже не просто тренд, это устойчивая тенденция. Как минимум, два предложения недавно были, в требованиях — опыт миграции с оракла на постгрес. На фоне этого интересно смотрятся усилия компании Oracle по привлечению клиентов в свой клауд. Похоже, что для компании это уже борьба за выживание, а не попытка выиграть в конкурентной гонке.

Відповісти

Підтримати

anonymous 26.02.2018 14:55

Да, оракл сейчас активно продвигает свой клауд и заманивает клиентов новой функциональностью, такой как автономная бд, например. Что из этого у них выйдет — посмотрим, но одно понятно, что в плане стоимости решений они не подвинутся ни на цент, так что здесь Амазон пока что в более выигрышном положении.

Опыт работы с кассандрой\постгресом уже норма для большинства дба позиций. Также все хотят видеть опыт автоматизации (ансибл), опыт работы с контейнерами (докер, кубернетес), непрерывной интеграции — все плавно движется к девопс либо дата архитект области, тот же Оракл активно сейчас продвигает эту идею в массы

Відповісти

Підтримати

Oleksandr Katykhin

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 26.02.2018 20:18

все плавно движется к девопс либо дата архитект области, тот же Оракл активно сейчас продвигает эту идею в массы

Интересно при этом, что классический ИТ у enterprise (как основные клиенты оракла, SAP, etc) пока воспринимают эти вещи как модные базворды, т.к. разработка у большинства вынесена в аутсорс и ее методы их парят в последнюю очередь.
В то же время для сотрудников эксплуатации данный опыт весьма ценен, т.к. позволяет стартануть с легаси позиций на заметно более хлебные, но без хоть какой-то внутренней разработки оно катит плохо.
Пока позиции Оракла сильны (и это видно по его ценовой политике), но уже хорошо видно что так будет отнюдь не всегда. Да и лавры AWS и AZURE не дают покоя. ))

Відповісти

Підтримати

anonymous 26.02.2018 20:46

У Оракла как у корпорации есть одно большое преимущество — огромное бабло, плюс оракл дб — это тяжелый наркотик, раз попробовал, слезть с него очень тяжело. Тем не менее отставание от Амазона у них пока что колоссальное и выстрелит их клауд или не выстрелит — сказать пока что тяжело, но в этом направлении они бросили все свои силы.

Что касается тяжелого энтерпрайза — там пока что без изменений, все по старинке в большинстве случаев, однако много операционных позиций аутсорсится в более дешевые страны вроде Индии, Румынии и чуть более дорогие вроде Чехии, Польши. Но в целом, это плохая идея цепляться за подобные позиции, даже если есть, скажем, более 20 лет опыта в этой области. Сам Оракл заявляет о трансформации концепции дба в да, дата администратора или дата архитекта — доля правды в этом несомненно есть

Відповісти

Підтримати

anonymous 26.02.2018 14:47

Для чистых оракл дба сейчас настали нелегкие времена, тк позиций становится все меньше и меньше, зарплаты тоже падают. Немного лучше ситуация для дб девелоперов, но не особо. Сейчас типичная дба позиция включает в себя знание\сопровождение одновременно многих платформ, таких как Oracle\MS SQL\MySQL\PostgreSQL\Cassandra etc. Ну и клауд с автоматизацией тоже здорово подпирают, так что тут нужно или активно включаться в это все, либо сразу уходить в другую область, правилы игры поменялись и очень сильно.

Моя следующая позиция в Германии, например, будет связана с миграцией MS SQL в AWS RDS\Redshift\Aurora\Postgres, так что опыт в Оракле будет лишь вспомогательным. Сложно конечно менять область экспертизы, мне оракл как продукт очень нравится, но тут главное не цепляться за обломки каких-то старых воспоминаний, а двигаться вперед. Рынок диктует новые правила и нужно уметь под них быстро подстраиваться. Такой работы, по моим наблюдениям, становится все больше и больше.

Відповісти

Підтримати

Ivan Bondarenko Data Tech Lead в WorldQuant Predictive 23.02.2018 11:54

Fargate кстати не пробовали? У меня задача сделать скалируемую платформу для всякого Data Science (production models + adhoc calculation когда локальных ресурсов не хватает), Spark не подходит, так как нашим саентистам не хватает нужной функциональности в MLLib, к тому же данных у нас не очень много (пару терабайт), но расчеты очень тяжелые. Я вот смотрю на такую архитектуру:

S3 для хранения сырых данных, доступ к ним через Spectrum если нужно для дашбордов или аналитики.
Для DS моделей и research доступ напрямую к сырым данным из платформы для расчетов построенной на Dask + Fargate/EKS(Kubernetes) для различного рода метаданных.

Думал изначально про Lambda, но в случае Lambda очень много ограничений: размер deployment package + максимальное время работы.

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 20:44

Спасибо за наводку !
Не смотрел детально, поскольку не увидел как применить. Actually у меня немного другая задача — организовать дейта процессинг и дейта лейк, до того как придут дейта сцяентисты.

Лямбда тут не вписывается. Redshift Spectrum хороший вариант. Но по личным ощущением Spectrum это урезанная Athena

Відповісти

Підтримати

Ivan Bondarenko

Нестор Иванович 23.02.2018 11:58

Спасибо за кучу деталей по ’мясу’

Проблем с непредсказуемым latency у Lambda не было?

Відповісти

Підтримати

Нестор Иванович 23.02.2018 12:01

хотя в таком то случае на это наверно как раз насрать скорее всего

Відповісти

Підтримати

Нестор Иванович

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 20:21

Lambda показала себя отлично. Это действительно второй Big Things от AWS после S3.
Есть ограничения по памяти времени параллелизму однако это решаемо.

Например удалось «обойти» ограничение по времени, путем перезапуска функции и подмены параметров ивента. Что то типа рекурсии. Долго не мог найти подтверждения такого ворэраунда, на днях нашел в whiter papers. Поэтому POC в состоянии стримить 20GB файлы через лямбду

Проблема cold start решаема путем dry run или генерацией фейкового ивента на рег основе (2-3 мин). Однако для нашего кейса — дейта инжестинг, 3-5 сек задержки (С#) не критично совершенно. К слову когда демонстрировал POC для upper management пришлось поддерживать две лямбды в хот стейт. Для эффекта near real time.
То есть кидаешь файл в S3 и через 5 сек первые записи появляются в базе. Эффект потрясающий.

В целом затыков не было, работает четко и предсказуемо. Чтение запись на S3 где то 25-30MB/seс. С января поддерживается мультитрединг (2 потока)
Один только челендж — траблшутинг тяжкий

Відповісти

Підтримати

Нестор Иванович

Alexander Makeev Магистр кофеварки 23.02.2018 13:04

i3 инстансы с NVM дисками не пробовали, когда в iops упёрлись?

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 20:37

Уперлись не в IOPS а в instance bandwidth, который 10GBps или 800MBps в теории для 8XL.
на I3 не смотрели, как того следует. У нас сейчас около 16TB подключено через EBS provisioned SSD чтобы мувнутся пришлось бы брать i3 16XL. А потом мы уперлись в потолок. Как никак топовый инстанс, а количество данных таково что нет смысла платить за I3 и хранить сырые данные (не транзакционные). Да и менеджмент давно смотрел в сторону DataLake.
Поэтому raw/half baked данные — S3, OLTP — MS SQL, DWH — Redshift/Athena+S3

Відповісти

Підтримати

Alexander Makeev

Alexander Makeev Магистр кофеварки 23.02.2018 20:46

provisioned — дорогое удовольствие. Но я так понимаю с бюджетом проблем нет :) Спасибо за информацию!

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 20:57

клауд это недешево по определению. это маркетинг только звучит — pay-as-you-go а go постоянно происходит

Відповісти

Підтримати

Alexander Makeev

Нестор Иванович 23.02.2018 21:04

Ну без клаудов тоже не дешево как бы, особенно если compliance кучерявый. От цен на HMS и особенностей жизни с банками AWS кажеться белым и пушистым...

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 21:08

Я не спорю что что AWS дорог, но и дешевым его не назвал бы. Любой чих — плати. Еще один момент — коли перебрался на клауд — назад дороги практически нет. Это зависимость которую видишь опосля.

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 23.02.2018 21:10

У меня ситуация смешная- клауд есть но это softlayer. Это лютый леденящий душу пздц, после которого что угодно будет выглядеть котиком

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 21:24

Могу посочувствовать, если поможет ;)
Тяжко потом будет со знанием такого стека куда мувнутся ?

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 23.02.2018 21:35

Я стек этот вижу мало, я больше по интеграции ( ну вот и по части перезда на что то более вменяемое похоже)

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 21:06

Пожалуйста !
Да мы тратим на AWS туеву кучу денег. Бюджет есть. Но идея все же поиметь больше за те же деньги ;)

Відповісти

Підтримати

Alexander Makeev

Полная трехмерная копия Юры Буряка 23.02.2018 20:18

интересно было бы посмотреть сколько денег жрет этот зоопарк вместе с 1000+ распараллеленых лямбд

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 23.02.2018 20:55

Очень демократично. Cost of Ownership следует держать всегда в голове, иначе твоя архитектура — только красивая картинка.
По моим расчетам 500 лябмд/1536MB/2h. = 90$ ( 100 ms — 0.000002501$, 50k invocations — almost free).
Для бизнеса где данные это критическая часть — это не затраты.

ЗЫ бывают ситуации когда бизнес готов платить десятки тысяч $ в день — только сделай деливери, так вот в один из таких дней я понял что инструменты нужно расширять (не менять !).

Відповісти

Підтримати

Полная трехмерная копия Юры Буряка

Полная трехмерная копия Юры Буряка 24.02.2018 13:41

90$? вы же эти лямбды не раз запустить и забыть собираетесь?
в моей конторе на AWS инфраструктуру тратится 6-значная сумма в мес, но при упоминании лямбд все вертят носом мол та ну дорого

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 24.02.2018 21:21

Я видел наши биллы. OMG... Мы ранним сотню инстансов ес2 олько в нашем подразделении из них ms sql около 30. Один из таких инстансов обходится под 7к в месяц. И он не масшабируется. Ибо то что в нем хранится это сырые данные. Если даже процессить 5тб в день мы не превысим то что тратим на ес2. ( вопрос лицензий я вообще опускаю), но при этом мы имеем запас по масштабированию.
В целом нужно процессить сотню другую гиг в день. А это другие цифры, но когда аврал и нужно перепроцессить весь дейта сет с нуля — тут вопрос денег выходит на второй план.
А какая альтернатива ? EMR или Fargate ?

Відповісти

Підтримати

Полная трехмерная копия Юры Буряка

anonymous 26.02.2018 12:33

Да, мне тоже доводилось видеть статистику, цифры впечатляют. 10К+ в месяц только на виртуалки для небольшого кассандра кластера в Azure — легко. Плюс еще сторэдж — 2-3К и там еще по мелочам. И это только продакшн, не говоря о DEV\QA. Кто там говорил, что онпремис слишком дорого обходится? :)

Відповісти

Підтримати

Kostiantyn Reu Sr. Principal Data Engineer в GoodRx 28.02.2018 01:49

Позволю уточнить. Оказывается я дважды ошибся.
Провели ревью aws биллов. тратим суммы, гораздо больше 1M./year
а на мигрируемый инстанс от ~12к/month (опять же без учета лизенций)

Відповісти

Підтримати

Нестор Иванович 28.02.2018 06:06

у нас хотя бы ms sql нету
я начал смотреть на azure оферинг тоже сейчас-HDInsight похоже может покрыть нашу задачу с коробки

Відповісти

Підтримати

Alex 23.02.2018 22:02

красиво

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись