Es dauerte drei Wochen, bis wir eine einzelne Datenpipeline auslieferten. Heutzutage erledigt ein Analyst ohne Python-Erfahrung dies an einem Tag. So sind wir dorthin gekommen.

Ich bin Kiril Kazlou, Dateningenieur bei Mindbox. Unser Group berechnet regelmäßig Geschäftskennzahlen für Kunden neu. Das bedeutet, dass wir ständig Datenmarts für Abrechnungen und Analysen erstellen und dabei auf Dutzende verschiedener Quellen zurückgreifen.

Lange Zeit haben wir uns bei der gesamten Datenverarbeitung auf PySpark verlassen. Das Drawback? Ohne Python-Erfahrung kann man nicht wirklich mit PySpark arbeiten. Jede neue Pipeline erforderte einen Entwickler. Und das bedeutete Warten – manchmal wochenlang.

In diesem Beitrag erkläre ich Ihnen, wie wir eine interne Datenplattform aufgebaut haben, auf der ein Analyst oder Produktmanager durch das Schreiben von nur vier YAML-Dateien eine regelmäßig aktualisierte Pipeline aufbauen kann.

Warum PySpark uns verlangsamte

Lassen Sie mich den Schmerz anhand eines Lehrbuchbeispiels veranschaulichen – der Berechnung von MAU (Month-to-month Lively Customers).

Oberflächlich betrachtet fühlt sich das wie ein einfacher SQL-Job an: COUNT(DISTINCT customerId) über ein paar Tische hinweg über ein Zeitfenster hinweg. Aber wegen des ganzen Infrastrukturaufwands – PySpark, Airflow DAG-Einrichtung, Spark-Ressourcenzuweisung, Checks – mussten wir ihn den Entwicklern überlassen. Das Ergebnis? Eine ganze Woche allein für den Versand eines MAU-Zählers.

Die Bereitstellung jeder neuen Metrik dauerte ein bis drei Wochen. Und jedes Mal sah der Prozess gleich aus:

1. Ein Analyst definierte die Geschäftsanforderungen, fand einen verfügbaren Entwickler und übergab den Kontext.
2. Der Entwickler klärte Particulars, schrieb PySpark-Code, führte eine Codeüberprüfung durch, konfigurierte die DAG und stellte sie bereit.

Was wir eigentlich wollten, warfare, dass Analysten und Produktmanager – die Leute, die die Geschäftslogik am besten verstehen und fließend SQL und YAML beherrschen – sich selbst darum kümmern. Kein Python. Kein PySpark.

Wodurch wir PySpark ersetzt haben: YAML und SQL sind alles, was Sie brauchen

Um einen deklarativen Ansatz zu verfolgen, haben wir unsere Datenschicht in drei Teile aufgeteilt und für jeden das richtige Software ausgewählt:

• dlt (Datenladetool) – Nimmt Daten von externen APIs und Datenbanken in den Objektspeicher auf. Komplett über eine YAML-Datei konfiguriert. Kein Code erforderlich.
• dbt (Datenerstellungstool) auf Trino – transformiert Daten mit reinem SQL. Es verknüpft Modelle über ref()erstellt automatisch ein Abhängigkeitsdiagramm und verarbeitet inkrementelle Aktualisierungen.
• Luftstrom + Kosmos – orchestriert die Pipelines. Der Airflow DAG wird automatisch generiert dag.yaml und das dbt-Projekt.

Wir verwendeten Trino bereits als Abfrage-Engine für Advert-hoc-Abfragen und hatten es in Superset für BI integriert. Es hatte sich bereits bewährt: Bei Abfragen mit Standardlogik verarbeitete es riesige Datenmengen schneller und mit weniger Ressourcen als Spark. Darüber hinaus unterstützt Trino nativ den Verbundzugriff auf mehrere Datenspeicher über eine einzige SQL-Abfrage. Für 90 % unserer Pipelines passte Trino perfekt.

So laden wir Daten: dlt.yaml

Die erste YAML-Datei beschreibt, wo und wie Daten für die Weiterverarbeitung geladen werden. Hier ist ein Beispiel aus der Praxis – Laden von Rechnungsdaten von einer internen API:

product: sg-team
characteristic: billing
schema: billing_tarification

dag:
  dag_id: dlt_billing_tarification
  schedule: "0 4 * * *"
  description: "Day by day refresh of tarification knowledge"
  tags:
    - billing

alerts:
  enabled: true
  severity: warning

supply:
  kind: rest_api
  shopper:
    base_url: "https://internal-api.instance.com"
    auth:
      kind: bearer
      token: dlt-billing.token
  assets:
    - identify: tarification_data
      endpoint:
        path: /tarificationData
        methodology: POST
        json:
          firstPeriod: "{{ previous_month_date }}"
          lastPeriod: "{{ previous_month_date }}"
          pricingPlanLine: CurrentPlan
      write_disposition: change
      processing_steps:
        - map: dlt_custom.billing_tarification_data.map

    - identify: charges_raw
      columns:
        staffUserName:
          data_type: textual content
          nullable: true
      endpoint:
        path: /data-feed/costs
        methodology: POST
        json:
          firstPeriod: "{{ previous_month_date }}"
          lastPeriod: "{{ previous_month_date }}"
      write_disposition: change

    - identify: discounts_raw
      endpoint:
        path: /data-feed/reductions
        methodology: POST
        json:
          firstPeriod: "{{ previous_month_date }}"
          lastPeriod: "{{ previous_month_date }}"
      write_disposition: change

Diese Konfiguration definiert vier Ressourcen aus einer einzigen API. Für jeden geben wir den Endpunkt, Anforderungsparameter und eine Schreibstrategie an – in unserem Fall change bedeutet „Jedes Mal überschreiben“. Sie können außerdem Verarbeitungsschritte hinzufügen, Spaltentypen definieren und Warnungen konfigurieren.

