Промышленное производство
Промышленный Интернет вещей | Промышленные материалы | Техническое обслуживание и ремонт оборудования | Промышленное программирование |
home  MfgRobots >> Промышленное производство >  >> Industrial Internet of Things >> Интернет вещей

Smart Talk Эпизод 8: Раскрытие инсайтов в реальном времени на Data Lakehouse

Data lakehouse стал гибким, многоцелевым репозиторием. В этом эпизоде Smart Talk Динеш Чандрасекар, CEO Stratola, и его гость Джастин Боргман, CEO и Chairman Starburst, обсуждают, как расширить возможности data lakehouse для включения данных в реальном времени и высокопроизводительных запросов, которые могут обеспечивать почти инсайты в реальном времени — все более частый сценарий использования. Необходимы две ключевые технологии — Kafka streams и мощный движок запросов.

Особенно интересны их взгляды на важность open-source ПО и открытых форматов, что было подтверждено объявлением Snowflake и Databricks о поддержке Apache Iceberg. Джастин делится советом по бенчмаркингу решений — используйте свои корпоративные данные, запускайте реальные запросы, симулируйте масштаб и, наконец, рассчитывайте затраты.

Темы, охваченные в эпизоде:

Гость

Джастин Боргман, CEO и Chairman, Starburst

Джастин Боргман — эксперт во всем, что касается big data и аналитики. До основания Starburst он был вице-президентом и GM в Teradata (NYSE: TDC), где отвечал за портфолио Hadoop-продуктов компании. Джастин присоединился к Teradata в 2014 году через приобретение его компании Hadapt, где он был сооснователем и CEO. Hadapt создал «SQL on Hadoop», превратив Hadoop из файловой системы в аналитическую базу данных, доступную любому BI-инструменту. Он основал Starburst в 2017 году, стремясь дать аналитикам свободу анализировать разнообразные наборы данных где бы они ни находились, не жертвуя производительностью.

Ведущий

Динеш Чандрасекар — технологический евангелист, мыслительный лидер и опытный аналитик IT-индустрии. С почти 30-летним опытом, Динеш работал с B2B корпоративным ПО, а также SaaS-продуктами, доставляя и маркетируя сложные решения для клиентов со сложными архитектурами. Он также определял и выполнял высоко успешные GTM-стратегии для запуска нескольких высокоростных продуктов на рынке в различных компаниях вроде LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM и др. Он много говорит, ведет блог и кодит по выходным. Динеш имеет MBA от Santa Clara University и магистерскую степень в компьютерных приложениях от Университета Мадрас. Сейчас Динеш управляет своей компанией Stratola, фирмой по консалтингу бизнес-стратегий и full-stack маркетинговым сервисам, ориентированной на клиента.

Ресурсы

Smart Talk Эпизод 7: Кардинальность, контроль и затраты в наблюдаемости

Smart Talk Эпизод 6: AIOps и будущее IT-мониторинга

Smart Talk Эпизод 5: Дисaгрегация стека наблюдаемости

Smart Talk Эпизод 4: Данные в реальном времени и векторные базы данных

Smart Talk Эпизод 3: Современные конвейеры данных и LLM

Smart Talk Эпизод 2: Восхождение GenAI-приложений с Data-in-Motion

Smart Talk Эпизод 1: Ландшафт экосистемы Data-in-Motion

Посмотреть карту экосистемы data-in-motion здесь

Узнать больше о data-in-motion на RTInsights здесь

Транскрипт

Динеш Чандрасекар:

Приветствуем вас в этом эпизоде Smart Talk серии лидерства Data and Motion. Я ваш ведущий, Динеш Чандрасекар, главный аналитик и основатель Stratola. Наш гость сегодня — Джастин Боргман, CEO и председатель Starburst. Джастин имел блестящую карьеру в компаниях по безопасности и аналитике данных, и до основания Starburst в 2017 году он основал компанию Hadapt, которая позже была приобретена Teradata, где он служил VP и GM довольно много лет. Добро пожаловать, Джастин. Итак, начнем со Starburst, правда? Думаю, многие знают Starburst как бренд, но есть также немало людей, которые жаждут узнать немного больше о Starburst. Расскажите нам о Starburst, особенно об его происхождении и вашем стремлении основать компанию.

