Когда, играя в ту или иную RPG, я оказываюсь в библиотеке, то обязательно перечитываю все книги на полках, чтобы лучше вникнуть во вселенную игры. Помнит кто-нибудь «Краткую историю империи» в Morrowind?

Большие данные (Big Data) и, в частности, экосистема Hadoop появились немногим более 15 лет назад и развились к сегодняшнему дню так, как мало кто мог тогда предположить.

Ещё только появившись, опенсорсный Hadoop сразу стал популярным инструментом для хранения и управления петабайтами данных. Вокруг него сформировалась обширная и яркая экосистема с сотнями проектов, и он до сих пор используется многими крупными компаниями, даже на фоне современных облачных платформ. В текущей статье я опишу все эти 15 лет¹ эволюции экосистемы Hadoop, расскажу о её росте в течение последнего десятилетия, а также о последних шагах в развитии сферы больших данных за последние годы.

Так что пристегнитесь и настройтесь на путешествие во времени вглубь 20 последних лет, поскольку наша история начинается в 2003 году в маленьком городке к югу от Сан-Франциско…

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

2003–2006: начало

Появились в 2003: iTunes, Android, Steam, Skype, Tesla. Появились в 2004: The Facebook, Gmail, Ubuntu, World of Warcraft. Появились в 2005: YouTube, Reddit. Появились в 2006: Twitter, Blu-ray, Waze, Oblivion. (фото Robert Anderson)

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

1. Как разместить сотни терабайт данных на тысячах дисков, установленных в более, чем тысяче машин, без даунтаймов, потери информации и с сохранением её постоянной доступности?
2. Как распараллелить вычисление эффективным и отказоустойчивым способом для обработки всех этих данных на всех машинах?

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

С 2003 по 2006 годы Google выпустили три исследовательские работы, объясняющие внутреннюю архитектуру данных. Эти работы навсегда изменили индустрию Big Data. Первая вышла в 2003 году под названием “The Google File System”. Вторая последовала за ней в 2004 году и называлась “MapReduce: Simplified Data Processing on Large Clusters”. Согласно Google Scholar, с тех пор её процитировали более 21 000 раз. Третий научный труд вышел в 2006 году и назывался “Bigtable: A Distributed Storage System for Structured Data”.

И пусть даже эти работы оказали решающее влияние на появление Hadoop, сама компания Google к этому появлению отношения не имела, поскольку хранила свой исходный код закрытым. Но за всем этим стоит очень интересная история, и если вы не слышали о Джеффе Дине и Санджае Гемавате, то вам определённо стоит почитать эту статью из New Yorker.

Тем временем основатель Hadoop, сотрудник компании Yahoo! Дуг Каттинг, на тот момент уже разработавший Apache Lucene (поисковая библиотека, лежащая в основе Apache Solr и ElasticSearch), работал над проектом сильно распределённого поискового модуля под названием Apache Nutch. Подобно Google, этот проект для достижения широкого масштаба нуждался в распределённом хранилище и серьёзных вычислительных возможностях. Прочитав работы Google по Google File System и MapReduce, Дуг осознал ошибочность своего текущего подхода, а описанная в тех работах архитектура вдохновила его на создание в 2005 году дочернего проекта для Nutch, который в честь игрушки (жёлтого слона) своего сына он назвал Hadoop.

Этот проект начался с двух ключевых компонентов: распределённой файловой системы Hadoop (HDFS) и реализации фреймворка MapReduce. В отличие от Google, компания Yahoo! решила открыть исходный код проекта в рамках Apache Software Foundation. Тем самым они пригласили все остальные ведущие компании к его использованию и участию в развитии, чтобы сократить технологическое отставание от своих соседей (Yahoo! расположена в Саннивейле рядом с Маунтин-Вью). Как мы дальше увидим, следующие несколько лет превзошли все ожидания. Естественно, и в Google за это время тоже добились многого.

2007–2008: первые соорганизаторы и пользователи Hadoop

Появились в 2007: iPhone, Fitbit, Portal, Mass Effect, Bioshock, The Witcher. Появились в 2008: Apple App Store, Android Market, Dropbox, Airbnb, Spotify, Google Chrome. (Фото Leonardo Ramos)