Die gesamte Konfiguration ist 40 Zeilen YAML. Ohne DLT wäre jeder Connector ein Python-Skript, das Anforderungen, Paginierung, Wiederholungsversuche, Serialisierung in das Delta-Desk-Format und Uploads in den Speicher verarbeitet.

Wie wir Daten mit SQL transformieren: dbt_project.yaml und assets.yaml

Der nächste Schritt ist die Konfiguration des DBT-Modells. Bei Trino bedeutet das SQL-Abfragen.

Hier ist ein Beispiel dafür, wie wir die MAU-Berechnung einrichten. So sieht Eventvorbereitung aus einer Hand aus:

-- int_mau_events_visits.sql (simplified)
{{ config(materialized='desk') }}

WITH interval AS (
    -- Rolling window: final 5 months to present
    SELECT
        YEAR(CURRENT_DATE - INTERVAL '5' MONTH) AS start_year,
        MONTH(CURRENT_DATE - INTERVAL '5' MONTH) AS start_month,
        YEAR(CURRENT_DATE) AS end_year,
        MONTH(CURRENT_DATE) AS end_month
),

occasions AS (
    -- Pull go to occasions inside the interval window
    SELECT src._tenant, src.unmergedCustomerId,
           'visits' AS src_type, src.endpoint
    FROM {{ supply('last', 'customerstracking_visits') }} src
    CROSS JOIN interval p
    WHERE src.unmergedCustomerId IS NOT NULL
      AND /* ...timestamp filtering by 12 months/month bounds... */
),

events_with_customer AS (
    -- Resolve merged buyer IDs
    SELECT e._tenant,
           COALESCE(mc.mergedCustomerId, e.unmergedCustomerId) AS customerId,
           e.src_type, e.endpoint
    FROM occasions e
    LEFT JOIN {{ ref('int_merged_customers') }} mc
      ON e._tenant = mc._tenant
      AND e.unmergedCustomerId = mc.unmergedCustomerId
)

-- Hold solely precise (non-deleted) prospects
SELECT ewc._tenant, ewc.customerId, ewc.src_type, ewc.endpoint
FROM events_with_customer ewc
WHERE EXISTS (
    SELECT 1 FROM {{ ref('int_actual_customers') }} ac
    WHERE ewc._tenant = ac._tenant
      AND ewc.customerId = ac.customerId
)

Alle 10 Ereignisquellen folgen genau dem gleichen Muster. Die einzigen Unterschiede sind die Quelltabelle und die Filter. Dann verschmelzen die Modelle zu einem einzigen Stream:

-- int_mau_events.sql (union of all sources)
SELECT * FROM {{ ref('int_mau_events_inapps_targetings') }}
UNION ALL
SELECT * FROM {{ ref('int_mau_events_inapps_clicks') }}
UNION ALL
SELECT * FROM {{ ref('int_mau_events_visits') }}
UNION ALL
SELECT * FROM {{ ref('int_mau_events_orders') }}
-- ...plus 6 extra sources

Und schließlich der Knowledge Mart, in dem alles aggregiert wird:

-- mau_period_datamart.sql
{{ config(
    materialized='incremental',
    incremental_strategy='merge',
    unique_key=('_tenant', 'start_year', 'start_month', 'end_year', 'end_month')
) }}

 int -%

WITH interval AS (
    SELECT
        YEAR(CURRENT_DATE - INTERVAL '{{ months_back }}' MONTH) AS start_year,
        MONTH(CURRENT_DATE - INTERVAL '{{ months_back }}' MONTH) AS start_month,
        YEAR(CURRENT_DATE) AS end_year,
        MONTH(CURRENT_DATE) AS end_month
),
events_resolved AS (
    SELECT * FROM {{ ref('int_mau_events') }}
),
metrics_by_tenant AS (
    SELECT
        er._tenant,
        COUNT(DISTINCT CASE WHEN src_type = 'visits'
              THEN customerId END) AS CustomersTracking_Visits,
        COUNT(DISTINCT CASE WHEN src_type = 'orders'
              THEN customerId END) AS ProcessingOrders_Orders,
        COUNT(DISTINCT CASE WHEN src_type = 'mailings'
              THEN customerId END) AS Mailings_MessageStatuses,
        -- ...different metrics
        COUNT(DISTINCT customerId) AS MAU
    FROM events_resolved er
    GROUP BY er._tenant
)
SELECT m.*, p.start_year, p.start_month, p.end_year, p.end_month
FROM metrics_by_tenant m
CROSS JOIN interval p

Für die Knowledge-Mart-Konfiguration verwenden wir incremental_strategy='merge'. dbt generiert automatisch die Zusammenführungsabfrage und ersetzt die unique_key für upsert. Es ist nicht erforderlich, das inkrementelle Laden manuell zu implementieren.

Um die Modelle in einem einzigen Projekt zu verknüpfen, haben wir eingerichtet dbt_project.yaml:

identify: mau_period
model: '1.0.0'

fashions:
  mau_period:
    +on_table_exists: change
    +on_schema_change: append_new_columns

Und sources.yamldas die Eingabetabellen beschreibt:

sources:
  - identify: last
    database: data_platform
    schema: last
    tables:
      - identify: inapps_targetings_v2
      - identify: inapps_clicks_v2
      - identify: customerstracking_visits
      - identify: processingorders_orders
      - identify: cdp_mergedcustomers_v2
      # ...

Das Ergebnis ist dieselbe Geschäftslogik wie in PySpark, jedoch in reinem SQL: sources.yaml ersetzt typedspark-Schemas, {{ ref() }} Und {{ supply() }} ersetzen .get_table()und die automatische Ausführungsreihenfolge über das Abhängigkeitsdiagramm ersetzt die manuelle Optimierung der Spark-Ressourcen.

