ClickHouse. Из разработки внутри Яндекса в самостоятельную компанию

Либо-либо. Всем привет! Меня зовут Самат Галимов, и это подкаст «Запуск завтра». Как технический директор я пытаюсь разобраться, как устроены сложные и интересные штуки. Я зову профессионалов, с которыми можно поговорить простым человеческим языком. Дорогие друзья, если вам нравится наш подкаст, пожалуйста, поставьте ему оценку там, где вы его слушаете. Для нас это очень важно, потому что это помогает новым людям узнать о подкасте. Любая компания с большим количеством пользователей рано или поздно сталкивается с задачей хранения огромных массивов данных. Речь обычно идет о том, чтобы записать все телодвижения пользователя, все его клики. И раньше каждая компания, которая с такой задачей сталкивалась, придумывала свое собственное решение, такое домашнее, какой-то набор костылей, который помогает передвигаться. Несколько лет назад в компании Яндекс сделали подходящую базу данных для подобных задач. Она называется Кликхаус, и вначале это был проект внутри Яндекса, которым пользовалась Яндекс.Метрика, а потом как-то внезапно она завоевала практически весь мир больших данных. Ей пользуются крупнейшие компании на планете— Microsoft, Disney, Cloudflare, Uber— сложно найти компании, внутри которых нет Кликхауса. Как так получилось, как маленький экспериментальный проект одного человека в Яндексе стал самостоятельной компанией с серьезными инвесторами и большой оценкой? Чем эта база данных отличается от других? Обо всем этом вы сейчас услышите от создателя этой системы Алексея Миловидова. Это подкаст студии Либо-Либо, а сделали мы его совместно с сервисом онлайн-образования Яндекс Практикум. У Практикума есть курсы не только для начинающих, но и для опытных разработчиков. Хорошим разработчиком можно быть и в маленьких компаниях, и в больших корпорациях, но требуемые технологии и скиллсет там немножко разный. Как это бывает и чем здесь могут помочь курсы, сейчас расскажет ментор с курсом Middle Python разработчик Роман Володин. Иногда бывает такая ситуация, что бэкенд-разработчик, даже если он с большим опытом и хорошо пишущий код, работает в небольших компаниях, либо в маленьких командах, либо же он работал до этого с невысоко нагруженными проектами и не пользовался в своей жизни рядом технологий разработки. Например, Кликхаус или другие колоночные базы данных. Далеко не каждый разработчик использовал в своей жизни. Она нужна только для огромных объемов данных поступающих и для дальнейшей обработки аналитиками. Или, например, другая технология Apache Kafka, которую часто используют несколько неправильно. Ну, по крайней мере, не на все 100%. И вот, на нашем курсе у разработчиков есть возможность попробовать руками все эти технологии. И если у бэкенд-разработчиков в планах на жизнь есть такой пункт, как участие в разработке либо работа в большой компании, то знакомство с этими технологиями будет огромным плюсом и поможет ему в дальнейшем. Курсы помогают заглянуть за ширму, как это бывает в больших компаниях. Если после этого вы захотите устроиться в большую компанию, то, скорее всего, вам придется пройти алгоритмическое собеседование. Яндекс.Практикум здесь тоже может помочь. Ссылка на бесплатный курс по подготовке к алгоритмическим собеседованиям в описании к этому эпизоду.

Привет, меня зовут Алексей Миловидов, я разработчик Кликхауса, и еще я работаю в компании, которая так и называется, Кликхаус, техническим директором.

Когда и где появился Кликхаус? Можешь рассказать историю?

Я работал в Яндексе, пришел туда в 2008 году, попал в совершенно новый сервис, он назывался Convertometer. Но это внутреннее название такое было, он еще не был запущен. И его цель была считать конверсии рекламы в Директе с помощью счетчиков на сайте. Запустили этот сервис в апреле 2008 года и решили назвать его по-другому – Метрика.

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

Да, но это изначальное предназначение для Метрики. Но на самом деле этот сервис гораздо больше. Он только начинался с того, чтобы оценивать конверсии рекламы. Сейчас это один из лучших с точки зрения юзабилити сервисов для веб-аналитики. Там есть и Session Replay, то есть смотреть, как именно люди пытались воспользоваться вашим сайтом, как они пытались найти эту кнопку-корзина, где что-то там купить надо, как они в самый последний момент передумали, вот все это можно увидеть. Идея у этого сервиса была такая, ставишь счетчик джаваскриптовый или просто картинку, и, во-первых, если ты рекламодатель, тебе скажут, что с твоими объявлениями происходило, сколько кликали, и интереснее, что потом на сайте происходило. На сайте можно было события определенные создать под названием цель, и из этого считалось просто conversion rate, ну и естественно там и click-through rate и все остальное.

То есть сколько людей попало на сайт, сколько что-то сделало и сколько потом в результате купило или там сделало какое-то другое целевое действие?

Да. А во-вторых, те же самые данные для рекламных площадок. Это называется, или до сих пор называется, или раньше называлось РСЯ, рекламная сеть Яндекса. Там тебе говорят, как на этой площадке лучше зарабатывать.

Дай мне, пожалуйста, масштаб. Сколько там данных примерно хранилось?

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

Так, в нем 100% с самого запуска уже была какая-то база данных. Какая?

MySQL. MySQL использовался везде, поэтому в Яндексе тоже.

Ага, это open-source проект, который можно бесплатно установить себе, пользоваться, им очень хорошо, умеют пользоваться в Яндексе, я знаю там вас тысячи этих серверов. Скажи, с какими задачами столкнулась Метрика такими, что MySQL вас не устроил?

