Explore Yellowfin now with our sample datasetGet Started
Yellowfin is platform agnostic – you can deploy it anywhere you choose. This includes on-premise or in the cloud. You can choose whatever operating system you want, provided it supports a JVM. You also have a wide range of choices for the configuration database.
Many customers choose to deploy Yellowfin using container technologies such as Docker.
Yellowfin will work with all of the major cloud providers including AWS, Azure, GCP, and more.
Yellowfin can be installed on Windows, Linux, or Mac OSX based desktop or laptop for evaluation or training purposes and installed on Windows, Linux, or Mac OSX based servers for evaluation, training, and production purposes.
Configuration data is stored within the Yellowfin database, this database is created as part of the standard installation process. In the installation, you define the location, type, and connection details of this database.
The Yellowfin configuration can be hosted on a range of databases
Yellowfin will work with all of the major cloud providers including AWS, Azure, GCP, and more.
Yellowfin can be deployed into any environment as it is both OS agnostic and self-hosted. This can range from physical servers on a private internal network, to highly dynamic cloud container services such as AWS ECS or Kubernetes.
In docker deployments, the container itself will hold individual application servers that act as cluster nodes, communicating with a static configuration database (often located in something like AWS RDS). The application is then scaled horizontally by deploying additional containers.
A fully managed hosting service for Yellowfin is available in all regions. Hosting services enable you to deploy Yellowfin quickly, without the cost and distraction of hiring or training your own people. Contact your Yellowfin representative for further information.
Global deployments of Yellowfin are possible, in several distinct implementation models.
To enable local administration of users, and groups, separate instances of Yellowfin can be deployed regionally that give access to the same report content. This requires the synchronization of content across instances. Local administrators can manage local users and their access to the shared content.
A single global instance of Yellowfin can be deployed in a central region but with separate regional entry-points. Each entry point caches static content in the region, only forwarding requests for dynamic content to the server. Having a central single instance (which could be clustered in the same datacenter) means that no content migration is necessary and upgrades are relatively straight forward. Global entry points in this model can be implemented with a web server with specific proxying and caching rules. Location-based DNS services can direct users to the nearest regional entry-point when using a common URL.
It is also possible to implement a global cluster of Yellowfin with regionally positioned application servers, with local copies of the Yellowfin repository database. This deployment method relies on a multi-write database cluster, allowing distributed nodes of Yellowfin to share the same repository database. Yellowfin supports the TiDB repository database for this type of deployment.
Yellowfin does support multilingual deployments where different users can use specific languages within the same instance. The user’s language selection can be inherited from their internet browser, or by profile settings within the application.
Yes, the Yellowfin interface is double byte enabled. Users can also choose specific font sets for content exporting such as to PDF to ensure readable content is generated.
As of now the following languages are supported:
Yellowfin has a mechanism for content to be translated into the languages supported by the application instance. This allows content meta-data, such as Report Titles, Report Descriptions and Field Names to be displayed in a user’s preferred language. Translation of this content can be performed via a bulk export/import process.
Yes, date formats can be rendered differently to suit their locale and personal preferences.
Yes, you can create dynamic filters in the meta-data layer and apply these to tables so that depending on the user you can show metrics in their preferred format.
This can be used to:
Convert sales amounts in a person’s preferred currency
Convert volume or distance in their preferred formats etc
Yellowfin allows for datasource, report, dashboard and view meta-data to be translated into supported languages. Other regional settings allow for timezone, and date and time formats to be configured based on a user’s locale.
Yellowfin can be clustered by layering multiple application servers on top of a single shared configuration database. Application nodes can reside wherever you choose as long as they are able to communicate between each other. Additionally it is possible to configure each cluster node to run specific tasks, allowing you to dedicate servers to high resource processes such as signals or broadcasts.
Yellowfin provides a single license file which is uploaded through the application’s UI (also possible to do through WS). Once the licence has been applied, the licensing parameters are stored in the shared configuration database. As new application nodes connect to that database, they compare themselves against the stored licence.
Yellowfin releases “minor” updates to the application on a quarterly basis and “major” version updates annually. Minor releases contain small improvements, changes, and fixes, while major builds feature larger changes in the form of new or re-worked functionality.
As a self-hosted solution, upgrades are scheduled and managed by you. Upgrades are performed by downloading an executable application from the Yellowfin web-site and pointing that application to your current Yellowfin installation, where it will perform the necessary schema and application updates automatically.
When performing an upgrade we recommend that you first test the process in a development environment. While Yellowfin upgrades are generally smooth, this will give you the opportunity to vet any changes, and limit access to new features prior to their release to your general user community.
We also recommend that you first backup both the configuration database as well as the application server, as this will allow us to easily roll-back should that be required.
On a single node server, it is necessary to shutdown the Yellowfin application prior to upgrading. However in a clustered environment we are able to offer zero down-time upgrades, by rolling the update across the application nodes. By maintaining two copies of the configuration database, one on each version, we can steadily bring nodes off and online, migrating/upgrading them to the newer version, without the users ever noticing.
As a self managed solution, it is necessary for our clients to have a clear picture into what is happening within their instance, and where to look when things go wrong. To facilitate this Yellowfin provides several resources both within and outside of the application.
The Yellowfin configuration database maintains a record not only of the content and users that currently exist within the application, but of the events that have occured as well. By querying this database we are able to obtain a clear picture of how the application is being used.
To do this Yellowfin provides an importable set of “Audit Content”, that is essentially a collection of pre-built views and reports designed to answer the most common questions a typical Yellowfin administrator may have of their instance:
By default, Yellowfin will not store any report data. However, it is possible to configure Yellowfin to store the result set of every report that has been run along with a record of what user ran it and at what time, providing you a clear audit history of all data transactions.
When scaling the Yellowfin application, you need to monitor two primary metrics:
CPU – Each process in Yellowfin will consume a thread, so how many processes can be run at any given time is determined by the number of threads available on the CPU. The more users that are in the application, the more threads will be consumed by their activities. This will be directly reflected in the server’s CPU usage. Once the CPU usage approaches its limit, additional requests will be delayed, and users will notice a sharp decline in performance.
Memory – Many processes in Yellowfin consume application memory, proportional to the size of the data being processed, and the amount of work that needs to be done on that data. As Yellowfin approaches the limit of the memory allocated to the JVM, it will need to work harder to free space for additional processes, and may eventually crash.
Performance in Yellowfin is comprised of several different factors, so monitoring performance means looking at each of these components individually
As a primarily direct read application, the speed of a Yellowfin report s broadly based on two factors:
The Yellowfin audit content contains several useful reports that can be used to monitor and optimize report usage. This includes a record of every report run along with key information relating that run including how many rows it returned and how long the query took to process.
To prevent long running queries you can set a timeout on your database. By default this is 3 min.
To prevent excessively large result sets you can place a row limit on all queries on that database.
Most content can also be created with “dummy data” rather than live data limiting the number of times the report query needs to be run.
All background tasks in Yellowfin are run on a set schedule, typically defined when the task is first created. These schedules can be through the “schedule management” page of the administration console, allowing you to optimize when high resource processes are run.
All long running background processes can be stopped from the “background execution” page in the administration console.
Users who initiate long running processes within the application are provided the option to cancel the request at any time.
Sometimes things go wrong, and most of the time, Yellowfin will provide a clear error that indicates why. For the other times, the first place we suggest looking is in the log files. Each Yellowfin server has a folder called “/appserver/logs” that contains several files tracking the various components of the application. General logging is stored in the primary “yellowfin.log” file.
These logs can be toggled to show more or less information by configuring the log4j properties file.
In a clustered environment it is common to use a log forwarding service (aws cloud watch, splunk forwarding, etc) to enable the analysis of errors across all application nodes simultaneously.