So konfigurieren wir Airflow: dag.yaml

Die vierte Konfigurationsdatei definiert, wann und wie Airflow die Pipeline ausführt:

product: sg-team
characteristic: billing
schema: mau
schedule: "15 21 * * *"  # each day at 00:15 MSK

params:
  - identify: start_date
    description: "Begin date (YYYY-MM-DD). Depart empty for auto"
    default: ""
  - identify: end_date
    description: "Finish date (YYYY-MM-DD). Depart empty for auto"
    default: ""
  - identify: months_back
    description: "Months to look again (default: 5)"
    default: 5

alerts:
  enabled: true
  severity: warning

Dann wird unser Python-Skript analysiert dag.yaml Und dbt_project.yaml und nutzt die Cosmos-Bibliothek, um einen voll funktionsfähigen Airflow DAG zu generieren. Das ist das einziger Teil des Python-Codes im gesamten Setup. Es wird einmal geschrieben und funktioniert für jedes DBT-Projekt. Hier ist der Schlüsselteil:

def _build_dbt_project_dags(project_path: Path, environ: dict) -> record(DbtDag):
    config_dict = yaml.safe_load(dag_config_path.read_text())
    config = DagConfig.model_validate(config_dict)

    # YAML params → Airflow Params
    params = {}
    operator_vars = {}
    for param in config.params:
        params(param.identify) = Param(
            default=param.default if param.default shouldn't be None else "",
            description=param.description,
        )
        operator_vars(param.identify) = f"{{{{ params.{param.identify} }}}}"

    # Cosmos creates the DAG from the dbt mission
    with DbtDag(
        dag_id=f"dbt_{project_path.identify}",
        schedule=config.schedule,
        params=params,
        project_config=ProjectConfig(dbt_project_path=project_path),
        profile_config=ProfileConfig(
            profile_name="default",
            target_name=project_name,
            profile_mapping=TrinoLDAPProfileMapping(
                conn_id="trino_default",
                profile_args={
                    "database": profile_database,
                    "schema": profile_schema,
                },
            ),
        ),
        operator_args={"vars": operator_vars},
    ) as dag:
        # Create schema earlier than operating fashions
        create_schema = SQLExecuteQueryOperator(
            task_id="create_schema",
            conn_id="trino_default",
            sql=f"CREATE SCHEMA IF NOT EXISTS {profile_database}.{profile_schema} ...",
        )
        # Connect to root duties
        for unique_id, _ in dag.dbt_graph.filtered_nodes.gadgets():
            job = dag.tasks_map(unique_id)
            if not job.upstream_task_ids:
                create_schema >> job

Kosmos liest manifest.json aus dem dbt-Projekt analysiert das Modellabhängigkeitsdiagramm und erstellt für jedes Modell eine separate Airflow-Aufgabe. Aufgabenabhängigkeiten werden automatisch basierend darauf erstellt ref() Aufrufe im SQL.

Wie Analysten Pipelines ohne Entwickler aufbauen

Wenn ein Analyst nun eine neue wiederkehrende Pipeline benötigt, kann er diese in wenigen Schritten zusammenstellen:

Schritt 1. Erstellen Sie einen Ordner im Repo: dbt-projects/my_new_pipeline/.

Schritt 2. Wenn eine externe Datenaufnahme erforderlich ist, schreiben Sie eine YAML-Konfiguration für dlt.

Schritt 3. Schreiben Sie SQL-Modelle in die fashions/ Ordner und beschreiben Sie die Quellen in sources.yaml.

Schritt 4. Erstellen dbt_project.yaml Und dag.yaml.

Schritt 5. Auf Git übertragen, Überprüfung durchführen, zusammenführen.

CI/CD erstellt das dbt-Projekt und sendet Artefakte an S3. Airflow liest die DAG-Dateien von dort, Cosmos analysiert das DBT-Projekt und generiert das Aufgabendiagramm. Pünktlich führt dbt die Modelle auf Trino in der richtigen Reihenfolge aus. Das Endergebnis ist ein aktualisierter Knowledge Mart im Warehouse, auf den über Superset zugegriffen werden kann.

Was sich nach der Migration geändert hat

Damit Analysten selbst Pipelines aufbauen können, müssen sie verstehen ref() Und supply() Konzepte, der Unterschied zwischen desk Und incremental Materialisierung und die Grundlagen von Git. Wir haben einige interne Workshops durchgeführt und Schritt-für-Schritt-Anleitungen für jeden Aufgabentyp zusammengestellt.

Warum der neue Stack PySpark nicht vollständig ersetzt

Für etwa 10 % unserer Pipelines ist PySpark immer noch die einzige Possibility – wenn eine Transformation einfach nicht in SQL passt. dbt unterstützt Jinja-Makros, aber das ist kein Ersatz für vollwertiges Python. Und es wäre unehrlich, die Grenzen der neuen Instruments außer Acht zu lassen.

dlt + Delta: experimentelle Upsert-Unterstützung. Wir verwenden das Delta-Format in unserer Speicherschicht. Der Delta-Connector von dlt ist als experimentell gekennzeichnet, daher hat die Zusammenführungsstrategie nicht sofort funktioniert. Wir mussten Workarounds finden – in einigen Fällen haben wir sie genutzt change anstatt merge (Opfer der Inkrementalität), und in anderen haben wir Brauch geschrieben processing_steps.

