Jim Dowling, CEO und Mitbegründer von Hopsworks, erläuterte auf der IT Press Tour, wie sein Unternehmen mit dem Open Source AI Lakehouse punkten will. Jim Dowling, CEO and co-founder of Hopsworks, explained at the IT Press Tour how his company plans to score with the open source AI lakehouse.
Das schwedische Unternehmen Hopsworks wurde 2018 von einem Forschungsteam von KTH, RISE und MySQL gegründet. Die Schweden haben 36 Mitarbeiter und 12,25 Millionen Euro Risikokapital in drei Finanzierungsrunden akquiriert. Die Kernkompetenz waren zunächst Datenbanken, vor allem MySQL.

Die aktuelle Innovation ist ein Open Source AI Data Lakehouse. Damit soll dem Trend entsprochen werden, dass analytische Daten in das Lakehouse wandern, um Kosten zu sparen und die Bindung an den Anbieter zu verringern. Es gibt jedoch ein Problem mit der KI, da Echtzeit-KI und Python im Lakehouse Bürger zweiter Klasse sind.

Die Vision ist es, bessere Modelle in der Produktion zu finden, die durch eine einheitliche Datenschicht für KI schneller sind. Die Mission ist es, das leistungsfähigste, offene und modulare KI-Lakehouse zu entwickeln, das alle Arten von KI-Systemen unterstützt.

Die Herausforderungen sind: MLOps-Plattformen waren bisher nicht besonders erfolgreich bei der Produktion von KI-Anwendungen. Im Jahr 2024 wird fast die Hälfte aller Modelle (48% laut Gartner) den Sprung in die Produktion noch nicht geschafft haben. Die Einführung von MLOps-Plattformen hat nur geringfügig dazu beigetragen, dass mehr und bessere Modelle schneller in Produktion gehen.

Ein Grund dafür ist die fehlende Verbindung zwischen den bestehenden MLOps-Plattformen und dem Lakehouse – der Trennung der Daten zwischen Analyse- und Data Science-Teams. Das Lakehouse wird zur Quelle der Wahrheit für verwaltete historische Daten sowohl für die Analyse als auch für die KI, und MLOps-Plattformen müssen nativ mit ihm integriert werden. Dem Lakehouse selbst fehlen jedoch viele Funktionen, die erforderlich sind, um zu einer Fabrik für die Erstellung von KI-Anwendungen zu werden.

Das Lakehouse bietet keine Unterstützung für Echtzeitdaten für KI, keine leistungsfähigen Python-Clients, die Entwickler für eine schnellere Iteration benötigen, und keine Infrastrukturdienste (z. B. Modellregistrierung, Model Serving und Feature Serving-Datenbank).

Jim Dowling, CEO und Mitbegründer von Hopsworks, erklärt: „Wir glauben, dass der Ausgangspunkt für die nächste Generation von KI-Plattformen das Lakehouse ist. Was wir brauchen, ist ein KI-Lakehouse, das das Lakehouse um Unterstützung für die Erstellung und den Betrieb aller Arten von KI-Anwendungen erweitert – Batch-, Echtzeit- und LLM-KI-Systeme. SQL für Datenbanken ist nach wie vor wichtig und bietet einen echten Mehrwert. NoSQL kam 2010 auf, stößt aber zehn Jahre später an seine Grenzen. Wir führen bei SQL auf Python und sind mindestens zehnmal schneller als die Konkurrenz. Databricks und Snowflake sind nicht schnell genug und wir sind viel günstiger. Außerdem ist das Hopsworks AI Lakehouse offen und es gibt kein Vendor Lock-in“.

Hopsworks hat den Hopsworks Query Service entwickelt, um das Problem des Hochgeschwindigkeits-Datentransfers von Lakehouse nach Python zu lösen und KI-spezifische Anforderungen zu erfüllen, wie z.B. die Erstellung korrekter Trainingsdaten zu einem bestimmten Zeitpunkt und die Reproduktion gelöschter Trainingsdaten. Im SIGMOD’24 Forschungsbericht zeigte Hopsworks, dass das Lesen von Lakehouse-Daten für Pandas-Clients im Vergleich zu Databricks, AWS Sagemaker und GCP Vertex um das 9-45-fache beschleunigt wird.

Der Hopsworks Query Service ermöglicht leistungsstarke Python-basierte KI-Systeme, die die FTI-Architektur (Feature, Training, Inference) nutzen. Die FTI-Architektur ist ein einheitliches Rahmenwerk für den Aufbau von Echtzeit-, Batch- und LLM-KI-Systemen, wobei die KI-Pipelines in eine von drei verschiedenen Klassen fallen:

– Feature-Pipelines, die Eingabedaten aus einer Vielzahl von Datenquellen (einschließlich Lakehouse-Tabellen) erhalten und Feature-Daten in Lakehouse-Tabellen (und in Feature-Serving-Tabellen, wenn die Features von Echtzeit-KI-Systemen verwendet werden sollen) ausgeben,

– Trainingspipelines, die Merkmalsdaten aus Lakehouse-Tabellen erhalten und ein trainiertes Modell an eine Modellregistrierung ausgeben,

