Jesse Anderson, директор Big Data Institute, и Martin Kleppmann, автор книги «Высоконагруженные приложения. Программирование, масштабирование, поддержка», вместе исследуют меняющийся ландшафт обработки данных. Они начинают с истории создания книги Мартина, подчеркивая важность искусства задавать правильные вопросы. Мартин рассказывает об изменениях, произошедших в отрасли с 2017 года, подчеркивая рост облачных сервисов. Затем беседа приобретает новый поворот, когда Мартин погружается в академические круги, делясь своими соображениями о программном обеспечении для совместной работы на основе локального подхода и увлекательном мире Automerge. Начинающие программисты получат несколько советов о том, как найти тонкий баланс между простотой и гибкостью. В завершение обсуждают о различных карьерных путях в динамичной сфере инженерии данных, что делает разговор полезным для профессионалов на любом этапе их пути.

Введение

Jesse Anderson: Привет и добро пожаловать на GOTO Unscripted. Мы находимся в Амстердаме. Меня зовут Jesse Anderson. Я управляющий директор Big Data Institute. Со мной Martin Kleppmann. Мартин увлекался разными темами в области данных и сейчас занимается довольно интересными вопросами. Мы собираемся поговорим об этом немного подробнее. Добро пожаловать, Мартин. Еще раз спасибо, что присоединились к нам.

Martin Kleppmann: Спасибо, Джесси. Здорово быть здесь.

Jesse Anderson: О, я ценю это. Итак, вы, вероятно, больше всего известны в мире данных благодаря своей работе над книгой «Высоконагруженные приложения. Программирование, масштабирование, поддержка». Не могли бы вы вкратце рассказать, что вы хотели донести до читателя в этой книге?

Martin Kleppmann: Да, конечно. Я был поражен количеством различных технологий, существующих в пространстве данных. Так много различных систем обработки данных и баз данных, так много различных способов выполнения задач, и так много записей в блогах, рассказывающих о том, какая система лучше или какая программа хуже. Я просто пытался придумать способ дать людям хороший совет, какие технологии использовать для их конкретного случая, потому что я понял, что нет одного правильного решения, верно? Все зависит от того, что вы хотите сделать, а это значит, что нужно задавать правильные вопросы о технологии, чтобы понять, подходит она вам или нет. По сути, этой книгой я хотел научить читателей задавать правильные вопросы, чтобы они сами могли определить, как строить системы с большим количеством данных и какие технологии использовать.

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

Martin Kleppmann: Точно!

Эволюция систем обработки данных

Jesse Anderson: Что изменилось с момента написания книги до сегодняшнего дня, о чем бы вы хотели, чтобы люди узнали?

Martin Kleppmann: Книга вышла в 2017 году, так что прошло уже немало времени, на ее написание у меня ушло довольно много времени. Итак, первые несколько глав были написаны в 2014 году или что‑то в этом роде. Таким образом, им уже почти десять лет. Думаю, одним из самых значительных изменений за это время стал рост облачных сервисов. В 2013 году облако уже существовало, но оно не было таким распространенным, как сейчас, и мне показалось, что тогда многие компании все еще занимались самостоятельным хостингом на локальных серверах. Именно этому и была посвящена книга. Но сейчас я думаю, что облачные нативные архитектуры (cloud‑native architectures) стали гораздо более популярными и распространенными. Кроме того, это действительно изменило архитектуру построения систем обработки данных, потому что это больше не идея концентрации на отдельных машинах, где каждая машина имеет жесткие диски, а, скорее, вы создаете один сервис из других сервисов, и каждый сервис по отдельности может быть распределен по нескольким машинам.

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

Jesse Anderson: Давайте спрошу по другому. Что остается неизменным?

Martin Kleppmann: К счастью, большая часть. Основы, такие как транзакции и модели согласованности, я думаю, не сильно изменились. Основы репликации, распределение данных по нескольким машинам и разделение на секции — большинство из этих идей не претерпели особых изменений за 30 лет. Зато изменились другие вещи. Например, я думаю, что MapReduce был довольно заметным элементом в первом издании, и я думаю, что сейчас он уже практически мертв. На смену им в одном направлении пришли облачные хранилища данных для бизнес‑аналитики, а в другом — потоковые системы для пользовательской логики приложений.

Jesse Anderson: Есть ли какие‑то спорные моменты, которые, как вы думаете, вы включите в первое или второе издание?

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

