0: Дорогие друзья, всем доброго вечера. Я рад вас приветствовать в офисе компании честный знак. Сегодня он дружелюбно распахнул свои двери, чтобы открыть его для 1 митапа по большим

1: Данным по дате. Ну, за ближайшие, наверное, года 2 в Санкт-Петербурге. Так точно. Вот. И для нас это начинание. Поэтому прошу поддержать нас активным участием. Приветствую участников, которые подключились

2: К нам онлайн. Давайте знакомиться. Меня зовут Алексей Зазуля. Я руковожу командой, которая строит в честном знаке большую аналитическую платформу. Сравнительно мы такая молодая дата компания, но то, что мы

3: Мы делаем те объёмы данных, которые мы процессим и обсчитываем. Ну, заставляют нас взрослеть. Это 1 из причин, почему этот митап появляется. Мы хотим делиться опытом, рассказывать, что мы делаем. Ну и, конечно, учиться у друг друга.

4: Этим и сильно комьюнити сообщество, в том числе и дата инженеров, и уже с кем-то мы перекинулись парой фраз. И есть такой посыл правильный, что, ну в Москве есть тусовки, есть конференции больших данных.

5: А в Питере как-то нету, но вот я думаю, что мы будем теми, кто если все хорошо сложится, начнём такую череду Митапов по большой дате. Ну, конечно, с вашим участием, поэтому, наверное, даже чуть чуть забегая вперёд.

6: Будем ожидать от вас обратную связь и отклик. И, возможно, вы здесь станете нашими содокладчиками, участниками подобных Митапов. Почему честный знак? Почему мы говорим о большой дате?

7: Несколько слов о нашей компании. Чем мы занимаемся, честный знак, кто ещё вдруг не знает, с ним вы не явно сталкиваетесь, постоянно покупая различные товары. Это компания, которая реализует проект по глобальной мар.

8: Маркировки товаров. Что это такое? Ну, по сути, это сквозное прослеживание любых операций с товаром по экземплярно от его производства и заканчивая чеком на кассе, то есть продажей в обычном

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

10: И все прочее. Но что важно для нас, как для команды, которая строит аналитическую платформу, это то, что мы получаем, по сути, трассировку любого товара от производства.

11: При передаче от 1 участника товара товарооборота к другому до выбытия. И вот этот поток данных к нам льётся достаточно интенсивно. И несмотря на то, что мы, ну, сравнительно молодая компания, где-то

12: На 6 или 7 лет на рынке мы, ну, объём данных у нас приличный, он измеряется, питаба это миллиарды операций в сутки и там десятки тысяч rps наши сервисы держат, ну и соответственно это все приходит к нам в дат.

13: Которую мы успешно обсчитываем и собираем соответствующие показатели. Ну так, ещё немножко цифр в нашем витринном слое больше 4000 объектов. Он содержится в клихаус. Ну, чтобы вы понимали объём

14: Задач, которые мы решаем. Наша команда, она и технологическая, и продуктовая. Поэтому это и нашло отражение в темах наших докладов. Сегодня мы будем 1 из докладов. Это прям очень крутой бизнес кейс.

15: На очень приличном объёме данных, которые мы решили. 2 доклад от нашей компании. Он такой глубокий нырок в технику, и там будет горячо. Обычно на конференциях именно так и помечают спайси доклад.

16: Будет. Ну и сегодня 3 доклад. Это от наших друзей. Сергей Шеремета расскажет о качестве данных, и это тоже на самом деле дополнит всю картину, которую вы сегодня увиди.

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

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

19: Им ссылку, чтобы они тоже подключились. Если вы не в чате нашего митапа обязательно туда вступите, потому что там будет возможность пообщаться со спикерами, в том числе и после этого митапа, да, то есть мы можем там поддерживать

20: С вами связь у нас будет после каждого доклада. Вопросы можно будет задать спикеру вопросы в зале и также те, кто подключились к нам онлайн. Пожалуйста, можете писать там вопросы. У нас будет 10 минут на ответы, если

21: Даже мы не успеем. Можно будет потом обсудить, кто пришёл к нам в офис на автопати, задать вопрос, подискутировать с нашими, ну, сильнейшими дата инженерами, а те, кто онлайн, у них тоже будет.

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

23: Ну, наверное, это все. Не буду сильно затягивать. Самое интересное впереди, поэтому я хочу пригласить сюда нашего 1 докладчика. Давайте встретим аплодисментами петра.

24: Пётр руководитель 1 из команд разработки нашей компании. И 1 доклад, он будет именно про очень крутое, нетривиальное решение. Ну, непростой за

25: Задачи, бизнес задачи. И чем мне ещё этот доклад очень нравится. Я рад, что именно он открывает сегодняшний митап. Вы поймёте, в чем специфика сложности обработки данных именно в честном знаке, почему именно мы пересчитываем петабайты дан

26: Когда мы анонсировали этот доклад в чатике дата инженеров, посыпались такие комментарии, что это за кликбейт какой-то? Откуда, как может быть спарк без шафла на таком объёме данных? Ну, наверное, нас просто заманивают красивыми заголовками. Да нет.

27: Это реально трустории. И вы сегодня убедитесь в этом, что этого достичь результата. Ну, у нас получилось. Достичь этот результат. Не буду затягивать. Пётр. Алексей, спасибо. Я ещё раз представлюсь.

28: Меня зовут юга Пётр, я тимлид, дата инженеров и тема моего доклада эволюция ежедневного расчёта на 1 петабайт данных от house chief of three спарт.

29: О чем этот доклад? У нас достаточно специфическая задача, и чтобы рассказать вам о ней, мне придётся в саму задачу вас погрузить. Я постараюсь это сделать максимально просто далее расскажу.

30: О решении по структуре данных, к которым мы пришли, и 2 реализациях клихаус и sparks, потом подведём итоги, и можно будет задать вопросы.

31: Алексей на самом деле очень подробно рассказал про честный знак. Хочу уточнить. Вот поднимите руку, кто вот сегодня впервые узнал про эту компанию?

32: Все уже знали. Супер. Тогда я не буду повторяться. Единственное, расскажу про сам процесс, как это работает. То есть производитель наносит код маркировки в виде датаматрикса на упаковку товара.

33: Дальше этот товар едет до магазина, где мы можем его купить. И вот эти все операции над товаром приходят к нам и обрабатываются нашим процессингом.

34: Немного о техническом ландшафте. Наш процессинг работает на эбс и кассандре, и в аналитику. Мы получаем данные через кафку. Далее мы загружаем эти данные в хдфс, обрабатываем их с парком, строим

35: Витрины и готовые витрины загружаем уже в кликхаус а ну и оркестратором мы пользуемся айрфлоу.

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

37: И также я буду говорить много про историю кода маркировка для нас это просто совокупность всех операций, которая была над этим кодом маркировки.

38: Какая у нас задача? Мы уже накопили около полутора петабайт данных истории кодов маркировки, и каждый день нам приходит примерно 4 терабайт, причём данные могут приходить за любой период.

39: Возможны дубли операции. И ещё есть такой момент. В зависимости от типа операции. 1 операция влияет на другую, она может её отменять, подтверждать, корректировать. Ну, есть бизнес показатели, которые считаются по не

40: Скольким операциям я сейчас покажу, как это работает. Допустим, нам нужно посчитать просто текущего владельца для кода маркировки. И у нас есть вот такая история. И что мы видим, у нас есть

41: Передача и её подтверждение, так как есть подтверждение передачи, мы можем считать, что владельцем является ип. Иванов.

42: Но нам может прийти отмена, которая отменяет предыдущую операцию.

43: И после этого текущим владельцем становится ооо ромашка.

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

45: Ооо рассвет

46: Ну и операция может прийти задним числом таким образом, что отмена перестаёт отменять подтверждение и передача становится опять валидной, и текущий владелец.

47: Становится ип. Иванов. Итак, получается, что нас наша задача не дитина, и нам нужно строить связи между ними в рамках 1 кода.

48: Которые могут со временем меняться.

49: Для начала я расскажу, к какому решению по структуре данных мы пришли.

50: Изначально каждый показатель мы старались посчитать отдельно.

51: Для этого мы складывали операции для расчёта, например, ввода в оборот, в стейджинг ввода в оборот, выбытие в стейджинг, выбытие и так далее. И на каждом стейджинге мы считали уже витрины данных. Но что оказалось, если

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

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

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

55: Внесение, он был нанесён тогда-то введён в оборот тогда-то и так далее.

56: К плюсам данного подхода мы можем отнести унификацию, то есть везде ввод в оборот. Выбытие будет посчитано одинаково и оптимизацию по ресурсам, но также есть и минусы.

57: Провождение автотестов зачастую занимает намного дольше времени, чем сама доработка, потому что нам нужно протестить все варианты, все бизнес, показатели, ну и сопровождение самого кода, где рассчитаны все бизнес, показали.

58: Тоже не самая простая задача.

59: Итак, мы вот с вами сейчас обсудили, какую структуру данных мы пришли и знаем, куда идти. Теперь важно, на какую реализацию мы туда пойдём. И 1, что мы сделали, это реализовали на клихаус, каким

60: Образом. То есть данные мы получали из кафки, загружали в хдфс дневной инкремент и после уже загружали и рассчитывали все в клихаус.

61: В чем вообще заключалась наша идея, если мы все операции по коду сможем в 1 массив положить, то с помощью функции, которая в клихаус очень широко реалии?

62: Над массивом мы сможем их посчитать.

63: Как это сделать? Ну, мы выбрали агрегат меж 3. Это движок таблицы, и с помощью группы рей стейт мы можем обновлять сам массив операций.

64: Как мы это реализовали, мы взяли дневной инкремент и распределили его по кластеру через функцию c h 64 от кода и другим приложением просто в параллель.

65: На каждой из реплик шарда начали считать наши показатели. Через какое-то время нам перестало хватать ресурсов, поэтому мы разделили данные и начали считать на

66: Каждой реплики, но этого оказалось тоже мало.

67: И мы просто поделили данные также на партиции по остатку отделения от хэша кода маркировки и также начали просто просчитывать параллель каждую партицию.

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

69: Пример. И основной скрипт у нас уже достиг 100 строк, нееет 1000 строк на эскьюэль, и это достаточно уже сложночитаемые, ну и сама методика расчёта.

70: Не совсем прозрачное. 2, это деградация. Мы вместо 4 часов начали обсчитывать 12 часов данные, и сам расчет уже начал накладываться на время.

71: Работы наших потребителей данных, что повлекло также эффект на всех пользователей витрин. Ну и, казалось бы, этот вопрос решаем с помощью добавления новых шардов. Клихаус это хорошо умеет, но

