tarrusGlebanskiСходил тут SQL Saturday в недавнюю..... кажется субботу(!)
Микрософт просто адски пушает Databrick, но речь не об этом.

Местные консалтеры уверены, если вы хотите современное Хранилище - то, где вместо унылых файлов и/или базы под Staging Аrea всем надо срочно внедрить Data Lakи
Что думаете?

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

https://databricks.com/blog/2017/11/15/a-technical-overview-of-azure-databricks.html

нет там хадупов, пропихивают какого-то франкинштейна, где у спарка вместо hdfs какой-то dbfs и прочая ажурная муть.

Полковник.
У Инмона есть статья почему даталайк не хранилище данных. В двух словах 1 пользователям нужны понятные им структуры данных для анализа - это хранилище данных, данные структурированы, разложены по таблицам и колонкам 2 даталайк это технология обработки больших массивов данных параллельным процессом.
а можно точнее что за книга? а то как-то не понятно на кой пользователю хранилище, если даталейк витрины пользователям строит. вполне структурированные.

.ЕвгенийУ меня есть архив ХД, в который складываются входящие XML. Но сделать это центральным элементом ХД и обозвать DataLake мне в голову не пришло...
и никому не приходит. далейком называют то во что эти xml трансформировали . orc, parquet, hbase и прочие файлики на hdfs.

Полковник.Я выше написал - статья. Года три назад Инмон раз в неделю писал по статье, где обличал любителей свалить все в кучу и назвать это даталайк.

ну вот хотелось бы ссылочку, что бы не вышло как в той истории, где рабинович напел

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

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

Полковник. А теперь вопрос - зачем эта прослойка, которую все упорно пытаются варить называя это изделие красивым словосочетанием - озеро данных?
- что бы эффективно обрабатывать данные там где они лежат, а не таскать без конца данные из субд во всякие питоны, R и sas data майнеры. в обычной субд нет даже базовых алгоритмов анализа, все что сложне AVG() требует перекачки данных.
- что бы пользователь получил привычные данные в человеческом виде, а не набор мутных фактов, которые еще толпа инженеров нужна, что бы правильно заджоинить.
- имея резиновые ресурсы, многие вещи можно тупо и в лоб проворачивать. там где рсубд хранилище будет выдумывать мутные алгоритмы исправлений косяка, на хадупах просто перестроят витрину, не вникая даже в суть проблемы.
- что бы с какой-нить ESB в реалтайме данные читать, а не по старинке батчами
- с консистентностью на хадупах все сделано удобней, в рдбмс же exchange partition на всю бд не сделать.

Критикя считал, что Data Lake это все это в одном месте,
то есть такая мегамусорка
дикие вы какие-то там, за мкадом. неужели в ваших краях нет ни банков ни страховщиков ? как бы те кто считает деньги с мегамусорками деньги считали ?

.ЕвгенийА-аа, все понятно! Datalake по определению бывает только поверх Hadoop, поэтому мне надо запихать xml-ки в хадуп и вот тогда озеро украсит мой повседневный пейзаж ИТ-систем! Не было у меня ни малейшей нужды в хадупе - а вот появилась!
нет уж, делай как делал раньше. и желательно на какой-нить экзадате. иначе людям не понятно зачем мне платить в пятеро больше

.Евгений "In broad terms, data lakes are marketed as enterprisewide data management platforms for analyzing disparate sources of data in its native format," said Nick Heudecker, research director at Gartner. "The idea is simple: instead of placing data in a purpose-built data store, you move it into a data lake in its original format. This eliminates the upfront costs of data ingestion, like transformation. Once data is placed into the lake, it's available for analysis by everyone in the organization."
Что такое "native", "original format", когда этих форматов - много, по числу источников?

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

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

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

.ЕвгенийЧерт побери, как эта "резина" должна развращать и отбивать желание думать...

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

.ЕвгенийУ меня есть скромный сервер ETL на виртуальной машине, который среди прочего обрабатывает поток из кролика в 200 сообщений за секунду, максимально тянет почти тысячу. Обрабатывает поток - это значит читает сообщения, пишет в БД xml, затем пишет в БД теги параллельно с отправкой кролику подтверждений. Задержка - несколько секунд, реалтайм ненастоящий, но достаточно похоже. И никакого хадупа, только SSIS и немного умения им пользоваться.

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

.ЕвгенийВы знаете, у меня нарождается подозрение, что вы под даталейком подразумеваете что-то свое, принципиально отличное от понимания авторов термина и от общепринятого понимания. Прошу, развейте это подозрение.

ваша проблема в том что вы хаваете маркетинговый булшит, от людей которые энтерпрайза не видели. поверьте, в реальных мире ни один банк не сможет "move it into a data lake in its original format"

.ЕвгенийH5N1анализировать грязные данные запрещает закон,
Гы. Хотел бы я такой закон... Простите, а что вы понимаете под грязными данными?

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

.ЕвгенийЕще интереснее. Получается, что в вашем личном понимании Datalake нечто вроде ODS?

ODS это субд, она не хранит истории. даталейк это файлики. просто файлики на S3, hdfs, но уже более менее обработанные, зачастую колончатой структуры типа parquet формата. по ним можно гонять SQL квери из спарка или импалы.

.ЕвгенийНикто ее не убивал. Эта аналитика вполне неплохо ложится на поток данных, которым оперируют ETL решения. Далее нужно либо самому реализовать окна и агрегацию, либо слать данные во что-нибудь стороннее типа StreamInsight.