Довольно скоро другие компании, начав использовать Hadoop, столкнулись с аналогичными проблемами обработки больших объёмов данных. В те времена это означало огромные обязательства, поскольку им требовалось организовать и самостоятельно управлять кластерами машин, а написание задачи MapReduce явно не представлялось лёгкой прогулкой. Попытка Yahoo! уменьшить сложность программирования этих задач реализовалась в виде Apache Pig, ETL-инструмента, способного переводить собственный язык Pig Latin в шаги MapReduce. Однако вскоре к развитию этой новой экосистемы подключились и другие.

В 2007 году молодая быстро растущая компания Facebook, под началом 23-летнего Марка Цукерберга, выпустила в открытый доступ два новых проекта под лицензией Apache: Apache Hive и через год Apache Cassandra. Apache Hive – это фреймворк, способный преобразовывать SQL-запросы в задачи MapReduce для Hadoop. При этом Cassandra является обширным столбцовым хранилищем, предназначенным для широкомасштабного распределённого доступа к контенту и его обновления. Это хранилище не требовало для своей работы Hadoop, но вскоре, когда были созданы коннекторы для MapReduce, стало частью этой экосистемы.

В то же время менее известная компания Powerset, работавшая над поисковым движком, вдохновилась работой Google по Bigtable и разработала Apache Hbase, ещё одно столбцовое хранилище, опирающееся на HDFS. Вскоре после этого Powerset была поглощена корпорацией Microsoft, которая запустила на её основе новый проект под названием Bing.

Кроме всего прочего, на быстрое внедрение Hadoop решительно повлияла ещё одна компания – Amazon. Запустив Amazon Web Services, первую облачную платформу с доступом к ресурсам по требованию, и быстро добавив поддержку MapReduce через сервис Elastic MapReduce, эта компания позволила стартапам с удобством хранить свои данные в S3, распределённой файловой системе, а также развёртывать и выполнять в ней задачи MapReduce, исключая лишнюю возню с кластером Hadoop.

2008–2012: рост числа вендоров Hadoop

Появились в 2009: Bitcoin, Whatsapp, Kickstarter, Uber, USB 3.0. Появились в 2010: iPad, Kindle, Instagram. Появились в 2011: Stripe, Twitch, Docker, Minecraft, Skyrim, Chromebook. (фото Spencer Davis)

Основной болью при использовании Hadoop были невероятные усилия, требовавшиеся для настройки, мониторинга и поддержки кластера. Первый вендор услуг Hadoop под названием Cloudera появился в 2008 году и вскоре был выкуплен Дугом Каттингом. Cloudera предлагала готовый дистрибутив Hadoop, который назывался CDH, а также интерфейс для мониторинга кластеров Cloudera Manager, который, наконец, упростил установку и управление кластерами и сопутствующим ПО вроде Hive и HBase. С той же целью вскоре были основаны компании Hortonworks и MapR. Хранилище Cassandra также получило своего вендора Datastax, который появился в 2010 году.

Спустя некоторое время все участники рынка пришли к согласию, что несмотря на удобство Hive в качестве SQL-инструмента для управления огромными ETL-пакетами, он плохо подходит для интерактивной и бизнес-аналитики (BI). Все, кто привык к стандартным БД на языке SQL, ожидает от них возможности сканировать таблицы с тысячами строк в течение считаных миллисекунд. Hive же требовал для этой операции минуты (так происходит, когда ты просишь слона проделать мышиную работу).

Это послужило началом SQL-войны, которая не затихает по сей день (хотя далее мы увидим, что с тех пор на арене появились и другие участники). В очередной раз Google косвенно оказала решающее влияние на мир больших данных, выпустив в 2010 году четвёртую исследовательскую работу под заголовком “Dremel: Interactive Analysis of Web-Scale Datasets”. В ней описывались две основных инновации:

1. Архитектура распределённых интерактивных запросов, вдохновившая появление большинства интерактивных SQL-инструментов, о которых будет сказано ниже.
2. Форма столбцового хранилища, которая легла в основу нескольких новых форматов хранения данных, таких как Apache Parquet, совместно разработанного Cloudera и Twitter, и Apache ORC, выпущенного Hortonworks совместно с Facebook.

Вдохновлённая работой по Dremel, компания Cloudera в стремлении решить проблему высокой задержки в Hive и оторваться от конкурентов в 2012 году решила запустить новый открытый SQL-движок для интерактивных запросов под названием Apache Impala. Параллельно с этим MapR запустила собственный опенсорсный интерактивный движок, назвав его Apache Drill. А вот руководство Hortonworks, вместо создания нового движка с нуля, предпочло заняться ускорением работы Hive, запустив проект Apache Tez, некое подобие версии 2 для MapReduce, и адаптировав Hive под выполнение Tez вместо MapReduce. В основе этого решения лежало две причины: во-первых, компания располагала меньшим ресурсом сотрудников, чем Cloudera, а во-вторых, большинство её клиентов уже использовали Hive и предпочли бы ускорить его работу, а не переходить на иной SQL-движок. Как мы дальше узнаем, вскоре появилось множество других распределённых механизмов, и новым слоганом стало «Всё быстрее Hive».