72: Так как мы распределили данные по остатку, ну, по ключу коду маркировки.

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

74: Ну и последнее, мы начали терять данные из за синхронной репликации. Мы по итогу разобрались. Это, безусловно, небольшой объём данных, это где-то единицы на миллионы строк, но для нас это критично. У нас есть

75: Верки. И мы делали пересчёты. По итогу мы разобрались, так как репликация асинхронная в кликхаусе. Мы не всегда успевали при нагруженном кластере реплицировать данные на оба хоста из за этого

76: Мы иногда могли пропустить часть данных, но это на самом деле решаемые вопросы.

77: Например, мы написали очень подробный туториал, и вы видите фрагмент этого туториала. Каким образом наши показатели можно считать с помощью функции на массивах. Также мы

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

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

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

81: Ну, в целом на митапе про spark мы начнём сейчас говорить про спарк, это уже радует.

82: Да что мы сделали? Мы перенесли все расчёты в хдфс. Нас парк оставили в клихаус только витрины и просто их копируем с хадупа.

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

84: Каждый из этих этапов я постараюсь вам продемонстрировать на таком демонстрационном варианте. Здесь перед вами видны ресурсы, размеры, которые мы взяли. Единственное, что отмечу.

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

86: От остатка отделения функция видно на экране.

87: Да, ещё такой момент. Мы будем рассматривать базовый вариант, что такое базовый вариант. Это тот вариант, которому мы все остальные будем сравнивать. Здесь мы берём просто нашу историю.

88: Получаем результат. Здесь такой момент. Отмечу, что могли, наверное, ну, увидеть, что дедубликация как-то странно реализована. Помните, я в начале показывал, что у нас есть отме,

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

90: А так как добавление этих полей нам позволяет сразу сделать дедубликацию, то строить окно по коду, типу и дате не нужно, можем просто по коду сделать это такой вот лайфхак.

91: Если запустить наш базовый вариант, то мы можем просто отметить, что вот у нас есть такой шафл.

92: По структуре бизнес показателей мы супер сократим и возьмём просто последнюю операцию.

93: Тут также отметим, что Шаф присутствует.

94: Для сравнения будем заполнять вот такую таблицу за основной показатель. Возьмём время, и процент будет считаться от этого времени.

95: Вообще вот такого решения в проде у нас никогда не было, когда мы просто взяли вот огромную таблицу, взяли маленькую таблицу юнион и поехали, потому что когда

96: Мы просто попытались на наших объёмах это сделать. Приложение чаще падало, чем отрабатывало до конца. И что это было. То есть приложение работало 6 часов в среднем, и на 5 часе оно могло упасть, и мы теряли просто

97: Весь результат, который был посчитан до

98: К чему мы пришли? Мы пришли к

99: Тому, что у нас уже был опыт и идея в кликхаусе, где мы обрабатывали данные по партициям отдельно, и что мы сделали, просто начали считать каждую партицию отдельно в своём треде.

100: Также мы добавили такое условие, что если в директории, которую мы пишем, уже есть файл с акцесс, значит, надо его пропустить. Тем самым мы при падении тел можем не

101: Считывать тот результат, который уже посчитали начать расчет с последней партиции.

102: Также это позволяло нам сократить нагрузку по шафла на диск в 1 момент времени. То есть мы не берём все данные сначала их shuffling, потом читаем шафл. Мы берём только часть данных, часть мы

103: Часть уже мы читаем, и таким образом сокращается нагрузка на наш кластер.

104: Итак, у нас 1 результат.

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

106: Нас, наверное, самое главное.

107: Следующее, что мы внедрили.

108: Это пакетирование, если прям совсем простым языком сказать, что представьте, вы делаете репортин по определённому полю.

109: И сохраняете его в результате, как таблицу.

110: А потом спарк, когда обращается к этой таблице, знает, что если вы хотите сделать join групбай,

111: Или окно по этому полю то шафл можно пропустить?

112: Вообще у нас по пакетированию есть пересечение с 3 докладом.

113: И там более подробно обсудят плюсы, минусы этого подхода. Сейчас для нас важен 1 недостаток. То, что количество Бакетов задаётся 1 раз при создании таблицы, и то, что

114: Ограничение этого количества 100000.

115: У нас очень много данных, и если мы разложим их просто на 100000 Бакетов, мы получим огромные файлы, ну что, не так критично огромные файлы, но мы получим огромные таски, потому что при расче

116: Если мы хотим избавиться от шафла, он будет разбивать их Ровно на 100000 тасок, что влечёт для нас огромное количество времени на обработку. Возможно.

117: Пилы, а возможно, огромные экзекьюторы, что тоже не очень удобно.

118: Поэтому мы прибегли к предыдущей реализации по параллельному запуску, но перед нами стала задача а как нам по частям обновлять не файлики, а таблицу.

119: Тут в принципе не самое сложное алгоритм мы взяли просто каждую из job и сказали сохраняй в какую-то темповую таблицу.

120: После чего мы эти паркеты.

121: Уже мували под нашу продовую таблицу, и все это работает. Жалко то, что мы чуть чуть спешим. Здесь я

122: Не надо спешить. Да, тут 1 момент просто ещё остался. У нас партийцы разбиты на

123: 10 партиций, да, получается, и оно не меняется, потому что у нас остаток отделения. Если у вас будет примерно такой же подход, но у вас будут другие партиции, то и они могут изменяться, то не забывайте команду мстк репер тейбл.

124: Само приложение вам об этом не скажет. Вы сможете потом увидеть, что таблица просто не видит паркет в новых партициях. Окей.

125: Так.

126: Я понял. Мне надо перейти просто на другой.

127: Итак, давайте рассмотрим реализацию для истории км. Как вы видите, мы здесь вообще никак не, ну не отказались от шафла. Казалось бы, зачем мы это делали?

128: Ну, юнион букетио не убирает, тут как бы ничего не получилось у нас, но отмечу то, что мы при сохранении в таблицу ещё добавили сортировку. Это будет важно позже.

129: Но в структуре бизнес показателей, где мы искали просто последнюю операцию, мы видим, что shuffle полностью отсутствует.

130: И есть ещё 1 такой момент, как выбрать количество партиций и количество Бакетов, если у вас партиции по остатку отделения от кода и Бакетин по

131: Этому полю, то не стоит выбирать их таким образом, чтобы у них был общий делитель. Например, если бы здесь я сделал бы 200 Бакетов, то у меня в каждой партиции было бы 20 файлов, а не 200.

132: Потому что здесь остаток отделения у них совпадал бы.

133: Окей.

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

135: Скорее, связано не с букетировка. Безусловно, это связано с тем, что мы отсортировали данные и количество Шафа с точки зрения объёмов у нас понизилось почти в 2 с половиной раза.

136: Так, мы отказались от шафла в 1 структуре, но пришла идея отказаться от шафла и в другой структуре. Каким образом это можно было бы сделать, мы взяли дневной инкремент.

137: И просто загрузили его в виде Бакетин, ой, таблицы, так же, как мы обсчитываем любые другие партиции в минус 1 партицию. И дальше мы взяли юнион.

138: И заменили его просто на фильтрацию.

139: Таким образом, мы также

140: Избавились от шахмат.

141: Да, добавим также наш результат в нашу таблицу.

142: И последнее, что мы внедрили, это архив.

143: Для этого мы добавили партиции, архив 0 и архив 1 что вообще такое архив? Вот код маркировки может выбыть?

144: Но может вернуться по нему может прийти также разные корректировки и так далее. Как мы считаем, если код маркировки выбыл из оборота, его кто-то купил, или он его списали, и по нему более чем 90 дней не приходит ни

145: Какой операции? Мы можем его отложить и обрабатывать его раз в месяц, раз в неделю. Если по нему вернутся какие-то операции, его вернут в оборот или что-то такое. Он просто мигрирует в архив. 0.

146: Окей, но здесь возникает вопрос. Нам нужно решить.

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

148: Показатели, где есть информация о том, какой архивный, какой не архивный, но по факту это выглядит вот так. То есть во много раз правая таблица больше левой. И тут, конечно, можно было бы её

149: Шить вот так просто заджойнив здесь, я не буду говорить, что это у нас не работало. Все это работало просто мы берём 2 и 8 миллиард, ну, в тестовом варианте 2 и 8 миллиардов данных шафрин и получаем результат. Но здесь

150: Можно было это как-то тоже улучшить, поэтому

151: Мы вот здесь попробуем на примере блум фильтра показать, как это можно сделать, что он позволяет.

152: Он позволяет взять 2 и 8 миллиардов данных.

153: И отфильтровать их теми ключами, которые пришли в нашем инкременте и по факту зашалить не 2 и 8 миллиардов, а только 67000000.

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

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

156: Скажите, а кто был на смарати? Вот на смарати, который неделю назад буквально так. Ладно, я ожидал, что больше хорошо, но в любом случае

157: На smart date был доклад, и в нём Дмитрий рассказывал как раз про наше решение он там рассказывал не только про наше решение, он как раз и про блум фильтр про блум, фильтр джойн рассказывал и вот по этому QR-коду.

158: Вы можете посмотреть этот доклад, потому что это был бесплатный день, насколько я комьюнити. Нет? Да, блин, это был комьюнити день.

159: Да, вот в любом случае, Дима сегодня с нами, и если у вас будет вопрос, я думаю, он всем обязательно ответит.

160: Внедрение архива сократило объём обрабатываемых данных примерно на 2 трети и поэтому дало такой результат.

161: Ну что, давайте подведём итоги.

162: Текущий ежедневный расчет в проде отрабатывает менее чем за 3 с половиной часа, потребляя не больше 31 терабайта памяти пересчёт архива около 7 часов на ресурсах не

163: Превышающих 40% от нашего кластера.

164: Мы постоянно находимся в состоянии поиска возможности оптимизировать наше решение. Следующим вызовом для нас будет инкрементный расчет, внедрение айсберга, оптимизация расчёта витрин. Ну, возможно, кто-то

165: Из вас подскажет нам, как сделать наше решение лучше мы на это тоже надеемся.

166: И если вернуться к этой таблице, то можно увидеть, что самой эффективной доработкой оказалось внедрение архива, поэтому в поиске оптимизации не зацикливайтесь на технических аспектах.

167: Задачи. Говорите со своим бизнесом, ищите решение вместе. Спасибо за внимание. Готов ответить на ваши вопросы.

168: Презентация вела себя how are поднимите руку, кто на кликхаусе считает показатели тут таких тоже нет. Ну ладно, в целом в целом окей.

169: Вроде работает. Спасибо, Пётр. Отличный доклад. Я, наверное, просто сделаю акцент. Пётр акцентировал. А я ещё сделаю ещё больший акцент на последний его.