Когда данных действительно много, то возникает проблема, что, во-первых, MySQL— это нераспределенная база данных. Если объем данных превышает, то с чем может справиться один сервер? Придется использовать шардинг. Что такое шардинг? Шардинг, если с английского перевести, это значит «осколки». И это значит, что данные просто разбивают на независимые, почти независимые части, и получается такой шардированный MySQL, и там, например, 100 серверов, каждый из которых какой-то кусочек обрабатывает. Но все это очень неудобно. Вторая проблема возникает в том, что разные системы специализированы под разные типы нагрузки. И MySQL это система, которая изначально не совсем для этого. И в 2006 году, чуть позже, там была создана еще система под названием MapReduce, на основе известной статьи от Google и появилась примерно в то же время, как Hadoop. И суть этой системы в том, что первое, данные хранятся распределенно, есть куча серверов, и на эти серверы можно отправить коды обработки этих данных. И этот код тихонечко так возьмет и по всем этим данным пройдется и что-то вычислит. И все. И если сравнивать это с реляционными базами данных, то получается полная противоположность. Нельзя отправить SQL-запрос, и чтобы через 10 миллисекунд получить ответ. Потому что он должен пойти и там 100 серверов, ну или в случае больших компаний там и тысячи, и десятки тысяч, и чтобы он там взял эти данные, просканировал. Это не выйдет. Но с помощью таких систем можно взять, например, логи из интернета и на основе этих логов сконструировать добавку для поискового индекса, которая позволит понять, на какие сайты пользователь с большей вероятностью перейдет в поисковую выдачу. Как-то так. А что интересно, это если брать Яндекс.Метрику, то до нее ни те системы не подходят, ни эти. И то, и другое плохо. Одновременно и большой объём данных, но и отвечать надо тоже на них быстро. И сейчас я расскажу, за счёт чего это, в принципе, возможно. Первое. Всё-таки есть возможность делать данные структурированными. Если брать посещаемость сайтов, то её можно рассмотреть как одну большую таблицу, которая и одновременно в ней много строк, десятки триллионов в целом. Я когда считал, не прямо сейчас, а давно, там было 200 триллионов где-то. И одновременно большое количество столбцов, атрибутов. Это даты и время, адрес страницы, куда перешел пользователь, регион, который мы вычислили. И все остальное, что только можно вычислить, и где-то несколько сотен, ну точнее больше 500, но меньше 1000 таких столбцов. И это позволяет хранить данные более эффективно. Но это не только это. Второе— это то, что все-таки запросы, которые идут, они не обязаны обрабатывать эти сотни триллионов данных. Они могут использовать индексы. Но при этом индексы не такие, как в традиционных базах данных. Сейчас я расскажу, что такое индекс. Обычно это просто какое-нибудь дерево, у которого в листах расположены данные о смещениях на дисках, откуда надо прочитать данные. Мы идем по этому индексу, и, например, в нашем диапазоне надо прочитать миллион строк. И вот мы получили миллион смещений и должны теперь сделать с диска миллион чтений. Но это тоже медленно. Вот этот миллион смещений, которые мы хотим прочитать, он должен быть расположен так, что идем и подряд все читаем, и у нас далеко не миллион чтений, а всего несколько. А во-вторых, чтобы эти данные еще и хорошо сжимались. Ну а, наверное, одно из таких очевиднейших общих мест в этих базовых данных— это то, что они хранят данные по столбцам. Я всегда говорю, что Clickhouse – это столбцовая база данных. Это значит, если мы из нескольких сотен столбцов хотим сделать отчет по регионам и график построить. Такая-то сторона, вот так вот она менялась. И для этого мы должны прочитать регион, дату с временем, возможно, без времени только дату. И, например, мы еще хотим посчитать не просто количество, но, например, там есть еще столбец, является ли этот клик пользовательским или роботным. Это столбец 1 бит, но мы его тоже должны прочитать. А еще, например, мы хотим узнать, сколько было пользователей. Один пользователь может дважды зайти на сайт и посчитать, надо один раз. Для этого там будет, например, 64 бита, идентификатор пользователя, и его надо сегрегировать.

То есть тебе не нужно читать все лишние столбцы, ты читаешь только ровно то, что тебе нужно.

Да. Три вещи давайте сформулируем. Первое. Читаю только нужные столбцы. Второе. Читаю диапазоны данных. Этот диапазон расположен локально на дисках. Это пункт 2. И третье. За счет первых двух пунктов эти данные еще и хорошо сжимаются.

Ну вот как-то так. Леш, скажи, пожалуйста, вот с такой проблемой столкнулись только в Яндексе или это вообще частый паттерн в больших IT-проектах?

Это очень частый паттерн, и Кликхаус выложили в Open Source в 2016. Мы, кстати, еще об этом поговорим, как и почему. Но каждый раз на крупной конференции типа HighLoad или RIT на них каждый раз был доклад, как в какой-то компании сделали абсолютно то же самое.

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

Почти решила. Проблема в том, что это сложно, и там много деталей. Сделать прямо ground-up архитектуру, чтобы вообще все хорошо работало. И сделать это на основе MySQL или Postgres. У каждой из них кодовая база, несколько миллионов строк. Это очень сложная задача, получается не очень хорошо. Для Postgres есть Greenplum. Это форк Postgres, который как раз аналитическая column-oriented, то есть столбцовая база данных, почти как ClickHouse. Есть то, что называется MariaDB ColumnStore, но не надо путать с MariaDB, это отдельный плагин к ним. Изначально InfiniDB называлось. И еще несколько штук есть, они тоже периодически появляются, исчезают. Это просто огромный объем работы. Это трудно представить, но с чем бы сравнить. Ну представьте, например, вам надо электростанцию построить, какую-нибудь большую. Ну это можно сделать? Ну просто очень Много работы.

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