2010–2014: Hadoop 2.0 и революция Spark

Появились в 2012: UHDTV, Pinterest, Facebook reaches 1 billion active users, Gagnam Style video reaches 1 billion views on Youtube. Появились в 2013: Edward Snowden leaks NSA files, React, Chromecast, Google Glass, Telegram, Slack. (фото Lisa Yount on Unsplash)

В то время как Hadoop укреплял свои позиции и был занят внедрением нового ключевого компонента YARN для управления ресурсами, с чем ранее неуклюже справлялся MapReduce, началась небольшая революция, связанная с резким ростом популярности Apache Spark. Стало очевидно, что Spark окажется отличной заменой MapReduce ввиду более широких возможностей, простого синтаксиса и высокого быстродействия, которое, в частности, обуславливалось его способностью кэшировать данные в ОЗУ. Единственным слабым местом в сравнении с MapReduce в первое время была нестабильность Spark, но эта проблема по мере развития продукта была решена.

Этот инструмент также имел высокую операционную совместимость с Hive, поскольку SparkSQL основывался на синтаксисе Hive (в действительности изначально разработчики Spark позаимствовали у Hive лексер и парсер), что существенно упрощало переход с Hive на SparkSQL. Вдобавок к этому — Spark привлёк обширное внимание в мире машинного обучения, так как прежние попытки писать алгоритмы МО через MapReduce, например, Apache Mahout, явно проигрывали реализациям Spark.

Для поддержки и монетизации быстрого роста Spark его создатели в 2013 году запустили Databricks. Целью этого проекта стало предоставление каждому возможности обработки огромных объёмов данных. Для этого платформа реализовала простые и эффективные API на многих языках (Java, Scala, Python, R, SQL и даже .NET), а также нативные коннекторы для многих источников и форматов данных (csv, json, parquet, jdbc, avro, etc.). Интересно здесь то, что рыночная стратегия Databricks отличалась от стратегий предшественников. Вместо предложения локального развёртывания Spark, компания заняла позицию исключительно облачной платформы, изначально интегрировавшись с сервисом AWS (который на тот момент являлся самым популярным облаком), а затем с Azure и GCP. Девять лет спустя, можно уверенно сказать, что это был грамотный ход.

Тем временем для обработки потоковых событий появлялись новые открытые проекты вроде Apache Kafka, распределённой очереди сообщений, разработанной LinkedIn, и Apache Storm ³, движка распределённых потоковых вычислений от Twitter. Оба инструмента вышли в 2011 году. В тот же период платформа Amazon Web Services достигла небывалой популярности и успеха: это можно продемонстрировать одним только резким скачком развития Netflix в 2010 году, ставшим возможным преимущественно благодаря облаку Amazon. В облачной сфере начала зарождаться конкуренция. Сначала в 2010 году появился сервис Microsoft Azure, следом за которым в 2011 родилась Google Cloud Platform (GCP).

2014–2016: достижение апогея

Появились в 2014: Terraform, Gitlab, Hearthstone. Started in 2015: Alphabet, Discord, Visual Studio Code. (Фото Wilfried Santer)

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

Также начали появляться и более высокоуровневые проекты вроде Apache Apex (закрыт) или Apache Beam (в основном продвигаемый Google), нацеленные на предоставление унифицированного интерфейса для обработки пакетных и потоковых процессов поверх различных распределённых бэкендов, таких как Apache Spark, Apache Flink или Google DataFlow.

Также можно упомянуть, что на рынок, наконец, начали поступать хорошие опенсорсные планировщики — спасибо Airbnb и Spotify. Использование планировщика обычно привязано к бизнес-логике корпорации, и пишется это ПО вполне естественно без особой сложности, как минимум поначалу. Затем ты всё же понимаешь, что очень трудно сохранять его простым и понятным для других. Именно поэтому практически все крупные технологические компании написали собственные, а иногда и открытые, продукты: Yahoo! — Apache Oozie, LinkedIn — Azkaban, Pinterest — Pinball (закрыт) и многие другие.