170: Message о том, что нужно приходить к бизнесу в мире больших данных, показывает практика нельзя просто решать техническую задачу изолированно от бизнеса, иначе мы все потонем или придётся вырубить все деревья на нашей планете.

171: Поэтому это очень правильно. И спасибо Петру за этот классный вывод. Итак, друзья, сейчас время для вопросов у нас есть на это 10 минут есть вопросы, пожалуйста, поднима.

172: Поднимайте руку, мы дадим вам микрофон.

173: И можно будет задать. Ага.

174: Привет, привет. Вот спасибо за доклад. Меня Стас зовут, чтобы быть честными. В конце была табличка, где было написано, сколько потребляется ресурсов парком для расчёта.

175: В текущем, в текущих условиях со всеми доработками. Угу. Так, мне показалось, что вот, вот, да, вот эта вот табличка красивая. А сколько ресурсов клихаус потреблял на 12 часов?

176: Я понял вопрос, то есть где выгода сравнения по ресурсам крик хауса и парка не было я правильно понимаю, ваш? Ну да, мы же как бы да, это связано с тем-то, что когда мы реализовывали решение на crack house.

177: Объём данных был не этот и по факту тогда был core четырна это 7 шардов по 2 машины, но и объём данных, которых мы обрабатывали в тот момент кластер, у нас

178: Тоже не 300 машин тут прям намного меньше где-то на порядок. То есть там были в принципе соизмеримые цифры. Ну и тут ещё такой момент я не говорю то ну надеюсь не видно было, что clickhouse работает.

179: Долго ехаус быстрый, но обслуживание вот этого решения оказалось тяжёлым. И если мы вернёмся, основной вариант был в том. Мы сейчас вернёмся.

180: Чуть чуть заодно вы вспомните, про что было.

181: Там был пример. Ну давайте даже вот этот.

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

183: Добавление узлов также сыграло роль. То есть нам поддержать решение на спарке намного удобнее, чем на кликхаусе. Просто. Угу. Спасибо. Ну, тут, на самом деле, по поводу кода можно подискутировать, как бы сейчас есть современные шаблонизатор.

184: Которые позволяют в более человекочитаемом виде там оперировать этими кусочками. Ну, в принципе, ну, а все-таки примерно, то есть, во сколько по ресурсам, я насколько помню, у нас 1 реализации было

185: 30 хостов вместе с ней нодами, а в клихаус было, получается, 14 хостов.

186: Ну то есть получается, что кликхаусу чуть не хватает каких-нибудь компьют нот. Аля, вот, вот эта вот история, я не расслышал. Получается, клихаус не хватает каких-то компьют нот, просто компьютер, да, можно сказать.

187: Так что не хватало, но я бы не сравнивал именно с точки зрения скорости и объёма. Я же специально не сравнивал по ресурсам. И даже вот для этого доклада я специально сделал одни условия, хотя

188: Внедрение каждого из происходило на разных этапах и на разных объёме кластера, поэтому сравнивать именно Крикау и sparks не было моей задачей, но если вы хотите, я могу это

189: После, ну, объяснить, в чем плюсы, в чем минусы у нас были прям более подробно, но по компьюте, возможно, мы здесь и на креате были меньше. Спасибо. Спасибо.

190: Пожалуйста, ещё вопросы?

191: Ага, вот рука.

192: Смирнов Антон ЮMoney вопрос такой ты говорил, что у вас там до 6 часов там выполнялся расчет. Если он падал, был не круто. Вот в финальном решении, которое у вас сейчас, сейчас как происходит дизастер рекавери, как вот вообще?

193: Справляетесь. Я понимаю, что 3 часа это быстро, да, но тем не менее, ладно, не буду искать. Это в чем суть. У нас были определённые инфраструктурные ещё проблемы в то время, которые

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

195: Полностью. Единственное, это сейчас не так критично для нас, потому что 3 с половиной часа, ну, я не помню, когда последний раз у нас такая проблема была, если честно, но все это

196: Осталось. Мы, как бы, если что знаем, что делать, то если я смог ответить на ваш вопрос, то есть абсолютно все доработки, которые я перечислил, они сейчас в проде, и они накладывались решение на решение.

197: Так, ещё вопросы?

198: Да, пожалуйста.

199: Раз, раз, привет, привет, Сергей алиэкспресс russia меня такой вопрос а что является бутылочным горлышком, что является вот камнем преткновения в этом решении? Почему просто не завалить ресурсом?

200: Потому что их не было. Ну, на самом деле, здесь, ну, вот 3 часа. Почему я не могу запустить 5 раз больше цпу или получить прирост скорости? Да. Слушай, я, наверное, не сказал про это. Вот задача, о которой я рассказываю, она вообще не

201: Единственное, я не могу как бы прийти и с 2 ног сказать все. Теперь кластер мой, и я считаю на нём свои показатели. Есть ещё куча задач, которые также должны на кластере считаться, поэтому мы

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

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

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

205: Пьют, а я для себя не мог понять, как, почему они все на это обращают внимание. У нас самое бутылочное горлышко, это как положить объём данных такой, и как его потом считать. То есть

206: Для нас диски это самая долгая задача, то есть чтение и запись. А вот задача по расчёту это занимает, ну, для нас минимальное время. Я почему прицепился? Вот ты сказал, что

207: Не стесняйтесь приходить к бизнесу и спрашивать каких-то воркраунд, каких-то допущениях. Вот здесь тоже самое. Вполне возможно вы упёрлись в проблему и пытаетесь её решить технически. То есть вам нравится эта задачка с точки зрения алгоритмики? Вы ищете какое-то решение, хотя

208: Есть воркраунд, есть допущение от бизнеса и есть допущение залить ресурсами. Вполне возможно, если задачу решать не чистым спарком, не как алгоритмик у нас парке, а не знаю, на pierre, например, то есть уйти на более низкий уровень, использовать

209: Диски. Получится более оптимальное, более живое решение. Почему нет?

210: Это вопрос хороший. Я как-то задумался тоже о том, а почему бы нам просто не закидать дисками? Просто каждый раз спотыкаюсь о реальность, когда мне говорят, что их нет и в целом нельзя сказать, что

211: Бизнесом мы не общаемся по этому поводу. Мы просто вместе с ним ищем наши возможности. Я понял. Спасибо.

212: Ещё вопросы? У нас ещё есть 2 минутки по поводу адити ных показателей инкрементного расчёта. Пётр закинул, если у вас есть опыт расчёта недитивное показателей инкрементным способом.

213: На автопати с удовольствием пообщаемся с вами, расскажем свои идеи, ну и выслушаем вас. Это прям для нас, как бы следующий челлендж. Ну что у нас остаётся буквально 2 минутки, наверное, чтобы и об этом

214: Там не сказал специально, поэтому вопросов было мало. Но у нас есть приз за лучший вопрос. Вот, Пётр, какой тебе вопрос больше всего понравился?

215: Ага, так, я помню вопросы.

216: Мне в принципе понравился.

217: Так, друзья, будем потихонечку присаживаться, проходить на свои места. Мы продолжаем

218: Хочу представить вам сергея, вы уже успели познакомиться. Самый лучший вопрос был Сережин Сергей, инженер компании алиэкспресс russia. Как вы уже поняли, чтобы, скажем так, немножко повысить наше внимание ещё больше.

219: К этому докладу скажу следующее. Я был на предварительном просмотре сережиного доклада, его слышал. Потом мы уехали на смарда у, и там 1 большая компания схожего по цвету с

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

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

222: Ответили в самом конце. Пожалуйста, Серёж, тебе слово попрошу приветствовать. Спасибо. Это доклад. Всем привет.

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

224: Да, для начала обо мне, как уже сказали, я инженер, даже став инженер компании алиэкспресс russia, и повидал всякое, поработал я и с биай системами разными поработал, и с хранилищами было.

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

226: Внедряемые в компании, в процессы и тому подобное и вот буквально недавно, наверное, полгода, как мы с командой подумали и решили а почему бы нам не внедрить деку дата quality?

227: Ну, собственно data quality это такая штука, которая в вакууме не существует. Качество данных нас же не интересует абстрактное качество каких-то данных ни о чем. Оно интересует нас в контексте чего-либо и.

228: И поскольку мы сегодня собрались обсуждать биг дейта биг дату митап по этому направлению, я хочу поговорить про data quality в контексте дата Лейков или data lake хаусов, которые сейчас наверняка у вас тоже у всех на слуху, ну и?

229: Краткое содержание того, о чем буду говорить все вы видите, пойдёмте дальше начнём с того, что такое data lake хаусы почему почему data quality именно в контексте длк длх здесь есть смысл вообще?

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

231: Которые оперировали жёстко структурированными, известными и сравнительно небольшими объёмами данных. Потом, чуть позже, мы пришли в эру биг дейта, когда огромные объёмы вариативной, меняющейся, скоростной

232: Именно большой даты приходили к нам откуда-то извне. Обычно это были какие-то машинные машинные данные, что-то поступающее от сенсоров, что-то поступающее с датчиков и так далее. И это нужно было обрабатывать. Ну вот.

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

234: Лучшее из обоих миров, из классических хранилищ данных, из даталейки, которые объединены. Собственно, мы в компании алиэкспресс Россия, строим даталей хаус. Да, и вы тоже, я думаю, что большинство присутствующих здесь коллег занимаются именно

235: Lifehouse ну и говорить будем как раз-таки о data quality в контексте data lake house здесь я не могу не привести вот такую интересную картинку. Знаете, я недавно с семьёй сходил на кулинарный мастер класс и вот.

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

237: Потоки, эволюция данных от сырья, от каких-то Сырых ингредиентов до конечного блюда, которое мы потом потребляем, используем. Это может быть морковный пирог, это может быть морковный крем, суп, что-то ееще подставьте сами. К чему?

238: Эта картинка к тому, чтобы вы ещё раз вспомнили или узнали, если вы не знали о том, что из себя представляют деталей хаусы и в чем их, наверное, концептуальная особенность в том, что они слоистые, в том, что

239: Данные перетекают от слоя к слою, проходят какую-то фазу очистки, обработки, реконсиляции, красивое слово, да и получение конечной конечного блюда конечной витрины.

240: Ну, если продолжать вот эту вот метафору с приготовлением данных в контексте data lake house, то что такое етль, тоже, наверное, известная вам аббревиатура экстракт трансформ лоуд етль, это то, как мы?

241: Готовим, как мы вот эту сырую морковку или, не знаю, кабачок турнепс превращаем в целевое, не знаю, блюдо в целевую витрину.

242: Да, это, это инструменты, это ножи, это какие-то поваренные книги с рецептами и тому подобное.