Trinos begrenzte Fehlertoleranz. Trino verfügt zwar über einen Fehlertoleranzmechanismus, dieser funktioniert jedoch durch das Schreiben von Zwischenergebnissen in S3. Bei unseren Datenmengen im Terabyte-Bereich ist dies unpraktisch – die schiere Anzahl der S3-Vorgänge macht es unerschwinglich teuer. Ohne aktivierte Fehlertoleranz schlägt die gesamte Abfrage fehl, wenn ein Trino-Employee ausfällt. Im Gegensatz dazu startet Spark nur die fehlgeschlagene Aufgabe neu. Wir haben dieses Drawback mit Wiederholungsversuchen auf DAG-Ebene und durch die Zerlegung schwerer Modelle in Ketten mittelschwerer Modelle behoben.

UDFs und benutzerdefinierte Logik. In Spark können Sie benutzerdefinierte Logik in Python direkt in der Pipeline schreiben – tremendous praktisch. Mit der neuen Architektur ist dies viel schwieriger. dbt auf Trino hilft nicht: Jinja generiert nur SQL und die Python-Modelle von dbt funktionieren nur mit Snowflake, Databricks und BigQuery. Sie können UDFs in Trino schreiben, aber nur in Java – mit dem gesamten damit verbundenen Aufwand: einem separaten Repo, einer Construct-Pipeline und der Bereitstellung von JARs für alle Employee. Wenn additionally eine Transformation nicht in SQL passt, entsteht entweder ein nicht wartbares SQL-Monster oder ein eigenständiges Skript, das die Abstammungslinie unterbricht.

Was kommt als Nächstes: Checks, Modellvorlagen und Schulungen

Bessere Checks. Wir hatten solide Pipeline-Checks in PySpark, aber die neue Architektur holt immer noch auf. In den letzten dbt-Versionen wurden Unit-Checks eingeführt – Sie können jetzt die SQL-Modelllogik anhand von Scheindaten validieren, ohne die gesamte Pipeline hochfahren zu müssen. Wir möchten DBT-Checks sowohl auf Modellebene als auch als separate Überwachungsebene hinzufügen.

Wiederverwendbare Vorlagen für gängige Muster. Viele unserer dbt-Modelle sehen gleich aus. Eine einzelne Konfiguration könnte ein Dutzend Modelle mit demselben Muster beschreiben – nur die Quelltabelle und die Filter unterscheiden sich. Wir planen, die gemeinsame Logik in DBT-Makros zu extrahieren.

Erweiterung der Nutzerbasis der Plattform. Wir möchten, dass mehr Ingenieure und Analysten unabhängig mit Daten arbeiten. Wir planen regelmäßige interne Schulungen, Dokumentationen und Onboarding-Leitfäden, damit neue Benutzer sich schnell einarbeiten und mit der Erstellung ihrer eigenen Modelle beginnen können.

Wenn Ihr Group in der gleichen Schleife „Analysten warten auf Entwickler“ feststeckt, würde ich gerne hören, wie Sie das Drawback lösen. Vernetzen Sie sich mit mir auf LinkedIn und vergleichen wir unsere Notizen.

---

Alle Bilder in diesem Artikel stammen vom Autor, sofern nicht anders angegeben.

Bild von Autor | Leinwand

# Einführung

Erhöhen Sie Ihre Hand, wenn Sie Ihre Datenanalystenkarriere in Excel gestartet haben. Ja, ich auch. Excel ist ein leistungsstarkes Instrument für die Datenanalyse und Visualisierung – und Sie wissen es. Lassen Sie uns die Excel -Witze für einen anderen Artikel behalten. Trotz der Verbesserungen bei der Behandlung größerer Datensätze gibt es einen Punkt, an dem Excel unter der Final zu knarren beginnt.

An diesem Punkt denken Sie vielleicht: „Ah, Screw Excel, ich hätte Python lernen sollen.“ Du kannst immer noch. (Lernen Sie Python, keine Schrauben Sie Excel.) Auch die Verschiebung bedeutet nicht, Excel aufzugeben. Stellen Sie sich Python als eine natürliche Erweiterung Ihrer Fähigkeiten vor, die sich in diesen Schritten widerspiegelt.

# Schritt 1: Map Excel -Fähigkeiten zu Python -Äquivalenten

Einige Excel -Fähigkeiten können auf Python übertragen werden, obwohl es sich um eine Programmiersprache handelt. Sie können es sich als „Excel ohne Raster“ vorstellen, da viele Funktionen zwischen den beiden Instruments kartieren. Hier sind einige Beispiele.

Während Sie immer noch Pythons Syntax- und Sprachgrundlagen lernen müssen, fangen Sie nicht von vorne an – Sie verstehen den Analytics -Teil des Jobs bereits. Jetzt geht es darum, in Python zu tun, was Sie bereits in Excel tun.

# Schritt 2: Python -Grundlagen lernen

Bevor Sie mit dem Codieren beginnen, machen Sie sich mit den Sprachgrundlagen vertraut. Ich empfehle mit:

• Grundlegende Syntax
• Variablen, DatentypenAnwesend SchleifenBedingungen
• Hear Und Wörterbücher (Sie sind ähnlich wie benannte Bereiche oder Suchtabellen)
• Funktionen zur Wiederverwendung von Code (sie sind wie wiederverwendbare Formeln in Excel)

Hier sind einige Ressourcen, um Ihnen den Einstieg zu erleichtern:

# Schritt 3: Richten Sie Ihre Umgebung ein

Sie brauchen keine komplizierte Python -Umgebung. Wenn Sie es lokal haben möchten, installieren Sie Anakonda. Es kommt mit Python und den wichtigsten Bibliotheken, die Sie am Anfang benötigen (PandasAnwesend NumpyUnd Matplotlib). Es beinhaltet auch Jupyter -Notizbücher; Stellen Sie sich es als Arbeitsmappe vor, in dem Sie Code und Textnotizen schreiben.