Однако ни одно из этих решений так и не было признано лучшим, в связи с чем большинство компаний придерживались собственных. К счастью, где-то в 2015 году Airbnb запустили открытый проект Apache Airflow, а Spotify – Luigi⁴. Это были два планировщика, которые быстро завоевали интерес и были приняты на вооружение многими компаниями. В частности, Airflow сейчас в режиме SaaS доступен на Google Cloud Platform и Amazon Web Services.

Со стороны SQL тоже возникло несколько распределённых хранилищ данных, нацеленных на предоставление возможности ускоренной обработки запросов в сравнении с Apache Hive. Мы уже говорили о Spark SQL и Impala, но также стоит упомянуть Presto, открытый проект, запущенный Facebook в 2013 году. В 2016 году этот проект компания Amazon в рамках своего предложения SaaS переименовала в Athena, а когда его начальные разработчики покинули Facebook, то они сделали отдельный форк, который назвали Trino.

В то же время появилось и несколько проприетарных распределённых хранилищ для аналитики, к которым можно отнести Google BigQuery (2011), Amazon Redshift (2012) и Snowflake (2012).

Полный список всех проектов, числящихся как часть экосистемы Hadoop, можно найти на этой странице.

2016–2020: на смену Hadoop приходит контейнеризация и глубокое обучение

Появились в 2016: Occulus Rift, Airpods, Tiktok. Появились в 2017: Microsoft Teams, Fortnite. Появились в 2018: GDPR, Cambridge Analytica scandal, Among Us. Появились в 2019: Disney+, Samsung Galaxy Fold, Google Stadia (фото Jan Canty)

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

Первым трендом стало массовое перемещение инфраструктур данных в облако, при котором HDFS оказалась заменена облачными хранилищами вроде Amazon S3, Google Storage и Azure Blob Storage.

Вторым трендом была контейнеризация. Вы наверняка слышали о Docker и Kubernetes. Docker – это фреймворк контейнеризации, который вышел в 2011 году и с 2013 начал резко набирать популярность. В июне 2014 Google выпустили открытый инструмент для оркестрации контейнеров под названием Kubernetes (он же K8s), который тут же взяли на вооружение многие компании для построения новых распределённых/масштабируемых архитектур. Docker и Kubernetes позволили развёртывать новые виды таких архитектур, уже более стабильные, надёжные и пригодные для множества случаев, включая событийно-ориентированные преобразования в реальном времени. Hadoop потребовалось время, чтобы поспеть за Docker, и поддержка запуска в нём контейнеров появилась лишь в версии 3.0 в 2018 году.

Третьим трендом, как уже говорилось, стало появление полностью управляемых распараллеленных хранилищ для аналитики на базе SQL. Этот момент хорошо демонстрируется формированием “Современного дата-стека” и выходом в 2016 году инструмента командной строки dbt.

Наконец, четвёртым трендом, повлиявшим на Hadoop, стало развитие глубокого обучения. Во второй половине 2010-х все уже слышали о глубоком обучении и искусственном интеллекте. AlphaGo обозначила знаковый момент, победив Ке Джи, мирового чемпиона по игре в Го, аналогично тому, как за двадцать лет до этого программа IBM Deep Blue превзошла чемпиона по шахматам, Гарри Каспарова. Этот технологический скачок, который уже творил чудеса и обещал ещё большее – например, автономные автомобили – зачастую был связан с большими данными, поскольку модели ИИ требовали для своего обучения обработки огромных объёмов информации. Однако Hadoop и МО являлись слишком разными и подружить эти технологии было трудно. По факту глубокое обучение указало на потребность в новых подходах для обработки больших данных и подтвердило, что Hadoop не является универсальным инструментом.

Поясню вкратце: учёные по данным, работающие с глубоким обучением, нуждались в двух вещах, которые экосистема Hadoop им предоставить не могла. Во-первых, им нужны были GPU, коих в узлах кластеров Hadoop обычно не было. Во-вторых, учёным требовались последние версии библиотек для глубокого обучения, таких как TensorFlow и Keras, установить которые на весь кластер было проблематично, особенно когда многие пользователи просили разные версии одной библиотеки. Эту конкретную проблему отлично решал Docker, но интеграция этого инструмента в Hadoop требовала времени, а ждать аналитики данных были не готовы. В связи с этим они обычно предпочитали вместо использования кластера запускать одну мощную виртуальную машину с 8 GPU.

