Преподаватель колледжа Брэдфилд Озан Онай о карго-культе, возникающем вокруг новых технологий, и о методе, который помогает в выборе технологий для компании.
Разработчики сходят с ума от самых нелепых вещей. Нам нравится думать, что мы гиперрациональны, но когда нам нужно выбрать технологию, мы в некоторой степени становимся безумными — мы прыгаем от комментария одного человека на Hacker News к посту другого в блоге до тех пор, пока не сдаемся и не дрейфуем в ступоре к самому яркому световому пятну, на самом деле забыв о том, что мы искали в самом начале.
Рациональные люди принимают решения не так, но так разработчики решают использовать MapReduce.
Как сказал Джо Хеллерстайн в своем уроке для студентов по базам данных:
Дело в том, что где-то пяти компаниям в мире нужны такие большие задачи. Для всех остальных…вы совершаете все эти операции ввода-вывода для достижения отказоустойчивости, которая вам на самом деле не нужна. В 2000-х у всех было что-то вроде Google-мании: “Мы будем делать всё, так как Google, потому что мы также управляем самым большим в мире интернет-сервисом передачи данных”.
Сколько этажей в вашем центре хранения данных? Google остановился на четырех.
Избыточная отказоустойчивость может показаться нормальной, но подумайте о стоимости: вы не только будете совершать больше операций ввода-вывода, но и переключитесь с устойчивой системы со своими транзакциями, индексами и оптимизаторами запросов на что-то неизведанное. Какой большой шаг назад. Сколько пользователей Hadoop сделали этот переход осознанно? Сколько из них совершили переход мудро?
MapReduce/Hadoop — это удобная цель, потому что даже поклонники карго-культа поняли, что их деревянные самолеты все еще стоят на земле. Но на эту тему можно посмотреть и более широко: если вы используете технологии, которые пришли из крупной компании, но ваш опыт использования совершенно отличается, вряд ли вы применяете их умышленно — вероятно, что вы просто следуете ритуалу, по которому имитация гигантов принесет вам их прибыль.
Итак, да: это ещё одна статья против карго-культа. Но подождите! У меня есть для вас полезный чеклист, используя который вы сможете принимать решения.
Крутая технология? UNPHAT
Когда в следующий раз вы обнаружите, что гуглите крутую новую технологию, чтобы перестроить свою архитектуру, я призываю вас остановиться и последовать этому плану:
- Даже не начинайте принимать решение, пока вы не поймете (Understand) проблему. Ваша цель — “решить” проблему в области проблемы, а не в области решения.
- Перечислите (eNumerate) несколько кандидатов. Не начинайте просто топить за своего фаворита!
- Рассмотрите решение, затем прочитайте документацию (Paper), если она есть.
- Определите исторический (Historical) контекст, в котором было создано решение.
- Взвесьте преимущества (Advantages) и недостатки. Определите, что было деприоритизировано, чтобы достичь то, что было приоритизировано.
- Думайте! (Think) Трезво оцените, как это решение подходит к вашей проблеме. Какие факты должны измениться, чтобы вы изменили свое мнение? Например, насколько меньше должны быть данные, чтобы вы отказались от Hadoop?
Вы не Amazon
Применение UNPHAT довольно прямолинейно. Взгляните на мое недавнее обсуждение с компанией, которая рассматривала использование Cassandra для рабочего процесса с данными, которые загружались в ночное время:
Я прочитал документацию Dynamo и знал, что Cassandra — это его близкая производная, поэтому я понял, что эти распределенные базы данных приоритизируют доступность записи (Amazon хотел, чтобы действие “Добавить в корзину” всегда было успешным). Я также оценил, что они сделали это в ущерб последовательности, как и в ущерб каждой функции в традиционных реляционных СУБД. Но компания, с которой я общался, не хотела приоритизировать доступность записи, потому что функция записи вызывается раз в день.
Amazon продает множество вещей ежедневно. Если действие «Добавить в корзину» не состоится, они потеряют мнго денег. Ваш случай такой же?
Компания рассматривала Cassandra, потому что запрос PostgreSQL занимал минуты, что они определили как ограничение оборудования. После нескольких вопросов мы определили, что таблица занимала около 50 миллионов строк по 80 байт, поэтому для полного чтения на SSD требовалось около 5 секунд, если необходим был полный FileScan. Это медленно, но на 2 порядка быстрее, чем реально выполнялся запрос.
К этому момент я все еще хотел задать больше вопросов (понять проблему), начал взвешивать около пяти стратегий, но все равно уже стало понятно, что Cassandra будет неверным решением. Им нужна была некоторая точная настройка, возможно, перемоделирование некоторых данных, вероятно, другая технология… но точно не решение, которое Amazon создал для своей корзины с покупками!
Более того, вы не LinkedIn
Я был удивлен, когда узнал, что компания одного из студентов выбрала Kafka для создания архитектуры. Это было удивительно, потому что их бизнес обрабатывал всего несколько ценных транзакций в день, может быть, несколько сотен в хороший день. При такой нагрузке основным хранилищем данных может быть даже обычная книга с записями.
Kafka была создана, чтобы справляться со всеми событиями LinkedIn: огромное число. Даже пару лет назад оно составляло около триллиона событий ежедневно, с пиками в 10 миллионов сообщений в секунду. Я понимаю, что Kafka все ещё полезна для более низкой пропускной способности, но не на 10 же порядков меньше?
Солнце больше Земли на 6 порядков.
Возможно, инженеры действительно приняли осмысленное решение, основанное на их потребностях и понимании назначения Kafka. Но я предполагаю, что они приняли энтузиазм сообщества вокруг Kafka и не подумали, подойдет ли она для их работы.
Вы снова не Amazon
Сервис-ориентированная архитектура, модель, которая позволила Amazon вырасти, ещё более популярна, чем их распределенное хранилище данных. В 2001 году Amazon понял, что он не может масштабировать свой фронтенд, и им помогла сервис-ориентированная архитектура. Это мнение переходило от одного инженера к другому до тех пор, пока стартапы с несколькими сотрудниками и почти нулевым количеством пользователей не начали раскалывать свои приложения на наносервисы.
Но когда Amazon решил перейти на SOA, у них было около 7800 сотрудников и более $3 миллиардов продаж.
Аудитория вмещает 7000 человек. Amazon перешел на SOA, когда в компании работало 7800 человек.
Не хочу сказать, что вы не должны переходить на SOA пока не достигнете 7800 сотрудников, просто думайте сами. Это лучшее решение для вашей проблемы? В чем заключается ваша проблема и как вы можете решить её по-другому?
Если вы скажете мне, что ваша организация из 50 человека не справляется без SOA, я задумаюсь, почему столько более крупных компаний обходится всего одним, большим, но хорошо организованным приложением.
Даже Google не является Google
Использование движков для больших объемов данных вроде Hadoop и Spark может быть довольно забавным: часто традиционная СУБД лучше подходит для данного объема работы, а иногда количество данных так невелико, что может уместиться в памяти. Знали ли вы, что вы можете купить терабайт ОЗУ за 10 тысяч долларов? Даже если у вас миллиард пользователей, у вас будет 1 килобайт на пользователя.
Возможно, это недостаточно для вашей нагрузки, и вам нужно будет считывать данные и записывать их обратно на диск. Но нужно ли вам читать и записывать на тысячи дисков? Сколько у вас данных? GFS и MapReduce были созданы, чтобы решать проблему поиска во всем вебе.
Цены на жесткие диски намного ниже, чем в 2003, когда были опубликованы документы GFS.
Возможно, вы читали документацию по GFS и MapReduce и понимаете, что проблема для Google заключалась не во вместимости, а в пропускной способности: они распределили хранилище, потому что данные слишком долго извлекались с диска. Но какая пропускная способность у устройств, которые вы будете использовать в 2017? Примем во внимание, что вам будет нужно не так много устройств, как Google, сможете ли вы просто купить оборудование получше? Сколько будут стоить вам SSD-накопители?
Может быть, вы планируете расширяться. Но вы учили математику? Вероятно ли, что вы будете аккумулировать данные быстрее, чем падает цена на жесткие диски? Насколько должен вырасти ваш бизнес, чтобы ваши данные больше не помещались в одном устройстве? В 2016 году сайты Stack Exchange обрабатывали 200 миллионов запросов ежедневно, базируясь всего на четырех серверах: один для Stack Overflow, один для всего остального и два запасных.
Повторюсь, вы можете пройти процесс UNPHAT и все ещё решить использовать Hadoop или Spark. Это решение даже может быть верным. Важно то, чтобы вы действительно использовали правильный инструмент для работы. Google отлично это знает: как только они решили, что MapReduce не подходит для построения поискового индекса, они перестали его использовать.
Сначала поймите проблему
Мое сообщение не ново, но, может быть, эта версия донесет до вас мысль или вы хорошо запомните UNPHAT. Если нет, попробуйте посмотреть выступление Рича Хики Hammock Driven Development, или почитать How to Solve It Поля, или пройти курс Хэмминга The Art of Doing Science and Engineering. Мы все побуждаем вас думать! И действительно понять проблему, которую вы пытаетесь решить. Как сказал Поля:
Глупо отвечать на вопрос, который ты не понимаешь. Грустно работать над тем, чего ты не хочешь.
https://www.youtube.com/watch?v=f84n5oFoZBc