To continue my last article on SAS new Enhanced Compute Engine, I will in this post help you understand when to leverage ECE over CAS.   Analytics is experiencing a shift as organizations demand greater flexibility, scalability, and efficiency from their data platforms. As a response, SAS has continued to innovate with SAS Viya. Two critical components at the heart of this innovation are Cloud Analytic Services (CAS) and the Enhanced Compute Engine (ECE). In this blog, we’ll break down what sets ECE and CAS apart, examine their unique strengths, and provide practical guidance to help you select the right engine for your business needs. Whether you’re running large-scale enterprise analytics or focused on agile, programming-centric projects, understanding these technologies will empower your organization to maximize value and performance.   Introduction As mentioned, the analytics landscape is evolving rapidly, and SAS Viya is at the forefront of this transformation. Traditionally, Cloud Analytic Services (CAS) has been the powerhouse behind SAS Viya’s in-memory analytics. But with the introduction of the Enhanced Compute Engine (ECE), SAS is redefining flexibility and cost efficiency for modern workloads.    Why SAS Introduced Enhanced Compute CAS delivers exceptional performance for large-scale, multi-user analytics. However, not every workload requires a dedicated CAS cluster. Many customers need a lighter, more cost-effective option for programming-centric tasks, proof-of-concepts, and Python-driven analytics.   ECE addresses this need by enabling CAS-enabled procedures to run in-process on the Compute Server—without requiring CAS infrastructure. This is part of SAS’s CAS-optional strategy, reducing complexity and total cost of ownership. This flexibility gives teams the freedom to scale resources up or down based on current project needs, making analytics more accessible and budget friendly.   Key Advantages of Enhanced Compute Enhanced Compute offers significant benefits, including lower total cost of ownership by making CAS optional and reducing infrastructure needs, with early benchmarks showing up to a 70% reduction in footprint for programming-only workloads. Deployment is simplified since many tasks no longer require a CAS cluster, making operations less complex. The platform is optimized for Python-focused development, supporting flexible and rapid analytics, and maintains backward compatibility by running SAS PROCs and CAS-enabled procedures.   Where CAS Still Wins Large Data & Massively Parallel Processing (MPP) - CAS is essential for massive datasets, multi-user environments, and global table semantics. Advanced Analytics Pipelines - CASL scripting and collaborative workflows thrive in CAS. Scheduled Heavy Jobs - Nightly batch or compute-intensive tasks benefit from CAS’s distributed architecture. Visual Interfaces - CAS is still the backbone for SAS Viya’s visual interfaces like Visual Analytics, and you will still need a CAS server to serve the result from SpeedyStore if you have that in your SAS Viya architecture.   CAS is crucial for handling large-scale data and complex batch processing, supporting multi-user environments, and enabling global table functionality. It excels in advanced analytics pipelines that require collaborative workflows, as well as running scheduled, compute-intensive batch jobs, all of which benefit from its robust, distributed architecture.   Aspect Enhanced Compute Engine (ECE) Cloud Analytic Services (CAS) Execution Model In-process, serverless compute Singel Server or distributed, in-memory engine  Best For SAS code, Python-centric workflows, ad-hoc and batch-jobs Enterprise-scale analytics, multi-user concurrency Visual Interfaces SAS Studio, VSCode, SAS Enterprise Guide Visual Analytics, Model Studio, SAS Studio, VSCode, SAS Enterprise Guide Scalability Single-container, elastic compute pods Multi-node MPP Table management Session tables Session and Global/promoted tables   Value of shared global tables Traditionally, when using the enhanced compute, just in like SAS 9.4 you need to extract some data from somewhere put it in your SAS WORK, then do analytics, meaning that there might be many users duplicating the same data, and if he dataset is large, there will be a need for expensive high performant storage for cashing the data in SAS WORK. Since each SAS session will have its own compute instance and its own SAS WORK.   CAS handles this is a bit different. If a table is loaded to CAS and promoted to a global table, users how have access to it can rely on the same table for ex. BI, analytics and model training. In some cases, this can be the most cost-efficient alternative.   Looking ahead ECE is part of SAS’s vision for a CAS-optional future, integrating on-demand analytic servers and multi-language architecture. CAS remains critical for high-scale scenarios, but ECE reduces complexity for many customers, especially those modernizing from SAS 9.4 to Viya.   Closing Thoughts Choosing between CAS and ECE depends on your workload profile: If you need; distributed compute for large datasets, collaboration, or global tables that many users can share, CAS is your go-to. If you want cost efficiency, simplicity, and Python-first workflows, ECE is the future. And it has all the advanced PROC’s that you earlier need CAS to access. ... View more

This juletip covers bought Visual Analytics 7.x and 8.x   Visual Analytics 7.x  Requires SAS/GRAPH    If you want to visualize your data using a map object in Visual Analytics with custom coordinates, you better hope that your longitude and latitude coordinates are in WGS84 format, or at least that was what I thought until recently.  I found out that the dataset SASHELP.PROJ4DEF contains 7124 different coordinate definitions and that we can convert between these with the help of PROC GPROJECT.    Step one, find your coordinate system  My suggestion would be to search the DESC variable in SASHELP.PROJ4DEF (see code example below). Identify name of the target coordinate system, for WGS 84 the name is "EPSG:4326".      proc sql;  select *   from SASHELP.PROJ4DEF  where upcase(DESC) like '%SWEREF99 TM%';  quit;    When you have found the names for the source and target coordinate systems we can move on to converting the data. In my example below there is one observation containing the coordinates for the city of Malmö in SWEREF99 TM format.      data coordinates;  input City $ Longitude Latitude;  datalines;  Malmö 373547 6163386  ;  run;    Step two, convert the data  To do this you need to rename your longitude and latitude variables to X and Y, specify the output dataset and the names of the from and to coordinate systems. You also need to specify City as ID.     /* Convert SWEREF99 TM to WGS84 */  proc gproject   data=coordinates (rename=(Longitude=X Latitude=Y))   out= coordinates_WGS84  project=proj4   from="EPSG:3006" /* SWEREF99 TM */  to="EPSG:4326";  /* WGS 84 */  id City;  run;    Step three, visualize and PROFIT!      Visual Analytics 8.x  When you are using Visual Analytics 8.x the conversion above aren’t necessary! You create your custom geography item like you are used to do in the 7.x version but when you specify the coordinate space you choose Custom and then enter the name of the coordinate system you found in the SASHELP.PROJ4DEF table. In my case “EPSG:3006” for SWEREF99 TM.      ... View more