Airbnb

O produto do Airbnb é compartilhamento de casas. A influência deles em data engineering é desproporcional — eles open-sourceram duas das ferramentas que moldam a maioria dos times de dados modernos:

• Apache Airflow (originalmente interno do Airbnb, hoje o orquestrador default)
• Apache Superset (a ferramenta interna de BI, hoje o BI open-source líder)

Mais o Dataportal (conceito de catálogo de dados, gerou o Amundsen e inspirou o DataHub) e o Knowledge Repo (writeups analíticos longos).

Se você já se perguntou por que "usa Airflow" é a resposta default pra perguntas de orquestração no Stack Overflow — é por isso. Entender a plataforma do Airbnb é entender as restrições de design que essas ferramentas foram feitas pra resolver.

O Airbnb construiu o Airflow em 2014 porque cron + shell scripts não expressavam os DAGs que o time de dados escrevia: "recompute features de pricing depois que o pipeline de eventos terminar, a menos que a tabela de trust upstream tenha falhado, aí manda alerta."

A ideia central do Airflow que pegou:

• DAGs como código em Python — versionados, revisados, testados como qualquer outro software
• Operators encapsulam trabalho (BashOperator, PythonOperator, SparkSubmitOperator, operator do dbt...)
• Task instances são a unidade de retry, alerta e observabilidade

Um DAG mínimo mas com cara de produção:

from airflow import DAG
from airflow.decorators import task
from datetime import datetime

with DAG(
    "listing_features_daily",
    start_date=datetime(2026, 1, 1),
    schedule="0 4 * * *",  # 4h UTC diariamente
    catchup=False,
    default_args={"retries": 3, "retry_delay": timedelta(minutes=10)},
) as dag:

    @task
    def wait_for_bookings():
        # sensor na tabela bronze upstream
        ...

    @task
    def compute_features(**context):
        # job Spark que escreve em silver.listing_features
        ...

    @task
    def publish_metric():
        # registro da métrica no Minerva
        ...

    wait_for_bookings() >> compute_features() >> publish_metric()

10.000+ DAGs como esse rodam todo dia no Airbnb. É menos "orquestrador" e mais "sistema operacional da plataforma de dados".

A ferramenta interna mais subestimada do Airbnb é o Minerva — a plataforma de métricas. O problema que resolve: cinco dashboards diferentes mostrando "bookings" com cinco números diferentes.

O Minerva impõe uma fonte única de verdade para métricas:

• Toda métrica é definida uma vez, em YAML, com suas dimensões, agregação e granularidade
• A plataforma gera as tabelas subjacentes no lakehouse
• Superset, Druid, notebooks e serviços todos consultam tabelas certificadas pelo Minerva
• Quer uma métrica nova? Abre um PR; owners aprovam, a plataforma materializa

É o padrão pro qual dbt Semantic Layer, Cube.dev e Looker LookML apontam. O Airbnb construiu internamente em 2019 porque BI sem camada semântica vira caos na escala deles.

O Superset existe porque o Airbnb queria que analistas, PMs e até execs respondessem as próprias perguntas sem abrir ticket pro time de dados. É uma ferramenta de BI enxuta: conecta em Presto/Druid/Snowflake, escreve SQL, salva um chart, monta um dashboard.

Duas decisões de design importam pra escala:

• Cache de query + controle de acesso row-level — dá pra botar o Superset na frente de um warehouse de produção sem morrer de queries repetidas.
• SQL Lab — um notebook de SQL de primeira classe. Analistas não vão pra outra ferramenta pra explorar antes de fazer um chart.

O Superset hoje sustenta dashboards no Airbnb, Netflix, Twitter, Dropbox, Wikipedia e milhares de times menores. É como "BI self-service" fica quando é construído por engenheiros de dados, não vendido por eles.

A arquitetura medallion do Airbnb (bronze → silver → gold) hoje é o padrão de referência da indústria:

• Bronze: eventos brutos aterrissados como vieram do Kafka. Schema-on-read.
• Silver: limpo, deduplicado, com join em tabelas de dimensão. Schema imposto.
• Gold: agregados de negócio. É o que dashboards e modelos consomem.

Mesmo padrão que a Databricks hoje vende como "medallion architecture". O Airbnb já fazia em 2018 porque o layout Hive flat antigo não sobrevivia a schema drift e eventos duplicados. Os nomes são novos; o padrão é mais antigo.

• Métricas moram numa camada semântica, não num dashboard. Se o mesmo "revenue" está definido em sete charts do Superset, você não tem sete charts — tem sete definições de revenue. dbt semantic layer, Cube ou um Minerva-lite caseiro — escolha uma, mas centralize.
• Airflow primeiro, depois questione o Airflow. Pra maioria dos times, Airflow é o default certo. Só quando você sente dor real (DAGs dinâmicos, scheduling sub-segundo, sensibilidade de custo por task) Dagster/Prefect/Temporal viram escolhas óbvias.
• O catálogo não é opcional. O Airbnb construiu o Dataportal porque 1.500 usuários não conseguem perguntar "qual tabela tem o dado real de bookings?" 1.500 vezes. Entregue um catálogo no dia um, mesmo que seja uma planilha.
• Medallion é piso, não teto. Bronze/silver/gold é como "qualidade de dados suficiente" se parece. Pule isso e toda tabela downstream vai ter que reimplementar dedup + join.