|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Бумбараш, спасибо за вопрос. Помогите мне разобраться. Вообще, думаю, коллективно легче будет.. Я просто свои мысли накидаю, очень буду благодарен за комментарии и конструктивную критику, особенно по части хранилищ. Начнем с общих определений, как информация доходит до конечного пользователя. Пользователь <-> система визуализации <- ADWH <- Источники данных (т.ч. DWH / DataLake) С "Системой визуализации", надеюсь, все понятно. PBI, Excel, ряд специализированных систем (Табло) и т.д. Что я имею в виду под ADWH? Это "чистые" (достоверные) данные (прошедшие контроль качества) и рассчитанные показатели на их основе, пригодные и предназначенные для принятия управленческих решений. Обычно не он-лайн, есть лаг в несколько часов или даже дней. Больше ничего там нет - только необходимые для аналитический отчетов данные. Могут ли там лежать транзакции и прочие детальные данные? Да, если это необходимо для принятия управленческих решений (моделирования, прогнозирования и т.д.), но данная система категорически не предназначена для хранения исторических данных. Фактический, это слепок / выгрузка необходимых данных с заданным уровнем визуализации из систем хранения данных. Под ADWH я подразумеваю класс или подкласс систем, описывающих вышеуказанную задачу - это может быть и витрина / Datamart, или кубы / OLAP / специализированные системы для ускорения работы с данными и передачи их в визуализатор - Vertica, Greenplum и т.п. То есть основная задача - хранить подготовленные данные с приемлемым уровнем актуальности и достоверности и быстро выдавать их по запросу пользователю через интерфейс визуализатора (ну или прямым запросом, это на любителя). Происходит ли подготовка данных в ADWH? Да, происходит. Рассчитываются агрегаты, показатели, можно посчитать общее и потом в отдельное поле проставить доли, чтобы система быстрее работала на типовых запросах можно обработать данные (при загрузке или сразу после загрузки), и ввести отдельные поля, дающие ответ на часто задаваемый вопрос - дней с последнего платежа или покупки, кол-во уникальных (лучше заранее просчитать, чем Distinct Count'ом потом систему мучить, а это может быть критично при работе с большим кол-вом данных), или флажок там взвести - sum по отфильтрованным всяко легче отработать чем тот же Distinct Count. Т.е. обработка данных там происходит. Откуда же ADWH берет данные? В идеале - из DWH, а еще лучше если она является ее подмодулем. Кстати, сейчас все больше примеров подобных гибридов - реляционка DWH и ADWH поколонка: одна быстро пишет данные, вторая быстро их вытаскивает. Но, как говориться, возможны варианты, особенно когда мы в сценарии начинаем рассматривать возможность использования DataLake. Теперь давайте о том, что же необходимо хранить в DWH?? 1. DWH ни в коем разе не должен быть "копией" транзакционной базы - это сисадминские дела, хранилище не для этого. Все-таки, DWH предназначен для построения отчетности. Следовательно, пихать туда "а это еще может пригодиться, вдруг понадобиться" - скоро получим кладбище данных, к 90% которых ни разу не обращались. В DWH должны попадать данные из разных систем и там же должен быть осуществлен процесс "чистки" данных. Возможно разделение на зоны "грязные" данные и "чистые" (с методологией очистки, чистки выбросов, насыщением необходимой аналитической информацией и т.д. Или только "чистые" при наличии доступа к транзакционным системам с "грязными" данными. Это говорит о том, что в DWH также происходит преобразование информации, как на уровне загрузки, так и процессинг загруженных данных. 2. Следовательно, состав данных в DWH - зависит от ADWH, и, соответственно, от задач пользователей. Возможно и избыточное хранение данных - ряд данных нужен для расчета сводных показателей и выгрузки в ADWH или даже для [возможного] прямого от пользователя. 3. И именно в DWH необходимо хранить исторические данные. Например, для расчета прогнозов. Или "разбора полетов". Или LFL или построения отчетов / выгрузки в ADWH исторических данных для расчета подобных показателей. Таким образом мой посыл такой - уже на выходе из DWH мы имеем чистые данные, пригодные для дальнейшего анализа. ADWH - это надстройка, которая позволяет быстрее с ними работать - оперативный слепок. Да, ряд показателей рассчитывается, но только по этому слепку, чтобы не вносить лишние преобразования. А вот теперь вопрос - что мы грузим в DataLake? И стоит ли туда грузить структурированные данные? Мой личный ответ - нет, структурированные данные туда грузить не стоит. Их лучше сразу загонять в DWH. Тут мы подходим к другим проблемам 1. Отсутствия необходимых данных. Т.е. если натравить ИИ / ML (да даже простой datamining) на нашу описанную выше DWH, то эти системы на найдут корреляции между спросом и структурой спроса и погодой и курсами доллара / Евро / стоимостью нефти. Почему? Да потому что их там нет! Мои проекты по DM на 80% состояли из поиска и загрузки релевантных данных, потом уже отсматривали корреляции, убирая случайные. <-здесь подробнее надо будет 2. Данные есть, Отсутствие знаний / алгоритмов / поиска ценности в этих данных. Например, проект в МЭС. Ну, например, есть данные по всем электросчетчикам г. Москвы. И что? Майнеров вычислять? Когда народ дома бывает и в отпуск / на дачу ездит? Что делать-то с ними?? Т.е. данные есть, а ценности (пока) не видно. [Ценность - в совокупности разных данных - раскрыть тему] Я считаю, что в DL необходимо грузить сырые данные, но проводить над ними [пост]обработку. Причем результаты этой обработки могут быть как сохранены в DL (насыщение данных, тегирование, связывание данных с мастер-справочниками и с "чистыми" данными DHW), так и извлеченные знания необходимо уже переносить в DWH. Т.е. пока мы туда кладем слабоструктурированные "сырцы" - видео, записи разговоров, тексты книг, датасатанисты извлекают ценность, которая уже идет в DWH/ADWH. А те же чеки - вот еще вопрос, стоит ли их хранить в DL, так как они хорошо структурированы! Вопрос, как их обратно правильно извлечь, учитывая что BigData - это, в первую очередь контекст и релавантность. Т.е. я по запросу "Чек номер 1 000 000" не ожидаю, кроме чека с №1000000 (есть он есть) получить чек с суммой 1000000 рублей или чек с книжкой "Миллион рецептов борща", "как завести миллион друзей" или "Как заработать первый миллион, тираж 2 000, стоимость 500 рублей" - а так и будет при неаккуратной работой с BigData! Стоит ли "все" данные грузить в DL - большой вопрос. С одной стороны - нет, мы же не Плюшкины. С другой - а кто знает, какая ценность в них скрыта, и как они поведут себя при насыщении с имеющимися данными? Как я и говорил, Ценность - в совокупности разных данных. То есть сегодня мы просто храним записи камер, и потом подключили распознавание лиц. Сначала просто пол / возраст, а потом связали с кассой и временем. И получили корзину конкретного покупателя! а если он картой платил - то и ФИ. В общем, очень заманчивые для маркетинга возможности появляются. Надо просто знать, какую задачу решать, и как. Кто что думает, кто чем дополнит? С Уважением, Георгий ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2018, 18:02 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
George Nordic, насчет чистки. Что можно, то нужно чистить - были бы ресурсы, опыт и желание. А GIGO надо предотвращать в момент зарождения в исходных системах, если это не чужие внешние данные, на которые слабо влиять можем. Как правило, влиять на источники внутри компании - это административная борьба восходящая к Топ - менеджменту. Никто не будет, например, править хлам в кредитных заявках годичной давности. Имеется ввиду дозаполнение атрибутов и устранение нелогизмов. Это нужно тогда повторный ввод с первичных документов. Да и первички уже может не быть. Главное что - продажи! Продали и забыли, живем "сегодняшним днем". И тех уже спонсоров и разрабов нет. А чтобы точкой зарождения классификаторов и справочников, равноудаленной от всех систем и запитывпющей все системы стал MDM - это та еще притча. Положим, есть MDM, но вместе с тем и локальные Экселя с доп. правильными атрибутами живут. А потом - многолетний MDM это изнурительный труд. И он тоже сходит на нет, т.к. движуха, текучка и опять же - главное - торгануть и свалить. В DWH надо тянуть про запас, но не откровенный шлак. Ибо когда бизнес допрет, созреет, схватится - и понеслось скорей, скорей давайте закачивать то, чем пренебрегли ранее. Опять же историчные данные брать уже негде будет / GIGO / нет ресурсов. Дорога ложка к обеду, и если у вас в DWH поболее чем только ложки, то и ценность другая. Удалить ненужное не так долго, ломать - не строить. Куда чаще встречаются дублирующиеся таблицы, платформы, дублирующиеся кланы отделы, строителей DWH, витрин, кубов и прочих слоев бескультурного наследия ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2018, 20:33 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
George NordicКто что думает, кто чем дополнит? Билл Инмон дополнил в 2016. прочитайте, советую. George NordicВопрос, как их обратно правильно извлечь, учитывая что BigData - это, в первую очередь контекст и релавантность. Т.е. я по запросу "Чек номер 1 000 000" не ожидаю, кроме чека с №1000000 (есть он есть) получить чек с суммой 1000000 рублей или чек с книжкой "Миллион рецептов борща", "как завести миллион друзей" или "Как заработать первый миллион, тираж 2 000, стоимость 500 рублей" - а так и будет при неаккуратной работой с BigData! поверьте, в хадупе есть разные форматы хранения и в том числе те что на select * from table where field=1000000 в состоянии вернуть те же строки что и реляционная субд. и вы не сможете записать "борщ" в field, если поле нумерикал объявили. например в колончатые форматы parquet, orc. еще есть kudu - сторидж на хадупе практически со всеми атрибутами рсубд. по мне так копирование структурированных данных с data lake, по нетворку, в настоящую реляционную DWH должно приносить серьезный бонус. если бонуса нет, нет смысла и копировать. хадупы далеки до идеала, работа с файликами, в том числе структурированными имеет свою специфику, но очищенные и структурированные данные прямо в хадупе вполне рабочий вариант, который открывает дорогу и к реал-тайм аналитике и к более эффективным вариантам анализа, прямо там, где данные лежат. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2018, 21:27 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
В целом вроде все об одном и том же говорят, только немного разными словами и с разными акцентами. Попытаюсь обобщить для себя: - сваливать данные в DL без их "маркировки" и подготовки - это формирование свалки, в которой потом не разберёшься; - до сих пор много активностей по DL (не все конечно) - это скорее дань маркетингу, чем осознанный шаг, связанный с необходимостью работы с большими объёмами данных и плохо структурированной информацией с применением соотв.аппарата по анализу накопленных данных (то есть сначала начнём накапливать и может пытаться анализировать, а потом посмотрим, что из этого выйдет); - от реляционных СУБД и хранилищ данных бежать не стоит - просто так чуда с DL не случится - менять шило на мыло смысла нет для "стандартных" задач большинства Заказчиков, а для развития в сторону DL нужно осознание новых целей, с которыми устоявщийся подход не эффективен. По теме... Data Lake как Staging Area (именно Staging Area, а не хранилка впрок)... А нафига? Объёмы в SA сильно больше того, что пойдёт дальше в DWH? В этом плане обратная выгрузка старых данных из традиционного DWH выглядит более привлекательной - освобождаем дорогую систему от старых данных, но выгрузка старых данных в Hadoop такую архивную систему Data Lake-ом не делает... То же и со складированием информации впрок... Боевые системы могут значительно меняться, и разобраться в данных из прошлого, основываясь на знаниях сегодняшнего дня, может быть очень сложной задачей. То есть дай человеку текущие данные, опиши, как система работает сегодня, а потом дай данные, скажем, двух летней давности, и можно встрять с их анализом, найдётся например какая-нибудь классификация, которая сегодня уже не нужна и не используется, которая просто умерла... И что, разбираться что там было и означало? То есть с моей точки зрения тупое складирование на будущее - это странность схожая тому, как складируются вещи дома на всякий случай (старое пальто, лыжи на балконе, деталюшки всякие прикольные...). Нужно снабжать складируемые данные дополнительной информацией, которая потом позволит понять, что сложено, откуда взято и т.д... Тупо сваливать, вдруг пригодится - не выглядит рационально. А вот делать действительно упорядоченную систему хранения и анализа больших объёмов, из которой что-то, возможно, можно докинуть в том числе и в стандартное DWH, работающее рядышком (пока и если оно не будет заменено полностью на DL поверх Hadoop) - это уже другое дело. Только цель нужно видеть хотя бы примерно прежде, чем за это браться - нужно вот это и не могу сделать на том, что есть, с теми данными, что имею, в том виде, в котором они представлены. Конечно, DL нужны, но всем ли? Иногда кажется, что рынок разгоняют тем, что пугают, что кто-то, используя новые подходы, найдёт в стоге сена иголку, которая позволит "сделать" всех остальных, а потому нужно себе тоже создать такой же стог сена и начать в нём копаться, дабы не отстать в процессе поиска той самой иголки, на поиск которой может уйти денег больше, чем возможный выхлоп... Мне очень понравилась фраза про "отсутствие знаний / алгоритмов / поиска ценности в этих данных". В интересное время живём. =) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2018, 21:59 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
авторData Lake как Staging Area (именно Staging Area, а не хранилка впрок)... А нафига? Объёмы в SA сильно больше того, что пойдёт дальше в DWH? Фига и еще как. лично участвовал в DL где парсились соцсети. И объемы были гиганские - хотя и уже вполне структурированные в момент еще до заливки. Так вот кроме как в хадуп такой объем никуда не сложить изначально. А потом после обработки выжимка из него шла в РСУБД. Разница объемов примерно на порядок. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2018, 15:18 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Ivan DurakавторData Lake как Staging Area (именно Staging Area, а не хранилка впрок)... А нафига? Объёмы в SA сильно больше того, что пойдёт дальше в DWH? Фига и еще как. лично участвовал в DL где парсились соцсети. И объемы были гиганские - хотя и уже вполне структурированные в момент еще до заливки. Так вот кроме как в хадуп такой объем никуда не сложить изначально. А потом после обработки выжимка из него шла в РСУБД. Разница объемов примерно на порядок. В каком смысле выжимка - что с данными делали, если не секрет? =) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2018, 16:04 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Ivan Durak, Дурное дело - не хитрое. Это я про парсинг соцсетей и поиска там золота. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2018, 17:14 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
HunterikВ каком смысле выжимка - что с данными делали, если не секрет? =) агрегировали вестимо ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2018, 17:32 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
StarikNavyHunterikВ каком смысле выжимка - что с данными делали, если не секрет? =) агрегировали вестимо Да мне скорее детали интересны, чем в общем, наверняка же не только агрегировались, но и фильтровались, и, наверное, сохранялись долгосрочно... Ну да ладно, захочет человек - поделится. =) От конкретного использования, как мне кажется, зависит можно ли назвать такое использование просто использованием в качестве Staging Area, или обогощением одной аналитической системы другой. Ну вполне возможно, что просто игра терминов и привычки, ну то такое... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2018, 18:12 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
HunterikStarikNavyпропущено... агрегировали вестимо Да мне скорее детали интересны, чем в общем, наверняка же не только агрегировались, но и фильтровались, и, наверное, сохранялись долгосрочно... Ну да ладно, захочет человек - поделится. =) От конкретного использования, как мне кажется, зависит можно ли назвать такое использование просто использованием в качестве Staging Area, или обогощением одной аналитической системы другой. Ну вполне возможно, что просто игра терминов и привычки, ну то такое... ну как-как использовали. Для скоринга :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2018, 21:49 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
George NordicКто что думает, кто чем дополнит? С Уважением, Георгий Большие данные - это данные про людей. Точнее, про их взаимодействие. И нужны они исключительно для рекламы товаров и услуг. Любых товаров и любых услуг. Нужно заглянуть внутрь человека, чтобы ему что-либо продать по той цене, которая устраивает продавца и которую можно навязать покупателю. А как навязать. Двумя путями. Первый - "ведь ты этого достоин". А чтобы узнать, чего считает себя покупатель достойным - нужно его проанализировать. Его сообщения. Это первый источник Big Data (в широком смысле, не только текстовые, но и звонки в голосовом виде и записи видеокамер для распознавания мимики и эмоций). Второй - "у всех твоих знакомых уже есть, ты что, собрался выделяться среди них, ты лох дрожащий или право купить имеешь?" Для этого нужно собрать его граф знакомых. Это второй источник Big Data. А проблема в том, что на лету это не обработать. Чтобы правильно распознать эмоции с видеосъемки - нужно собрать информацию о том, на что была такая реакция. Может быть, покупатель шел по улице, увидел рекламу Pepsi и скривился в гримасе - все, таки готово, продаем ему кока-колу, пепси он пить не будет. Так вот - поступление такой информации из разных источников не синхронно. Поэтому нужно сложить, подождать некой точки наполнения для восстановления контекста, по которому можно уже проанализировать покупателя, и только после этого продолжить анализ. И Data Lake действительно Staging Area. Состоящий из разных кусков, пополняемых с некой разной задержкой, которая еще и плавает во времени. И окончательный вывод - "он скривился при слове пепси, нужно пометить в DWH, что это покупатель кока-колы" будет по источнику 1 и 2 из этого озера. И другой окончательный вывод - "он носит кожаную куртку зимой, наверняка приехал на машине, из базы ГАИ получена информация, что за ним числится новенький вольво, ему нужно продавать зимнюю резину и кожаные мужские перчатки, причем очень дорогие, от кошерного бренда" будет по источнику 2 и 3 из этого озера. И эти staging куски будут постоянно использоваться, чтобы в цикле все больше узнавать про покупателя и то, что он готов купить, заносить в DWH. Вот такое дополнение. Все в этом мире ради шекелей, поэтому тот, кто тратит деньги на сервера и Data Lake, думает прежде всего о том - "где мои покупатели и их бездонные кошельки, что я им смогу продать и заработать на этом чуть-чуть немножко больше". ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 01:15 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Andy_OLAP, какие-то сказки дивные излагаете. В бэнках унифицировать профессии, указываемые в кредитных заявках, а затем сгруппировать и проанализировать - и то не могут, не знают для чего ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 09:42 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Alex_496Andy_OLAP, какие-то сказки дивные излагаете. В бэнках унифицировать профессии, указываемые в кредитных заявках, а затем сгруппировать и проанализировать - и то не могут, не знают для чего человек ночью писал, сон у него хороший был. Не обламывайте ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 10:02 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Andy_OLAP, Какой образцово-лютый маркетологический бред... В Голливуде сценарии блокбастеров пишете ? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 11:17 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
L_argoAndy_OLAP, В Голливуде сценарии блокбастеров пишете ? А откуда у Вас эта информация? На кого Вы работаете? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 23:52 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Alex_496Andy_OLAP, какие-то сказки дивные излагаете. В бэнках унифицировать профессии, указываемые в кредитных заявках, а затем сгруппировать и проанализировать - и то не могут, не знают для чего Банкам (обычным, за исключением 4-х банков в отдельности и ФРС в целом) просто никто не разрешит заниматься такими вещами. Каждому по способностям, от каждого по потребностям того, кто контролирует этих "каждых". ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 23:54 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Alexander RyndinAlex_496Andy_OLAP, какие-то сказки дивные излагаете. В бэнках унифицировать профессии, указываемые в кредитных заявках, а затем сгруппировать и проанализировать - и то не могут, не знают для чего человек ночью писал, сон у него хороший был. Не обламывайте Я таки просто на достаточно неабстрактных примерах попробовал обобщить выше высказанное и пояснить участникам форума, которые забредут в эту ветку, что data lake сначала нужно собрать как staging, потом циклично пополнять, потом в какой-то момент использовать для анализа и агрегации вверх, в сторону DWH. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 23:56 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
в продолжении вот этой ветки может будет кому-то интересно (извиняюсь за ошибки, не перечитывал, всё писал на лету с головы) Полтора месяца плотно использую Azure Databricks Premium (Spark, SQL, Scala, иногда Python): - если коротко, то впечатления только положительные - поскольку это Spark, то можно юзать 3 вида API: RDD, Data Frame, SQL, есть выбор, если надо микроменеджить всё что под капотом RDD, если не надо, то Data Frame или SQL - читать данные можно с HDFS, Azure Blob Storage, S3 (вообще можно к чему угодно, если работаешь на уровне RDD API, в моем случае так и вышло) - реально работающий интерактивный интерфейс, можно кверить и крутить данные (попробуй сделать тоже с U-SQL) - в Databricks Notebook'e можно мешать код на Scala, Python, SQL. очень класно, когда нужно вытащить что-то с нестандартного источника/нестандартный формат, то делаешь этот кусок в c помощью Scala/RDD скидуешь в parquet, дальше читаешь его с помощью DataFrame API или SQL там же в Notebook... - полученный Notebook можно легко зашедулить с помощью Data Factory - Databricks Premium дает возможность создавать таблицы своего "формата" организованные в каталоги: parquet + tranlog/versionhistory. Это позволяет делать на них UPDATE/MERGE/DELETE :). SCD дименшны теперь можно пилить без гемора прямо здесь. По сути Databricks Premium дает всё: ETL, stage, DWH с колумнстором всё можете делать прямо здесь. писатели и читатели разруливаются на уровне версий (никто никого не блокирует, всё консистентно) - всё скейлится на лету либо статично выделяется нужное число нод - как настроишь, можете задать число нод например 2-35, кластер стартанет с 2 нод, если будет реальная нагрузка, оно добавить неактивные ноды постепенно пока не упрется до 35, нагрузки не будет, уменьшит число нод, если вообще Idle в течении времени N - кластер потушится автоматом :). стартует кластер либо явно либо при первом запросе пользователя - Power BI может коннектиться напрямую к DWH в Databricks'e Premium - прост в использовании, аналитики вьезжают с первого раза, все довольные... - Spark Streams поддерживается (не использовал пока) вобщем-то DataLake чувствуется тут :) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2018, 18:11 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
+ удобство работы: - интегрировано с github/bitbucket (можно получше) - хорошо организован worckspace, можно шарить друг с другом notebooks - можно насоздавать кучу кластеров под разные нужды, которые будут автоматом подниматься джобом или запросом пользователя (говноскриптить ничего не надо), много кластеров может быть полезно под разные job'ы, в зависимости от потребности джоба, interactive querying etc) - всё биллится pay as u go - о! вспомнил, стандартный коннектор для Azure DWH - Polybase aware, т. е. если вам нужно перекачать много данных из DataBricks в Azure DWH, то юзаете в несколько строчек этот коннектор, он в несколько потоков (линейно скейлится) выгружает это на промежуточный blob storage в parquet файлы, и инициирует загрузку выгруженного в Azure DWH через Polybase (каждая дочерняя нода параллельно всасывает в себя файлы), что самое класное при этом на стороне Azure DWH поддерживается опции DISTRIBUTION = ROUND_ROBIN/REPLICATE/HASH + COLUMNSTORE, оно налету параллельно через DMS сервис раскидывается по дистрибюшнам и сразу летит в columnstore индексы на каждом distribution'e. И всё это в несколько высокоуровневых строчек... - еще продумана работа с хранением кредов к стораджам, базам и прочим, можно юзать Azure Vault либо Databricks'овский scope... - в Databricks Premium вроде есть RBAC security для notebooks, clusters, jobs, and tables (пока не тестили) - техподдержка ажура работает быстро, помогают ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2018, 18:25 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
churupaha, У вас же в профиле Краснодар, а не (условный) Ганновер. Простой вопрос - что будете делать, если: 1) Роскомнадзор заблочит ваш сервис за компанию с кем-нибудь; 2) реализуются политические риски в виде санкций с обоих сторон? Просто я знаю довольно крупную компанию, которая поставила на облака и осталась совершенно без отчетности в момент блокировки телеграма. И именно из-за этого летом они хотели стартовать локализованный проект. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2018, 10:55 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
churupaha- в Databricks Notebook'e можно мешать код на Scala, Python, SQL. очень класно, когда нужно вытащить что-то с нестандартного источника/нестандартный формат, то делаешь этот кусок в c помощью Scala/RDD скидуешь в parquet, дальше читаешь его с помощью DataFrame API или SQL там же в Notebook... года два назад смотрел датабрикс, ноутбуки были просто скрипты. т.е. все ошибки в рантайме. имхо если уж дают нормальный спарк, то логичней делать по взрослому, на чем то компилирующемся, с юнит тестами и прочая. плюс уход от вендор лок. спарк на любое облако перетянуть можно. churupaha- Databricks Premium дает возможность создавать таблицы своего "формата" организованные в каталоги: parquet + tranlog/versionhistory. Это позволяет делать на них UPDATE/MERGE/DELETE :). SCD дименшны теперь можно пилить без гемора прямо здесь. По сути Databricks Premium дает всё: ETL, stage, DWH с колумнстором всё можете делать прямо здесь. писатели и читатели разруливаются на уровне версий (никто никого не блокирует, всё консистентно) а есть где почитать подробности? мы тоже это проворачиваем писаниной в отдельный фолдер, но писать всю витрину приходиться. может они чего круче придуали ? churupaha- Power BI может коннектиться напрямую к DWH в Databricks'e Premium они считают что PowerBI будет нормально и без рсубд, сразу из озера отчетики строить? как то я с трудом такое представляю, имхо отчетной системе нужно что-то, что не станет на каждый чих скан партиции делать. 2Критик завтра в сирии рзбомбят случайно амов, эмбарго, майкрософт точно так же отключит ваши майкрософт сервера. у вас такой же вендор лок. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2018, 11:34 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
Критикchurupaha, У вас же в профиле Краснодар, а не (условный) Ганновер. Простой вопрос - что будете делать, если: 1) Роскомнадзор заблочит ваш сервис за компанию с кем-нибудь; 2) реализуются политические риски в виде санкций с обоих сторон? Просто я знаю довольно крупную компанию, которая поставила на облака и осталась совершенно без отчетности в момент блокировки телеграма. И именно из-за этого летом они хотели стартовать локализованный проект. А я на заграничную компанию работаю (по удаленке, не бодишоп, прямо напрямую), предыдущее место также. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2018, 12:14 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
H5N1года два назад смотрел датабрикс, ноутбуки были просто скрипты. т.е. все ошибки в рантайме. имхо если уж дают нормальный спарк, то логичней делать по взрослому, на чем то компилирующемся, с юнит тестами и прочая. плюс уход от вендор лок. спарк на любое облако перетянуть можно. Скриптами они и остались Про время обнаружения ошибок - зависит от выбранного API . Ещё, если логика действительно не тривиальная, можно засунуть ее в jar'ы и зааплоадить в Databricks и указать к какому кластеру или ко всем ее атачить при старте, maven поддерживается. Python'овские eggs, pypi тоже поддерживаются и т. п.. H5N1churupahaDatabricks Premium...UPDATE/MERGE/DELETE...SCD дименшны а есть где почитать подробности? мы тоже это проворачиваем писаниной в отдельный фолдер, но писать всю витрину приходиться. может они чего круче придуали? Оно гуглится по словам Databricks Delta. https://docs.databricks.com/delta/index.html https://vimeo.com/274267634 Если коротко - они не перетирают весь датасет, а лишь добавляют delta файлы к существующему датасету, и ведут метаданные. Чуть попозже покажу пример, что там происходит с файлами. H5N1churupaha- Power BI может коннектиться напрямую к DWH в Databricks'e Premium они считают что PowerBI будет нормально и без рсубд, сразу из озера отчетики строить? как то я с трудом такое представляю, имхо отчетной системе нужно что-то, что не станет на каждый чих скан партиции делать. Просто, как опция , коннектится Power BI к каталогу таблиц ("базе"), которые, учитывая DataBricks Delta и parquet может и быть полноценным DWH со всякими SCD и прочим... Плюс сам Power BI может работать в режиме Direct Query и генерит Spark SQL или в режиме import'a можно приготовить ему агрегированные таблицы и зашедулить Refresh в Power BI Online. Что выбирать - зависит. При этом выгружать в Azure DWH можно также легко и параллельно в неск. строчек кода... На сторонние стораджи тоже, этоже Spark... --- Еще прикольная фича Spark'a - можно начать что-то не стандартное с RDD, вытащить данные и плавно в середине перейти к Data Frame API... и т. д.. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2018, 14:26 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
H5N1, Databricks Delta UPDATE/DELETE Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286.
Обратите внимание еще на статистику MIN/MAX для каждого файла... используется для pruning'a... Ещё инфа https://docs.databricks.com/delta/optimizations.html https://databricks.com/blog/2018/07/31/processing-petabytes-of-data-in-seconds-with-databricks-delta.html ... |
|||
:
Нравится:
Не нравится:
|
|||
02.12.2018, 15:37 |
|
Data Lake как Staging Area
|
|||
---|---|---|---|
#18+
churupaha, Databricks кооперируется с Информатикой https://www.businesswire.com/news/home/20190521005827/en/Databricks-Informatica-Partner-Accelerate-Development-Intelligent-Data Ну все, рынок энтерпрайза эти двое теперь точно подомнут. ЗЫ: Юзаю Databricks пару недель. Пока впечатления хорошие. Щас пробую Datalake на нем сбацать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.05.2019, 17:48 |
|
|
start [/forum/topic.php?fid=49&msg=39738374&tid=1857084]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
others: | 247ms |
total: | 389ms |
0 / 0 |