243: Я очень надеюсь, что ваши, ваши инструменты, ваши поваренные книги действительно выверены. То есть они покрыты юни тестами, и вы уверены в том, как вы формируете ваши витрины, как ваш морковный пирог, доставляемый конечным потреби.

244: Любителям, не знаю, топ менеджменту где-то на дашборде он выверен.

245: То есть вы уверены в самом алгоритме формирования этого пирога? Но всегда ли этого достаточно? Всегда ли все хорошо с данными? Уверяю вас, не всегда. Более того, я уверен.

246: Что вы сами это знаете? Вы сами сталкивались с ситуациями, когда грязные данные, грязные ингредиенты влияют на конечный результат. Что такое грязные данные? Если оперировать вот этой метафорой с приготовлением, то это

247: Ну, гнилая морковка, гнилой ингредиент. Не соблюдали условия транспортировки, да, что-то пошло не так или ещё хуже. Хотели приготовить морковный пирог, а на вход нам подали. Ну, поставщик облажался кабачок в сентябре это, наверное, правомерно.

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

249: Системы та же apache Кавка. Она предполагает, что у нас могут быть дубли в общем, дубли, пустые ключевые атрибуты, где-то что то пошло не так. Данные до нас не доехали или доехали не полностью, ну и совсем уж экзотические случаи, когда в принципе

250: Приехало совсем не то ожидали морковку, приехал турнепс.

251: Окей, плохо работать с грязными данными. Плохо формировать грязный результат, как вы считаете?

252: Ну серьёзно, давайте вот вернёмся к этой, к этой метафоре с готовкой. Вот вы пришли в ресторан, вам подали блюдо с мухой или со стеклом? Ну окей, может быть, разочек вы и съедите, но пойдёте ли вы туда 2 раз, я не уверен.

253: Я бы не пошёл вот также и здесь, если вы, если вы конкурентная компания, находитесь на конкурентном рынке и ждёте, что к вам будут приходить за вашими блюдами, за вашими морковными пирогами, наверное, вы не будете мириться с тем, что в них будут

254: Волосы или ещё что-нибудь похуже. Ну и да, ещё 1 пример. А что если вы поставляете ваши данные не конкретному 1 человеку, какому-нибудь топ менеджеру, который сидит наверху и смотрит на ваши отчёты? А что, если ваши данные завязаны?

255: На процессы других компаний, если вы внедряете или применяете так называемую операционную аналитику, то есть на формируемых вами витринах таблицы витрины, как угодно назовите, строится бизнес других компаний.

256: То есть, опять же та метафора если ваши морковные пироги каждое утро разъезжаются в детские сады, школы, не знаю, куда угодно в кафе вашего города, и вы допустили ошибку, вы допустили грязную гнилую морковку или, не знаю, турнепс.

257: И получившиеся морковные пироги разъехались везде плохо. Я считаю, что безумно плохо, как

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

259: Я не хочу этот вариант рассматривать. И давайте рассмотрим другие альтернативы. Здесь они представлены. Если вы знаете что-то ещё, давайте обсудим. Я с радостью готов узнать какие-то альтернативные варианты. Ну вот 1, что приходит в голову.

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

261: Более того, это вполне применимо, если вы оперируете небольшими объёмами данных, если вы оперируете не big data, если нет вот этой вариативности и скорости объёмов, в том случае вы действительно можете вставить проверки прямо в потоке.

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

263: Небольшие объёмы данных с небольшой скоростью поступления, когда мы говорим про вал морковок, когда морковки к вам сыплются по морковному трубопроводу откуда-то из белоруссии или Бульба там сыпется в этом случае отбрасывать и

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

265: То есть в моменте, когда морковный пирог готов, мы его все, мы его приготовили, он лежит у нас, лежит у нас на столе. Так вот, перед тем, как выносить его клиенту потребителю или рассылать во все садики и школы города.

266: Давайте на него посмотрим, давайте его проверим.

267: И здесь мы переходим к так называемому ваб паттерну. Эта аббревиатура стала известна уже больше года, как и в русскоязычном комьюнити. Вот именно связанно с большими данными. Я знаю, что тоже активно исполь

268: Пользуются и многие компании её внедряют. Здесь вкратце приводится принцип работы этого паттерна. Но тем не менее я ещё раз проговорю суть максимально простая, просто до идиотизма простая. Формируем результат, формируем наш морковный пирог.

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

270: То есть сделали аудит, проверили и убедились, что нам не будет стыдно за это блюдо, и только потом делаем публикацию, только потом выносим это наружу полностью уверенными в том, что мы приготовили здесь.

271: Что касается вот этой паблиш фазы, очень важно, если мы опять вернёмся от метафоры с готовкой и переключимся к tale хаусам, таатта Лейкам и так далее вот этот вот war паттерн.

272: Очень важно, чтобы он был zero copy, чтобы вам в момент публикации переноса данных можно было просто вот нажать пальцем там, не знаю, щёлкнуть пальцем. И вот эта вот приготовленная витрина, она не переносилась целиком, а не знаю,

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

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

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

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

277: Включить вот этот паттерн, если очень грубо включить такой гид лайк. Режим работы, гид, режим работы с вашей таблицей. Собственно, уже, наверное, люди уже понимают, к чему это ведёт, к тому, что дальней

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

279: Другими табличками, которые тоже находятся, которые, для которых тоже включена эта тейбл пропертис. Вот в такой изолированной гит лайк веточке. И это не видно никому другому. То есть остальные пользователи, которые подключаются через

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

281: Вашими потенциально опасными несвежими блюдами итак, записали записали наши данные с помощью ddu етль запроса в целевую табличку в рамках.

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

283: С включённой опцией, спарк ваб бреч, если все хорошо, вас устраивает качество ваших данных? Нет дубликатов, нет пропусков, нет волос, стекла. Видите? Да, у меня какой-то птср с волосами в блюдах.

284: Тогда в этот момент можно делать публикацию, можно доносить вот эти сформированные изменения до Конечных потребителей, и вот здесь бинго как раз и используется zero copy механизм, мы просто вызываем некую систему.

285: Процедуру фаст форвард, которая подменяет, которая вот в моменте делает мастер ветку, ну здесь main ветку, смотрящей на merge, new трансферс, ну и потом оставшуюся веточку, которая хранит в себе какие-то

286: Лишние метаданные можно удалить. То есть вот преимущество технологии айсберга и других подобных движков, которые вот насаждают ещё дополнительный уровень метаданных. А теперь для сравнения, что

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

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

289: Не в какую-то гид лайк ветку нашей таблицы, а пишем в таблицу сбоку, то есть мы создаём новую табличку, мы даём ей какой-то префикс или суффикс, говорящий о том, что эта табличка конкретной вап ветки.

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

291: Мы делаем рокировку данных и вот этой из этой таблицы сбоку, у которой есть суффикс, там некий ваб айди, мы делаем перенос в целевую таблицу. И вот здесь следите за руками. В чем преимущество айсбергов по сравнению с

292: Айсбергов с маленькой буквы по сравнению с ванильным решением в том, что в айсберге я нажимаю, я вызываю некую процедуру систем фаст форвард, и буквально секунды спустя моё блюдо опубликовано здесь же я должен сделать

293: Некую атомарную, консистентную вот эту рокировку, перенос данных в целевую табличку. И это это труднее. Ну,

294: Может быть именно у нас немножко труднее получается, но, но тем не менее труднее. Почему? Потому что мы вынуждены либо переписать данные из таблицы сбоку. То есть это опять же это не гид ветка, это таблица, полноценная таблица, сбоку из которой мы можем

295: Сделать селект звёздочка бла бла бла и вставить инсерт аппенд в нашу целевую табличку медленно, дополнительное использование ресурсов, потенциальные ошибки и так далее. В общем не очень.

296: Приятно. И здесь мы сошлись на том с командой, что будем переносить сами данные. То есть мы внимательно следим за структурой создаваемой таблицы сбоку и исходной таблицей. То есть вот что мы хотим опубликовать.

297: Какой, какой результат? Мы должны синхронизировать табличку сбоку и исходную табличку по по схеме данных записываем данные в табличку сбоку, будучи уверенными в том, что она по

298: Теме комфортно, исходной табличкой прогоняем проверки, а потом делаем рокировку на уровне данных поскольку у нас используется ванильный хадуп, данные лежат в hadoop hdfs, файловая система мы просто определяем конкретный location наших дата Фай.

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

300: Небольшой скриншот 1 из боевых Дагов я думаю никому не нужно рассказывать что такое даги это 1 из компонент, 1 из терминов из мира эйрфлоу тоже надеюсь не нужно рассказывать что такое flow?

301: Так вот, та группа, которая как раз и имплементирует вот пример вап паттерна для 1 таблички Дим гео, справочник географических локаций, где на этапе врайт мы используем вот здесь так называемый

302: 2 аш пайспарк, оператор. Здесь вот видно, какие операторы используются на этапе аудит. Мы используем некий деку пайспарк, оператор об этом чуть позже и на этапе паблиш, некий вап, паблиш, оператор. То есть это вся вот эта вот машине.

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

304: Можно имплементировать даже на могильном хадупе, но это медленно. Это более трудоёмко и потенциально более опасно, нежели что-то из модер. Дата стека, в частности, айсберг, дельта или худи. В общем, внедряйте их, а я прошу.

305: Связаться кого-то из community за рекламную интеграцию итак, лап поговорили, ну достаточно очевидные вещи записали, аудировали, опубликовали, очевидно, да не.

306: Всем аудит это это как раз то, что мы должны. Это то, что тождественно равно дата quality, то есть именно здесь data quality раскрывается в полный рост на фазе аудит. Именно там мы должны применять наши дата колити провер.

307: И именно там мы должны делать эти проверки максимально демократично. Что я имею ввиду?

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

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

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

311: Таблиц, которые мы формируем. В общем, не все было радужно. И к чему мы в итоге пришли. Более того, интересный кейс. В какой-то момент мы выяснили, что некоторые проверки даже не проверяют. То есть они

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

313: И что мы стали делать? Мы стали искать некий некий фреймворк. Не знаешь, не знаешь, что делать? Ищи фреймворк. Это же старая классика. И рассмотрели.

314: Различные варианты. Все мы знаем как гуглить. Все мы знаем, что есть аббревиатура дку спарк, что-то ещё там хадуп стали гуглить, стали смотреть и сравнивать. 1, что вылазит в любом поисковике при поиске по

315: Деку и spark это конечно же грейд expectations, особенно когда у вас используется пайспарк, мы к сожалению или к счастью используем именно пайспарк, так вот, грейд expectations крутое решение очень мощное.

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