Джастин Боргман:

Да, с удовольствием. Как вы упомянули во введении, я в сфере аналитики данных уже около 15 лет, начиная с того первого стартапа, который был приобретен Teradata. Конечно, как, уверен, знает ваша аудитория, Teradata на протяжении многих десятилетий, честно говоря, был лидером в аналитике хранилищ данных. И эта модель действительно требовала перемещения всех ваших данных в проприетарную базу данных, которая была вашим корпоративным хранилищем данных. И оттуда вы могли запускать быструю аналитику и понимать свой бизнес. Думаю, что мы увидели возможность по сути перевернуть эту модель с ног на голову, особенно двумя способами. Номер один — возможность использовать открытые табличные форматы в data lake, давая вам производительность хранилища данных. Но в data lake, иногда это называют архитектурой lakehouse, а также возможность подключаться к другим источникам данных и соединять таблицы, живущие в другой базе данных, с таблицами в том data lake.

Так, например, у вас может быть база данных Oracle или SQL Server, и вы хотите соединить таблицу в одной из этих систем с таблицей в формате файла Iceberg в data lake. И это по сути то, что делает наша технология. Это базовая технология под названием Trino. Это open source проект. Он изначально родился в Facebook, и именно так многие из крупнейших интернет-компаний — LinkedIn, Airbnb, Netflix, Apple и др. — делают свою аналитику хранилищ данных. Опять же, в той модели, где data lake — центральный репозиторий, где они могут получить очень низкую стоимость владения, храня данные в этих data lakes, а также иметь возможность соединять другие таблицы. И так Starburst — это просто коммерциализация этого open source проекта. Мы предоставляем enterprise-версию Trino, которая имеет дополнительные функции безопасности, дополнительные коннекторы, дополнительные выгоды производительности и целый ряд других фич и функциональности.

Динеш Чандрасекар:

Спасибо. И я определенно хочу немного глубже погрузиться в Trino и Iceberg и все это. Думаю, это все отличные темы для сегодня, но могу ли я отступить немного и спросить вас об эволюции архитектур данных, у нас были традиционные базы данных, затем появились хранилища данных, и с взрывом данных и потребностью в обработке большего количества данных в реальном времени появились lakehouse-архитектуры и другие. Так в вашем мире, глядя на эволюцию архитектур данных, data lakehouse, и в вашем случае, я думаю, у вас есть концепция Icehouse, как это повлияло на способность организаций эффективно обрабатывать данные в реальном времени?

Джастин Боргман:

Отличный вопрос. И просто для уточнения вашим слушателям, концепция icehouse — это просто lakehouse на базе Iceberg. Данные хранятся в формате таблицы Iceberg, и вы можете делать аналитику в стиле хранилища данных поверх этого. Чистый результат обеспечивает действительно низкую общую стоимость владения, а также способность обрабатывать данные, близкие к реальному времени, как вы описали. И то, как мы об этом думаем, мы видим огромный рост количества стриминговых технологий данных на рынке, как Kafka, например, где клиенты все чаще используют это для стриминга данных в near real time в data lake.

И с нашей точки зрения, именно там мы хотим это подхватить. Мы построили то, что называем streaming ingest, где вы можете подключиться к Kafka-стриму, и мы автоматически превратим это в Iceberg-таблицы и сделаем их доступными для запросов почти мгновенно. Так что это действительно позволяет бизнесу теперь иметь гораздо более быстрые свежие инсайты по своим данным как результат этой архитектуры.

Динеш Чандрасекар:

Спасибо. Так что Lakehouse определенно обещает быть очень унифицированным архитектурным подходом для batch и real-time аналитики. Можем ли мы сказать, что, я имею в виду, как вы видите этот архитектурный сдвиг, трансформирующий BI и традиционное принятие решений по отраслям сегодня? Как это изменилось?

Джастин Боргман:

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

И так этот data lake дает вам большую гибкость, потому что вы используете открытые форматы, что позволяет клиенту выбирать, какой движок правильный для доступа к моим данным. Это дает вам много гибкости, снижает lock-in, но также позволяет хранить ваши данные в действительно недорогом commodity-хранилище, что в контексте облака все чаще является S3 или Google GCS или Azure Data Lake storage. И даже в on-prem мире мы видим S3-совместимое объектное хранилище от компаний вроде Dell или IBM или что у вас там, где вы можете в основном получить S3. Так что это становится своего рода общим фундаментальным слоем для хранения данных очень, очень эффективно по стоимости, и это часть того, что движет этой трансформацией.

Динеш Чандрасекар:

Хорошо, давайте теперь, возможно, займемся, теперь, когда я думаю, что это как раз весь драйвер за вашим предложением, оно набрало популярность за годы как очень мощный движок запросов в пространстве realtime данных. Как вы видите его роль, эволюционирующую в современной экосистеме данных? Особенно как вы упоминали, есть другие open source технологии вроде Apache Iceberg, которые также предлагают много интероперабельности между разными системами данных и так далее. Так как это в сочетании с комбинацией некоторых других open source технологий меняет современную экосистему данных?

Джастин Боргман:

Думаю, это становится своего рода Postgres для хранилищ данных. Postgres, конечно, широко развернутая, экстремально популярная open source база данных. Это традиционный R-D-B-M-S single node. Trino — это своего рода MPP (massively parallel processing) эквивалент хранилищ данных аналитики. И так для ваших big data, для ваших хранилищ данных стиля активностей, это теперь становится де-факто open source выбором.

Иногда люди спрашивают, ну, а что насчет Spark в сравнении? Spark — отличный general-purpose processing движок, но не действительно оптимизирован для SQL аналитики. И я думаю, к вашей точке ранее о бизнес-интеллекте и принятии решений, SQL все еще является языком тех типов сценариев использования, будь то подключение BI-инструмента, запуск отчетности или даже построение data-driven приложений, SQL продолжает быть действительно важным языком для интерфейса, и Trino — номер один движок для этого на рынке сегодня.

Когда вы объединяете это с чем-то вроде Iceberg, как вы сказали, у вас теперь есть полное хранилище данных по сути. У вас есть часть query engine, у вас есть часть storage, и теперь у вас есть полное open data warehouse. Они также могут запускаться где угодно, могут запускаться on-prem, могут запускаться в облаке. Так что у вас есть много гибкости с этим стеком.

Динеш Чандрасекар:

Могу ли я задать небольшой отвлеченный вопрос? Поскольку вы упомянули SQL как своего рода go-to для многих из этих хранилищ данных в наши дни, и я верю, что за последние 30, 40 лет ничего не смогло это потрясти наверняка, но с приходом gen AI технологий и обработки естественного языка везде, люди теперь могут говорить о демократизации данных, где вы теперь распределяете это даже бизнес-аналитикам, у которых, вероятно, нет равных знаний, но могут использовать естественный язык, чтобы сказать, получи мне последние три месяца продаж в этом конкретном регионе и так далее.

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

Джастин Боргман:

Это действительно отличный вопрос, и я думаю, вы на чем-то наступили. Думаю, постепенно со временем, я думаю, генеративный ИИ как интерфейс станет супер-популярным, потому что, к вашей точке, он своего рода упрощает это для кого угодно, честно говоря, для использования. Так что теперь это больше Google-подобный опыт на всех данных в предприятии, и это очень вдохновляюще. Фактически, мы включили раннюю версию этого в наш собственный продукт, и я думаю, все будут, это станет table stakes.

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

Динеш Чандрасекар:

Более легкий доступ к данным, определенно наверняка. Думаю, это то, куда мы направляемся. Так что определенно вдохновляющее пространство. Так что мы говорили о Trino. Могу ли я сменить тему и спросить вас об Iceberg снова? Это становится очень, очень популярным. Я вижу более крупных гигантов в индустрии начинающих принимать iceberg как очень естественный способ сказать, мы интероперабельны, мы поддерживаем это, и так далее. Так как организации все чаще принимают real-time аналитику, какая роль iceberg в обеспечении более эффективного и масштабируемого управления данными? Какое ваше мнение об этом?

Джастин Боргман:

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

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

Они владеют этим, и это значит, что они могут играть движки друг против друга. Они могут сказать, ок, Starburst сделает эту рабочую нагрузку, которая даст мне лучшую стоимость/производительность для этого. Может быть, Snowflake лучше для этой рабочей нагрузки. Может быть, Databricks лучше для той рабочей нагрузки, и у клиента есть выбор между этими движками, что удивительно. Когда движки конкурируют, вы выигрываете как клиент, и я думаю, это именно то, что Iceberg делает доступным.

Динеш Чандрасекар:

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

Джастин Боргман:

Именно.

Динеш Чандрасекар:

Джастин, почему бы нам не поговорить о примере клиента здесь, потому что Trino и Iceberg в центре разговора сегодня, расскажите нам о, может быть, клиентском case study, где вы видели это практически поставлено в использование и какие виды выгод они увидели, приняв Trino и Iceberg?

Джастин Боргман:

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

В случае Comcast, очень традиционное on-prem хранилище данных. В случае DoorDash, я бы назвал это очень традиционным облачным хранилищем данных. И в любом случае, то, что они в конечном счете пытаются сделать — получить лучший TCO на своей SQL-аналитике и обеспечить гибкость работы с последними передовыми технологиями, которые могут интерфейситься от этого одного общего формата.

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

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

Динеш Чандрасекар:

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

Джастин Боргман:

Так что есть концепция версионирования и time travel и возможность как бы увидеть, как данные эволюционировали внутри нашей платформы. Мы также добавили data lineage, метрики качества данных, которые мы можем захватить и представить нашим пользователям, так что вы можете действительно понять, откуда пришли эти данные, как они эволюционировали, как они итерировались и предоставить эту видимость снова в конечном счете конечному пользователю.

Динеш Чандрасекар:

Хорошо. Тогда с Trino, вы говорили о том, как вы можете объединять разнородные источники данных и делать некоторые joint querying и все это. Архитектура движется больше в сторону централизованного источника данных или хранилища данных, или это оставляет их там, где они есть, но предоставляет способность объединять их и давать видимость для потребителей? Какая in-state архитектура мы смотрим здесь?

Джастин Боргман:

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

Может быть, это exploratory аналитика. У меня просто гипотеза, которую я хочу пойти протестировать, что, я думаю, может быть действительно большим для нашего бизнеса, но я не хочу разрабатывать все ETL-пайплайны и проходить через весь этот процесс просто для идеи, просто для догадки, которую у меня есть. Что ж, это отличный сценарий использования, где возможность соединить таблицу, живущую где-то еще, с тем, что у вас есть, является game changer. Это может на самом деле позволить вам пойти протестировать эту гипотезу за минуты вместо недель, чтобы заставить команды переместить данные так, как вам нужно. И так я думаю, оба ценны, но мы думаем об этом как большинство в lake и затем выходя за пределы этого lake — это то, как мы об этом думаем.

Динеш Чандрасекар:

Так что если я стороннее предприятие, которое, скажем, ищет современную платформу данных, какие некоторые критические соображения производительности я хотел бы иметь в своем чек-листе, когда я смотрю на Trino против кучи других альтернатив? Тогда мой приоритет — скажем, обработка real-time данных запросов, убедиться, что есть низкая задержка и вещи вроде того. Так что это мои требования. Какие некоторые соображения, которые я хотел бы иметь в своем чек-листе?