Sie können es noch einfacher machen. Wenn Sie ein Google -Konto haben, können Sie verwenden Colab. Es ist Googles Model des Jupyter -Notizbuchs und wird mit noch mehr Bibliotheken ausgestattet als Anaconda.

# Schritt 4: Beginnen Sie mit Pandas

Python ist berühmt für sein Ökosystem, reich an Bibliotheken, die seine Fähigkeiten verlängern. Einer von ihnen ist Pandaseine Bibliothek für die Datenanalyse und -manipulation. In der Datenanalyse ist es so häufig, dass es praktisch untrennbar mit Python selbst untrennbar untrennbar ist. Sobald Sie anfangen, Python zu lernen, lernen Sie auch Pandas. Einige Dinge, die Sie üben sollten, sind:

• Erstellen Datenrahmen aus Excel- oder CSV -Dateien
• Filterung, Sortieren, Verschmelzen, Aggregation
• Replizieren Sie Ihre Excel -Workflows: Drehtabellen, Suchabläufe, bedingte Berechnungen

Versuchen Sie im Allgemeinen, alles zu übersetzen, was Sie in Excel in Python Code tun.

Sobald Sie Pandas erhalten, beginnen Sie mit der Verwendung Numpyeine Bibliothek für numerisches Computing, die Pandas untermauert.

# Schritt 5: Üben Sie auf echten Daten

Der schnellste Weg zu lernen ist durch das Tun. Es gibt mehrere Optionen. Sie können lösen Analytische Fragen zu StratAscratch Und Leetcode und Übung auf echte Interviewfragen. Sie erhalten die Daten und das Drawback zu lösen. Alles, was Sie tun müssen, ist die Lösung in Python zu schreiben.

Eine andere Possibility ist die Verwendung der verfügbaren Datensätze und die Lösung der Probleme, an die Sie denken. Einige großartige Datensatzquellen sind Kaggle -DatensätzeAnwesend Knowledge.govUnd Tolle öffentliche Datensätze.

Wenn Sie einige Vorschläge für Probleme benötigen, beginnen Sie mit:

• Datenreinigung (Entfernen von Duplikaten, Standardisierungsdaten, Füllen fehlender Werte)
• Erstellen einfacher Berichte, die Sie normalerweise in Excel machen würden

# Schritt 6: Daten visualisieren

Der nächste Schritt besteht darin, Ihre Analysen zu visualisieren. Ein guter Begin ist es, in Python die Charts nachzubilden, die Sie bereits in Excel haben. Die beiden beliebtesten Python -Bibliotheken der Datenvisualisierung sind:

• Matplotlib – für Basisdiagramme (Linie, Balken, Streuung)
• Seeborn – Für fortgeschrittene Visualisierungen mit minimalem Code

# Schritt 7: Kombinieren Sie Excel und Python

Sie müssen Excel nicht aufgeben. Selbst wenn Sie wollten, konnten Sie es nicht, weil die meisten Stakeholder in Ihrer Umgebung sind verheiratet, um sich zu übertreffen.

Die ideale Kombination ist zu verwenden openpyxl oder Xlwings Um in Excel -Dateien von Python zurückzuschreiben. Mit anderen Worten, Python macht das schwere Heben im Hintergrund, aber die endgültige Ausgabe landet für die Stakeholder in Excel. Keine Notwendigkeit, hier anzuhalten; Derzeit testet Microsoft die Neue Copilot () -Funktion Dadurch können Sie KI in Excel verwenden.

# Abschluss

Wie Sie sehen können, bedeutet der Übergang von Excel nach Python nicht, dass Sie bei Null beginnen. Wenn Sie Datenanalysen in Excel durchführen, bedeutet dies bereits, dass Sie über ein grundlegendes Wissen verfügen. Sie kennen Ihre Datenanalyse. Das einzige, was es technisch anspruchsvoller macht, indem dieses Wissen auf eine Programmiersprache übertragen wird.

Befolgen Sie die Schritte in diesem Artikel, und Ihr Übergang wird reibungsloser sein als Sie denken.

Nate Rosidi ist Datenwissenschaftler und in Produktstrategie. Er ist außerdem eine zusätzliche Professorin für Lehranalysen und Gründer von Stratascratch, einer Plattform, die Datenwissenschaftlern hilft, sich auf ihre Interviews mit echten Interviewfragen von High -Unternehmen vorzubereiten. Nate schreibt über die neuesten Tendencies auf dem Karrieremarkt, gibt Interviewberatung, teilt Datenwissenschaftsprojekte und deckt alles SQL ab.

In der Autor Highlight -Serie chatten die TDS -Redakteure mit Mitgliedern unserer Neighborhood über ihren Karriereweg in Knowledge Science und KI, ihr Schreiben und ihre Inspirationsquellen. Heute sind wir begeistert, unser Gespräch mit zu teilen Mariya Mansurova.

Mariyas Geschichte ist ein ewiges Lernen. Ausgehend von einer starken Grundlage für Software program -Engineering, Mathematik und Physik hat sie mehr als 12 Jahre damit verbracht, Experience in Produktanalysen in allen Branchen zu bauen, von Suchmaschinen und Analyseplattformen bis hin zu Fintech. Ihr einzigartiger Weg, einschließlich praktischer Erfahrung als Produktmanager, hat ihr einen 360-Grad-Blick darauf gegeben, wie analytische Groups Unternehmen helfen können, die richtigen Entscheidungen zu treffen.

Jetzt als Produktanalysemanager fungiert, zieht sie Energie aus und entdeckt neue Erkenntnisse und revolutionary Ansätze. Jeder ihrer Artikel über in Richtung Knowledge Science spiegelt ihre neueste „AHA!“ Wider, die Second: Ein Beweis für ihre Überzeugung, dass Neugier den wirklichen Fortschritt treibt.