317: Поняли что это не наш вариант, для нас это оказалось слишком сложно я уверен, что больше половины присутствующих тоже смотрели на great expectations тоже смотрели их доки может быть какие-то видосики смотрели и тоже мало что поняли вот я.

318: Мало что понял, мне это было не по силам. 2 фреймворк, который мы по пилотировали и который нам зашёл. Это сода. Собственно, про него я и буду дальше рассказывать.

319: Тут, наверное, ключевое преимущество. Почему он нам так зашёл, почему нам так понравился? Это читаемые и понятные проверки, то есть проверки пишутся на каком-то, ну, достаточно внятном языке, и к этому дсль, к этому.

320: Ты привыкаешь достаточно быстро. Ещё альтернативное решение, которое мы тоже рассматривали, но уже так поверхностно. Это, конечно, дику. Поскольку раньше некоторые члены команды писали на scala, то посмотрели и на него, но все-таки скала не наш путь.

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

322: Которые его поддерживали, они были заняты на других проектах. И те фичи реквесты, которые мы заводили, они реализовывались не так быстро, как нам хотелось бы. В общем, мы выбрали соду вкратце.

323: Что такое сода? По большому счёту, это питон, библиотека, pip install и и все такое, и погнали, в чем же её основные преимущества, как я уже сказал, это понятные проверки, так называемая.

324: Soda чек ленгвич, проверки сода сиэль проверки просто сода чекс, где легко и непринуждённо, демократично описывается, как именно вы хотите и что именно вы хотите протестировать, проверить ну и?

325: Разумеется, поддержка спарк эскуэль вообще в целом сода, она ориентирована на эскуэль движки, на какие-то вот такие эскуэль лайк движки, которые могут выполнять запросы. И так она и работает. Вот эти вот понятные

326: Soda чек ленгвич не скажу запросы конструкции да, вот такие вот конструкции они в момент запуска некой проверки они транслируются в эскуэль запросы, причём транслируются в эскуэль.

327: Вопросы, согласно тому движку, который вы используете, вы можете подключить различные движки. Это может быть вертика, это может быть БИК вери, что угодно. То есть в зависимости от того, какой движок используется в такой запрос, с такой вот с таким синтаксисом.

328: Это и будет транслировано. Ну и, наконец, с помощью этого движка, например, подключённой спарк сессии, эти эсколь запросы выполняются и возвращают какой-то результат.

329: Ну, давайте посмотрим, а что ж там такого классного то? Почему, почему Сергей здесь распинается? Проверки, проверки, которые представлены, доступны нам в соде, делятся на 2 большие группы. Это стандарт.

330: То, за из за чего мы, собственно, и Любим соду, и пользовательские, то, из за чего мы Любим соду ещё больше.

331: Стандартные. Ну смотрите, ну вот очевидно же, инвел аккаунт, инвалид, персент, фейлит, роуз, дубликат, персент. То есть я, я уже сейчас читаю проверку, я понимаю, у меня уже на подкорке это срабатывает, что именно

332: Она будет делать вот в этом и есть суть демократизации. Деку проверок в том, что, да, кто угодно с инженерным образованием или даже без инженерного образования. Джун может прийти и начать писать проверки, просто набрасывая вот такие вот

333: Ключевые слова пример проверок, которые у нас работают в бою.

334: Проверки чекс фо Дим пейдж тайп, то есть некий справочник некая табличка, которая создана у нас в data lake house, data lake house, которая проверяет что-то ну разве не очевидно, можно даже убрать теги нейм?

335: Описание. И уже будет понятно, что делает эта проверка. В 1 случае проверяет количество дубликатов по столбцу лаяут айди. Должно быть 0. Если не 0, то будет ошибка. Либо либо ворнинг тоже настраивается мисси каунт.

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

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

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

339: Пользуете опенсорсную версию. Ну это, это бизнес, просто бизнес. Если вы не покупаете некую подписку и не храните результаты ваших проверок где-то в облаке, то часть вещей вам недоступна. Ну и окей, ладно.

340: Даже тех проверок, которые есть 80% проверок, которые нам доступны в опенсорсной версии, они уже покрывают большую часть наших потребностей. А то, что не покрывают стандартные проверки, мы покрываем юзер дефайнд, мы покрываем нашими пользователя.

341: Проверками. В частности, здесь приводится пример того, как мы проверяем инкремент, как мы проверяем, что наш справочник, скол, что прирост данных в нём находится в неком неком доверительном интервале.

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

343: Raw аккаунт или каких-то ещё вот этих баззвордов я могу сам написать запрос, ориентируясь на тот движок, который будет использоваться в моём случае спарк эскуэль, проверить его, выверить и выпустить в prod.

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

345: Витрину и потом над этой витриной строим дашборд, который показывает нам, показывает нам динамику проверок какой-то, не знаю, day today, сравнение проверок для конкретной таблицы, общее количество упавших, не упав.

346: И так далее. Проверок, в общем, достаточно достаточно неплохо. Это как как замена стандартному решению сода клауд, от которого мы отказались. Ну потому что soda клауд хранит, да?

347: Наших проверок неизвестно где. Мы не можем себе такое позволить. Мы хотим, чтобы все данные оставались у нас. Поэтому не используем. Клауд. Решение используем on premise опенсорсное решение. И вот, в частности, для этого мы и сгружаем.

348: Все результаты наших проверок куда-то в витрину и по ней потом строим дашбордик.

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

350: Можно делать через осерты в вашем коде это можно делать вот с помощью wap паттерна прогонять какие-то простейшие сколь запросы можно даже внедрить какие-то фреймворки грейт expectations да пожалуйста внедряйте, используйте, но будет.

351: Ли это приносить пользу, будут ли ваши разработчики в итоге? Или ваши деку инженеры эти проверки писать и применять далеко не факт, что будут, как мы эту проблему решили.

352: Есть небольшой шаг в сторону. Отступление у нас для работы с данными для итля используется монорепозиторий. Я думаю, многие из вас про это слышали. Такое тоже достаточно модное решение, где все

353: Хранится в 1 месте такое вот кольцо всевластия в нашем монорепозитории находится как ддл скрипты, то есть создающие витрины, таблицы, описывающие структуры этих витрин. Там же находятся и миграции, которые

354: Держи в себе все альтертейбле команды, все изменения. Там же находится и код пайспарк приложений. То, что является етелем. Там же находятся юниттесты. То есть мы уверены в том, что наш етель работает так.

355: Как мы от него ожидаем, мы покрываем пайтест юниттест ми все возможные кейсы. Ну, конечно, я вру, конечно, не все, но, но, тем не менее, уровень покрытия нашей кодовой базы 73%. Это, это очень неплохо. То есть мы

356: Мы действительно стараемся покрывать наши детель процедуры, разбивать их на функции и каждую функцию покрывать позитивным негативным сценарием на синтетике. Здорово. И вот туда же мы впихнули и судопроект у нас

357: Есть отдельный каталог, в котором хранятся ям файлы с нашими соддо проверками, множество проверок.

358: Да, ну и где-то рядышком ещё ci cd. Без него, конечно же, никак. Что такое сиайсиди, наверное, пояснять не нужно. В нашем случае это тот инструмент, с помощью которого мы прогоняем различные тесты юни, тесты, интеграционные тесты, проверки на на форматирование.

359: Собственно, сборку кода в какой-то целевой артефакт, в нашем случае колесо, wheel, колесо и публикацию куда-то на сервера. Ну то, то есть deploy. В общем, все это находится в 1 месте, и мы

360: Мы увязали с помощью регрессионного юниттеста все эти проверки с кодом, с кодовой базой итля и с ддл скриптами. Это ещё не все, это, это лишь начало, но это уже позволило нам получить консистент.

361: Версию наших проверок относительно данных. То есть если какой-то разработчик внедрит ломающую функциональность, внедрит код етеля, который что то что-то меняет или ещё хуже поменяет табличку.

362: С помощью ддл скрипта. И это приведёт к неработоспособности сода, проверки, деку проверки. Мы об этом об этом узнаем. Наш регрессионный тест покажет нам, ну, перед, перед созданием Тега, то есть перед релизным

363: Циклом мы поймём, что что-то пошло не так. Сода, проверки стали невалидными, какие то какие-то из них

364: И, наконец, это вот это how to я считаю, что нужно писать больше Тестов Богу, Тестов, да и много Тестов не бывает не знаете, чем заняться в пятницу вечером напишите тестик, вам потом скажут спасибо.

365: Так вот, ключевой pointe всего моего доклада в том, что деку проверки это код, а код должен быть протестирован. Мы не должны доверять тому, что кто-то написал деку проверку, и она

366: Наверное, работает, наверное, какой-то момент, когда что-то пойдёт не так, когда волосы попадут в наши ингредиенты, наверное, деку проверка нам об этом скажет. Так вот, не факт. Давайте убеждаться, давайте покрывать юни тестами наши

367: Проверки. И, собственно, что мы сделали? Мы стали писать юнитесты на деку проверки, и все. И это, это реально меняет правила игры, когда ты, будучи тимлидом техлидом, в общем, будучи человеком, который отвечает за

368: Ревью кода видишь, что кто-то деку, инженер, дата инженер, вносит что-то в мой репозиторий, какое-то изменение, изменение и новую деку проверку и не покрывает её.

369: Тестом деку проверку не покрывает, юни. Тестом ты вправе отклонить в рамках ревью этот мёрший квест. Дорогой, доработай. Я не верю, что твоя деку проверка. Она очевидна. Да, я согласен, но я не верю, что она безопасна. Что

370: Она сработает, когда настанет время, и каждый вынужден сейчас, ну вот такое добровольное принуждение вынужден писать по 1, как минимум по 1 юни тесту на позитивный и негативный сценарий.

371: Должен проверить, да, должен проверить, что все будет хорошо или все будет плохо.

372: Итого качество данных важно с этим, наверное, спорить мы не будете на больших потоках данных, на больших объёмах данных лучше использовать wap паттерн, чтоб проверять целиком блюдо.

373: Целиком перед публикацией, а не не в моменте не в потоке для аудит фазы нужны проверки проверки должны быть демократичными какой фреймворк вы выберете дело ваше, решайте сами это может быть great expectations допуска.

374: Но быку проверки должны быть встроены в процессы, в процессы разработки, и они должны покрываться тестами. На этом. Все, спасибо.

375: Спасибо. Спасибо, Сергей. Твои аллегории просто топчик, волосы и детские сады. Это, конечно, классно. Прям чуть не расплакался. Окей, спасибо.

376: Ребят, есть возможность задать вопросы? Мы чуть чуть овертайме, но я думаю, ничего страшного. Да, пожалуйста, здесь вопрос.