Jesse Anderson: Я думаю, что это связано с вашим опытом, который вы приобрели работая в академии: «Я не собираюсь говорить вам, что делать». Вы выходите из консалтингового мышления и говорите: «Вот как нужно думать о проблеме». И это действительно то, над чем, на мой взгляд, стоит задуматься. Что вам нужно сделать, чтобы понять, как решить проблему?

Martin Kleppmann: А что вы заметили в своей работе? Когда вы консультируете, вы стараетесь, чтобы люди тоже задавали вопросы. Что скажете по этому поводу?

Jesse Anderson: Одна из главных вещей, которую я советую людям, — не рассматривать варианты технологий до тех пор, пока вы не разберетесь в проблеме, потому что обычно это происходит постфактум: «Эй, все, мы делаем MapReduce». Теперь мы переворачиваем эту проблему и говорим: «Окей, теперь каждая бизнес‑задача должна использовать Hadoop». И, работая в Cloudera, я видел проблемы, связанные с этим: «Слушайте, все, вы используете Hadoop и MapReduce, а они имеют такие‑то и такие‑то ограничения», и теперь вам приходится искать способы обхода этих ограничений вместо того, чтобы посмотреть на бизнес‑задачу и сказать: «О, эта технология подходит для этого».

Я бы сказал, что другая причина заключается в том, что люди ищут одну технологию для всего, а ее просто не существует. В свое время мы работали с небольшими данными, просто говоря: «У нас есть база данных и, возможно, веб‑сервер, если мы делаем что‑то подобное». У нас было всего три технологии, а теперь мы имеем этот взрывной рост, и люди говорят: «Ну, этот взрыв — всего лишь наша попытка оверинжиниринг вещей». Я так не думаю. Мы пытаемся все оптимизировать, оптимизировать с точки зрения бизнеса, когда нам приходится этим заниматься.

Martin Kleppmann: Точно. Именно так. Я думаю, что если вы работаете с небольшими объемами данных, если они достаточно малы, их можно поместить в таблицу. Если объем немного больше, можно поместить их в реляционную базу данных, и все будет в порядке. Но когда вы переходите к большим объемам данных, вам нужны специализированные системы для работы с конкретной рабочей нагрузкой, с которой вы хотите справиться. И, знаете, вы сказали, что люди ищут, например, один инструмент, который может делать все, но я отвечаю на это так: если у вас есть один инструмент, который может делать все, единственный способ, которым он может это сделать, — это делать все плохо. Поэтому лучше иметь специализированные инструменты, которые хорошо справляются с одной задачей, а затем попытаться скомпоновать их, чтобы в итоге все ваши проблемы решались хорошо, а не плохо.

Jesse Anderson: Да. И если уж говорить об этом, то, поскольку мы находимся на GOTO Amsterdam, мы с вами сидели вместе и наслаждались выступлением Dave Thomas, а суть выступления Дэйва заключается в том, что наша самая большая или самая важная задача как технических специалистов заключается в том, чтобы создавать возможности для изменений, верно? Сделать так, чтобы изменения происходили как можно легче. Как, по‑вашему, это проявляется? И давайте сведем это к работе с данными.

Martin Kleppmann: Я считаю, что это очень важно в сфере данных. Отчасти это происходит потому, что я вижу это в дискуссиях о масштабируемости. Например, стартапы приходят ко мне и говорят: «Эй, не могли бы вы посоветовать нам, как сделать нашу систему масштабируемой?». А я спрашиваю их: «Ну, сколько у вас сейчас конечных пользователей данных?». А они говорят: «О, мы еще не запустились. Мы просто хотим быть готовыми к будущему». Тогда мой совет номер один: не беспокойтесь о масштабируемости, потому что на ранней стадии вы хотите оптимизировать работу, чтобы все было легко менять. Поэтому просто реализуйте все самым простым способом, который будет работать, и позволит вам легко модифицировать его и адаптировать к тому, что вы узнаете о рынке, о ваших пользователях и так далее. А это часто означает выбор технологий общего назначения.

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

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

Jesse Anderson: Поскольку мы с вами оба работаем в мире потоковой передачи данных, я думаю, что одно из самых больших изменений, которое мы увидели, связано с Kafka, с Pub/Sub, распределенными системами Pub/Sub, в которых возможность изменения и добавления систем значительно лучше, чем в других случаях, если вы хотите добавить конкретную базу данных для конкретного случая использования, если эти данные уже есть в вашей системе Pub/Sub, эффективное добавление может быть либо тривиальным, либо очень простым. Поэтому я бы сказал, что самое главное, что, по моему мнению, нужно сделать тем, кто движется в этом направлении, — использовать Pub/Sub, это позволит вам легче меняться.