---

Sie haben ausführlich über geschrieben Agenten AI und Frameworks wie Smolagents und Langgraph. Was begeistert Sie am meisten über diesen aufstrebenden Raum?

Ich fing an, generative KI weitgehend aus Neugier und zugegebenermaßen ein bisschen FOMO zu erkunden. Jeder um mich herum schien LLMs zu verwenden oder zumindest darüber zu sprechen. Additionally habe ich Zeit geschliffen, um praktisch zu werden, angefangen mit den Grundlagen wie der Aufforderung von Techniken und LLM-APIs. Und je tiefer ich ging, desto aufgeregter wurde ich.

Was mich am meisten fasziniert, ist, wie Agentensysteme die Artwork und Weise beeinflussen, wie wir leben und arbeiten. Ich glaube, dass dieser Einfluss nur im Laufe der Zeit weiter wachsen wird. Aus diesem Grund verwende ich jede Probability, Agenten -Instruments wie Copilot oder Claude Desktop zu verwenden oder meine eigenen Agenten mit Technologien wie Smolagents, Langgraph oder Crewai zu erstellen.

Der wirkungsvollste Anwendungsfall von Agentic AI für mich struggle für mich Codierung. Es ist wirklich beeindruckend, wie Instruments wie Github Copilot die Geschwindigkeit und die Qualität Ihrer Arbeit verbessern können. Während Jüngste Forschungen Von METR hat gefragt, ob die Effizienzgewinne wirklich so erheblich sind, ich bemerke definitiv einen Unterschied in meiner täglichen Arbeit. Es ist besonders hilfreich bei sich wiederholenden Aufgaben (wie Pivoting -Tabellen in SQL) oder bei der Arbeit mit unbekannten Technologien (z. B. Erstellen einer Net -App in TypeScript). Insgesamt würde ich etwa 20% der Geschwindigkeitssteigerung schätzen. Bei diesem Schub geht es jedoch nicht nur um Produktivität. Es ist eine Paradigmenverschiebung, die auch das erweitert, was sich möglich anfühlt. Ich glaube, dass wir mit der Entwicklung von Agentenwerkzeugen eine wachsende Effizienzkluft zwischen Einzelpersonen und Unternehmen feststellen werden, die gelernt haben, diese Technologien und diejenigen zu nutzen, die es nicht getan haben.

Wenn es um Analysen geht, freue ich mich besonders über automatische Berichtsagenten. Stellen Sie sich eine KI vor, die die richtigen Daten ziehen, Visualisierungen erstellen, bei Bedarf eine Grundursache für Ursachen durchführen kann, offene Fragen beachten und sogar den ersten Entwurf der Präsentation erstellen. Das wäre einfach magisch. Ich habe gebaut ein Prototyp Das erzeugt solche KPI -Erzählungen. Und obwohl es eine signifikante Lücke zwischen dem Prototyp und einer Produktionslösung gibt, die zuverlässig funktioniert, werden wir glaube, dass wir dort gelangen werden.

Sie haben drei Artikel unter dem „geschrieben“Praktische Computersimulationen für Produktanalysten”Serie. Was hat diese Serie inspiriert und wie kann Simulation die Produktanalyse neu formen?

Die Simulation ist ein stark nicht ausgelastetes Werkzeug in der Produktanalyse. Ich habe diese Serie geschrieben, um den Menschen zu zeigen, wie mächtig und zugänglich die Simulationen sein können. In meiner täglichen Arbeit begegne ich immer wieder, was-wenn Fragen wie “Wie viele operative Agenten brauchen wir, wenn wir diese KYC -Kontrolle hinzufügen?“ oder „Was hat die wahrscheinliche Auswirkungen der Einführung dieser Funktion in einem neuen Markt?“. Sie können jedes System simulieren, egal wie komplex. Simulationen gaben mir additionally eine Möglichkeit, diese Fragen quantitativ und ziemlich genau zu beantworten, selbst wenn noch harte Daten noch nicht verfügbar waren. Ich hoffe additionally, dass mehr Analysten diesen Ansatz verwenden werden.

Simulationen leuchten auch bei der Arbeit mit Unsicherheit und Verteilungen. Persönlich bevorzuge ich Bootstrap -Methoden, um eine lange Liste statistischer Formeln und Signifikanzkriterien auswendig zu lernen. Das Simulieren des Prozesses fühlt sich oft intuitiver an und ist in der Praxis weniger fehleranfällig.

Schließlich finde ich es faszinierend, wie sich die Technologien in der Artwork und Weise verändert haben, wie wir Dinge tun. Mit der heutigen Rechenleistung, bei der ein Laptop computer in Minuten oder sogar Sekunden Tausende von Simulationen durchführen kann, können wir leicht Probleme lösen, die vor dreißig Jahren eine Herausforderung gewesen wären. Das ist ein Spielveränderer für Analysten.

Einige Ihrer Beiträge konzentrieren sich auf den Übergang von LLM -Anwendungen von Prototyp Zu Produktion. Welche häufigen Fallstricke sehen Sie Groups in dieser Section?

Durch die Praxis habe ich festgestellt, dass zwischen LLM -Prototypen und Produktionslösungen, die viele Groups unterschätzen. Die häufigste Fallstricke ist die Behandlung von Prototypen, als ob sie bereits produktionsbereit sind.

Die Prototypphase kann täuschend glatt sein. Sie können in ein oder zwei Stunden etwas Funktionales bauen, es an einer Handvoll Beispiele testen und das Gefühl haben, das Drawback zu knacken. Prototypen sind großartige Werkzeuge, um die Machbarkeit zu beweisen und Ihr Crew über die Chancen zu begeistern. Aber hier stolpern Groups oft: Diese frühen Versionen bieten keine Garantien für Konsistenz, Qualität oder Sicherheit, wenn es sich um unterschiedliche, reale Szenarien handelt.

