Комментарии 7
Сначала от NoSQL к SQL, теперь вот к схемам и миграциям. Как же любят люди переизобретать реляционные базы.
Ну вот вроде норм перевод, и статья интересная… но что-то тут не так. А знаете что? Тут нет контекста. Delta Lake — а это что, собственно? Вот хорошо я допустим слышал, и читал, но представляю, насколько непонятно это может выглядеть для тех, кто новичок в теме.
А ведь достаточно было бы не просто перевести одну из статей немаленького цикла, а хотя бы дать ссылку на delta.io, где на первой же странице написано: Delta Lake is an open-source storage layer that brings ACID transactions to Apache Spark™ and big data workloads. Или ссылку на разработчика, databricks.com.
Ну т.е., в сущности, схемы, и все манипуляции с ними — это все вторично. А первично то, что Delta Lake дает нам ACID (а еще проще — транзакции) в среде Apache Spark и на больших данных.
А ведь достаточно было бы не просто перевести одну из статей немаленького цикла, а хотя бы дать ссылку на delta.io, где на первой же странице написано: Delta Lake is an open-source storage layer that brings ACID transactions to Apache Spark™ and big data workloads. Или ссылку на разработчика, databricks.com.
Ну т.е., в сущности, схемы, и все манипуляции с ними — это все вторично. А первично то, что Delta Lake дает нам ACID (а еще проще — транзакции) в среде Apache Spark и на больших данных.
по моему и статья бредовая. схема — она у паркетов, что под низом у delta lake, а то что delta lake тоже имеет схему и schema evolution, так это скорее следствие того, что delta lake надстройка над паркетом.
а по транзакциям, транзакции тут вторичны. главная фишка delta lake то что он дает возможность делать update/delete/merge на файлки лежащие на hdfs. транзакции идут как бонус к невероятному к update на hdfs.
а по транзакциям, транзакции тут вторичны. главная фишка delta lake то что он дает возможность делать update/delete/merge на файлки лежащие на hdfs. транзакции идут как бонус к невероятному к update на hdfs.
>по моему и статья бредовая.
Статья — перевод с databricks.com. Эти ребята многое делают для развития спарка, я как-то априори склонен им скорее доверять. Не считая явной дури в примерах кода:
где original_loans не определена. Кстати, эта дурь — она из оригинала.
>транзакции идут как бонус к невероятному к update
Ну, мне кажется что это скорее не бонус, а наоборот, фундамент. Все-таки, как вы себе представляете update, если транзакций нет? Впрочем, не настаиваю.
Статья — перевод с databricks.com. Эти ребята многое делают для развития спарка, я как-то априори склонен им скорее доверять. Не считая явной дури в примерах кода:
# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
CAST(rand(10) * 10000 * count AS double) AS amount
FROM loan_by_state_delta
""")
# Вывести исходную схему DataFrame
original_loans.printSchema()
где original_loans не определена. Кстати, эта дурь — она из оригинала.
>транзакции идут как бонус к невероятному к update
Ну, мне кажется что это скорее не бонус, а наоборот, фундамент. Все-таки, как вы себе представляете update, если транзакций нет? Впрочем, не настаиваю.
Эти ребята многое делают для развития спарка, я как-то априори склонен им скорее доверять.
делают, но паркет со схемой и эволюцей схемы появился до них и до их настройки над паркетом.
Ну, мне кажется что это скорее не бонус, а наоборот, фундамент. Все-таки, как вы себе представляете update, если транзакций нет?
да легко. как у них работает — у них при апдейте пары срок в фолдере паркетов ищутся паркетники, где нужно заменить строки. найденные файлы целиком копируются, с модификациями. после этого в папочке лога добавится json. вот появление этого json и означает фиксацию транзакции. мягко говоря не самая захватывающая фишка. DWH мир уже давненько не пишет терабайты в единой транзакции, а давно заливают в параллель и делают что-то типа exchange partition.
>мягко говоря не самая захватывающая фишка.
Ну это я бы сказал самый реалистичный сценарий. Если бы меня попросили — я бы тоже примерно так и делал. Второй вариант который напрашивается — хадуповские hdfs снапшоты.
Т.е. делаем что угодно, в другой папке, копируем, меняем… потом атомарно фиксируем транзакцию. А как? А так — либо поменяв locaton в метаданных Hive (которые в жизни обычная реляционная БД, постгрес или там оракл), либо атомарно же создав файлик. Пусть даже и json. Это фактически и выглядит как близкий аналог exchange partition, как я его знаю скажем по MS SQL.
Я могу понять, что хочется быстро и красиво. Но в рамках хадуповского существующего подхода — это практично. Хотя наверное да, шуму вокруг слегка многовато.
Ну это я бы сказал самый реалистичный сценарий. Если бы меня попросили — я бы тоже примерно так и делал. Второй вариант который напрашивается — хадуповские hdfs снапшоты.
Т.е. делаем что угодно, в другой папке, копируем, меняем… потом атомарно фиксируем транзакцию. А как? А так — либо поменяв locaton в метаданных Hive (которые в жизни обычная реляционная БД, постгрес или там оракл), либо атомарно же создав файлик. Пусть даже и json. Это фактически и выглядит как близкий аналог exchange partition, как я его знаю скажем по MS SQL.
Я могу понять, что хочется быстро и красиво. Но в рамках хадуповского существующего подхода — это практично. Хотя наверное да, шуму вокруг слегка многовато.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Погружение в Delta Lake: принудительное применение и эволюция схемы