Martin Kleppmann: В частности, вы можете комбинировать и расширять систему. Так, если у вас есть один потребитель данных, и появляется другое приложение, которое хочет получить данные в другом виде, то все в порядке, просто добавьте еще одного потребителя. Это легко сделать в системе Pub/Sub, такой как Kafka. Поэтому я считаю, что наличие общей инфраструктуры потоковой системы позволяет вам проводить больше экспериментов с несколькими потребителями, если вы хотите перейти от одного потребителя к другому. Например, вы можете запустить оба потребителя бок о бок в течение определенного времени, проверить согласованность двух систем, а затем принять решение о переходе от старого потребителя к новому. Потоковые системы позволяют это гораздо лучше, чем, например, системы, основанные на обращениях к отдельным сервисам. Поэтому мне кажется, что, как вы сказали, потоковая передача может помочь облегчить процесс изменений.

Принятие перемен и неизменные принципы в стартапах

Jesse Anderson: Я согласен. Вы упомянули кое‑что интересное, и это вопрос, который мне часто задают, а именно — о стартапах. Стартапы обычно испытывают нехватку ресурсов на нескольких разных уровнях: люди, время и технологии. Что бы вы посоветовали стартапу прямо сейчас, чтобы справиться с этой проблемой? Вы упомянули реляционные базы данных. Что еще вы могли бы им посоветовать?

Martin Kleppmann: Я думаю, что что‑то вроде потоковой передачи данных может быть полезным на ранней стадии, если вам нужны какие‑то обновления в реальном времени, потому что, да, в принципе, вы можете построить событийные системы поверх реляционной базы данных, но вы как бы идете против правил, потому что, например, обычно не существует хорошего способа подписаться на новые изменения. Поэтому такая система, как Kafka, хотя и рассчитана на большие масштабы, но если вы стартап на ранней стадии, у вас не будет таких масштабов, у вас не будет таких потребностей. Но мне кажется, что это фундаментальный строительный блок, который вы можете встроить в свою систему. Если у вас есть этот поток событий, то он может стать тем, что позволит проводить всевозможные эксперименты в дальнейшем. Так что это может быть одним из элементов инфраструктуры, который стоит внедрить на ранней стадии. Но в остальном, я думаю, лучшей рекомендацией будет максимально упростить систему, и чем меньше строк кода, тем лучше, по сути.

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

Martin Kleppmann: И возможно это не решит проблемы, которые вы обнаружите через два года.

Jesse Anderson: Точно. Поэтому старайтесь делать все как можно проще. Сложность — ваш враг на самых разных уровнях. Не заходите слишком далеко. Сохраняйте свободу действий.

Martin Kleppmann: Да, согласен.

Local-First Collaboration Software

Jesse Anderson: Вы сейчас занимаетесь исследованиями в Техническом университете в Мюнхене. Не могли бы вы рассказать нам об исследованиях, которые вы проводите?

Martin Kleppmann: В течение последних нескольких лет я изучаю программное обеспечение для совместной работы. Например, в стиле Google Docs, где несколько человек могут редактировать документ одновременно, я пытался изменить этот стиль программного обеспечения, чтобы оно было менее облачным и давало больше контроля конечным пользователям. Так что если облачный сервис, например, заблокирует вас, вы не потеряете все свои данные, а будете хранить их на устройстве пользователя. У вас все еще есть копия данных. Частично это позволяет также использовать сквозное шифрование, например. Мы можем создать программное обеспечение, которое позволит нескольким пользователям сотрудничать, не предоставляя серверам доступ ко всем нашим данным, чтобы серверы видели только зашифрованные данные, а конечные пользователи на своих устройствах имели доступ к реальному содержимому документа. И это интересный набор проблем распределенных систем, немного криптографии и протоколов безопасности, немного баз данных и так далее — все вместе.

Jesse Anderson: Вы писали статьи на эту тему или код, который может кому‑то пригодиться?

Martin Kleppmann: Да, документы, код, доказательства, разные вещи. Так что мы подходили к этому с разных сторон. Частично это теоретический подход, когда мы пытаемся понять, какие алгоритмы являются правильными и как мы можем доказать, что эти алгоритмы работают. Доказательства очень важны, потому что некоторые из этих алгоритмов очень тонкие и их очень легко испортить. И поэтому без формального доказательства правильности я бы просто не поверил, что они верны. Такова теория, но есть и практический аспект. Я сотрудничаю с некоторыми компаниями, чтобы разработать открытую реализацию некоторых наработок, которые мы сделали в теоретической части. Так, например, у нас есть библиотека под названием Automerge, которая теперь является профессионально поддерживаемой библиотекой с открытым исходным кодом для создания программного обеспечения для совместной работы. Мы называем стиль «local first», когда данные хранятся в основном на вашем устройстве, а облачные хранилища выступают в качестве своеобразного механизма синхронизации и резервного копирования данных. И это была, знаете ли, забавная смесь объединения теоретических и практических перспектив.