Ну да, и при этом все время надо следить за существующими пользователями, сценариями, за обратной совместимостью, апгрейдами и огромной пользовательской базой.

Скажи, пожалуйста, когда ты понял, все, нужно садиться и писать свое, а расскажи, как это вообще случилось?

Это такая идея, которая кажется изначально трудно реализовывать, потому что ты думаешь, вот вроде бы это сделать можно, но сколько усилий на это потребуется, непонятно. Вроде бы системы похожие существуют. Про столбцовые базы данных я где-то прочитал. Основные представители, которые были известны, это Sybase IQ и Vertica. Все эти штуки начинаются с некоторых прототипов. И одна из таких идей— это сделать конструктор отчетов. Изначально в метрике, когда мы ее запустили, там почти ничего не было. Там тебе говорили, нажимай сюда— вот тебе отчет по регионам. Нажимай сюда— вот тебе конверсия по браузерам. Вот версии браузеров, вот тебе Internet Explorer 6. Люди говорят, давайте, чтобы я выбрал такой регион, а потом выбрал браузер, а в этом браузере сделайте мне разбивку пользователей, которые конвертировались, которые не конвертировались. Как же это делать, если мы все эти данные агрегируем в эти маленькие отчетики и засовываем в MySQL? В MySQL просто нет уже этих данных, они исчезли, сагрегировались. И единственное решение— это хранить неагрегированные данные.

Сырые прямо.

Да.

Можешь сформулировать, как звучала задача, которую ты сам себе поставил?

Сначала просто сделать конструктор отчетов этот прототип. Там написана была одна простая структура данных на C++, которая в сжатых файлах. хранил столбцы и в нужном порядке рядышком индексы, и там переупорядочил их. И запустили это уже в январе 2009-го. Работал конструктор отчетов в Метрике. А потом я думаю, а если чуть-чуть продолжить это делать? Ну, я эту идею отбрасывал, потому что она слишком сложная. И сначала там пробовал что-то написать, чтобы прикрутить туда SQL-запросы, а изначально у меня там просто надо было эти запросы писать как конфигурационные файлы XML-ники, фиксированные структуры. Вот, я думаю, прикручу туда, чтобы можно было разные таблицы создавать с разной структурой, а то там была просто одна таблица фиксирована в коде.

И запрос их не в виде XML конфигурации.

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

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

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

Файловая система не выдерживает, скорее всего.

Да, не выдерживает. Ну, мне человек из другой комнаты сказал, что давай попробуем XFS. Мы попробовали XFS, и все заработало. А потом что-то начало тормозить, и пришлось переделать быстренько.

Ага. На каких данных ты тренировался? Ты сразу туда посылал поток живых пользовательских данных из метрики, или как это работает?

Есть поток живых пользовательских данных. Для обработки он сначала попадал в MySQL, в кусочки данных по одной минуте или пять минут. И можно было произвольно набор этих кусочков данных взять, плюс еще они разбиты на шарды. Скажем, берешь один шард, берешь данные там за час и проверяешь свою систему.

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

Да, а если не завалилось, то пишешь скрипт, который берет и постоянно туда отправляет данные. И если оно через день еще не развалилось, то будет шанс развалиться через неделю.

Классическая ситуация. Ты программировал все один на этом этапе или сразу уже кого-то подключил?

Там была маленькая команда, сначала два человека, а потом, когда это случайно превратилось в кликхаус, тогда еще немножечко людей подключил. Ну там частично, потому что есть такие задачи, которые постоянно возникают. Например, добавить в ещё один столбец с какой-то характеристикой пользователя. То, что мы называем «прокинуть столбцы»— это тупейшая задача, но её тоже приходится делать. Или там помочь саппорту с метрикой. И на такие задачи уходит больше половины времени. Но когда есть небольшая команда, там 2-3 человека, удаётся немножечко привлечь других людей тоже, чтобы было интересно.

Ты сказал, я сел и напробовал прототип. Сколько времени ушло на то, чтобы сделать такую штуку, чтобы люди заметили и поняли, что в это стоит дальше вкладываться?

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

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

На разных этапах разные люди, и некоторых совершенно не приходилось уговаривать, некоторых чуть больше. Вот, например, один из руководителей Метрики на том этапе, как раз в 2012, это был Артур Суилин. Он к нам пришел из другого стартапа под названием WebVisor. Как раз тоже участвовал в том, когда они к нам присоединились. Сначала просто эту команду присоединили, потом Артур стал менеджером Метрики. Но он такой человек технический, и я ему показал эту штуку, он сразу понял, что да, надо делать так. Более того, мы с ним придумали полностью новую версию сервиса, метрика 2.0, и запустили ее в 2014 году. В ней ключевой основой, сердцем системы, был как раз Clickhouse.

А в какой вообще момент появилось название, кстати?

Я сам плохо помню, но я придумывал разные названия, и потом как-то придумал это. Оно значит Clickstream и Data Warehouse. Clickstream— это общее название для такого типа данных, которые возникают в веб-аналитике, в рекламных системах. Короче, клики просто.

Взаимодействие с пользователем, типа, что он делает.

Да.

Окей. А warehouse, data warehouse— это место, где, типа, все данные хранятся, да? Это правильно?