Именно поэтому, когда Cloudera в 2017 году сделала своё первое публичное размещение акций (IPO), компания уже занималась разработкой и распространением новейшего продукта, Data Science Workbench. Это решение основывалось уже не на Hadoop или YARN, а на контейнеризации с помощью Docker и Kubernetes, позволяя учёным по данным развёртывать модели в собственной среде в виде контейнеризованного приложения без риска для безопасности и стабильности.

Но для возвращения рыночного успеха этого оказалось недостаточно. В октябре 2018 года Hortonworks и Cloudera претерпели слияние, и остался только бренд Cloudera. В 2019 MapR была куплена Hewlett Packard Enterprise (HPE), а в октябре 2021 частная инвестиционная фирма CD&R приобрела Cloudera по стоимости акций ниже изначальной.

Хотя угасание Hadoop не означает полную кончину всей экосистемы, поскольку многие крупные компании по-прежнему её используют, особенно для локальных развёртываний. Используют её и многие решения, построенные вокруг этой технологии или её частей. При этом также внедряются инновации, например, Apache Hudi, выпущенный компанией Uber в 2016 году, Apache Iceberg, запущенный Netflix в 2017, и открытый продукт Delta Lake, который разработчики Databricks представили в 2019.

Интересно, что одной из основных целей этих новых форматов хранения было обойти следствия первого описанного тренда. Hive и Spark изначально создавались для HDFS, и некоторые элементы быстродействия, гарантированные этой файловой системой, при переходе в облачные хранилища вроде S3 были утрачены, что привело к падению эффективности. Но я здесь не буду вдаваться в детали, так как для этого потребовалась бы целая статья.

2020–2023: современность

Появилась в 2020: пандемия COVID-19. Появились в 2021: уязвимость Log4Shell, Meta, Dall-E. Появились в 2022: Midjourney, Stable Diffusion. (фото Jonathan Roger)

В настоящее время облачные развёртывания Hadoop уже в основном заменены приложениями Apache Spark или Apache Beam ⁵ (преимущественно на GCP) в пользу Databricks, Amazon Elastic Map Reduce (EMR), Google Dataproc/Dataflow или Azure Synapse. Я также видел, как многие молодые компании стремятся использовать «Современный дата стек», построенный вокруг хранилищ для аналитики, таких как BigQuery, Databricks-SQL, Athena или Snowflake, сопряжённых с бескодовыми (или малокодовыми) инструментами доставки данных и организованных с помощью dbt, исключая потребность в решениях для распределённых вычислений вроде Spark.

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

По мере развития индустрии данных появлялось всё больше инструментов для управления и каталогизации. В этом отношении стоит упомянуть опенсорсные решения вроде Apache Atlas, выпущенного Hortonworks в 2015 году, Amundsen, открытого компанией Lyft в 2019, и DataHub, который LinkedIn открыла в 2020. Немало в этом сегменте возникло и закрытых стартапов.

Новые компании также строились и вокруг последних технологий реализации планировщика. Здесь можно назвать Prefect, Dagster и Flyte, которые запустили свои открытые репозитории в 2017, 2018 и 2019 годах соответственно и сегодня уже бросают вызов царящему превосходству Airflow.

Наконец, начала формироваться концепция Lakehouse. Lakehouse представляет собой платформу, совмещающую преимущества озера данных и хранилища данных⁶. Это позволяет учёным по данным и бизнес-аналитикам работать в рамках одной платформы, упрощая управление, обмен информацией, а также повышая безопасность. Активнее всех в этом сегменте себя проявила компания Databricks благодаря совместимости Spark как с SQL, так и с DataFrames. За ней последовало предложение Snowpark от Snowflake, затем Azure Synapse от Microsoft и пока самой последней подключилась корпорация Google, запустив BigLake. Если же смотреть в сторону опенсорса, то здесь с 2017 года аналогичную платформу предлагает Apache Dremio.

2023: кто предскажет ближайшее будущее?

Появится в 2023: кто знает? (фото Annie Spratt)

С самого начала истории Big Data количество открытых проектов и стартапов год за годом лишь продолжало расти (только оцените масштабы этой индустрии в 2021). Я помню, как в районе 2012 года звучали прогнозы, что новые SQL-войны закончатся и объявятся истинные их победители. Пока что этого не произошло, и сложно прогнозировать, как ситуация будет развиваться дальше. Потребуется ещё не один год, чтобы осела вся поднятая пыль. Хотя если всё же пытаться строить догадки, то я бы спрогнозировал следующее:

