Achieving High Performance Analytics

10 Imperatives for Scalable Enterprise BI and Reporting

With the need for greater and faster insights shooting up across the enterprise, this
article describes ten areas that play key roles in offering reliable, high performance
BI and analytics without breaking the budget.

One of the major challenges with enterprise-wide Business Intelligence and reporting is how to manage performance and
scalability without impacting production databases, applications, and budgets. There are many facets to ensuring your
users can get access to their data and analyze it in real time without having to wait to access results until the next morning
or even the next week. Here are 10 important considerations - along with a description of how JReport addresses them when designing your BI and analytics environment for performance and scalability.

1. ANALYTICS & REPORTING ENGINE.

A high performing reporting engine is one that can quickly access millions of rows of data for thousands of concurrent
business users without choking a system. High performance is reached only after many years of R&D and customer-driven
improvements. It should not require you to spend hundreds of thousands of dollars on dedicated servers and software.

Visa utilizes JReport's unique clustering and report bursting technology to generate reports that aggregate metrics
from over 200 million rows of data, providing vital account and tax information to commercial cardholder accounts.
JReport is embedded into multiple high performance Visa analysis and reporting applications addressing its
member, IRS, travel merchant, and corporate cardholder needs.

2. ACCESS TO DATA.
Provide efficient access to the data required by the report. This may be through direct access to REST APIs, columnar
cloud-based tables, materialized views created in the database, extracted summary tables or a full data warehouse. Offer
optimization strategies such as results caching and data bursting to compliment data access.
JReport does not require any data extraction into custom storage; it can directly access data in any environment including
relational DBMSs, columnar DBMSs, and huge data sources such as MongoDB, MemSQL, or Hortonworks. It can even directly
access cached data from Java objects. JReports query performance is a key enabler for delivering responsive BI applications.

3. DYNAMIC QUERIES.
Ensure that query and visualization tools have the intelligence to dynamically shape queries on-the-fly based on
user and visualization context. Maximize network speed and user experience by only retrieving data actually
required by the visualization, and not all of the data in the query. Automatically push down aggregations and
groupings to database engines when the output needs summary data instead of detailed data.
JReport dynamically modifies the query as the user interacts with
the data to ensure only the required data is returned. JReport
also automatically groups and summarizes data directly in the
DBMS without developers needing to modify the query.

4. PERFORMANCE TUNING.
The BI and reporting tool needs to be able to manage threads
and instances on a server to most efficiently utilize all its resources.
On large systems with many CPUs, just one instance of the tool cannot fully leverage all available resources. Its
important to design for clusters of instances to take full advantage of the aggregated, available resources.

JReport provides many ways to tune the performance of its resources. This might, for example, set a lower priority for
report generation processes so that faster, on-demand queries, dashboards, and visual analysis requests could complete
quicker. Another example might assign a round-robin algorithm to balance load across eight JReport nodes.

5. CLUSTERING.
The system must provide the power to join together a set of physical or virtual machines into a cluster of nodes. It should
be highly efficient when adding nodes to the cluster to achieve scalability. Adding and removing nodes should be
completely transparent without requiring a cluster restart or having nodes go offline. Administrators must be able to
quickly add and remove nodes from the cluster without impacting any current users.

As an example, a 4-node cluster with quad-core CPUs (16 cores total) is able to run 34 instances of JReport in WebLogic with
up to 8 threads per instance. In this environment, 6,500 reports per hour can be delivered to 500 concurrent users with a sub
2-second response time. No other reporting tool can provide this level of performance on commodity physical or virtual
servers.

6. MONITORING AND MANAGEMENT.

An enterprise-class BI and analytics platform should provide browser-based monitoring and alerting so administrators can
be notified if server or process health is failing or not responding. The monitoring tools should allow system-wide visibility
into usage by users, queries, or reports. Management tools should display running processes and allow administrators to
add or remove nodes as required for increased performance and more efficient use of compute resources.

With JReport, a cluster of servers can be managed from JReport Server Monitor, a remote browser-based application,
allowing the system to be reconfigured without taking the system down. Nodes can be added or removed as necessary
for greater scalability during times of heavy use such as quarter end reports.

7. RELIABILITY.
There must not be a single point of failure in the system. If any one server crashes or is taken offline, the other
servers need to dynamically take over and execute query and report requests without any manual intervention. Even
if a disk goes down, the resources should be spread across multiple locations so there is no single resource,
software or hardware, which can disrupt analysis and reporting requests or schedules.
In JReport, the central scheduler runs on
one node but is rotated among specified
nodes in the cluster. If it goes
down, the next node automatically
takes over without any interruption.
There is no master/slave role, and every
server has a chance to be the central
scheduler of the cluster.

8. LOAD BALANCING.
The system needs to have multiple built-in
scenarios as well as customizable rules for
determining where the next report request should
run, including affinity to specific available servers.
JReport provides four built-in rules for load balancing behavior, as well as an API to let report developers create
their own rules. In one JReport test on Amazon EC2, results showed JReport throughput of over 3,000 pages per
second on a 4-node JReport cluster. As additional server nodes were added, each node demonstrated a scalability
factor averaging over 90%.
5

9. RESOURCE MANAGEMENT.
Resources such as dashboard templates, data views, and standard report layouts must easily deploy and update across an
entire cluster of servers with a single command. No matter which server the user created and saved their template on, it
must be available immediately on all of the other nodes.
In a clustered JReport environment, you can publish a template or schedule a report result on one node of the server and
JReport will ensure that it is automatically available to all users regardless of what node is making the request. For example,
you might automatically keep just two copies on two nodes of a cluster so there are no single points of failure. However, if the
user is on one of the nodes that is not storing a copy of the result or template it will be copied and made available without
any action by the end user.

10. PLATFORM & DEVICE INDEPENDENCE.

The analytics tools utilized by enterprise users to create and view analytics should work on Linux, Mac, or Windows-based
platforms, on-premises, or in a cloud computing environment. Modern analytics must take advantage of HTML and
JavaScript standards so they can display the most intuitive interfaces on all of todays desktop and mobile platforms.
JReport supports on-premises and cloud deployments on any application server that supports servlet containers such as
Oracle WebLogic, IBM WebSphere, JBoss, or Tomcat. JReport will also integrate with application servers that do not support
servlet containers via APIs to facilitate communication between JReport and the application server. If the application server is
not Java-based, JReport can be used as a stand-alone server and communicate with the application through HTTP calls.

ABOUT JINFONET SOFTWARE

Jinfonet empowers companies to embed the most sophisticated reports and dashboards into
web applications. Through the JReport analytics platform, developers and users gain
advanced visualization capabilities with any data source. Every day, JReport delivers insights
for hundreds of thousands of users at over 10,000 installations worldwide.
2016 Jinfonet Software, Inc. All rights reserved.

1.240.477.1000
jinfonet.com