Угу. Иногда, кстати, такое противопоставление идёт— база данных и хранилище данных. База данных— это database, а хранилище— data warehouse. Обычно используют понятие data warehouse, когда что-то большое, сложное, неудобное, но зато работает на большом объёме данных. А база данных— Маленькая, удобная, всё делает быстро. И с моей точки зрения это противопоставление совершенно лишнее, потому что ClickHouse это база данных, но одновременно которая заменит любой Data Warehouse.

Дорогие друзья, у студии либо-либо есть платная подписка. С ней вы получите доступ к дополнительным выпускам разных подкастов, например, «Закат империи», «Запуска завтра», «Зависимости», «Новой волны», а скоро еще и к другим. Подписаться можно в приложении Apple подкасты или в Телеграме. А еще только для наших подписчиков мы выпускаем подкаст «Студия». В нем мы рассказываем, как мы живем и работаем. Подписка – это самый простой способ нас поддержать. Все ссылки в описании выпуска. Спасибо, что слушаете. Окей, я могу себе представить, что ты напробовал систему, ты ее хорошо знаешь, ты ее эксплуатируешь. Расскажи, когда у Clickhouse или вот у твоей программы для хранения данных, еще тогда без названия, появились первые внешние пользователи, первые пользователи, кроме тебя самого. Как это было?

Сначала они появились внутри компании, сделали эту систему, решили использовать ее для метрики 2.0, сконвертировали предыдущие данные из конструктора отчетов, сделали, чтобы она работала в продакшене для временных данных, как раз для кусочков трафика, который раньше был в MySQL. сделали, чтобы туда шли запросы, и одновременно с этим пришлось написать документацию для этой системы. Я подошёл несколько творчески к этому процессу, сделал сайт внутренний с документацией, сделал, чтобы всё красивенько было, чтобы прям можно было начать читать, и от начала до конца читаешь. Кстати, если что, оригинальная версия этой документации до сих пор есть, я могу ссылочку прислать.

Прикольно. Положим её в описании к этому эпизоду.

И что интересно, похожие задачи были в других отделах Яндекса. Например, есть отдел статистики самого Яндекса. Там эта статистика считается далеко не только по трафику, который на все сервисы Яндекса приходит, но и по внутренним событиям. Даже есть анонимизированные обобщенные данные браузера. То есть можно считать данные и по метрике, и по браузеру. И есть, например, третьи данные— это поисковые логи. И вот все это считалось в другом отделе, который назывался «Портальная статистика». У них, в отличие от метрики, два недостатка было. Первое— данные обновлялись раз в день почти всегда, а иногда не обновлялись. Второе— эти данные нельзя было крутить, как хочется. Нельзя было смотреть внутрь просто какие-то такие странные отчеты.

Опять не было конструктора отчетов.

Да, у них не было конструктора отчётов. А ещё там был отдел, который разрабатывал эту портальную статистику, а был ещё отдел аналитиков поиска. Есть аналитики поиска, есть аналитики маркета и тому подобное. И задача аналитиков— решать, отвечать на вопросы и исследовать данные для оптимизации или для анализа бизнеса, готовить отчёты, по которым всё прогнозируется, решать эти задачи любым доступным методом. У них задача такая— вот, пожалуйста, данные, Они хранятся там, там и там. Хочешь, иди, сделай себе виртуальную машину, поставь туда скрипт, хоть на перле, хоть на питоне, без разницы. Какого качества это будет скрипт, твое дело. Хочешь, используй MapReduce. Хочешь, возьми там Spark себе поставь. Никто тебе против этого ничего не скажет. Если хочешь, возьми MySQL. Естественно, все эти аналитики сразу пришли в Кликхаус, потому что для них это как чудо. Там у тебя данные лежат мертвые, с ними ничего сделать нельзя. А здесь в реальном времени все данные из интернета, их можно вертеть как угодно. И еще одна из таких вещей – это то, что аналитикам был предоставлен ограниченный доступ с квотами и с ограничениями по тем полям, которые они могут читать, ну, чтобы там не было приватных данных, но к глобальным данным из интернета, собираемым метрикой. И это просто вообще охренеть. То есть ты пишешь SQL-запрос, и он обрабатывает данные всего интернета, и как правило быстро.

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

Да, вообще всего.

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

В 2016 году, где-то в июне, я не помню точную дату, и мы это стали обсуждать где-то в начале 2016. Там довольно интересно. Сначала у меня была команда разработки метрики, потом запустили метрику 2.0. Команда чуть выросла, там человек было 5 или 7, и решили просто сделать вторую команду. И чтобы была специализация, у меня получилась команда разработки именно Кликхауса. несколько людей, тоже где-то там 4 человека или типа того, которые делали исключительно Кликхаус. Потом Кликхаусом стали пользоваться в других сервисах Яндекса, не только Метрик, а аналитики и аналитики разных отделов. И потом, например, баннерную систему AdFox, и эту байерную систему интегрировали в Яндекс, и там тоже стали использовать Кликхаус, потому что пришел человек и понял, что у нас, оказывается, написано то, что они почти написали, но не до конца. Потом большая баннерная система тоже стала использовать ClickHouse для части задач, потом и для аналитики поиска. И в Яндексе еще была реорганизация, что сделали отдел инфраструктуры. Там был руководителем этого департамента, что ли, Алексей Башкеев. И я ему говорю, что есть такой вариант, чтобы сделать это open source. И там куча мотивации, почему это, в принципе, могло быть полезно, какие могут быть риски. А почему такая идея возникла, делать это в опенсорс, как раз потому, что наблюдал за тем, что эта технология является востребованной. Она действительно решает задачу, которая пока либо не решена вообще снаружи, либо решена недостаточно хорошо. А значит, для нее есть ниша. А значит, есть шанс сделать в опенсорсе что-то, получить для компании преимущество. Вот стали это обсуждать, вроде я его частично убедил, составил список, какие могут быть преимущества, какие риски.

