Patent Application
20110153592
This invention relates to travel scheduling and pricing, and more particularly to processing queries for air travel planning systems.
In travel planning such as for air travel scheduling, pricing and low-fare-search queries are posed by users from travel agent systems, airline reservation agent systems, travel web sites, and airline-specific web sites. Low-fare-search (LFS) queries typically include origin and destination information, time constraints and additional information including passenger profile and travel preferences. Travel planning computer systems respond to these LFS queries and typically return a list of possible tickets, each having flight and price information. Some systems to return answers in a compact form such as through a pricing graph.
Travel planning systems expend considerable computational resources responding to LFS queries. It is not uncommon for a travel planning system to spend more than 30 seconds responding to an LFS query, even for a relatively straightforward round-trip query leaving and returning from specific airports on specific dates. Typically, a single computer will be devoted to answering such a query, though the computer may range from a small personal computer or workstation class machine to a mainframe computer.
Because travel planning systems spend considerable computational resources on each LFS query, and because many such queries are answered every second, it is typical for travel planning computer programs to be run on large “farms” of computers, including tens, hundreds or even thousands of computer processors. In current practice, each query is answered by a single computer with different computers in a farm concurrently working on corresponding different queries.
However, there are many situations in which it is advantageous for multiple computers to work on the same query concurrently. One reason for doing so is that the response time (“latency”) can be reduced. For example, where one computer might expend 1 minute answering a query, it may be possible for 4 computers acting in concert to each expend 15 seconds answering the same query. The total number of CPU-seconds is the same, but the query latency is reduced from 1 minute to 15 seconds, a considerable improvement from the user's standpoint.
Also, in many cases the peak load on the farm, which may only be reached for short periods, dictates the size of a computer farm. For example, it is common for load on travel planning systems to be high in the early work hours but much lower late at night and on weekends and holidays (when travelers are less likely to access the internet and travel agencies are closed). It may be that a travel planning system requires 1000 computers to support its query load during peak periods, but only 250 during off-peak hours. Since the incremental cost of using an otherwise idle computer is negligible, during off-peak hours it may be economically practical to devote 4 times the computing resources to answering a query as at peak hours. The extra resources may enable more complicated queries, or be used to improve the search accuracy. However, it may be preferred to use these resources in parallel to maintain low query latency, rather than having each computer spend four times longer on each query.
According to an aspect of the present invention, a method includes dividing a travel query into sub-queries for execution by a travel planning system to return answers that satisfy the travel query.
According to an additional aspect of the present invention a method includes dividing a travel query into sub-queries according to a determined optimal division of the query for execution by a travel planning system to return answers that satisfy the travel query.
Depending on the travel planning system, there may be different ways to divide up a low-fare-search query amongst several computers. For example, some travel planning systems solve low-fare-search problems by first enumerating a list of from 1 to several thousand possible flight combinations that satisfy the airport and time specifications. Such systems then iterate over each flight combination finding prices for each, and return a small set of flight combinations that have low prices. Because the process of finding prices is typically much more computationally expensive than finding flight combinations, for a travel planning system with such a design a practical way to divide the work amongst several computers would be to have one computer generate the list of flight combinations and to divide the list of flight combinations into smaller lists to be priced concurrently by multiple computers.
However, again depending on the design of the travel planning system, this strategy may be less efficient than other strategies. For example, a travel planning system that achieves computational advantages by sharing work across the pricing of multiple flight combinations can divide queries in certain ways amongst the computers in order to retain those efficiencies resulting from sharing work. Such ways include having each computer price flight combinations for a different airline or by dividing up queries by time range. For such a system it is less efficient in terms of total resources expended to price many flight combinations separately on different computers than to price many flight combinations as part of a single computational process.
When dividing a low-fare-search query amongst multiple computers it is advantageous to have each computer perform roughly equal amounts of work, since typically the slowest computer determines the response time of the entire query. It is desirable that any technique of dividing a query into sub-queries be sophisticated enough to base its decisions in part on the expected work necessary to solve each sub-query.
Because of resource or program limitations, a travel planning system may be incapable of answering queries beyond a certain level of difficulty. For example, a system may be limited to solving problems involving no more than one-day departure windows, or a single origin or destination. For such a system, queries that exceed the limits of the system may need to be divided into smaller “sub-queries.” Techniques for dividing a query into smaller sub-queries executed concurrently with the goal of reducing query latency can be used to extend the capabilities of those travel planning systems that have difficulties handling more complex travel queries.
The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims.
Referring to
The answers for each sub-query may be collected and organized by the answer collator 25. If the form of the sub-query results is a simple list of travel options, the collation process used by the answer collator 25 may simply involve concatenating the answers from each sub-query. However more complex collations schemes are possible, such as selecting a subset of answers from each sub-query (possibly based on cheapest travel options from amongst all of the answers and so forth). Alternatively, if the query division process 12 produces sub-queries that overlap, the collation process 25 could remove duplicate answers. In the case where the travel planning computers produce answers in other forms, such as the pricing graph representation, other methods of collation may be used. For example, multiple pricing graphs can be merged into one by joining them with an OR node. It may also be that no collation process is used, so that answers for the different sub-queries are returned to the travel application as soon as they are available, rather than waiting for all sub-queries to complete.
Referring to
The process 40 divides 44 the query into sub-queries based on a criterion. There are many ways such a query could be divided into sub-queries. To reduce unnecessary work, it is typically advantageous to divide a query into sub-queries that do not overlap. For example, if dividing into at most 4 sub-queries, the following divisions of the query according to different criterion as set out in the examples below are all possibilities:
1. By destination airport (2 sub-queries)
2. By outbound departure time (4 sub-queries)
3. By outbound and return departure times (4 sub-queries)
4. By airline (4 sub-queries)
6. By flight combination (4 queries)
After dividing the query into sub-queries the process returns 46 the sub-queries. Though it may be desirable, it is not necessary for the sub-queries to exactly replicate the original query. Example 5, for instance, does not allow for mixtures of refundable and non-refundable coach-class fares.
For a particular travel planning system or low-fare-search query there may be advantages to particular ways of dividing queries. For example, for a travel planning system that shares work across dates it may be less desirable to divide the query by date or time than by airports, airline, fares or flights.
When dividing a query into sub-queries it may be desirable to produce sub-queries that involve approximately the same amount of work, so that total query latency is minimized. This does not necessarily correspond to equally sized query units. For example, since airlines vary widely by the number of flight combinations and fares they offer between any set of origins and destinations, it may require more computational expense to search over one airline than another. As another example, it may be that because of fare rule details, a query that spans a Saturday night takes more computational time than a query that does not involve a Saturday night stay, so two equal duration date or time ranges may result in unequal sub-query latency.
One place to provide the process to divide queries into sub-queries resides in the query distributor 22 (
Referring to
Referring to
As an example, the process 70 operates on a query with a long time range for some trip part, such as a flexible-date query “from BOS to LAX and back, departing any time in April, staying for about a week.” One approach is to divide the original query into sub-queries with non-overlapping outbound departure dates. However, it may be that different divisions have different costs; suppose, for example, that the travel planning computers are especially efficient if the time range they are presented with does not cross a Saturday night boundary. Then if 6 sub-queries are to be used, it might be best to divide April as follows, in order to eliminate those ranges, which include both a Saturday and a Sunday.
If a function time_range_cost( ) is defined that estimates the cost of a sub-query with a particular time range, this can be used to efficiently find the optimal division into sub-queries, using a variation of the Viterbi algorithm shown in a detailed example of the process 70 in Text Boxes 1 and 2 below:
This algorithm efficiently finds the optimal division of the original query's time range into a variable number of sub-queries. If the time_range_cost( ) function has a fixed component (CONSTANT_TERM in the sample function), so that any time range no matter how small has a cost, then the algorithm will avoid dividing the original query into unnecessarily many sub-queries; this is important in the typical case where the travel planning computers use some resources no matter how small the sub-query. Conversely, if time_range_cost( ) has a non-linear component (the QUADRATIC_TERM in the sample function), then the algorithm will favor allocating the original time-range equally among sub-queries, so that total latency is minimized.
For example, if time is expressed in minutes and a single travel planning computer spends on average 10 seconds for every days worth of time range it searches over (LINEAR_TERM=10*1440), plus a baseline overhead of 5 seconds (CONSTANT_TERM=5*1440), and it is desired that queries be sub-divided only if they exceed a two-day time range, then the quadratic term is chosen to be 2.5*1440*1440 since at that setting the total cost for a two-day query is the same whether the original query is divided into two sub-queries or not. More complex cost functions may be used to express costs for crossing Saturday night boundaries or other factors that might affect the performance of the travel planning computers.
Referring to
The algorithm 90 splits this query as represented in the table into multiple sub-queries, e.g., from 1 to N sub-queries by finding 92 sub-rectangles (sub time-ranges for outbound and return) that collectively cover all the possible travel date-pairs (X's in the table above). The process 90 attempts 94 to minimize total cost as determined by an arbitrary sub-query cost function. Continuing the example, for a certain sub-query cost function this set of travel dates is divided into 3 sub-queries as represented in Table 2 by numbers 1, 2, 3.
This process 90 is a variation of the Viterbi algorithm, which although is not guaranteed to find the minimum cost solution usually does. The process 90 maintains two tables/One table that is maintained 96 is best_cost_array1[i][n] which holds the minimum cost division into n sub-queries of the rectangular region covering the entire outbound range and the return range up to but not including the time with index i, as represented by the X's in Table 3 below:
A second table maintained 97 is best_cost_array2[l][i][j][n], which holds the minimum cost division into n sub-queries of a stair step region represented by the X's in Table 4 below:
The time units may be chosen arbitrarily, for example minutes or hours or days. For convenience it is assumed that the arbitrary time_ranges_cost( ) function used to measure the cost of a sub-query returns 0 if and only if the sub-query covers no valid travel times.
A detailed example of the process is shown below in Text boxes 3-5.
This process 90 is slightly more expensive to run than process 70. Here the time_ranges_cost( ) function takes a pair of time ranges.
Referring to
For flexible destination queries, such as “from BOS, round trip to any destination in Europe” it may be advantageous to divide into sub-queries by grouping destination locations. For example, one might divide the airports within Europe by country, allocating one sub-query per destination country.
For travel planning systems that do not take share work when processing multiple locations, the primary concern with dividing a query into sub-queries is to ensure that each sub-query requires approximately the same amount of computer processing resources. If a function location_size( ) is available that independently estimates the cost of adding each location to a query, then optimally dividing the locations becomes a variation of the “bin packing” problem. Optimal bin packing is never complete, but there are many well-known approximation algorithms for solving this problem. The algorithm for solving this problem given immediately below, get_locations_division( ) like the time-range division algorithms given previously, incorporates a cost function location_bin_cost( ) that is assumed to be monotonically increasing: An example is shown in Text Boxes 6 and 7 below.
Here the function location_size(location) should return an estimate of the additive cost of adding a particular location, such as an airport, to a sub-query. It might, for example, return the number of departures from the airport in one day. The location_bin_cost(bin_size) function takes as input the total size of a set of locations in a sub-query and returns an estimate of the cost of executing the sub-query. As with the time_range_cost( ) function, the QUADRATIC term favors equally sized sub-queries and the balance between the CONSTANT_TERM and the QUADRATIC_TERM can be used to control the number of sub-queries chosen.
If a travel planning system shares work across destinations, then it is advantageous to use more sophisticated methods for grouping locations, so as to maximize the work shared. For example, in such travel planning systems that share work across destinations much of the effort involved in pricing multiple flight combinations is shared if the flight combinations overlap. In this case when dividing the query it may be advantageous to group destinations that share sub-routes. Thus, for example, for a query from Boston to cities on the west coast of the United States, it may be advantageous to group small airports by the hub airports (San Francisco, Los Angeles, Phoenix, and so forth) they are most strongly connected to. This problem is closely related to other problems of “clustering”, and there are many techniques and algorithms for clustering that can be adapted for it.
Referring to
For some queries it may be advantageous to divide queries into sub-queries based on more than one criterion simultaneously. For example, for queries involving both flexible travel dates and flexible destinations (“from BOS to any destination in Europe sometime this winter”) it may be desirable to split both the original query's time range and its destinations. This can be accomplished by assuming independence between the costs of two dimensions and taking advantage of the fact that the various algorithms described above for finding the optimal divisions of single criteria (get_optimal_single_time_range_division, get_optimal_time_range_pair_division and get_locations_division) compute the costs for variable numbers of sub-queries.
The following sample algorithm is for the case of dividing locations and a time range simultaneously. It assumes a variation of get_optimal_single_time_range_division (get_optimal_single_time_range_division_X, presented below) that returns the best division and associated cost for each number of sub-queries, and similarly for get_locations_division.
The sample is shown in Text Boxes 8-10 below.
many different types of queries from different users. For example, at any moment computers within the farm may be answering a distribution of queries including scheduling queries, pricing queries and low-fare-search queries, and the low fare search queries may be of a wide variety of complexities, ranging from LFS queries with short-duration time windows and single-airport destinations to multi-month queries with many possible destinations.
In such a system, it is preferable that computational resources be devoted in proportion to queries' importance and difficulty. In addition, since the farm of computers is finite, it is necessary to limit the resources expended on queries to the total resources available. Thus, when the query rate is low it may be possible to devote many computers to each query, but near peak load it may be necessary to limit each query to a single computer.
The algorithms described above offer two mechanisms to control the number of computers used for a query (i.e., the number of sub-queries a query is divided into). The first is the max_subqueries argument, which is an absolute upper bound on the number of sub-queries for a query. The second is the cost function (time_range_cost, time_ranges_cost, location_bin_cost), in particular the constant component that assigns a base cost to every sub-query regardless of its size. Raising this component is likely to reduce the number of sub-queries chosen for a given query, and thus provides a mechanism for varying the average number of computers used to process queries. A travel planning system can dynamically alter the cost function (for the cost functions given above, through the parameter CONSTANT_TERM) in response to load to maximize the resources devoted to queries without exceeding the system's total computational resources. For example, the system may have a set of different cost function parameters and maximum sub-query limits that it uses for different load levels and levels of query priority as shown in Table 5 below:
In Table 5 each row reflects parameters to be used when the travel planning system is experiencing a certain arbitrarily defined load level. Rows with higher load levels contain parameters that reduce site load by reducing the number of sub-queries that will be generated for a query. For example, a month-long flexible date query assigned to priority level 1 might be divided into 10 sub-queries under load level 1 whereas the same query assigned to priority level 2 and processed with load level 4 might result in only 2 sub-queries.
Here the priority is intended to reflect an external assignment of importance, such as to reflect the amount being paid for the query, or to favor certain users. The choice of which load level to use is adjusted by the travel planning system in accordance with the computational load it is experiencing. In one implementation, a monitoring process measures the proportion of computing resources used over a time span (perhaps 30 seconds). If the proportion exceeds some threshold (perhaps 90%) then the load level is incremented (reducing the average amount of computing resources used by future queries) and if it is below some level (perhaps 70%) then the load level is reduced (increasing the average amount of computing resources used by future queries, but presumably improving query latency or efficacy).
Referring to
Referring to
Referring to
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10272426 | Oct 2002 | US |
| Child | 13040346 | US |
