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 на всю бд не сделать.