Можешь какие-то топ-один хотя бы плюсов и самый большой риск, который ты в этом видел?

Плюсы. Там их довольно много. Если технология внутри компании становится open source технологией, то больше людей внутри компании заинтересовано в том, чтобы ее использовать. Странная довольно мотивация, казалось бы, неочевидная. Люди думают, ой, такие хорошие технологии у нас. Вот вы там написали технологию под названием звездолёт, а другая технология называется самогон. А когда люди ими пользуются, они думают, ой, а как же я тогда потом перейду в Google? Поэтому люди заинтересованы, конечно, в том, чтобы использовать, я не знаю, Spark.

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

Да.

А какие минусы, какие риски?

Риски, есть немножко такие даже надуманные риски. Это открытый код может быть использован для нахождения уязвимостей и их эксплуатации конкурентами, ну и не только конкурентами. Этот риск несколько надуманный, потому что, во-первых, если говорить про исследование безопасности, то там гораздо больше того, что лежит на поверхности на уровне всевозможных API. Ну, неправильно сделали там тривиальные вещи и легко найти там какую-нибудь там SSRF, Server Side Request Forgery или что-нибудь еще. И, как правило, это далеко не связано с тем, чтобы идти и смотреть, читать код. Читать код— это сложно. Да, а гораздо проще, когда вот забыли просто ограничить доступ к PHP скрипту, который идет во внутренний API, который не должен быть наружу. Вот, это тривиально, это обычно все постоянно находится. Но на самом деле этот недостаток, то, что в принципе могут найти уязвимости, там всякие баги, это преимущество, а не недостаток. Это значит то, что в любом случае качество будет лучше. Вот, пришли к техническому директору, он говорит, да, Давайте попробуем. Потом составил план, какие надо материалы подготовить, документацию, сайтик выложить, анонс сделать, репозиторий подготовить. Постепенно все это сделали за полгода, даже меньше, чем за полгода, и все готово.

Какая была реакция снаружи?

Очень интересно. Это выяснилось уже ближе к осени на HighLoad. И там действительно много людей, которые говорят, у нас рекламная сеть, а у нас маленькая биржа для рекламодателей, а у нас e-commerce большой. «Можем ли мы использовать Кликхаус?» И я им говорю «Можно, да, все будет работать, все хорошо, используйте». И они уже спрашивают более существенные вопросы «Как мне посчитать когорты в Кликхаусе?» Я говорю «Пожалуйста, сапклери и на селект». И тут стало понятно, да, действительно классная вещь.

То есть это уже был довольно такой зрелый продукт в тот момент, когда ты его заопенсорсил?

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

Данные не теряются, быстро обрабатываются, и можно, типа, разный отчет устроить в real-time.

Угу.

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

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

Был какой-то момент, когда ты такой, нифига себе, и они начали пользоваться? Кто это был?

Например, в 2017 году мы решили сделать первый митап за рубежом в Берлине. И тогда я думал, как привлечь аудиторию. Но это не так просто, когда только запускаешь такой продукт, пытаешься собирать все по крупицам. И у нас сразу во время запуска там был один из пунктов сделать рассылку, на которую кто угодно может задать вопрос, написать про кликхаус. И там пишет, например, какой-то человек. Вот я из института такого-то использую кликхаус для анализа геномов человека. Они секвенируют эти геномы, а потом анализируют. И я этому человеку пишу просто напрямую, что интересное применение, давай можно будет рассказать на нашем метапе. Если хочешь, короткий доклад, 5-10 минут, не проблема. И так удается собрать там где-нибудь человек 5, докладчиков. Приходишь, там 100 человек сидит, слушает, и еще 5 человек рассказывают про то, как ClickHouse использовать. И самый скучный из всех докладов мой.

Класс. Очень прикольно. А как вообще западные компании узнали о Кликхаусе?

Очень многие узнали через тех сотрудников, которые русскоязычные, которые пришли из компаний, которые раньше использовали Кликхаус. Это один из каналов распространения, очень важный. Я постоянно вижу этот канал распространения для других компаний, для китайских, индийских компаний, о которых, в принципе, на Западе никто и не слышал. Они проникают постепенно вместе с людьми, вместе с сотрудниками. А другой канал распространения— это люди, которые просто интересуются и иногда совершенно случайно пробуют какие-то странные вещи. И да, кликхаус— это действительно странная вещь, но для многих людей нужно пробовать буквально всё, что потенциально может работать, потому что часто бывает, что технологии используют от безысходности.

Ты имеешь в виду, что если у тебя нет другого выхода, то ты возьмешь самый странный код из интернета и хоть как-нибудь что-нибудь сделаешь?

Да, наверное, так можно сказать. Действительно, очень много ситуаций, когда ClickHouse— это первое решение, которое просто работает.

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

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

Скажи, пожалуйста, сейчас у Кликхауса есть конкуренты какие-то серьезные?

Полно. Причем многие из этих конкурентов— это, по сути, такие клоны Кликхауса. Младшие братья или типа того. Есть даже целая ниша под названием «китайский кликхаус», потому что кликхаус очень популярен в Китае.

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

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

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

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

Они вот только себе доделывают? Или они иногда и делятся потом с тобой этими исходными кодами, пытаются как-то это передать в мир?

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

