Carta Spotlight: Datentechnik

Jan 26 2023
Es ist 2018. Mein vierter Tag bei Carta.

Es ist 2018. Mein vierter Tag bei Carta. Ich sitze allein mit dem scheidenden Data Science Lead im Büro des CEO in SF. Wir führen eine typische Übergabe durch. Als wir zum Thema Versionskontrolle kommen, öffnet mein zukünftiger Ex-Kollege Google Drive und scrollt durch hundert Google Docs voller SQL-Abfragen! Das Chaos überraschte mich nicht. Ein Jahr zuvor hatte ich beschlossen, vom Full-Stack-Software-Engineering zum Data-Engineering überzugehen, um genau wie dieses bei der Lösung von Problemen zu helfen. Der Data-Science-Boom in den frühen 2010er Jahren brachte Unternehmen wie Carta einen erheblichen Mehrwert, es gab jedoch Probleme bei der Skalierung und Wartung der Lösungen. Mein Posteingang wurde mit Personalvermittlern überschwemmt, die nach Beratern suchten, die mir helfen könnten, das Chaos zu beseitigen. Also beschloss ich, mich voll und ganz auf Datentechnik zu konzentrieren. Vier Jahre später ist die Verwendung von Google Docs für die SQL-Versionskontrolle eine ferne Erinnerung.

Möglicherweise wissen Sie nicht viel über Data Engineering. In einem kürzlich veröffentlichten Tweet setzte Gergely Orosz den Dateningenieur an die Spitze der Liste der Rollen, über die „viele Softwareentwickler wenig wissen“. Knapp 5 % der Befragten der Stack Overflow-Entwicklerumfrage 2022 stuften sich selbst als Dateningenieur ein. Was machen Dateningenieure bei Carta? In diesem Beitrag werde ich einige Geschichten erzählen, die das Data Engineering und die Rolle hervorheben, die wir beim Aufbau der Datenplattform von Carta gespielt haben – von Datenpipelines über produktives maschinelles Lernen (ML) bis hin zu Datenprodukten.

Was ist ein Dateningenieur?

Im letzten Jahrzehnt hat sich das Data Engineering über fragile Big-Data-Hadoop-Cluster, Ad-hoc-Skripte und Cron-Jobs hinaus entwickelt und nutzt Software-Engineering-Tools, Frameworks und Automatisierung. Im Diagramm unten können Sie den Übergang von Big Data zum Cloud Data Warehousing sehen, während der Preis für ein GB Datenspeicher sinkt und die Datenmenge, die die Welt verarbeitet und speichert, weiterhin explodiert.

Die Spezialisierung auf Data Engineering fällt mit der Entstehung des Cloud Data Warehousing zusammen.

Die Fähigkeiten im Bereich Data Engineering erstrecken sich über DevOps, Backend-Engineering, Datenbankverwaltung und Automatisierungs-Engineering. Hier ist unsere Arbeitsdefinition eines Dateningenieurs bei Carta:

Dateningenieure sind Softwareentwickler, die sich auf die zuverlässige Konsolidierung, Organisation und Aktualisierung der Carta-Datensätze spezialisiert haben, um strategische Entscheidungen mit herkömmlichen BI-Tools und Produktfunktionen zu ermöglichen, die durch maschinelles Lernen unterstützt werden.

Alle Unternehmen benötigen Softwareentwickler, die sich mit Data Warehousing, Datenbanken, Workflow-Management-Systemen, Überwachung, kontinuierlicher Integration/Bereitstellung (CI/CD) und ML auskennen. Die Softwareentwickler, die an der Schnittstelle dieser Tools arbeiten, werden Dateningenieure genannt.

Entwicklung des Carta Data Engineering

In den letzten vier Jahren hat sich der Aufgabenbereich des Datenteams von Ad-hoc-Berichten auf den Aufbau einer Datenplattform ausgeweitet. In den frühen Tagen von Carta funktionierten Reporting und Insights wie bei jedem anderen kleinen Startup. Henry würde eine einfache Frage stellen: „Gibt es diesen Monat ein Problem mit dem Rechnungsbericht?“ Und dann folgte ein langer Slack-Thread: „Schau es dir jetzt an. Aus irgendeinem Grund wurde das Skript, das es automatisch ausführt, nicht ausgeführt.“

Ein tatsächlicher Slack-Austausch aus dem Jahr 2015, der Datenqualitätsprobleme bei Carta hervorhebt.