Джастин Боргман:

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

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

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

И это где я думаю, также есть большая выгода от использования open source технологий вроде Trino, которые были доказаны на самом большом воображаемом масштабе, как Apple запускает это безумным масштабом, очевидно, Facebook безумным масштабом. Так что эта вещь может работать. Она работает на том масштабе. Это должно дать вам некоторое спокойствие. Но даже все равно, я бы сказал, симулируйте это сами в своем собственном процессе бенчмаркинга, чтобы действительно убедиться, что эти разные технологии будут удовлетворять потребности, которые у вас есть в production. Круто.

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

Динеш Чандрасекар:

Согласен. Думаю, этоmajor чек-лист пункт для многих людей, оценивающих решения там наверняка. Так что, может быть, давайте доведем это к закрытию с точки зрения трендов. Я просто хочу спросить, происходит много в data пространстве сегодня, верно? Есть data warehouse вендоры, lakehouse вендоры, data lake вендоры, и несколько альтернатив, real-time analytics базы данных и так далее.

Выбор определенно широк и запутан для покупателя. Так что с точки зрения emerging trends, видите ли вы какой-то вид конвергенции, когда речь идет о real-time обработке данных, data lakehouse архитектурах, о которых мы только что говорили, и open source экосистеме в целом? Есть ли какой-то вид конвергенции, который вы видите происходящим, который сделает это более понятным для покупателя в ближайшем будущем?

Джастин Боргман:

Я вижу. Думаю, мы начинаем видеть очень популярные паттерны появляющимися очень часто в наши дни, эти паттерны исходят в интернете, у гиперскейлеров, а затем переводятся в предприятие со временем. И думаю, мы сейчас в той точке, где это делает свой путь в предприятие. И паттерны, которые я вижу — использование технологий вроде Kafka для стриминговой части. И конечно у вас есть множественный выбор там. Вы можете сделать Confluent, вы можете сделать Amazon версию. У вас есть выбор во всех этих open source платформах, что отлично. Думаю, Iceberg наверняка, для формата хранения ваших данных, это, мне кажется, самая безопасная ставка, которую вы могли бы сделать. И затем на стороне движка, снова, поиск правильного движка для правильной работы. Думаю, если это SQL Analytics, мы бы сказали, Trino и Starburst — лучшая ставка, но вы должны доказать это себе.

Если вы обучаете модель машинного обучения, вы, вероятно, используете Spark для этого. И это паттерны, которые мы видим. Думаю, все четыре этих технологий будут невероятно популярны в open-source-derived архитектурах данных на годы вперед. И снова, open source дает вам ту гибкость, чтобы иметь возможность микшировать и подбирать компоненты со временем, что заставит вашу архитектуру выдержать испытание временем. И думаю, это действительно то, что вы хотите сделать — не создавать технический долг, который у вас будет действительно трудно заменить 10 лет отныне. И open source дает вам эту гибкость.

Динеш Чандрасекар:

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

Джастин Боргман:

Спасибо, Динеш. Это было мое удовольствие.

Интернет вещей

  1. IoT-безопасность: почему отрасль должна приоритезировать глобальные тренды PKI, по мнению Thales
  2. 5 лучших вебинаров 2016 года для расширения знаний
  3. Siemens, NXP и партнеры усиливают кибербезопасность через Хартию Доверия
  4. Как IoT повышает качество производства в индустрии FMCG
  5. Как IoT стимулирует устойчивость и экономический рост
  6. Защита DDS с Intel SGX: Часть 3 — Укрепленные DDS-сервисы
  7. Оцифровка раскрывает эффективность и рост на пищевых производствах
  8. ИИ, IoT, программно-определяемые системы и цифровые двойники: построение резилиентных, устойчивых индустрий
  9. IoT-as-a-Service: стратегическое решение для защиты производства от кибератак
  10. Продвинутая система управления дрэйджем: оптимизация эффективности цепочки поставок