Размышления об академии

Jesse Anderson: А была ли причина для таких перемен? Не похоже, что это поворотный момент. Скорее, это следующий шаг Мартина Клеппманна. Что привело к этому?

Martin Kleppmann: Что, переход в академию?

Jesse Anderson: Ну да, давайте поговорим об академических кругах. Что привело вас в академическую среду?

Martin Kleppmann: До этого я почти десять лет работал в стартапах, и это было очень интересно, я многому научился, но мне надоело постоянно торопиться и не успевать что‑то детально обдумать. Мне казалось, что мы относимся ко всему очень поверхностно и никогда не доходим до сути вещей. Мне хотелось свободы, чтобы больше думать и пытаться понять, как и почему все работает. И такую свободу вы получаете в академических кругах. Это компромисс. Знаете, в стартапе вы можете оказать немедленное влияние. Вы можете запустить что‑то в производство, и пользователи сразу же увидят это, в то время как в академической среде я могу написать статью, через пять лет она будет реализована в open‑source, а через 10 лет — в промышленном ПО. Так что сроки гораздо больше, но, с другой стороны, мне нравится эта свобода, позволяющая углубиться и убедиться в том, что мы все понимаем, потому что, знаете ли, в распределенных системах очень многое сложно сделать правильно, и я чувствую, что это та область, которая поощряет глубокие и тщательные размышления.

Jesse Anderson: Да. Глубокое и тщательное исследование. Иногда такое можно увидеть в дизайне систем. Не знаю, видели ли вы когда‑нибудь такое. Вы смотрите на дизайн технологии и говорите: «Ну, тут проблема, и тут проблема, и тут проблема, и тут проблема». И, вероятно, если вы поговорите с разработчиком этой технологии, он скажет: «Ну, она работает достаточно хорошо для пользователей». Что вы думаете об этом?

Martin Kleppmann: Часто бывает, что распределенные системы работают просто отлично, пока у вас нет проблем. А потом возникает странная проблема, например, возникает разделение сети(network partition), которое отключает две части вашего центра обработки данных друг от друга или, например, отключает одну стойку от остальной части дц на несколько минут, и, например, сетевой трафик пытается пройти через это сетевое разделение, но он не проходит. А потом его восстанавливают, и по сети идет много трафика, а потом куча серверов начинают убивать друг друга или у вас split‑brain, когда разные части системы или обе считают, что имеют право на какие‑то данные, но, знаете, у вас возникла противоречивая ситуация, которой не должно было быть, и тогда все рушится, и это катастрофа.

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

Jesse Anderson: Вы затронули тему, которую я давно не встречал. Время от времени я видел, как кто‑то решал, что хочет написать свою собственную распределенную систему, и она хорошо работала в первых 80% случаев использования, а затем в 20% возникали основные проблемы, и система не справлялась. Так что, к счастью, у нас есть достаточно открытого исходного кода, где люди реализовали и продумали все это.

Martin Kleppmann: У вас есть какие‑то конкретные примеры того, что пошло не так, если можно, поделитесь? Мне всегда нравится слушать примеры неудач. Из них можно многому научиться.

Jesse Anderson: Например, докторская диссертация — это совсем не то, что вы хотите запустить в производство.

Martin Kleppmann: Да, возможно.

Jesse Anderson: Давайте скажем об этом прямо. Я видел всего несколько докторских диссертаций, которые выдержали испытание временем. Например, Apache Flink. Я не знал, что несколько лет назад это была докторская диссертация Kostas. И она выдержала испытание временем. Когда я впервые встретил его, я спросил — «Что ты сделал по‑другому или что они сделали по‑другому, что позволило коду докторской диссертации попасть в производство?». Чаще всего компания нанимала их, они писали докторскую диссертацию и говорили: «О, код готов. Давайте запустим его в производство». Но это не код, пригодный для производства. Он либо был предназначен для гораздо меньшего количества применений, либо не учитывал другие моменты, и в результате они были привязаны к этому унаследованному коду, который, как они думали, они когда‑нибудь смогут вытащить и использовать для чего‑то другого, и никто другой не сможет его поддерживать, потому что это код этого человека. И что еще хуже, этот код был написан плохо. Он не был готов к профессиональной разработке программного обеспечения.