Was ich gelernt habe ist, dass eine erfolgreiche Produktionsbereitstellung mit einer strengen Bewertung beginnt. Bevor Sie etwas skalieren, benötigen Sie klare Definitionen darüber, wie „gute Leistung“ in Bezug auf Genauigkeit, Tonfall, Geschwindigkeit und andere für Ihren Anwendungsfall spezifische Kriterien aussieht. Dann müssen Sie diese Metriken kontinuierlich verfolgen, während Sie es iterieren, um sicherzustellen, dass Sie sich tatsächlich verbessern, anstatt nur die Dinge zu ändern.

Stellen Sie sich dies wie Software program -Exams vor: Sie würden keinen Code ohne ordnungsgemäße Exams versenden, und LLM -Anwendungen erfordern denselben systematischen Ansatz. Dies wird in regulierten Umgebungen wie Fintech oder Healthcare besonders wichtig, wo Sie nicht nur Ihrem internen Crew, sondern auch den Stakeholdern der Compliance zuverlässig sind.

In diesen regulierten Räumen benötigen Sie umfassende Überwachung, Überprüfungsprozesse und Prüfungswege, die der Prüfung standhalten können. Die Infrastruktur, die erforderlich ist, um all dies zu unterstützen, braucht häufig weit mehr Entwicklungszeit als der Aufbau des ursprünglichen MVP. Das ist etwas, das Groups konsequent überrascht, die sich hauptsächlich auf die Kernfunktionalität konzentrieren.

Ihre Artikel verbinden manchmal Engineering -Prinzipien mit den Greatest Practices von Knowledge Science/Analytics, wie z. B. Ihre “High 10 Engineering -Lektionen, die jeder Datenanalyst kennen sollte.Denken Sie, dass die Grenze zwischen Daten und Engineering verwischt ist?

Die Rolle eines Datenanalystens oder eines Datenwissenschaftlers erfordert heute häufig eine Mischung aus Fähigkeiten aus mehreren Disziplinen.

• Wir schreiben Code und teilen uns gemeinsam mit Software program -Ingenieuren.
• Wir helfen Produktteams, Strategie zu überdenken und Entscheidungen zu treffen, sodass Produktmanagementfähigkeiten nützlich sind.
• Wir stützen uns auf Statistiken und Datenwissenschaften, um strenge und umfassende Analysen aufzubauen.
• Und um unsere Erzählungen zu überzeugen und Entscheidungen tatsächlich zu beeinflussen, müssen wir die Kunst der Kommunikation und Visualisierung beherrschen.

Persönlich hatte ich das Glück, früh in der Schule und in der Universität verschiedene Programmierkenntnisse zu erwerben. Dieser Hintergrund hat mir bei der Analytik enorm geholfen: Er hat meine Effizienz erhöht, mir besser mit Ingenieuren zusammenarbeiten und mir beigebracht, wie man skalierbare und zuverlässige Lösungen aufbaut.

Ich ermutige Analysten nachdrücklich, die Greatest Practices für Software program -Engineering zu übernehmen. Dinge wie Versionskontrollsysteme, Exams und Codeüberprüfung helfen analytische Groups, zuverlässigere Prozesse zu entwickeln und Ergebnisse höherwertiger Qualität zu liefern. Ich denke nicht, dass die Grenze zwischen Daten und Engineering vollständig verschwindet, aber ich glaube, dass Analysten, die eine technische Denkweise annehmen, in modernen Knowledge -Groups weitaus effektiver sein werden.

Sie haben beide erforscht kausale Inferenz und modernste LLM-Tuning-Techniken. Sehen Sie diese als Teil eines gemeinsam genutzten Toolkits oder separaten Denkweisen?

Das ist eigentlich eine großartige Frage. Ich bin fest davon überzeugt, dass all diese Werkzeuge (von statistischen Methoden bis hin zu modernen ML -Techniken) zu einem einzigen Toolkit gehören. Wie Robert Heinlein berühmt sagte: „Spezialisierung ist für Insekten.“

Ich denke an Analysten als Datenassistent, die ihren Produktteams helfen, ihre Probleme mithilfe von Instruments zu lösen, die am besten passen: unabhängig davon, ob es sich um einen LLM-angetriebenen Klassifizierer für NPS-Kommentare erstellt, wobei kausale Schlussfolgerungen zur Treffen strategischer Entscheidungen oder zum Erstellen einer Net-App zur Automatisierung von Workflows verwendet werden.

Anstatt sich auf bestimmte Fähigkeiten zu spezialisieren, konzentriere ich mich lieber auf das Drawback, das wir lösen, und halte das Toolset so weit wie möglich. Diese Denkweise führt nicht nur zu besseren Ergebnissen, sondern fördert auch eine kontinuierliche Lernkultur, die in der heutigen schnelllebigen Datenbranche von wesentlicher Bedeutung ist.

Sie haben eine breite Palette von Themen behandelt, von Texteinbettungen Und Visualisierungen Zu Simulation Und Multi -AI -Agent. Welches Schreibgewohnheit oder das Leitprinzip hilft Ihnen, Ihre Arbeit so kohärent und zugänglich zu halten?

Normalerweise schreibe ich über Themen, die mich im Second erregen, entweder weil ich gerade etwas Neues gelernt habe oder eine interessante Diskussion mit Kollegen geführt habe. Meine Inspiration stammt oft von On-line-Kursen, Büchern oder meinen täglichen Aufgaben.