Wir hatten keine Überwachung auf unserem Analyse-Stack. Wir waren streitsüchtig. Damals wurde unser „Data Warehouse“ von einem High-School-Praktikanten mit dem Postgres Foreign Data Wrapper zusammengefügt. Unsere Looker-Installation vor Ort hatte regelmäßig nicht mehr genügend Arbeitsspeicher und stürzte ab, ohne dass eine Warnung erfolgte. Und wenn Berichte fehlschlugen oder Daten fehlten, stellte das Führungsteam zu Recht die Qualität des gesamten jungen Analysesystems in Frage.

Bei Carta entstand die Data-Engineering-Funktion, als unser Berichtsbedarf begann, die freien Zyklen eines einzelnen freundlichen Backend-Ingenieurs zu übersteigen. Das erste Data-Engineering-Projekt war ein Redshift-Data-Warehouse und ein S3-Data-Lake. Mit dem Wachstum von Carta wuchs auch die Zahl der Führungskräfte, die qualitativ hochwertige Datenräume bei anderen Unternehmen gesehen hatten. Nach einer Reihe von Looker-Ausfällen, fehlgeschlagenen ETL-Skripten und unmöglichen Datenanfragen hat unser CTO dem Aufbau einer neuen Dateninfrastruktur Priorität eingeräumt. Wir haben Looker vom Fremddaten-Wrapper getrennt und Looker mit Redshift verbunden.

Also zurück zur Geschichte über SQL in Google Docs. Die Daten von Carta sind komplex und die Verwendung von Google Docs zur „Versionierung“ unserer Datenmodellierungsarbeit war unzureichend. Zu dieser Zeit hatte ein innovatives Team in Philly an einem neuen CLI-Tool gearbeitet, das Git-Versionskontrolle und Vorlagen in SQL-Projekte integrieren sollte. Dieses Team war Fishtown Analytics (jetzt Series-D dbt Labs) und das Projekt war dbt. Ich habe hastig eine DBT-Demo zusammengestellt und unser sehr skeptisches Team, das Befehlszeilen-Aversionen gegenübersteht, gebeten, es „einfach auszuprobieren“. Wir waren eines der ersten 200 dbt-Projekte und führten eine Alpha 0.10-Version von dbt in der Produktion aus. Der Einsatz von dbt hat sich gelohnt und ermöglichte uns, unser Datenteam zu erweitern, während Carta wuchs. Heute hat unser dbt-Projekt 47 Mitwirkende und 2553 Modelle.

Als nächstes kam für uns die Containerisierung. Das DevOps-Team ermutigte uns, ihre neu entwickelte Rancher-Installation für die Bereitstellung unserer Datenpipelines und unseres DBT-Projekts zu übernehmen. Rancher war ein Fehltritt für Carta. Damals war es schwer vorherzusagen, aber die Open-Source-Community konvergierte schnell auf Kubernetes als Standard-Container-Orchestrierungssystem. Wir haben schnell umgedreht. Einige Monate später, Anfang 2019, richteten wir einen kOps-Cluster ein und begannen mit der Umstellung auf Kubernetes.

Die Engineering-Organisation von Carta hat den Wechsel zu Kubernetes abgeschlossen. Und wir verwenden Airflow, um ELT-Workloads in Kubernetes-Pods zu orchestrieren. Durch den Betrieb von Datenpipelines auf derselben Containerplattform, die von allen anderen Softwareentwicklern bei Carta verwendet wird, können wir Ideen und Code austauschen und fachkundige Unterstützung vom Produktionstechnikteam von Carta erhalten. Databot ist beispielsweise eine der beliebtesten Apps von Carta Data Engineering. databot ist eine schlanke API rund um dbt, die es Datenwissenschaftlern ermöglicht, Modelle in verschiedenen Umgebungen direkt in Slack auszuführen. Der vollständige Workflow ermöglicht es unserem Team, SQL zu schreiben und dbt lokal in einer Sandbox-Umgebung auszuführen, Codeüberprüfungen und CI in GitHub durchzuführen, kontinuierlich neue Datenmodelle für die Produktion bereitzustellen und einzelne Modelle mit einer einfachen Slack-Nachricht zu aktualisieren.

Ausführen des mypy-Registrierungs-DBT-Modells mit dem Slack-Databot von Carta.