1. Как уже говорили другие, основные платформы данных (Databricks, Snowflake, BigQuery, Azure Synapse) продолжат совершенствоваться и добавлять новые возможности для восполнения пробелов между друг другом. Я ожидаю увидеть всё бо́льшую связность компонентов, в том числе между языками для обработки данных вроде SQL и Python.
2. В течение пары следующих лет может замедлиться появление новых проектов и компаний, хотя причиной тому скорее станет недостаток финансирования после взрыва очередного пузыря доткомов (если такой вообще произойдёт), чем недостаток желания или идей.
3. С самого начала наиболее дефицитным ресурсом являлись квалифицированные кадры. Это означает, что для большинства компаний⁷ проще вложить дополнительные средства в решение проблем производительности или перейти на более рентабельные продукты, чем тратить лишнее время на оптимизацию. Особенно это актуально теперь, когда стоимость услуг распределённых хранилищ стала столь низкой. Но, возможно, в какой-то момент вендорам станет сложно продолжать ценовое соперничество путём демпинга, и цены пойдут вверх. Хотя даже в этом случае объём сохраняемых бизнесом данных продолжает год за годом расти, а с ним и сопутствующие финансовые потери из-за неэффективности. Быть может, однажды возникнет тенденция, по которой люди начнут искать новые, более дешёвые, опенсорсные альтернативы, что приведёт к возрождению нового витка Hadoop-технологий.
4. В долгосрочной же перспективе, на мой взгляд, реальными победителями окажутся облачные провайдеры Google, Amazon и Microsoft. Для этого им достаточно просто подождать и оценить, в каком направлении дует ветер, после чего в удачный момент приобрести (или просто воссоздать) наиболее оптимальные технологии. Каждый инструмент, интегрируемый в их облако, существенно упрощает жизнь пользователей, особенно когда дело касается безопасности, руководства, контроля доступа и управления расходами. И при условии отсутствия в процессе серьёзных организационных ошибок я не вижу для этих компаний реальных конкурентов.

Заключение

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

В заключение хочу подчеркнуть, что человеческие знания и технологии в сфере ИИ и больших данных никак не смогли бы продвинуться столь быстро без магической силы опенсорса и обмена информацией. Мы должны быть признательны основателям Google, которые изначально поделились своим опытом через исследовательские работы, а также всем компаниям, раскрывшим исходный код своих проектов. Открытый и бесплатный (или хотя бы дешёвый) доступ к технологии на протяжении последних 20 лет являлся мощнейшим стимулом инноваций в сфере интернета. Реальный бум развития программного обеспечения начался с 1980-х годов, когда люди смогли позволить себе домашние компьютеры. То же можно сказать и о 3D-печати, которая существовала несколько десятилетий и начала набирать обороты только в 2000-х с появлением самовоспроизводящихся машин, или о выпуске одноплатных компьютеров Raspberry Pi, подхлестнувших движение DIY.

Открытый и удобный доступ к знаниям всегда должен поощряться и отстаиваться, причём даже в большей степени, чем это происходит сейчас. Война за эти принципы никогда не стихает. И одно из, возможно, наиболее важных её сражений, разворачивается сегодня в сфере ИИ. Крупные компании делают свой вклад в опенсорс (например, Google представили TensorFlow), но они также научились использовать открытое ПО как венерины мухоловки, заманивая пользователей в свои проприетарные системы и оставляя наиболее важный (и сложный для воссоздания) функционал под защитой патентов.

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

«Делай, что должен, и свершится, чему суждено» — Марк Аврелий

▍ Сноски

1. Получится даже 20 лет, если посчитать предысторию Google. Отсюда и заголовок статьи. ↩

2. В 2022 мы, пожалуй, уже добились достаточного прогресса в надёжности аппаратного обеспечения, чтобы не так сильно озадачиваться подобным нюансом, но 20 лет назад он определённо доставлял серьёзные неудобства. ↩

3. В 2016 Twitter выпустил на замену Apache Storm Apache Heron (всё ещё находится на стадии инкубации Apache). ↩

4. В 2022 разработчики Spotify решили прекратить использование Luigi и перешёл на Flyte. ↩

5. Подозреваю, что Apache Beam используется в основном на GCP с DataFlow. ↩

6. Как это преподносят в Databricks, Lakehouse совмещает в себе гибкость, высокую рентабельность и масштабность озёр данных с управлением данными и ACID-транзакциями хранилищ. ↩

7. Естественно, я не говорю здесь о компаниях размером с Netflix или Uber. ↩