377: Отличный, очень прикладной доклад спасибо, очень интересно, мы тоже развиваем у себя в юмане такие вещи, поэтому максимально конкретный вопрос вот ты сказал, что у вас в unit?

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

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

380: Грейтер expectation там стандартный набор проверок, так вот зачем юни тестами все обмазывать, можно просто же выделить методологические там типовые проверки, а потом их переиспользовать. Мне просто нравится писать проверки.

381: Писать, писать тесты. Вот больше Тестов Богу Тестов. Смотри, может быть так, что та штука, которой ты доверяешь, тот фреймворк, которому доверяешь, в какой-то момент получит ломающую, ломающую функциональность изменения.

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

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

384: На основании проверок, которые перестали работать. Ну хорошо, если можно, 2 вопрос. Вот ты говорил про демократизацию и значит то, что у вас инженеры делают проверки, как

385: Вы защищаетесь от такой истории, что, допустим, вот совокупность проверок может съедать столько ресурсов, что аффектить уже бизнесовые процессы, потому что, как я понял, что инженеры это отдельная команда, они там накрутят проверок по желанию.

386: Пользователя на каждую колонку в итоге будет нарушен, не знаю, эслэй по доставке данных. Угу. Да, мы решаем с помощью тегов. У нас есть так называемые п. Теги приорити, теги п, 0, п, 1, п, 2 и чаще

387: Всего п 0. Теги, то есть самые критичные, пишут деко инженеры, то есть они за них отвечают. То есть все равно так или иначе, за качество данных будут отвечать деко, инженеры к ним придут и их распнут, а дата инженеры пишут проверки, потому что они, ну, лучше код понимают, то есть они могут

388: Придумать какую-то хитрую проверку, которая вот видя по логике, что здесь может стрельнуть, они её пишут, и потом деко инженеры тоже смотрят и ревьювят, и решают, что да, это хорошая проверка. Мы сделаем её п 0. То есть проверок у нас много.

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

390: Блюдо перед вынесением конечным потребителем. Понятно, что время ограничено. Мы хотим как можно быстрее прогнать наши проверки. Если мы делать регресс, проверять все 100, 500 проверок, включая п 100, приедет п 100, то это буде

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

392: Вечером или ночью, когда ресурсы кластера немножечко подсводовом, потом уже в асинхронном режиме, через dashboard, мы посмотрим, где у нас что пошло, не так. Проанализируем, сделаем выводы ещё раз. Спасибо. Отличный доклад у меня конечн.

393: Ещё есть вопросы, но их потом задам. Вопросиков побольше в этот раз. Поэтому поскромней задам вопрос из чата, от рустама не по очереди, по очереди, если проверка потоковых.

394: Данных, какие есть для этого решения потоковых данных? Ну, потоковых данных, потоковых данных. Хороший вопрос. Кстати, Рустам, это прям, прям хорошая. Я догадываюсь, что это за Рустам.

395: Наверное, нет, у нас есть мёртвая очередь, когда мы отбрасываем в мёртвую очередь. Ну, понятно, что kafka, да, чаще всего именно кафка используется как инструмент доставки вот этой реалтаймовой потоковой информации, над ним работает спарк страк 4.

396: Приложение, оно вычитывает что-то и обрабатывает. И вот прямо сейчас, да, дата колити проверок для потока у нас, наверное, нет. У нас есть такие мини ассерты, которые не препятствуют этим данным.

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

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

399: Привет. Спасибо за доклад. У меня, в принципе, тоже вопрос по тестам, но более такой, типа, детализированный. Интересно, сколько у вас вообще Тестов? Сколько они идут по времени? Как это влияет на доставку? Ну, типа конечного результата в deploy хороший.

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

401: То, наверное, нужно, ну, как-то, какую-то инфраструктуру выстроить для Тестов, возможно, тем более, если синтетика использовать, какие-то там, не знаю, мимезис или ещё что-нибудь. Вот об этом интересно. Угу. Окей, сейчас попробую что-нибудь рассказать.

402: Самое простое, сколько длятся наши тесты. Регресс у нас сейчас проходит за 15 минут. То есть все тесты, которые есть, включая регресс, по дата колити проверкам, да, то есть тесты на дата колити. То есть вообще все, все тесты проходят за 15 минут, это плохо, и мы

403: Только сейчас начали задумываться о том, что пора оптимизировать. Почему? Потому что, ну, долго, 15 минут ты делаешь любой коммит в рамках меши квеста, а коммитим мы часто, и ты ждёшь 15 минут. Ну, это как бы это уже накладывает ограничения на time to market. Мы, мы

404: Вынуждены как-то это тюнинговать. Работает это все в 1 поток, да, то есть у нас используется пай тест как фреймворк тестирования, мы используем локальный спарк. То есть у нас же, у нас же про спарк разговор, то есть все

405: Вокруг спарка крутится так, то есть есть pytest фреймворк, есть фикстуры пайтест фреймворка, которые запускают локальный спарк с какими-то минимальными настройками. 1 ядро там 4 потока, нет, веб айки.

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

407: Да вот пожалуй все что ещё расскажешь сами тесты сама вот эта вот инфраструктура где запускаются тесты это некий docker контейнер так называемый билд систем то есть в нашем гитлаб нас gitlab да, у нас.

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

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

410: Билл систем образа, то есть им все, все необходимо доступно и вот там это все прогоняется. Ну вот 15 минут плохо, да, будем тюнинговать точно, да, 1, что мы сделаем, это разбиение на мультипоточность или мультипроцессность, даже, наверное,

411: Чтобы pytest прогонял это несколько потоков и наверное 1, да, 2, что сделаем, это разобьём на группы отдельно.

412: Юниттесты, отдельные юниттесты на деку, проверка и так далее. Пока все.

413: Коллеги, предлагаю дискуссионную часть переместить на автопати. У нас ещё есть вопросы. Время поджимает до следующего доклада от михаила онлайн. Вопрос сода умеет выполнять.

414: Несколько проверок 1 из cure запросом. Ведь данные бывают очень объёмные. 20 раз их читать заново очень накладно. Действительно бывают витрины. Отличный. Десятки гигабайт весят. Ущучил ты меня, Михаил. Я даже догадываюсь, кто это. Да.

415: Это 1 из ограничений соды, с которым мы пока миримся, сода не умеет сгребать различные проверки в 1 запрос. То есть представим, что семантически различные проверки над 1 таблицей можно написать 1.

416: Запросом. Ну то есть ты проверяешь, не знаю, количество пустых атрибутов, процент пустых значений в каком-то атрибуте, в атрибуте 1, 2, 3 на текущий момент, если ты напишешь такие проверки, 3 проверки, Миссинг персон,

417: Атрибут 1, атрибут 2 и так далее. У тебя сформируется и запустится последовательно 3 разных спарк. Сколь запроса это не очень хорошо, мы с этим миримся, потому что сода не умеет транслировать это.

418: В единый запрос. По крайней мере, та версия, с которой мы живём сейчас, совместимая с нашей версией, пайспарк. Что мы делаем? Мы, конечно же, мы мониторим время работы наших наших проверок, спарк, сколь запросов, которые запускаются в рамка.

419: Проверок и если понимаем, что вот здесь прямо больно, мы переписываем на user defined, на кастомную проверку, где сами описываем, что и как проверять вот, ну и надеемся, что в будущем комьюнити отвечающее за развитие соды, что-нибудь придум.

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

421: Окей, спасибо. Ну, наверное, последний вопрос. Пожалуйста. Здравствуйте, Сергей. Здравствуйте. Стас. Вопрос, наверное, больше к тебе, как к архитектору. Скажи, пожалуйста, время, когда выбирали тестовый фреймворк?

422: Примерно какой год этот 2024? Замечательно. Тогда, естественно, я не мог задать этот самый простой вопрос из 3 букв. Почему не дибити? Это отличный вопрос. Это прямо очень хороший вопрос.

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

424: Какие-то проверки и это потом работает. Более того это прекрасно работает. Более того, у нас был mvp проект по внедрению дибити, мы его раскатили, мы реализовали множество витрин и справочников, на дибити, которые формирова

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

426: Но в нашем случае это не взлетело, не взлетело, потому что точка входа, то где запускать, сколь запросы у нас отсутствовала альтернативы, которые на тот момент мы использовали.

427: Это spark Триф сервер, то есть где-то поднятое решение, которое может принимать сколь запрос по дибиси jdbc протокол и его запускать на выполнение он работал крайне нестабильно, а qb ещё 1 отличное реше.

428: Мы по ряду причин не стали внедрять если бы сейчас передо мной стоял вопрос использовать дибити и qb, я бы наверное попробовал, попробовал потом, если бы мы находились вот в начале пути, но.

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

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

431: Или spark, или spark ну, спарк эскуэль нужен спарк эскуэль, но я же видел на картинках у тебя что, проверки кастомные для соды, тем не менее, пишутся на эскуэль? Да, но сейчас, сейчас.

432: Поясню, да, они пишутся на скуеле, но когда ты их запускаешь, ты их запускаешь через что-то, как питон, библиотеку. То есть в момент запуска у нас есть отдельное пайспарк. Приложение называется деку раннер, которое 1 делом запускает спарк сессию, то есть у неё

433: Есть спарк контекст 2 делом инициализирует сода скан, то есть инстанцирует класс сода скан запуливает в него все нужные проверки, которые вот сейчас нужно прогнать их женит сода, скан и spark сессию и запускает все.

434: Пошло работать. То есть это 1, это, это стабильно, это управляемо, ты можешь множество таких докурантов запустить, а когда мы говорим про дибити, у тебя должна быть 1 точка входа, ну или какой-то балансировщик, то есть вот этот вот qb что-то, что-то куда ты сможешь подключиться.

435: По о дибиси пио дибиси. Протоколу из из дибити и отправить запрос это менее управляемо в нашем случае оказалось, но до кьюби мы не дошли. А тебе не кажется, что вообще все практически все эти фреймворки в конце?

436: Концов умрут, потому что, по сути, они вот я говорю именно про статические проверки, где мы проверяем аккаунты или там, не знаю, проценты, или ещё че то. По сути, это самые обычные запускаторы самых простых запросов, да, и все, что от них требуется, это рендеринг и удоб.

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

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

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

440: Что демократизацию мы делаем? Но при этом код ревью проверок осуществляет лит. Дата инженеров. На мой взгляд, демократизация. Нет, нет, нет, не обязательно. Кто угодно может, может ревьювить. Главное, чтобы было 2 пра, ну, по факту, ты говоришь, дата инженер.

441: Пишут проверки и тесты на них подловил. Да, да. Но я не прошу отвечать на этот вопрос. Это мой вопрос для дискуссии дальнейшей. Ну, я обещал сказать, чего