Mit dieser soliden Grundlage aus Container-Pipelines und zuverlässigen Analyse-Dashboards wuchs und skalierte unser Datenteam, um jedes Team bei Carta zu bedienen. Airflow hat im vergangenen Jahr 1,3 Millionen automatisierte Pipeline-Aufgaben für uns ausgeführt. Das Datenteam von Carta wurde um die Bereiche Datentechnik, Analysetechnik, Datenwissenschaft und maschinelles Lernen erweitert. Gleichzeitig hat sich der Umfang von Carta von einem Produkt zu einer Plattform erweitert . Heute verwaltet Carta einen Eigenkapitalwert von 2,5 Billionen US-Dollar für über 2 Millionen Stakeholder. Unser Datenteam arbeitet derzeit an zwei strategischen Zielen, die über herkömmliche Analyse-Dashboards hinausgehen: Datenprodukte und maschinelles Lernen.

Datenprodukte

Cartas Funding Benchmarks-Datenprodukt

Bei Carta haben wir ein Datenprodukt namens Funding Benchmarks – eine Seite im Dashboard-Stil mit Diagrammen, Grafiken und Filtern, die es Benutzern ermöglicht, ihre Startup-Fundraising-Runde mit ähnlichen Unternehmen zu vergleichen. Die erste Version des Fundraising-Dashboards wurde durch OLTP-Datenbankabfragen unterstützt. Der Code war mit teuren Datenbankabfragen und Daten-Munging in Python gefüllt. Das Bewertungsteam hatte die Idee, mit Data Engineering zusammenzuarbeiten, um die Zahlenverarbeitung in dbt-SQL-Modelle zu verlagern und die transaktionalen Datenbankabfragen durch neue, von dbt erstellte aggregierte Datensätze mit OLAP-API-Unterstützung zu ersetzen.

OLTP steht für Online Transactional Processing. Denken Sie an Postgres und MySQL – Datenbanken, die für Echtzeitvorgänge mit hohem Durchsatz optimiert sind. OLAP ist die Abkürzung für Online Analytical Processing. Denken Sie an Snowflake, Redshift, BigQuery. OLAP-Datenbanken eignen sich hervorragend für die Bearbeitung komplexer Abfragen großer Datenmengen.

Wenn Sie in einem Produkt ein dynamisches Diagramm oder ein Dashboard mit Filtern sehen, ist die API, die diese Funktion unterstützt, ein guter Kandidat für eine OLAP-API. ORMs, die auf einer Transaktionsdatenbank basieren, eignen sich hervorragend für CRUD-Vorgänge. Wenn Ingenieure jedoch Funktionen erstellen, die viele Verknüpfungen zwischen Tabellen, das Aggregieren oder Filtern von Daten erfordern, gibt es drei häufige Muster:

  1. Das erste Muster ist das häufigste für Ingenieure, die sich nicht mit SQL auskennen: Verwenden Sie ORM, um alle Daten in den Speicher zu ziehen und sie in das Format für die API umzuwandeln. Das Hauptproblem bei diesem Ansatz ist die Leistung. Wenn der Datensatz groß ist, ist die API langsam.
  2. Verwenden Sie einen SQL-Abfrage-Builder wie die SQLAlchemy Query API, um eine komplexe SQL-Abfrage in Python zu erstellen. Das Problem bei diesem Ansatz besteht darin, dass es sich um eine komplizierte Abstraktion zusätzlich zu SQL handelt.
  3. Schreiben Sie in Python-Code eingebettetes Roh-SQL. Dies funktioniert gut für einfache SQL-Abfragen ohne Aggregation, Filterung oder Gruppierung. Wenn SQL dynamisch mit SQL-Injection-Schutz und Parameterbindung sein muss, beginnt dieser Ansatz zu scheitern.
Architekturdiagramm des Data Products-Backends von Carta

Bei Carta sind OLAP-APIs eine Lösung, die wir für analyseintensive Produktfunktionen verwenden. OLAP-APIs sind ein Datenprodukt – eine programmatische Schnittstelle zu dokumentierten, versionierten, codeüberprüften DBT-Datenmodellen. Die Grundvoraussetzung ist die Bereitstellung einer großartigen Dashboard-BI-Erfahrung für diese Datenmodelle. Aber die Produktteams bei Carta möchten diese aggregierten Datensätze in Anwendungen integrieren. Wir begannen mit einer gRPC-Schnittstelle für Backend-Ingenieure, um vom Datenteam erstellte Datensätze abzufragen. Fast sofort forderten Frontend-Ingenieure REST-APIs. Also machte ich mich an die Arbeit, eine separate REST-Schnittstelle für unsere OLAP-APIs zu programmieren. Glücklicherweise hat mich das Infrastrukturteam von Carta bei der Codeüberprüfung dabei erwischt, wie ich das Rad neu erfand. Mit nur wenigen Zeilen Transcoder-Konfiguration haben wir unseren gRPC-Endpunkten REST-Unterstützung hinzugefügt. Wir verfügen jetzt über konsistente Daten über BI-Dashboards und Datenprodukte hinweg, indem wir OLAP-APIs verwenden, um dasselbe zugrunde liegende DBT-Datenmodell abzufragen. Wir haben 7 OLAP-APIs in der Produktion mit 11 Mitwirkenden am Projekt hinzugefügt.