Wenn ich schreibe, denke ich immer an mein Publikum und wie dieses Stück sowohl für andere als auch für mein zukünftiges Selbst wirklich hilfreich sein kann. Ich versuche, alle Konzepte klar zu erklären und jedem, der tiefer graben möchte, Brotkrumen hinterlassen. Im Laufe der Zeit ist mein Weblog zu einer persönlichen Wissensbasis geworden. Ich kehre oft zu alten Beiträgen zurück: Manchmal nur um ein Code -Snippet zu kopieren, manchmal um eine Ressource mit einem Kollegen zu teilen, der an etwas Ähnlichem arbeitet.

Wie wir alle wissen, ist alles in Daten miteinander verbunden. Das Lösen eines realen Issues erfordert häufig eine Mischung aus Werkzeugen und Ansätzen. Wenn Sie beispielsweise die Auswirkungen des Begins in einem neuen Markt schätzen, können Sie Simulation für die Szenarioanalyse, LLMs verwenden, um die Kundenerwartungen und die Visualisierung zu untersuchen, um die endgültige Empfehlung zu ermitteln.

Ich versuche, diese Verbindungen in meinem Schreiben zu reflektieren. Technologien entwickeln sich, indem sie sich auf früheren Durchbrüchen aufbauen, und das Verständnis der Fundamente hilft Ihnen, tiefer zu gehen. Deshalb verweisen sich viele meiner Beiträge gegenseitig und lassen die Leser ihrer Neugier folgen und aufdecken, wie unterschiedliche Teile zusammenpassen.

Ihre Artikel sind beeindruckend strukturiert und wandeln sich häufig von grundlegenden Konzepten bis hin zu fortgeschrittenen Implementierungen. Was ist Ihr Prozess, um ein komplexes Stück vor dem Schreiben zu skizzieren?

Ich glaube, ich habe diese Artwork der Präsentation von Informationen in der Schule entwickelt, da diese Gewohnheiten tiefe Wurzeln haben. Als Buch Die Kulturkarte Erklärt, unterschiedliche Kulturen unterscheiden sich in der Artwork und Weise, wie sie die Kommunikation strukturieren. Einige sind Konzept-First-First (ausgehend von Grundlagen und iterativ zu Schlussfolgerungen), während andere Anwendungen zuerst sind (beginnend mit den Ergebnissen und bei Bedarf tiefer). Ich habe den Konzept-ersten Ansatz definitiv verinnerlicht.

In der Praxis sind viele meiner Artikel von On-line -Kursen inspiriert. Während ich einen Kurs ansehe, skizziere ich die grobe Struktur parallel, damit ich keine wichtigen Nuancen vergesse. Ich notiere auch alles, was unklar ist, und markiere es für zukünftiges Lesen oder Experimentieren.

Nach dem Kurs überlege ich, wie ich dieses Wissen auf ein praktisches Beispiel anwenden kann. Ich bin fest davon überzeugt, dass Sie etwas nicht wirklich verstehen, bis Sie es selbst versuchen. Obwohl die meisten Kurse praktische Beispiele haben, sind sie oft zu poliert. Nur wenn Sie dieselben Ideen für Ihren eigenen Anwendungsfall anwenden, werden Sie auf Kantenfälle und Reibungspunkte begegnen. Zum Beispiel kann der Kurs OpenAI -Modelle verwendet, aber ich möchte vielleicht ein lokales Modell ausprobieren, oder die Standardsystemaufforderung im Framework funktioniert für meinen speziellen Fall nicht und muss optimiert werden.

Sobald ich ein arbeitendes Beispiel habe, wechsle ich zum Schreiben. Ich bevorzuge separate Zeichnen von der Bearbeitung. Zunächst konzentriere ich mich darauf, alle meine Ideen und den Code zu räumen, ohne mich um Grammatik oder Ton zu kümmern. Dann wechsle ich in den Bearbeitungsmodus: Verfeinerung der Struktur, die Auswahl der richtigen Grafiken, die Zusammenstellung der Einführung und die Hervorhebung der wichtigsten Imbissbuden.

Schließlich habe ich das Ganze von Anfang an gelesen, um etwas zu fangen, was ich verpasst habe. Dann bitte ich meinen Accomplice, es zu überprüfen. Sie bringen oft eine neue Perspektive und weisen auf Dinge hin, die ich nicht in Betracht gezogen habe, was dazu beiträgt, dass der Artikel umfassender und zugänglicher wird.

---

Um mehr über Mariyas Arbeit zu erfahren und mit ihren neuesten Artikeln auf dem Laufenden zu bleiben, folgen Sie ihr hier auf Tds und weiter LinkedIn.

Meine Reise in die Datenwissenschaft begann mit einer Krise.

Am Montagmorgen um 9:01 Uhr summte mein Telefon mit einem PagerDuty-Alarm. Instinktiv rief ich das Dashboard des Unternehmens auf und sah, dass die Kreditgenehmigungsraten verdoppelt über Nacht.

Mein Herz begann zu rasen.

Ich conflict damals Risikoanalyst und verwaltete ein Kreditportfolio. Die Genehmigung von Krediten für ein Section mit höherem Risiko konnte große Auswirkungen auf die Verlustquote haben.

Mit verschlafenen Augen vertiefte ich mich in die Daten.

Ich sage verzweifelt:

• Schrieb SQL-Abfragen zum Abrufen von Daten,
• Analysieren Sie die Daten in Python, um Anomalien zu erkennen.
• Suche nach Mustern, die den plötzlichen Anstieg der Zustimmungsraten erklären könnten.

Ich stellte fest, dass sich ein bestimmtes Merkmal des Kreditmodells verschoben hatte.

Es stellte sich heraus, dass es sich um einen einfachen Zeitzonenfehler handelte.

Dieser Vorfall markierte einen Wendepunkt in meiner Karriere und conflict der Beginn meiner Reise vom Datenanalysten zum Datenwissenschaftler.