Martin Kleppmann: Да. Но я бы не стал винить в этом докторскую диссертацию. Думаю, то же самое можно сказать и о случайной библиотеке, которую вы найдете на GitHub. Вероятно, вам также не стоит запускать ее в производство просто так, не обдумав. Возможно, это разница между исследовательской работой одного человека, который пробует что‑то новое, и тем, что уже было опробовано, используется в производстве и уже имеет опыт, который отразился на его дизайне.

Jesse Anderson: Да. А потом, размышляя об этом, один из моих друзей сказал кое‑что интересное и хорошо сказал. Они сказали, что когда у вас есть технология, созданная для чего‑то одного, скажем, только для Pub/Sub, по мере добавления новых сценариев использования и новых возможностей вы все дальше и дальше отклоняетесь от документа. Поэтому он возвращался и читал оригинальную статью, а затем смотрел, как они ее меняют, чтобы увидеть, насколько сильно они отклоняются, и это давало бы хорошую метрику того, насколько сильно они меняют код или насколько низка вероятность того, что они изменили его достаточно хорошо, чтобы это было обходное решение, это патч. Думали ли вы об этом или видели ли такое когда‑нибудь?

Martin Kleppmann: Что именно, переход от исследований к промышленности или...?

Jesse Anderson: Я остановлюсь на Kafka, поскольку мы знаем, что в Kafka, например, собираются добавить механизм добавления в очередь. Я не читал KIP очень подробно, но мне было интересно, как они собираются реализовать очередь — на стороне клиента или на стороне сервера. Потому что, на мой взгляд, это должно быть в основном изменение на стороне сервера.

Martin Kleppmann: Верно. Да. Я тоже не читал его подробно, поэтому не знаю о конкретном предложении. Но в целом, мне кажется, что люди, работающие над Kafka, действительно хорошо разбираются в распределенных системах, и это отразилось в архитектуре Kafka на самом фундаментальном уровне. И поэтому я думаю, что это был хороший пример использования некоторых основополагающих принципов, которые сами по себе не являются сложными, таких как, например, идея журнала только для приложений, использование кэша страниц в том виде, в котором он используется, и, по сути, запуск протокола консенсуса для принятия решений о сообщениях, которые появляются в topic partition, но не совсем называя его так и полагаясь на что‑то вроде Zookeeper для обеспечения внешней координации. И, знаете, все эти дизайнерские решения очень разумны и хорошо сделаны.

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

Советы начинающим Data Engineers

Jesse Anderson: Хорошо. И последний вопрос. Что бы вы посоветовали начинающим инженерам по обработке данных?

Martin Kleppmann: Это сложный вопрос. Я имею в виду, что в настоящее время я довольно оторван от повседневной работы с данными, верно? Я теперь академик. Поэтому я в основном изучаю системы и их внутреннее устройство, чтобы понять, какие из них лучше использовать. Думаю, моя рекомендация заключается в том, чтобы узнать достаточно о внутреннем устройстве систем, которые вы используете, чтобы иметь достаточно точную ментальную модель того, что там происходит. Вам не нужно уметь самостоятельно модифицировать код Kafka, но я думаю, что достаточно иметь представление о внутреннем устройстве, чтобы, например, если производительность падает, вы могли представить себе, что происходит, или если что‑то идет не так и вы получаете странное сообщение об ошибке, или если вы пытаетесь понять, можно ли построить определенный механизм согласованности поверх него, — все эти вещи. Невероятно ценно иметь хоть какую‑то мысленную модель, а не просто относиться к технологиям как к черному ящику. Поэтому я бы посоветовал узнать немного о том, что происходит внутри.

Jesse Anderson: Хорошо. Мне кажется, я бы сказал, что есть много направлений. В конце концов, я к этому пришел. Хотел бы я знать об этом раньше, ведь это не только программирование, это один из вариантов. Есть еще путь в менеджмент. Обычно это два наиболее известных пути, но вы также показали третий путь — академический, или путь, по которому иду я, — консалтинга и бизнеса, или есть люди, которые занимаются влиянием или DevRel, отношениями с разработчиками. Существует множество путей. Нужно изучить различные направления, посмотреть, чем вы хотите заниматься и каковы ваши навыки, и понять, что подходит вам.

Martin Kleppmann: Это отличный совет.

Jesse Anderson: Что ж, Мартин Клеппманн, это было здорово. Большое спасибо. Большое спасибо за просмотр этого интервью. Это была программа GOTO Unscripted. Спасибо!

Дизайн высоконагруженных приложений будущего. Путешествие без сценария с Мартином Клеппманом