Pachyderm Documentation

repository·master·Indexed 27 days ago

https://github.com/pachyderm/pachyderm

Pachyderm is a data versioning and lineage platform that automates complex data transformation pipelines using Kubernetes for orchestration. This documentation covers the Pachyderm Console development, including installation, local development mode, environment variable configuration, and E2E testing with Cypress. It also provides guides for running REST and GraphQL API throughput tests, managing protobuf code, deploying test DAGs, and configuring OpenTracing with Jaeger.

Tokens
122.1K
Snippets
243
Records
673
Agent score
92%

What's inside Pachyderm

  1. Use S3 Gateway to interact with PFS storage

    master
    Starting in version 1.9.0, Pachyderm exposes an S3 interface to the data stored in the PFS. This allows applications to interact with Pachyderm storage using standard S3 protocols. Version 1.9.4 added support for multi-part uploads, multi-deletes, and authentication.
  2. Configure Pachyderm to report traces to Jaeger

    master
    Pachyderm can report and propagate OpenTracing traces to Jaeger. This is useful for diagnosing slow calls or slow clusters within your environment. To implement this, you must deploy Jaeger in your Kubernetes cluster using the manifests provided in the etc/deploy/tracing/ directory and then configure Pachyderm to point to the Jaeger endpoint. For detailed configuration steps, refer to the primary guide at doc/deployment/tracing.md.
  3. Deploy Pachyderm via Helm

    master

    Deploy Pachyderm using the pachyderm/pachyderm Helm chart. To activate Enterprise and RBAC authorization, you must provide the PACHYDERM_ENTERPRISE_KEY via the --set pachd.enterpriseLicenseKey flag.

    For Docker Desktop

    # Ensure you are in the root of the project
    $ helm install \
            --wait --timeout 10m pachd pachyderm/pachyderm \
            --version=2.6.0 \
            -f enterpriseProxyHelmValues.yaml \
            --set pachd.metrics.enabled=false \
            --set pachd.enterpriseLicenseKey=$PACHYDERM_ENTERPRISE_KEY

    For Kind

    # Ensure you are in the root of the project
    $ helm install \
            --wait --timeout 10m pachd pachyderm/pachyderm \
            --version=2.6.0 \
            -f enterpriseProxyHelmValues.yaml \
            --set pachd.metrics.enabled=false \
            -f kind.yaml \
            --set pachd.enterpriseLicenseKey=$PACHYDERM_ENTERPRISE_KEY
    # Docker Desktop example
    $ helm install \
            --wait --timeout 10m pachd pachyderm/pachyderm \
            --version=2.6.0 \
            -f enterpriseProxyHelmValues.yaml \
            --set pachd.metrics.enabled=false \
            --set pachd.enterpriseLicenseKey=$PACHYDERM_ENTERPRISE_KEY
  4. Implement datum batching with NextDatum

    master

    When running user code in a pipeline with datum batching enabled, you should call NextDatum to signal that the current datum has been processed and the code is ready for the next one.

    Important Notes:

    • NextDatum is a synchronous operation; your code will block until the next datum is set up.
    • The response NextDatumResponse contains an env field (a list of strings) representing environment variables that should be set for the next datum's processing.
    • If processing a datum fails, you can pass the error string in the NextDatumRequest.error field. This allows the system to handle retries or job failures according to datum error semantics.
    ### Worker
    
    | Method Name | Request Type | Response Type | Description |
    | ----------- | ------------ | ------------- | ------------|
    | Status | [.google.protobuf.Empty](#google-protobuf-Empty) | [.pps_v2.WorkerStatus](#pps_v2-WorkerStatus) |  |
    | Cancel | [CancelRequest](#pachyderm-worker-CancelRequest) | [CancelResponse](#pachyderm-worker-CancelResponse) |  |
    | NextDatum | [NextDatumRequest](#pachyderm-worker-NextDatumRequest) | [NextDatumResponse](#pachyderm-worker-NextDatumResponse) | NextDatum should only be called by user code running in a pipeline with datum batching enabled. NextDatum will signal to the worker code that the user code is ready to proceed to the next datum. This generally means setting up the next datum's filesystem state and updating internal metadata similarly to datum processing in a normal pipeline. NextDatum is a synchronous operation, so user code should expect to block on this until the next datum is set up for processing. User code should generally be migratable to datum batching by wrapping it in a loop that calls next datum.
  5. Develop with a Dev Container workflow

    master

    For macOS users or those wanting a containerized environment, use the Dev Container workflow. This requires a running Pachyderm instance (e.g., via kubectl port-forward service/pachd 30650:30650).

    1. Start the container:
      docker run --name jupyterlab_pachyderm_frontend_dev \
      -p 8888:8888 \
      -it -e GRANT_SUDO=yes --user root \
      --device /dev/fuse --privileged \
      -v $(pwd):/home/jovyan/extension-wd \
      -w /home/jovyan/extension-wd \
      pachyderm/notebooks-user:<latest master SHA> \
      bash
     *Note: On Linux, add `--net=host` to talk to minikube. On macOS, use `grpc://host.docker.internal:30650` instead of localhost.*
    
    2. **Inside the container**, install and start:
     ```bash
    pip install -e ".[dev]"
    
     jupyter labextension develop --overwrite
    
     jupyter server extension enable jupyterlab_pachyderm
    
     jupyter lab --allow-root
    1. Watch for changes: In a separate terminal (via docker exec), run:
      npm run watch
    
    ```bash
    # Example docker run command
    docker run --name jupyterlab_pachyderm_frontend_dev \
      -p 8888:8888 \
      -it -e GRANT_SUDO=yes --user root \
      --device /dev/fuse --privileged \
      -v $(pwd):/home/jovyan/extension-wd \
      -w /home/jovyan/extension-wd \
      pachyderm/notebooks-user:<latest master SHA> \
      bash
  6. Build and Load Containers

    master

    Containers are defined in the oci/ directory.

    Building Images

    • Build local architecture image: bazel build //oci:pachd_image (builds for the host architecture).
    • Multi-arch indexes: pachd, pachctl, and worker are available as multi-arch image indexes.

    Loading and Pushing

    • Load to local Docker daemon: Run bazel run //oci:load or bazel run //oci:load_pachctl to make images available for docker run.
    • Push to production: Run bazel run --stamp //oci:push to push to DockerHub (uses credentials from ~/.docker/config.json). Note: Only CI should typically run this command.
    bazel build //oci:pachd_image
    bazel run //oci:load
    bazel run --stamp //oci:push
  7. Run Console E2E tests with Cypress

    master

    End-to-End (E2E) tests run against a real Pachyderm cluster. Before running, ensure your local Pachyderm and Console setup matches the target edition (Community or Enterprise).

    Prerequisites:

    1. Run a local Pachyderm cluster (see README_Pachyderm.md).
    2. Run the Console locally using make launch-dev.

    Running the suites:

    • Enterprise Edition (Authenticated):

      make e2e-auth
    • Community Edition (Unauthenticated):

      1. Add the PACHYDERM_ENTERPRISE_KEY environment variable with a valid key to your .env.development.local file.
      2. Run:
      make e2e
    make e2e-auth
    # OR
    make e2e
  8. Profile Go tests with perf and hotspot

    master
    To perform whole-system profiling of tests, build Go binaries in debug mode and run them outside the Bazel sandbox using the local spawn strategy. This allows tools like hotspot to inspect the binaries.