Maschinelles Lernen in der Produktion (MLOps)

Durch maschinelles Lernen unterstützte Datenprodukte werden bald in jeder von uns verwendeten Software enthalten sein – ChatGPT, GitHub Copilot und Stable Diffusion sind nur der Anfang. Die Ingenieure für maschinelles Lernen bei Carta forschen ständig, entwickeln Prototypen und iterieren Modelle. Beispielsweise durchsuchte unser Launch-Team bis vor Kurzem Dokumente manuell nach Informationen, die sie zum Vervollständigen von Unternehmensprofilen benötigten. Deshalb halfen wir einem ML-Ingenieur bei der Einführung eines Modells zum Extrahieren von Schlüsselfeldern aus der Satzung. Das Launch-Team kann nun ein PDF auf eine API hochladen, die die extrahierten Daten in einer strukturierten Antwort zurückgibt.

Maschinelles Lernen (ML) auf Produktionsniveau ist eine wesentliche Fähigkeit von Datenteams. Jede Organisation versucht verzweifelt herauszufinden, wie sie mehr ML-Anwendungen online stellen kann. Dateningenieure wissen, wie man containerisierte Backend-Dienste mit automatisierten Testsuiten erstellt und bereitstellt. Die Dateningenieure bei Carta arbeiten eng mit MLOps zusammen, um Forschungsprototypen schnell vom Rohentwurf zur Produktion zu bringen. Typischerweise unterstützen Dateningenieure das ML-Team durch die Einrichtung von gRPC-Boilerplate, CI/CD, Testautomatisierung und Helm/Kubernetes-Konfiguration. Dadurch können sich ML-Ingenieure auf die Verbesserung von Modellen und die Durchführung von Tests konzentrieren, ohne DevOps-Experten werden zu müssen.

Ein Aufruf für Software-Ingenieure

Die Geschichten in diesem Beitrag über unsere Data-Engineering-Kultur mögen einzigartig für Carta sein, aber die Probleme sind nicht einzigartig. Data Engineering ist eine wesentliche Rolle. Durch die Standardisierung und Verbesserung der Tools für das Data Engineering konnte Carta über interne Dashboards und Berichte hinausgehen. Dieselben Datensätze und ML-Modelle, die für BI verwendet werden, stehen jetzt Ingenieurteams zur Erstellung von Datenprodukten mithilfe von OLAP-APIs zur Verfügung. Aber ohne Software-Ingenieure geht das nicht.

Datenteams brauchen mehr Softwareentwickler. Wenn Sie als Entwickler dies lesen und die Arbeit interessant klingt, sprechen Sie mit einem Datenwissenschaftler oder ML-Ingenieur über die Probleme, mit denen er konfrontiert ist. Wenn Sie eine Führungspersönlichkeit sind, rekrutieren Sie DevOps- und Software-Ingenieure für das Datenteam. Datenwissenschaftler und ML-Ingenieure leisten unglaubliche Arbeit mit Anwendungen, die über Berichterstattung und Forschung hinausgehen. Um diese Arbeit für die Verwendung in Datenprodukten zu produzieren, sind neue Infrastruktur und Automatisierung erforderlich.

Datenteams benötigen Ingenieure mit Erfahrung in den Bereichen Containerisierung, CI/CD, Testautomatisierung, Backend-APIs und SQL ORMs. Ähnlich wie bei ML brauchen wir Tool-Builder. Die Frameworks für Datenteams sind viel besser als vor zehn Jahren, aber wir müssen die gleiche Vielfalt sehen, die Full-Stack-Entwicklern zur Verfügung steht. Wenn Sie an einer Karriere im Bereich Data Engineering interessiert sind, schauen Sie sich Carta Careers an . Senden Sie uns eine Nachricht, um Ihre Erfahrungen mitzuteilen. Was haben wir in diesem kurzen Überblick über Data Engineering übersehen?