Чтобы потом сами не поддерживать.

Конечно. Потому что upstream двигается вперёд очень быстро. И если сейчас используешь, например, версию ClickHouse на два года назад, то будешь удивлен, как два года назад все было плохо.

Скажи, пожалуйста, а сколько вообще у вас людей в компании? Сколько людей работают над крейгхаусом сейчас?

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

из четырёх отделов, это сильно отличается от чувака, который написал C++ программку с одной структурой данных, зато очень качественной. Можешь ее как-то сравнить? Мы с тобой обсуждали в начале сам, что современная система управления базовыми данными типа Postgres или MySQL, это там миллионы строк кода и прям типа сотни человек лет разработки. Насколько большой ClickHouse?

Я очень слежу, чтобы он оставался маленьким. Это важно. Даже по таким странным метрикам, как количество строк кода. У нас сейчас количество строк кода, если его посчитать, посчитать можно по-разному. Если не считать зависимости и не считать генерированный код, там будет меньше миллиона, но где-то там 800 тысяч, как-то так. Если брать MySQL, PostgreSQL, Mongo, там несколько миллионов строк кода. Я сейчас приведу тоже некоторые вещи для сравнения. Если брать SQLite, там 350 тысяч где-то. Ну, SQLite— это понятно.

Там нет сервера, нет... Сетевого взаимодействия никакого.

Да, там всякой конкуренции нету. Структура данных на диске там довольно простая, репликация. Короче, ничего нету. 350 тысяч строк кода.

Справедливости ради, SQLite— это один из самых затестированных проектов в истории человечества. То есть у них там довольно много хорошего кода, просто понятно, что задача гораздо более локальная. Окей. Расскажи, как у Кликхауса. Где вы в этом трейд-оффе?

Очень стараемся, чтобы система была хорошей с архитектурной точки зрения. И даже если туда добавляется какой-то трэш, то это должен быть трэш, который легко убрать. То есть если какая-то функциональность, которая нужна маленькому количеству пользователей. Что, как ее интегрировать в продукт? Есть несколько возможных вариантов ответа на этот вопрос. Один из ответов— это говорить «нет» контрибьютору, который хороший человек и, может быть, твой друг работает в другой компании и им очень надо. Но есть другой вариант. Другой вариант состоит в том, что ты вместе с ним думаешь, как чуть-чуть хотя бы отполировать и, может быть, обобщить, как улучшить архитектуру самого кликхауса для того, чтобы вот эта маленькая фича получилась автоматически самым естественным образом.

Была более элегантной. Прикольно. Но это требует постоянной переделки кода уже существующего и архитектуры.

Да, и не всегда удается держать такой баланс, иногда даже приходится удалять старые фичи. Или очень обидно, когда появляется какая-то новая фича, и ты думаешь, в принципе, ее можно включить, но она еще не протестирована на настоящих объемах данных. Вот, например, у нас добавили недавно полнотекстовые индексы. Но я знаю, вот у меня есть датасет тестовый, там все комментарии Reddit и там парочка терабайт в сжатом виде. Маленький датасет. Кстати, на нем обучают все модели искусственного интеллекта. Ну не только на нем. Я хочу, чтобы полнотекстовый поиск работал на этом датасете. Если я его не протестирую, если мне никто не докажет, что он работает, Это не считается реализованной функциональностью. Поэтому у нас для таких вещей есть экспериментальные флаги. Это позволяет разбить задачу на маленькие части и помержить, добавить в кодовую базу заранее некоторые эти части, чтобы потом было легче двигаться дальше. Чтобы дать другим людям возможность тоже протестировать эти вещи. То есть они доступны в Кликхаусе, пересобирать ничего не надо. Надо просто включить экспериментальный флаг. Но очень обидно, когда этот экспериментальный флаг, там два года, например, Остается фича под экспериментальным флагом, а ты видишь, она уже начинает разваливаться. Другие вещи в коде меняют, а от этой фичи, от нее уже ничего не остается, и приходится удалять потом этот код.

Скажи, а традиционные базы данных начали как-то меняться из-за появления ClickHouse?

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

Внутри компаний.

Да, внутри компаний.

Условный Facebook, Google или кто-нибудь еще.

А они его не выложили в open source, а мы выложили. Это просто некоторое стечение обстоятельств, это нормально. У других тоже куча вопросов. Вот если брать тот же Greenplum, сейчас он не очень разрабатывается, это чисто организационная вещь, потому что компания, которая сейчас в данный момент за ним стоит, там некоторые потери инициативы идут.

Из-за кликхауса?

Не, не из-за кликхауса, просто другая стадия развития компании. Или если вот, например, брать Vertica, там изначально это классная разработка, вышедшая из C-Store, прототипа, написанного Майклом Стоунбрейкером, вместе со студентами и так далее. Куча классных принципов, все правильно сделано. Дальше продали компанию HP. Все нормально, все классно. Команда сначала сохранилась, но постепенно началась какая-то там диффузия этой команды. А потом, когда продали в Microfocus, то можно сразу закрывать, тушить свет, потому что Майкрофокус это компания, которая специализируется на покупке других компаний на поздней стадии, когда клиентская база уже есть, и можно эту клиентскую базу эксплуатировать, особо не развивая продукты. Это поддержка Legacy Software.

Звучит довольно стрёмно.