– Inferenz-Pipelines, die Merkmalsdaten aus Lakehouse-Tabellen und ein oder mehrere Modelle als Eingabe verwenden und Vorhersagen ausgeben. Batch-, Streaming- und Echtzeit-Inferenzpipelines gehören alle zu dieser Klasse.

Hopsworks hat Lakehouse erweitert, um Echtzeit-KI zu unterstützen, Python mit dem Hopsworks Query Service zu einem erstklassigen Datenabfrager zu machen und Unterstützung für LLMs mit Lakehouse-Daten hinzuzufügen. Ziel ist es, einen offenen, disaggregierten KI-Lakehouse-Stack zu entwickeln, der die KI-Systeme der Zukunft unterstützt.

The Swedish company Hopsworks was founded in 2018 by a research team from KTH, RISE and MySQL. The Swedes have 36 employees and have raised €12.25 million in venture capital in three rounds of funding. The core competence was initially databases, especially MySQL.

The current innovation is an open source AI data lakehouse. This is in response to the trend of moving analytical data to the lakehouse to cut costs and reduce vendor lock-in. However, there is a problem with AI, as real-time AI and Python are second-class citizens in the lakehouse.

The vision is to find better models in production that are faster through a unified data layer for AI. The mission is to develop the most powerful, open and modular AI lakehouse that supports all types of AI systems.

The challenges are: MLOps platforms have not been particularly successful in producing AI applications. By 2024, almost half of all models (48% according to Gartner) will not have made the leap into production. The introduction of MLOps platforms has only marginally contributed to getting more and better models into production faster.

One reason for this is the lack of connection between existing MLOps platforms and the lakehouse – the separation of data between analytics and data science teams. The lakehouse becomes the source of truth for managed historical data for both analytics and AI, and MLOps platforms need to natively integrate with it. However, the lakehouse itself lacks many of the capabilities needed to become a factory for building AI applications.

The Lakehouse lacks support for real-time data for AI, powerful Python clients that developers need to iterate faster, and infrastructure services (such as model registration, model serving, and feature serving databases.)

Jim Dowling, CEO and co-founder of Hopsworks, explains: „We believe the starting point for the next generation of AI platforms is the Lakehouse. What we need is an AI lakehouse that extends the lakehouse with support for building and running all types of AI applications – batch, real-time and LLM AI systems. SQL for databases is still important and provides real value. NoSQL emerged in 2010, but ten years on it is reaching its limits. We lead in SQL on Python and are at least ten times faster than the competition. Databricks and Snowflake are not fast enough and we are much cheaper. In addition, the Hopsworks AI Lakehouse is open and there is no vendor lock-in.“

Hopsworks has developed the Hopsworks Query Service to solve the problem of fast data transfer from Lakehouse to Python and to meet AI-specific requirements, such as creating correct training data at a given time and reproducing deleted training data. In the SIGMOD’24 research report, Hopsworks showed that reading Lakehouse data is 9-45 times faster for Pandas clients compared to Databricks, AWS Sagemaker and GCP Vertex.

The Hopsworks Query Service enables high-performance Python-based AI systems using the FTI (Feature, Training, Inference) architecture. The FTI architecture is a unified framework for building real-time, batch and LLM AI systems, with AI pipelines falling into one of three distinct classes:

– Feature pipelines, which receive input data from a variety of data sources (including lakehouse tables) and output feature data to lakehouse tables (and to feature serving tables if the features are to be used by real-time AI systems),

– Training pipelines that receive feature data from Lakehouse tables and output a trained model to a model registry,

– Inference pipelines that take feature data from Lakehouse tables and one or more models as input and output predictions. Batch, streaming and real-time inference pipelines all fall into this class.

Hopsworks has extended Lakehouse to support real-time AI, making Python a world-class data querier with the Hopsworks Query Service, and adding support for LLMs with Lakehouse data. The goal is to develop an open, disaggregated AI Lakehouse stack that supports the AI systems of the future.

Von Jakob Jung

Dr. Jakob Jung ist Chefredakteur Security Storage und Channel Germany. Er ist seit mehr als 20 Jahren im IT-Journalismus tätig. Zu seinen beruflichen Stationen gehören Computer Reseller News, Heise Resale, Informationweek, Techtarget (Storage und Datacenter) sowie ChannelBiz. Darüber hinaus ist er für zahlreiche IT-Publikationen freiberuflich tätig, darunter Computerwoche, Channelpartner, IT-Business, Storage-Insider und ZDnet. Seine Themenschwerpunkte sind Channel, Storage, Security, Datacenter, ERP und CRM. Dr. Jakob Jung is Editor-in-Chief of Security Storage and Channel Germany. He has been working in IT journalism for more than 20 years. His career includes Computer Reseller News, Heise Resale, Informationweek, Techtarget (storage and data center) and ChannelBiz. He also freelances for numerous IT publications, including Computerwoche, Channelpartner, IT-Business, Storage-Insider and ZDnet. His main topics are channel, storage, security, data center, ERP and CRM. Kontakt – Contact via Mail: jakob.jung@security-storage-und-channel-germany.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

WordPress Cookie Hinweis von Real Cookie Banner