442: Не было большой уважаемой жёлтой компании, не было Тестов на деку, огромное количество проверок, исчисляющиеся сотнями, но, к сожалению, непонятно, работают они или нет этот гэп.

443: Закрыл нам Серёжа сегодняшним докладом, за что ещё раз попрошу его поблагодарить.

444: И у нас будет очень короткий перерыв, буквально 2, 3 минуты. А мы забыли про лучший вопрос. У нас сегодня были онлайн вопросы, поэтому можем выбирать все-таки Стас, все-таки Стас, да, отлично. Стас получает приз от честного зна.

445: 9, 9 Бо короткий перерыв и сразу же начнётся последний доклад. И пристегните ремни. Там будет жарко.

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

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

448: 2 часть не очень нравится, 1 не очень, скажем так откровенно, но spark spark есть парк, да, спасибо очень предыдущим ораторам они рассказали очень.

449: Классные доклады. Спасибо Петру. Спасибо Сергею. Я бы хотел обратить внимание на доклад петра. Он рассказывал, что сделали мы спарк без шафла, то есть итель процессы.

450: Которые не генерят шафов. Коллеги, если у вас есть какой-то опыт работы со спарком, и вы знаете лучшее определение, красивое определение, смешное определение спарка предла.

451: Spark a shuffling предлагаю вам поучаствовать в конкурсе давайте, у нас есть небольшой приз на самое оригинальное определение шафла, это может быть любое определение, но оно должно быть оригинальное и не

452: Обязательно, точно.

453: Ну, давайте приступим тема моего сегодняшнего рассказа это как можно использовать в apache spark сторож партишны джоин и его производные, о чем я хочу рассказать 1 начнём.

454: С конца, что такое сторож партишн джойн рассказывать сразу не буду. Расскажу его типичные применения, где можно его использовать и почему его желательно использовать. Потом будет рассказ о партициях. То есть я

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

456: Что уже готовое и, соответственно, следующий этап. А что дальше, как он будет развиваться по мнению сообщества и расскажу некоторые примеры применения. Ну, 1, что-то это типичное применение.

457: Partition джойн это соответственно джойны для обогащения денормализации различных датасетов, мерс для обновления финальных таблиц или промежуточных таблиц, но мы именно

458: Обновляем таблицы хранения. Странное для джойна применение в групбай для агрегации, реализации бизнес логики. Почему? При том, причём здесь джоин и вдруг групбай? Ну это тоже интересный вопрос.

459: На самом деле типичное применение сторож партишен джоина это оптимизации, связанные с шаффлом и сортировками и также

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

461: Запросы и убираете Шафа при реализации.

462: Давайте рассмотрим, что такое партиции. Мы рассматриваем именно спарк. Напоминаю, в спарке существует 2 определения партиций. По моему мнению, 1 это партиции хранения в хай.

463: Нотации обычно его рассматривают, сейчас появились более другие, но будем рассматривать только hive нотацию. Что это такое? Это когда мы сохраняем данные, ну, паркет, там, орси, файлы там или любые другие, и в пути у вас.

464: Есть конструкции вида, условно говоря, имя столбца равно Такому то значению. То есть вы специальным образом задаёте хранение, чтобы у вас столбец перешёл в имя каталога, то есть для чего это используется в основном это

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

466: Каталоги, который совпадает с этим путём. То есть простейшая реализация, очень эффективная. Почему хайв, потому что она 1 появилась и популяризовалась в хайве, и она до сих пор там используется. И плюс не только хайв это используется

467: Парк используется и другие механизмы работы и фреймворки. Также есть партиции на этапе исполнения. То есть когда вы определённым образом формируете наборы данных.

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

469: Учитывается именно размер данных, которые вы запихали. Вы пытаетесь этим оптимизировать, и те набор ключей, которые туда приходят. Ну, набор ключей мы рассмотрим отдельно.

470: Формируют таски, формируются на 2 этапах. 1 это на этапе чтения данных. И когда мы читаем данные, формирование Тасков происходит с помощью специальной операции чтения данных. Это специальный

471: Элемент дата соурс вы передаёте я хочу прочитать данные и data source возвращает вам количество партиций, которое по его мнению будет обрабатываться размер он не возвращает, он возвращает количество партиций только и вот тут возникает.

472: Интересный вопрос. А как он это определяет? Текущая реализация определяется только обычно 2 способами. 1 это количество файлов. Если вы работаете с паркетом или любым коммунары форматом, это для паркета роу группы и также

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

474: Чего это не передаётся на исполнение только количество партиций и потом идут данные. Извините, следующий этап это формирование таск на Широких операциях. Тут только единственный параметр, то есть и

475: И, наверное, кто работает, ответит на вопрос есть такое интересное магическое число. Назовите его.

476: О, хорошо, правильно. По умолчанию в спарке, на Широких операциях всего лишь 200 партиций. Поэтому вы, когда работаете, вы должны изменить этот параметр и обычно его рассчитывают. Какой вы хотите размер таски иметь?

477: То есть, условно говоря, если вы хотите сказать, хочу размер таски 64 гигабайта, то вы должны сформировать партицию такого же размера, то есть нарезать все данные мапа, которые к вам приходят на определённые кусочки. Вот, то есть связи между

478: Хранение и рантаймом у вас никакой нету, то есть вы не можете сформировать количество Тасков в зависимости от количества партиций строго по файлам минима, ну

479: Это прямая связь. Есть, есть параметры, которые вам позволяют там сжать их чуть чуть, но это не очень эффективно работает, к сожалению.

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

481: Скана, сканируем 2 таблицы проджект. Выбираем столбцы. Там фильтрация будет потом у вас этап шафла. То есть вы раскладываете по ключикам у себя на экзекьютерах, потом делается джоин, потом аппенд. Ну че, что так?

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

483: Считаю, что операция шафл очень дорогая. То есть фактически вы берете. Давай, давайте посмотрим. Мы работаем действительно с большими данными. Мне нравится цифра 1 миллиард 1 миллиард записей немного. Ну, давайте 1 триллион записей. Вы берете весь триллион.

484: Записи к себе, че то с ним делаете, а потом начинаете его резать на кусочки триллион записей. Это, наверное, петабайт. Сколько вам нужно места и процессорных ресурсов, чтоб

485: Запилить из этого петабайта Шафа, наверное, много, поэтому это вы все распределяете по кластеру, ложите на локальные диски машины, а потом следующая задача. То есть шаг редьюс идёт

486: За этими кусочками данных и тащит к себе по сети. То есть вы, условно говоря, этот петабайт ещё мало того, что сохранили локально, вы ещё к себе и перетащите в основном. То есть вы на каждый экзекьютер это к себе притащит и обработает. То есть это очень такая тяжёлая

487: Рациона, ну, опасна.

488: Какая ж проблематика любое реализация распределённого выполнения в спарке требует подогнать строки с одинаковыми ключами к, ну, к этапу каждой таски.

489: Для этого есть классический метод, который я рассказал, это с помощью шафла. То есть, условно говоря, вы каждый раз, когда это делаете, то есть делаете джоины, делаете там ещё что-то, вы каждый раз делаете шафл и существуют альтернативные методы, то есть

490: Вы её предполагается в альтернативном методе делать шафл на этапе хранения. То есть вы 1 раз сделали шафл, подготовили данные, а потом его использу.

491: Если вы знаете паттерн больших данных, это в основном такой. 1 раз записали и множество раз читаете. То есть, и поэтому вам может быть выгодно 1 раз сделать шафл, положить его локально. Ну да.

492: В виде паркета и потом использовать подготовленные данные для джоинов или там ещё чего-то, чтобы не делать это 1000 раз, 1 раз сохранили, 1000 раз. Считаете вас шафла 1000 раз? Нет, только 1 ра.

493: Одни затраты ну, алгоритмы джоина классический сортер джойн и shuffle джойн.

494: Альтернативные методы шафла классический Бакетин джоин Бакет bucket джоин появился в higher сначала, затем он сейчас переехал в spark, полная реализация, эффективно.

495: То есть это как раз явная подготовка данных 1 раз записали подготовленные к джоину или ну там определённым образом, а потом 1000 раз читаете и уже не шафлить у вас в meta.

496: Данных хранится информация о столбце пакетирования и в имени файла. Обратите внимание в имени файла номер бакета. То есть мы храним в 2 местах информацию, зачем так было сделано. Странно. Ну, сделано.

497: Вот как это работает. Мы говорим пожалуйста, сделайте нам, разбейте наш датафрейм дф на 5 Бакетов по столу и сохраните происходит запись данных на диск на хдфс.

498: Условно говоря, в виде таблицы и происходит разделение на 5 файлов в каждом, в каждом файле хранятся ключи согласно остатка на от хэша столбца.

499: Ц остаток на отделения, на 5. То есть, условно говоря, мы разделили на 5 кусочков наши данные, то есть они автоматически создаются, какие нам плюсы. Это даётся. Кстати, цифру 5 я зря привёл. Это не очень хорошая цифра.

500: Как это работает, условно говоря, когда оптимизатор видит, что у вас таблицы одинаково пакетированы.

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

502: Как для того, чтобы нам сделать Джой, нам нужно свести ключи, а ключи лежат одинаково. Вы можете сделать это без шафла. Все готово. 1 раз зашалились и все. Потом можно использовать.

503: Вот, и, соответственно, вы можете включить определённую опцию, которая ещё и сортировку выключит. То есть у вас не будет сортировки и 3 версии спарка. 3, 1, 1. Я недавно это узнал. Появи.

504: Такая хитрая фича, если у вас таблицы Бакетин по номеру, количеству Бакетов с делением на 2, то есть вы делите на 2, то у вас можно использовать Бакетин вание сразу.

505: Количеством ключей. Условно говоря, вы можете включить эту опцию, она по умолчанию выключена у вас, условно говоря, делаете join с Бакетин ем 4 на 8 у вас тоже будет без шафла.

506: Вот проблемы 1 только 1 функция пакетирования другой нету и в хайве спарке они разные, самое удивительное нет партии.

507: То есть вот у вас есть Бакетин, её пользуйтесь, другого нет других вариантов, как с этим жить непонятно. И ключи обязательно должны совпадать с ключами. Бакетин. То есть у вас тоже нет вариантов, вы должны вот ключи такие сделать, и все у вас

508: Должны быть только эти ключи. Я тут написал. Количество бакетс должно совпадать, но это неправда. Оно должно совпадать определённым образом. И очень такая тонкий нюанс. У вас ограниченная поддержка пере.