угу. стандартный подход - забить на риалтайм, записать в субд и потом тащить копию данных из субд сторонним питонам, R и прочему ML.


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

.ЕвгенийПрошу, не надо переводить стрелки на мои проблемы, действительные или мнимые. Я задал просто вопрос: на чем основано ваше понимание Datalake? Документы, стандарты, статьи классиков? Или обычная жизнь, когда вы сотворили нечто и решили назвать это даталейком?

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


Data Lake Architecture: Designing the Data Lake and Avoiding the Garbage Dump
by Bill Inmon
Published by Technics Publications, 2016

Chapter 4 Data Ponds

An interesting architectural question is: once raw data flows from the raw data pond into the data pond, should the raw data remain in the raw data pond? The answer is no. Once raw data passes from the raw data pond to the analog data pond, the application data pond, or the textual data pond, it is best to remove the source data from the raw data pond. The raw data has already served its purpose and it would be extremely rare for analytical processing to ever be performed in the raw data pond.
...
Chapter 7
Application Data Pond

It is normal for application-based data to be entered into the application data pond in a standard relational database format. Most applications have data stored in a row and column format. So application data will usually be stored and transported into the application data pond in this standard database format.


.ЕвгенийЕще раз обращаю внимание на отличие ETL от СУБД. А именно: процесс ETL не скован транзакциями и не обязан синхронно записывать данные в БД (если не имеется соответствующих требований по консистентности, надежности получения/хранения и т.п.) В частности, у меня синхронность ограничена обменом с шиной, вся остальная обработка ведется асинхронно. Если я добавлю к парсингу xml отправку на интерфейс аналитического решения (на какой-нибудь сервис), то ничего принципиально не изменится.

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

Alex_496согласно требованиям FDA пациенты в прикладных информационных системах анонимизируются изначально.
На рандомизационный номер пациента записываются данные о дате рождения, поле, расе и т.п.
Данные хранятся десятилетиями, причем на электронных носителях в разных зданиях (защита от пожара).
А в прошлом году при прохождении зарубежного аудита нам был задан вопрос: помимо CD-дисков на чем архив есть? Оказалось, что аудитор имел ввиду, что спустя годы, когда CD-приводов уже не будет в обиходе, то как вы сможете предоставить архивные данные для прочтения.
ну те кто хранит данные пациентов думаю дата лейки не заводят. лично я видел как аудит натянул финкантору за хранение счетов, выставленные от каких-то клиник. в счетах были какие-то сенсетив данные по диагнозу, процедурам. GDPR за такое расстреливает на месте. подозреваю какие-нить страховые выплаты GDPR требует как-то особо обрабатывать

tarrusКогда успели? Правила GDPR вступили в силу в мае и то не для всей Европы. Первые наказания начнуться не скоро. Вы свой опыт на все Европу экстраполировать пытаетесь.
GDPR это про европу. там принято приглашать аудит до того как власти натянут и пока есть время исправить.

tarrusНаоборот, многие были бы и рады что-то новое поковырять, но вот экономическое обоснование супер шаткое получается. Где бенефит до сих пор не ясно. Наверняка он есть на каких-то проектах, но где чек лист по которому можно проверить, что лучше в данной ситуации БД или файлики.
24 ядра экзадаты стоят пол миллионна зеленых. реально нужны еще какие-то обоснования?

.ЕвгенийЭто все относилось бы к теме, не будь (по Инмону) все data ponds частями DataLake. Raw data pond - просто промежуточный слой, аналог Staging для ХД. Другие авторы предлагают другие принципы разделения (например, governed, lightly governed и ungoverned). Никто (вроде бы) не отрицает нужды в метаданных, но все (опять же вроде бы) избегают упоминания о трансформации данных (хотя грань между этими процессами довольно зыбка).

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

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

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

.ЕвгенийПовторяю простым языком: Datalake - это сырые данные. Разделенные на несколько частей в зависимости от структурированности и актуальности, а также слегка обогащенные метаданными. Но все равно сырые, никак не поджаренные с корочкой, как в ХД.
Покажите, где Инмон написал иное?

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

Chapter 7 Application Data PondIf data finds its way into the application data pond in an integrated state, the organization is lucky. If data finds its way into the application data pond in an unintegrated state (which is the normal case) the organization must transform the data after it has entered the application data pond. This transformation step is very similar to conditioning for the analog data pond. If data is to be meaningfully used for analysis in the application data pond, the transformation of data into an integrated state is absolutely necessary. There are many reasons for the transformation and integration of application data pond data. Consider the following set of transformations, as seen in Fig 7.5. The different applications have gender encoding. In order to make the analysis consistent, the application data needs to be transformed into a consistent definition of gender. The same considerations hold true for measurement of distance. Inches and feet and yards need to be converted to centimeters if consistent and meaningful analysis is to be done.

Полковник.Он бесплатный только чтобы поиграться. За энтерпрайз нужно тоже платить.
не надо. платить можно ... за супорт. но никто не заставляет. у клоудеры один дистрибутив
https://www.cloudera.com/downloads/cdh/6-0-1.html

tarrusТак объясните наконец. Кто файлики-то подготавливает? Святой дух? Или всё таки тот самый ненавистный вам ETL?

сам ETL делает хадуп, а как в raw data pond доставляют сырые файлики это зависит скорее от источника. есть коннекторы, есть sqoop, сейчас модно через кафку.