Так, а твой вопрос был про менялись ли... Да, очень даже меняются. И не нужно думать, что Clickhouse – это что-то уникальное. Есть куча сервисов, которые это делают, и во всех облачных провайдерах. Вот, например, взять Amazon Redshift. Он, кстати, это не полностью их разработка, а ParAccel, и компания переименовалась несколько раз, так что я уже не помню. Но им пришлось очень сильно доработать этот Redshift. И, кстати, там фронтенд изначально Postgres, и в целом она основана на Postgres. Что интересно, это то, что, например, идёшь в этот Redshift и смотришь, протокол Postgres 8.0. Почему? Но у них всё работает, и в той команде, которая это делала, никак эта команда не могла просто взять, сесть и обновить этот протокол, и до сих пор не может. Почему-то так получается. Но им пришлось очень много дописывать и полностью переделывать в этой системе, адаптировать её, и действительно много всего сделали. Но багаж этот даёт о себе знать, и когда есть большой объём кодовой базы, то задачи о том, чтобы капитально в ней что-то менять, они становятся на уровне пределов человеческих возможностей. То есть если есть команды разработчиков, какими бы они ни были классными инженерами, им просто физически сложно охватить и выполнить такую задачу. Я не знаю, может быть, нам должен помочь искусственный интеллект. Да, очень надеюсь. Было бы очень хорошо, потому что, к сожалению, куча образуется сложного кода, и деваться от этого некуда.

Ну да, мне кажется, проекты типа Postgres или MySQL, они как раз на пределе организационных возможностей, когда типа у тебя может быть какой-то коллектив людей, которые совместно могут куда-то двигать этот проект достаточно быстро. Как ты считаешь, вы скоро придете в такое же состояние? В смысле, есть ли опасность того, что Clickhouse станет таким же сложным?

Я думаю, да, постепенно становится сложнее. Удается более-менее держать, но в принципе видно, что риск есть, и я думаю, это неизбежно.

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

Да, конечно, и много систем. Берем Postgres, и вот, как я говорил, одна из таких штук это Greenplum, другая Citus, третья, например, TimescaleDB, и там еще несколько штук. Ну вот, например, недавно запустили какую-то штуку под названием Hydra. Каждая из них берет некоторые идеи из Кликхауса. но довольно разными вариантами. Да и в самом Postgres тоже по мелочам постепенно всякие штуки докручиваются. Вот, например, один из моих друзей, Андрей Бородин, добавил в Postgres более хороший метод сжатия данных. Правда, там он применяется к страницам отдельным в рамках одной страницы, поэтому в целом получается не очень эффективно, но зато намного быстрее. И там не то, чтобы это взято из Кликхауса, скорее даже нет, но некоторые идеи, которые позволили улучшить этот подход, эти идеи, скажем так, соотнесены с тем, что есть в Кликхаусе.

Хорошо. Скажи, пожалуйста, вы все еще проект внутри Яндекса?

Нет, мы же выделились в отдельную компанию в 2021 году.

Как это произошло?

В 2021 такой довольно бум на рынке с инвестициями, хотя началось это намного раньше, еще в 2019. Постепенно стали писать другие интересные компании, потенциальные инвесторы, спрашивать, что вы собираетесь делать с Кликхаусом. Они писали мне лично, они писали другим знакомым. там Алексею Башкееву, людям в совете директоров писали, и я смотрел и интересовался вариантами, что с этим можно сделать. Предлагал всякие варианты тоже руководству, и постепенно там это все обсуждалось, но эти обсуждения, они были какими-то такими вялыми довольно. То есть ничего особенного не происходило. Я говорю, ну вот предлагают такие интересные инвестиции, вроде люди хорошие, там знакомые, я знаю, что они вышли из другой компании, которая довольно успешная. И этот фонд основан там другими людьми, которые известны в индустрии и действительно классные люди из технологий. Я говорю, вот они готовы вложить там такие вещи, довольно интересно. Но если это сделать, то получается, что если я уйду из компании, то это довольно неудобно и придется потерять торговые марки, а мне не хочется ни с кем ссориться. Башкееву: мне не хочется с тобой ссориться. Но эти обсуждения, они что-то довольно вялые. А потом знакомые через совет директоров Яндекса в такие вопросы поставили. Вот Кликхаус, классная технология, а что вы собираетесь с ней делать? А Аркадий Волож и особо и не знал, что есть такая технология, пришлось рассказывать. И решили, что есть перспектива, что если сделать такой спин-офф из Яндекса, то у Яндекса будет маленькая доля, гораздо меньше, чем там контролирующая, то это позволит Кликхаусу вырасти намного больше, что в итоге будет выгоднее для всех.

Расскажи, как вы зарабатываете?

У нас облачный сервис для Кликхауса. Можете зайти на наш сайт, там написано «Создать кластер Кликхаус». Нажимаете, вам создается кластер. Сначала триал на 30 дней, потом надо добавить кредитку или для серьезных компаний можно сразу договориться, чтобы были специальные условия, которые рассчитаны на серьезное время, на более выгодных условиях. И этим сервисом уже пользуются. Мы его, кстати, запустили меньше, чем полгода назад.

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

И читать.

Окей, да, читать тоже довольно важно. Окей. Вы запустили этот клауд платный полгода назад, а компания уже есть очень давно. На что вы жили вообще?

Ну и инвестиции довольно хорошие получили как раз на можно сказать на пике рынка.

Получается Кликхаус теперь это коммерческая компания прям отдельная.

Да, отдельная компания. Цель этой компании – кликхаус. Смысл жизни исключительно кликхаус.

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

