Author: DEROBS

Amazon has announced a functional update to its business intelligence service, Amazon QuickSight, enhancing its layer map visuals with support for Point and LineString geometry types. This development extends the platform’s existing GeoJSON workflow, which was previously limited to polygon shapes such as sales territories or regional boundaries.

New capabilities for spatial data

By incorporating Point and LineString geometries, users can now represent granular spatial data directly on interactive dashboards. Point features allow for the mapping of individual locations, such as retail stores or facility sites. LineString features enable the visualization of movement or connections between locations, such as flight paths, shipping lanes, or delivery routes.

Unlike QuickSight’s native point maps, which geocode location names automatically, layer map visuals require users to provide explicit coordinates within a GeoJSON file. This configuration offers distinct advantages for specific use cases, including the ability to lock the map’s viewport to a fixed geographic region, thereby preventing users from inadvertently panning or zooming away from the intended area.

Technical implementation

The implementation requires a GeoJSON file—with a maximum file size of 100 MB—and a corresponding QuickSight dataset. Data linking is achieved through a shared join key found in both the GeoJSON properties and the dataset rows. Once linked, users can customize map layers by adjusting color, line width, and opacity to improve data clarity.

For complex visualizations, such as displaying customer distribution within specific territories or highlighting stops along a logistics route, QuickSight supports layering multiple visuals. By utilizing free-form layout settings, administrators can stack multiple layer map visuals to create a composite view. Each sheet supports up to five stacked layer map visuals.

Operational considerations

While standard QuickSight visuals update dynamically through SPICE or Direct Query, GeoJSON-based layer map geometry is static. Updates to locations or routes require either a manual re-upload of the GeoJSON file via the console or a programmatic approach using Amazon S3 and the QuickSight API. For automated workflows, developers can reference updated GeoJSON files stored in S3 and utilize the UpdateDashboard and UpdateDashboardPublishedVersion APIs to deploy changes to end users.

This update provides data analysts with more precise control over map-based insights, catering to scenarios where static geographic context is essential for operational reporting.

Source: aws.amazon.com
Original article: https://aws.amazon.com/blogs/machine-learning/visualize-points-and-routes-with-geojson-in-amazon-quick-sight-layer-maps/

Updating Amazon SageMaker AI real-time endpoints—such as modifying instance types or environment variables—can often result in deployment failures when using AWS CloudFormation or the AWS Cloud Development Kit (CDK). This challenge arises because SageMaker requires the deregistration of scalable targets before an endpoint configuration can be updated. When these processes are managed natively, CloudFormation often loses the ability to track Application Auto Scaling resources, leading to stuck states or endpoints running without auto-scaling capabilities.

Solving Orchestration Challenges

To address these limitations, a reusable CDK construct has been developed that utilizes custom resources to orchestrate the auto-scaling lifecycle during endpoint updates. Instead of relying on native resources alone, this solution employs three custom resources to manage the transition automatically:

• Deregister: Removes the scalable target before the endpoint update begins to prevent conflict.
• Register Scalable Target: Monitors the endpoint status and registers the target once it reaches an InService state.
• Attach Scaling Policy: Waits for the target to be ready before applying the designated scaling policy.

The construct uses a ConfigHash property, which ensures that CloudFormation triggers the necessary orchestration sequence whenever a change to the endpoint configuration or scaling parameters is detected. By leveraging the asynchronous completion pattern of the CDK provider framework, these operations can accommodate the time required for endpoints to initialize, preventing issues associated with standard Lambda timeouts.

Implementation and Integration

The solution provides a robust mechanism for developers to define endpoint parameters—such as instance types and model data URLs—alongside auto-scaling settings like minimum and maximum capacity within a single configuration. This approach ensures that updates are treated as a single, orchestrated event, reducing the need for manual intervention via the AWS CLI or the management console.

For organizations looking to integrate this logic into existing projects, the construct can be implemented by adding the required source files directly into a project and wrapping the existing endpoint definition. This method provides a cleaner, more resilient deployment pipeline for machine learning workloads, ensuring that infrastructure remains consistent across environment updates.

Source: aws.amazon.com
Original article: https://aws.amazon.com/blogs/machine-learning/orchestrating-sagemaker-ai-endpoint-auto-scaling-with-aws-cdk/

OpenAI has released technical details regarding the evolution of its Habitat storage infrastructure, designed to accommodate more than one billion ChatGPT users. The company reported that it has successfully implemented a series of optimizations to maintain performance and reliability at this scale.

A core component of these improvements involves the integration of Azure Cosmos DB, which serves as a central element of the platform’s storage strategy. By incorporating reliable multi-tenancy models and implementing global caching techniques, OpenAI stated that it has achieved read speeds that are 12 times faster than previous configurations.

These architectural updates are intended to ensure that the infrastructure can sustain high demand while maintaining consistent performance across the platform’s global operations.

Source: OpenAI
Original article: https://openai.com/index/scaling-storage-one-billion-users-part-two