509: Условно говоря, у вас при пакетировании в 1 файле может получиться 10 записей, AVDRUGOM1000000. И, соответственно, вот этот перекос вы исправить уже не сможете никогда. У вас нет механизма без пересохранения исправить этот перекос.

510: А если вы исправляете функция пакетирования у вас не меняется, вам нужно че то подмешивать, подсолить. То есть у вас целая такая эпопея, вы ничего с этим сделать не сможете, но проблема

511: Есть такая штучка сторож партишн джон Джой недавно появилась.

512: Это новый тип джоина, который появился в apache spark 3 3.

513: Он позволяет отобразить наши партиции хранения на файловой системы, на партиции выполнения. То есть мы можем на этапе разработки таблицы задать, как у нас будет

514: Формироваться таски, размер Тасков, количество Тасков. А так как это партиции, то есть это у нас не 1 место хранения информации, которую мы Режем, а множество мест, мы можем сделать глубину, условно говоря, 5, 5 партиций и потом

515: Ну, глубину вложения 5 или 10. И, соответственно, вы потом можете определённым образом этим управлять. Это более гибкая штучка.

516: Данная. Данный метод джойна снижает количество данных в стадии шафла. Он фактически их убирает. То есть классическая реализация. Сторож партишн джойн позволяет полностью отказаться от шафла, то есть при джойне у вас Шаф.

517: Не будет вообще. То есть от сортировок он отказаться не позволяет, но от шафла полностью при джоне нету полностью при, а при джоне нету шафла вот никакого.

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

519: На такой оптимизации под названием k группе партишн он с помощью этой операции дата соурс управляет сбором партиций, который передаётся на исполнение, и вы можете

520: Сказать как у вас датасорс будет отдавать вам данные, появилась физическая реализация датасурс версии 2 k exec base поддерживается только в пакетном чтении, то есть нельзя построчно.

521: Чтение его использовать, он там невозможен, используется только в spark sql коннекторах, и тут интересная такая штучка, я просто её расскажу вот k группе партишенинг работает очень просто у вас в каждой партии.

522: Лежат набор файлов, допустим, 10 файлов. Вы говорите, сделай мне, пожалуйста, вот по такой-то партиции группировку, и у вас он в Таску отдаст не 10 файлов, а все 10 файлов. 1 ба.

523: То есть он возьмёт эти 10 файлов и отдаст как партицию на исполнение. Наверх будет 100 файлов, он отдаст 100 файлов, и этот нюанс есть, но он решаем.

524: Вот, ну давайте рассмотрим, что у нас есть в сторож партишн джонни. Сейчас будет несколько слайдов по схеме джира спарковских и как это работает. 1.

525: Функции партицирования, так называемые функции функции партишн, трансформа это функции, которые так называемые так имплисит партишн, то есть невидимые партиции, то есть, условно говоря,

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

527: Условия. Возьми вот этот синтетический столбец, условно говоря, какой день недели, это и используй. Тут такого не надо. Вы говорите, пожалуйста, возьми столбец, на основе которого сделана эта невидимая партиция, допустим,

528: Day день, да, то есть дей от даты, и он сам уже определит, что это функция трансформации и, соответственно, будет подставлять именно искать партицию согласно этой функции. То есть вам не, ну

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

530: Хай хэш классический, есть айдентити, это значение столбца просто. То есть, условно говоря, значение есть айсберг, Бакет это айсберговата. Ну год, месяц, день, час, то есть вы можете из любой

531: Даты там сказать, сделай мне партицию год от даты. То есть у вас появится просто год. Это вот это уже есть, это работает. Это ключевая особенность. Кей, группе партишн.

532: Базовая реализация. Рассмотрим её таким образом. У нас есть 2 партиции. Т. 1. Ой, 2 таблицы, т. 1 и т. 2. И она партицирования по дню от даты. И вы хоти

533: Сделать.

534: Джой, как это работает? У меня есть опция определённые. Я включаю Бакетин, и я включаю для айсберга пресерв дата группин, чтобы он передавал сохранение групп, и все у вас работает. Как это происходит? Чита.

535: Определение партиций группируем, каждый партиции друг с другом выравниваем и делаем join. Все. И в этот момент у нас шафла не будет, потому что у нас все данные находятся в этих партициях. То есть, условно говоря, наш

536: Join по дате, по дате ото дня сделан ой, по дню от даты сделан без шафла, то есть я тут не показываю план выполнения, мы дальше это будем смотреть, это вот уже реализовано, это базовая реализация, она работает.

537: Также давайте рассмотрим такой вариант. У вас есть огромная террабайтная партиция, ой, террабайтная таблица, которая партицирование по дню от даты, и вы хотите её обновить выде.

538: Ну или join хотите сделать, ну или обновить. И, соответственно, у вас есть маленький кусочек данных, который содержится всего лишь 2, 1 табли, 1 партиция, которая есть в большой таблице, и 2, которых нету. То есть, вот, условно говоря, у вас показано

539: С левой стороны есть в большой таблице 0 8 16 0 7 17, а в малой таблице 0 0 7 17 0 6 19. Как такое можно сджойнить? Да никак. На самом деле, то да, если у нас партиции нету, то мы упадём, потому что

540: Нечем там стягиваться, но есть специальная опция, которая восстанавливает такую, такую проблему. Мы находим пропущенные партиции, видим, что у нас 2 партиции пропущены как с правой стороны, так с левой, то есть и создаём пустые партиции. И потом

541: Потом уже берём и склеиваем. То есть мы создали 2 партиции и склеили их. У нас все хорошо, все работает.

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

543: Будет одуренный перекос. Нам нужно огромное количество ресурсов, что сделает спарк? Он читает оригинальные партиции, клонирует малую сторону. То есть у нас из малой стороны получилось

544: Больше данных и разрезаем в большую сторону на такое же количество кусочков.

545: И выравниваем, и склеиваем. То есть у нас получилось из 1 таски, которая потенциально была, получилось 3 таски конечно, тут будет shuffle, потому что мы, ну, понимаем, что нужно все равно сжать, это дело будет shuffle, но он будет не такой большой, потому что все остально.

546: Будет хорошо, то есть остальные партийцы будут без Шахлова работать. Давайте посмотрим, что планирует сообщество развивать дальше. 1, это на что я хотел бы обратить внимание. Там, конечно, ещё есть

547: Фишки. Ну, я их просто самые важные вытащил. Работа с недостающими партициями. Условно говоря, у вас есть 2 таблицы, 1 партицирование и дню, a2 партицирования только по Бакет айти, то есть у вас

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

549: Мы сжимаем партиц, мы видим, какое у нас одинаковое партицирование, и делаем просто

550: Одинаковое партицирование и соответственно, потом делаем join все. То есть, конечно же, это не совсем такая вроде бы Нужная вещь, кажется, но это работает. Это я даже применял действительно интересно.

551: Штука в 4 спарке появилась.

552: Выравнивание количества Бакетов это вот как раз когда у нас разное количество Бакетов, то есть когда мы 1 таблица сделана с 4 бакетами в примере, a1 с шестью, как это работает, мы берём

553: Ищем общую функцию трансформации. Тут мы поделили на 2 перепорти, ируем. То есть у нас получается 2, 2 партиции и джойним все прекрасно, все хорошо.

554: И также есть такая интересная штука. Автоматическое партицирование 1 стороны. То есть у вас 1 таблица партицирования, а другая нет. Поэтому спарк при включении опции специальной сделает вот таким образом, он просто

555: 2 таблицу вам нарежет, конечно, будет shuffle, но 1 шафла у вас не будет, и джонет примеры применения?

556: Ну, у нас будет, есть 2 таблицы, которые одинаково партицирование по 4 бакета. И есть опция, которая позволяет включить Бакетин. Как это работает. Давайте попробуем замержиться.

557: То есть берём 2 таблички, мержим, стягиваем. По id, если такой строки не найдено, добавляем её полностью, если найдено, то обновляем план выполнения без без сторож партишн джойна шафл.

558: То есть, видно, шафл появился все хорошо, все прекрасно, как ожидаемо видим, что у нас чтение все отлично, все прекрасно, классическое чтение, ничего сверхъестественного нету, как мы хотели.

559: Как сделать без шафла? Включаем опцию, видим, что shuffle исчез, как это работает в чтении появился специальный специальная операцию, которую мы даём команду дата ридеру сделай нам, сгруппируй нам.

560: Пожалуйста, по id bucket и возвращаться будет уже данные не по.

561: Файлово, а по партициям, то есть, условно говоря, мы берём все наши 10 файлов из 1 партиции, собираем в 1 кусок данных и отправляем в бач все. То есть вот эта вся разница фактически все за нас делает оптимизатор и

562: Ридер, как сделать селект с джойном тоже самое абсолютно выключаем видим шафл, также видим что group by нету.

563: Не опустилось пустое как сделать без шафла включаем Бакетин ну, версия 2 пакетирования видим опять появился в группе by id bucket все прекрасно.

564: И, соответственно,

565: Это без шафла работает, но сортировка, как вы видите, осталась. От этого никуда не деться. К сожалению, хотелось бы как бы как в пакетировании, но нет.

566: А теперь такая интересная штучка. Агрегирование, опять же, причём тут join Бакетов, агрегирование делаем агрегацию простейшую. Мы посчитаем количество дубликатов, берём дст табличку, делаем Груба.

567: Значение, то есть не по ключу я по значению сделал, специально расскажу потом и отсекаем. Если account больше единицы, отлично видим. Классно тоже грубое нету. То есть что у нас происходит у нас по началу

568: Происходит частичное агрегирование. То есть смотрите, какая интересная штука лежит у вас 10 файлов. Вы делаете апен каждая, каждая запись, каждый файл содержит 10 записей и 10 файлов с десятью записями. То есть всего 100 записей, они одинаковые, абсолютно одинаковые.

569: Запись вы делаете каждый файл читаете, делаете пред агрегацию каждого файла, но там внутри файла, то записи то разные все. Но если смотреть, то в файлах они одинаковые и вы на следующий этап

570: Возвращайте все 100 записей, хэш агрегат, который конечный выдаст, выпрели вам все 100 записей, и только здесь схлопнет результат. То есть и вернёт всего лишь, условно говоря, там 10 записей, то есть

571: Но пред агрегат будет работать со 100 записью в 10 раз больше.

572: Как это победить? Мы берём и добавляем вот такую интересную штуку грубай айди 0. Если вы помните по айдишнику у нас была, была сделана, было сделано партицирование и вот тут возникает интересная ситуация. Мы видим

573: Что у нас файлы начинают на чтение группироваться по id, и уже на пред агрегате мы схлопнем эти 100 записей до 10.

574: Схлопнем до 10, то есть шафл уменьшается в 10 раз и выдаём данные наверх.