Наши инвесторы – это публичная информация для большинства из них. Там есть основные инвесторы, есть еще мелкие, которые просто решили тоже немножко проинвестировать так. Даже есть интересные, скажем так, люди. У нас два раунда инвестиций. Первый раунд были две компании, два фонда, это Benchmark и Index. Довольно известные, и они хороши тем, что у них есть еще в их портфолио тоже похожие компании. И это не такие странные фонды, как если сказать, там, Andreessen Horowitz или SoftBank, или я не знаю. Вот сейчас смотришь на какую-то компанию, которая поднимает деньги, и там написано, условно, я буду фантазировать фонд «Принца Катара». Ну и чего? Ну, может завезти какие-то деньги, но что там дальше, будет это под вопросом. Поэтому важно, чтобы фонды тоже были серьезные.

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

Нет, в конце концов инвесторов нашли через знакомых, и через знакомых также нашли нашего CEO. Отличный выбор, замечательный человек, и очень рад, что так получилось. Нашли через бывшего финансового директора Яндекса, у него был знакомый. Он говорит, ну вот такой интересный человек, пробивной, может сделать вещи. Рассказал ему про Кликхаус и встретились с ним. Вроде понравилось. И дальше уже нашли эти две интересные компании. Кстати, сейчас продолжается тоже. Многие хотят вложить, но это уже другой разговор.

Окей. Расскажи, на чем вы сейчас работаете.

О, вот твой подкаст называется «Запуск завтра». А ты в курсе, что у нас был запуск вчера?

Расскажи.

Вчера мы запустили сервис на GCP.

О, то есть уже можно развернуть ваш ClickHouse на Google Cloud Platform.

Но это было одно из самых востребованных. Многие клиенты говорили, что у них все сервисы уже существуют на GCP, поэтому если они хотят использовать ClickHouse в облаке, им надо, например, чтобы он был в той же сети, и чтобы там можно было сделать какой-то аналог PrivateLink, и чтобы данные не передавать и не платить за трафик, ну и еще ограничения, ну куча всего. Им нужен GCP. И оказалось, что это не всё так просто сделать. То есть, смотри, сервис наш работает в облаке, инфраструктура работает в Kubernetes. В чём смысл Kubernetes? Это смысл в том, чтобы абстрагировать облака. То есть это система, которая тебе ничего не упрощает, а всё делает только сложнее. Но зато ты можешь её, если хочешь, использовать в Амазоне, если хочешь, в GCP, а если хочешь, в принципе, на своих серверах. Но не всё так просто. В Амазоне куча сервисов. В GCP те же самые сервисы с чуть-чуть другим API. Чуть-чуть несовместимые. И если ты влип и используешь много из них, то просто перейти с одного облачного провайдера на другой у тебя полгода может занять легко. У нас меньше заняло.

А у вас ваш код, это код ваш написан, он типа используется напрямую, или это просто ваша обвязка инфраструктурная использует какие-то... Как это работает?

И то, и другое. То есть сам ClickHouse сервер может взаимодействовать с S3 для хранения данных, а также для импорта и экспорта, и для всяких data lakes. S3— это как расшифровывается?

Хранилище.

Sophisticated Storage Service.

Simple. Хорошая шутка.

То есть, теоретически он хранит данные. Но всё очень сложно.

А осталось ли что-то доделать в самом Крикхаусе? Какие-то фичи, которые еще прям вот горят?

Почему-то таких фичей появляется все больше и больше. Причем хочется, чтобы одновременно уделять время и тем вещам, которые нужны прямо сейчас клиентам, и одновременно, чтобы были какие-то инновации в самой технологии. Потому что иногда видишь, что некоторые задачи решаются очень криво в других системах. И ты думаешь, ой, давайте вот по-нормальному сделаем. Я сейчас буду фантазировать, и это не совсем относится к действительности, но вот представьте, что вам, чтобы сделать сервис, нужен Кликхаус, Kafka и Redis. А теперь представим то же самое, но только Кликхаус. И в нём внутри маленькая Кавка и маленький Редис.

Это, конечно, удобнее.

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

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

Вроде бы есть хороший Andy Pavlo, который, кажется, так и называется, что-то про базы данных. Так что я думаю, можно с него начать. Это, во-первых. Во-вторых, есть книги интересные. Вот, по-моему, есть что-то типа Designing Data-Intensive Applications.

Каким-то животным, насколько я помню. Это O'Reilly, в смысле, книжка.

Ага, вроде бы. Тоже должно быть довольно интересно. Вот просто статьи случайные читать я бы не советовал, потому что будет трудно. То есть если вы будете читать статьи, то потеряете уверенность в том, что вообще этим можно заниматься. Ага. Слушайте, вот еще недавно советовали где-то, не то сайт, не то еще что-то, где говорят «туториал» типа «Build your own Redis». Вообще можно исходники кликхауса почитать. Почему? Потому что одна из идей, которую я пытаюсь продвигать, это то, чтобы должно быть понятно любому человеку с улицы. Комментарии в коде должны быть везде. Неочевидные вещи должны быть написаны. Если ты написал какую-то хрень в коде, извиняешься и бьёшься головой, как тебе пришлось написать этот код, а лучше такого не делать. И есть инструкция для разработчиков, так что, пожалуйста, попробуйте начать, может быть, даже какую-нибудь фичу законтрибьютить в ClickHouse.

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

Спасибо.

Это подкаст Студии Либо-Либо. Сделали мы его совместно с сервисом онлайн-образования Яндекс Практикум. Над подкастом работали редакторка Маша Агличева, продюсерки Настя Медведева и Саша Малинина, звукорежиссер Юрий Шустицкий. За джингл спасибо Алексею Зеленскому. Редактор субтитров А.Синецкая Корректор А.Егорова