US9069681B1 - Real-time log joining on a continuous stream of events that are approximately ordered - Google Patents

Real-time log joining on a continuous stream of events that are approximately ordered Download PDF

Info

Publication number
US9069681B1
US9069681B1 US14/038,060 US201314038060A US9069681B1 US 9069681 B1 US9069681 B1 US 9069681B1 US 201314038060 A US201314038060 A US 201314038060A US 9069681 B1 US9069681 B1 US 9069681B1
Authority
US
United States
Prior art keywords
event
primary
key
term memory
primary event
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
US14/038,060
Inventor
Tianhao Qiu
Manpreet Singh
Haifeng Jiang
Ashish Gupta
Sumit Das
Venkatesh Basker
Rajagopal Ananthanarayanan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Priority to US14/038,060 priority Critical patent/US9069681B1/en
Assigned to GOOGLE INC. reassignment GOOGLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ANANTHANARAYANAN, RAJAGOPAL, BASKER, VENKATESH, DAS, SUMIT, GUPTA, ASHISH, JIANG, HAIFENG, QIU, TIANHAO, SINGH, MANPREET
Application granted granted Critical
Publication of US9069681B1 publication Critical patent/US9069681B1/en
Assigned to GOOGLE LLC reassignment GOOGLE LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: GOOGLE INC.
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24568Data stream processing; Continuous queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0873Mapping of cache memory to specific storage devices or parts thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • G06F16/2272Management thereof

Definitions

  • Log joining systems may attempt to join one source of secondary events with another source of primary events.
  • primary events may include search queries, while secondary events may include user clicks on advertisements. Every primary event is uniquely identified by a key, and every secondary event is associated with a key for a corresponding primary event. The purpose of log joining is to locate the corresponding primary event for every secondary event based on the primary key.
  • the joining may be performed in sequential batches. This can easily be achieved by a series of massive map-reduces having a mapper component and a reducer component. Both secondary and primary events may be fed into the mapper component, and the mapper may emit secondary events keyed on the common primary event ID.
  • the reducer in turn, can take the joining decision and output the joined logs.
  • such a configuration may not scale well in a larger system having a continuous stream of events.
  • the method includes receiving a continuous stream of primary events, each associated with a corresponding primary event key; storing the received primary events in a short term memory; generating, by a processor, an index map based on the received primary events currently stored in the short term memory; after a time T has passed, storing the received primary events in a long term memory; receiving a secondary event associated with a particular primary key; and using the index map to determine whether the particular primary event key is included in the short term memory.
  • the method also includes, when the particular primary event key is included in the short term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system.
  • the method also includes, when the particular primary event key is not included in the short term memory, determining whether the particular primary event key is included in the long term memory.
  • the method also includes when the particular primary event key is included in the long term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system.
  • the method also includes receiving a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events.
  • using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew value for the index map; determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
  • using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew values for the index map; seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
  • the system includes a cache layer for storing a continuously received stream of primary events for a time T. Each primary event of the continuously received stream of primary events having a corresponding primary event key.
  • the system also includes a long term memory for storing the continuously received stream of primary events after a time T and a processor.
  • the processor is configured to generate an index map based on the continuously received primary events currently stored in the short term memory; receiving a secondary event associated with a particular primary key; and using the index map to determine whether the particular primary event key is included in the short term memory.
  • the processor is also configured to, when the particular primary event key is included in the short term memory, join the secondary event with the primary event that is associated with the primary event key in the short term memory and to send the joined primary event and secondary event to a joined event storage system.
  • the processor is also configured to, when the particular primary event key is not included in the short term memory, determine whether the particular primary event key is included in the long term memory.
  • the processor is also configured to, when the particular primary event key is included in the long term memory, join the secondary event with the primary event that is associated with the primary event key in the long term memory and to send the joined primary event and secondary event to a joined event storage system.
  • the processor is also configured to receive a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events.
  • the processor is also configured to use the index map to determine whether the particular primary event key is included in the short term memory by determining a maximum skew value for the index map; determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
  • the processor is also configured to use the index map to determine whether the particular primary event key is included in the short term memory by determining a maximum skew values for the index map; seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
  • a further aspect of the disclosure provides a non-transitory tangible computer-readable storage medium on which computer readable instructions of a program are stored.
  • the instructions when executed by a processor, cause the processor to perform a method.
  • the method includes receiving a continuous stream of primary events, each associated with a corresponding primary event key; storing the received primary events in a short term memory; generating an index map based on the received primary events currently stored in the short term memory; after a time T has passed, storing the received primary events in a long term memory; receiving a secondary event associated with a particular primary key; and using the index map to determine whether the particular primary event key is included in the short term memory.
  • the method also includes, when the particular primary event key is included in the short term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system.
  • the method also includes, when the particular primary event key is not included in the short term memory, determining whether the particular primary event key is included in the long term memory.
  • the method also includes when the particular primary event key is included in the long term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system.
  • the method also includes receiving a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events.
  • using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew value for the index map; determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
  • using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew values for the index map; seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
  • FIG. 1 is a functional diagram of a system in accordance with aspects of the disclosure.
  • FIG. 2 is a pictorial diagram of the system of FIG. 1 .
  • FIG. 3 is an example diagram of an event joining system in accordance with aspects of the disclosure.
  • FIGS. 4A and 4B are example flow diagrams in accordance with aspects of the disclosure.
  • aspects of the disclosure relate generally to a distributed event joining system for joining primary and secondary events based on a common key.
  • a continuous stream of primary events may be received. Each primary event may be associated with a primary event key.
  • the stream of primary events may be stored in short-term memory.
  • An index map for the primary events of the short-term memory may be generated using the primary event keys.
  • the stream of primary events may be sent to a long term memory for storage. This process may repeat continuously as new primary events are received from the continuous stream of primary events.
  • a continuous stream of secondary events, each associated with a primary event key, may also be received.
  • a secondary event may be selected. Whether the primary event key associated with the selected secondary event is included in the short-term memory may be determined using the index map generated as described above. This may be repeated several times. If the primary event key is included in the short-term memory, the primary event may be joined with the secondary event and sent to a joined event storage system. Another secondary event may be selected and used as described above.
  • the primary event key is not included in the short-term memory, whether the primary event key associated with the selected secondary event is included in the long-term memory may be determined. Again, this may be repeated several times. If the primary event key is included in the long-term memory, the primary event may be joined with the secondary event and sent to a joined event storage system. If the primary event key is not included in the long-term memory, the pairing may fail, and another secondary event may be selected. Again, this process may repeat continuously as new primary events are received from the continuous stream of primary events.
  • FIGS. 1-2 depict a system 100 , which is used herein as an example system in which the event joiner system described herein may be implemented. It should not be considered as limiting the scope of the disclosure or the usefulness of the features described herein.
  • system 100 can include computers 110 , 120 , 130 , 140 , 150 , 160 , 170 , and 180 and databases 10 , 20 , 70 , and 80 .
  • Computers 110 and 120 can contain a processor 112 , memory 114 and other components typically present in general purpose computers.
  • Memory 114 of computer 110 can store information accessible by processor 112 , including instructions 116 that can be executed by the processor 112 .
  • Memory can also include data 118 that can be retrieved, manipulated or stored by the processor.
  • the memory can be of any type capable of storing information accessible by the processor, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable, and read-only memories.
  • the instructions 116 can be any set of instructions to be executed directly, such as machine code, or indirectly, such as scripts, by the processor.
  • the terms “instructions,” “application,” “steps” and “programs” can be used interchangeably herein.
  • the instructions can be stored in object code format for direct processing by the processor, or in any other computer language including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. Functions, methods and routines of the instructions are explained in more detail below.
  • Data 118 can be retrieved, stored or modified by processor 112 in accordance with the instructions 116 .
  • the data can be stored in computer registers, in a relational database as a table having many different fields and records, or XML documents.
  • the data can also be formatted in any computer-readable format such as, but not limited to, binary values, ASCII or Unicode.
  • the data can comprise any information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other memories such as at other network locations, or information that is used by a function to calculate the relevant data.
  • the processor 112 can be any conventional processor, such as commercially available CPUs. Alternatively, the processor can be a dedicated device such as an ASIC or other hardware-based processor.
  • FIG. 1 functionally illustrates the processor, memory, and other elements of computer 110 as being within the same block, the processor, computer, or memory can actually comprise multiple processors, computers, or memories that can or cannot be stored within the same physical housing.
  • memory can be a hard drive or other storage media located in a housing different from that of computer 110 . Accordingly, references to a processor, computer, or memory will be understood to include references to a collection of processors, computers, or memories that can or cannot operate in parallel.
  • the computer 110 can be at one node of a network 190 and capable of directly and indirectly communicating with other nodes, such as computers 130 , 150 , 160 , 170 as well as databases 10 and 70 , of the network.
  • computer 120 can be at another node of the network and capable of directly and indirectly communicating with other nodes, such as computers 140 , 150 , 160 , and 180 as well as databases 20 and 80 .
  • the network 190 and intervening nodes described herein, can be interconnected using various protocols and systems, such that each can be part of the Internet, World Wide Web, specific intranets, wide area networks, or local networks. These can use standard communications protocols or those proprietary to one or more companies, Ethernet, WiFi and HTTP, and various combinations of the foregoing.
  • computers 120 , 130 , 140 , 150 , 160 , 170 , 180 can be configured similarly to the computer 110 , with a processor, memory, instructions, and data, similar to processor 112 , memory 114 , instructions 116 , and data 118 .
  • computers 110 and 120 may be key registry servers
  • computers 170 and 180 may be worker computers
  • computers 130 and 140 may be web servers
  • computers 150 and 160 may be client devices.
  • key registry server 110 , worker computer 170 , web server 130 , and databases 10 and 70 may operate at a first data center DC1 (shown in FIG.
  • first and second datacenters may be considered a geographically distributed computing system 105 (shown in FIG. 2 ). Although not shown, the computing system many more datacenters.
  • FIGS. 1 and 2 depict key registry servers 110 and 120 and worker computers 170 and 180 as singular devices, these devices may each represent many key registry servers or worker computers.
  • web servers 130 and 140 may also comprise many computers, e.g., a load balanced server farm, that exchange information with different nodes of network 190 for the purpose of receiving, processing and transmitting data to the client devices 150 and 160 .
  • the client devices will typically still be at different nodes of the network than any of the computers of servers 110 , 120 , 130 or 140 or worker computers 170 or 180 .
  • Each client device 150 and 160 can be a personal computer, intended for use by a user 210 or 220 , having all the components normally found in a personal computer such as a central processing unit (CPU), display device, CD-ROM, hard drive, user inputs, speakers, modem and/or network interface device, and all of the components used for connecting these elements to one another.
  • a personal computer such as a central processing unit (CPU), display device, CD-ROM, hard drive, user inputs, speakers, modem and/or network interface device, and all of the components used for connecting these elements to one another.
  • client devices in accordance with the systems and methods described herein can comprise any device capable of processing instructions and transmitting data to and from humans and other computers including general purpose personal computers, PDAs, network computers lacking local storage capability, set-top boxes for televisions, wireless-enabled PDA, hand-held or in-car navigation device, tablet PC, netbook, a cellular phone capable of obtaining information using the Internet, and other networked devices.
  • databases 70 and 80 may store logs of event information reported by web servers 130 and 140 .
  • the logs may include input from continuous data streams including a primary data stream of primary keys or primary event identifiers, timestamps, and other associated information.
  • This log data may be accessed by worker computers 170 and 180 arranged as a distributed event joining system 107 of FIG. 2 .
  • the joining system may further include a cache layer 310 for the primary event stream 320 .
  • the cache layer may be configured as one or more cache server computer, again configured similarly to computer 110 , with a processor and memory storing instructions and data similar to processor 112 , memory 114 , instructions 116 , and data 118 .
  • the cache layer 310 may store primary event information and generate an index map 330 as described in more detail below.
  • the instructions of worker computers 170 and 180 may include a joiner tool 340 and a lookup tool 350 .
  • the joiner tool may be used to join primary and secondary events by common keys, here, event IDs.
  • the lookup tool may be used to query the databases 70 and 80 for primary keys.
  • Databases 10 and 20 may include logs that store joined keys or event IDs.
  • the logs may include primary keys or primary events IDs that have been paired with secondary keys or secondary event IDs. These logs may be managed by the key registry servers 110 and 120 as a distributed joined event storage system, such as system 109 of FIG. 2 .
  • the users may be provided with an opportunity to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), or to control whether and/or how to receive content from the content server that may be more relevant to the user.
  • user information e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location
  • certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed.
  • a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined.
  • location information such as to a city, ZIP code, or state level
  • the user may have control over how information is collected about the user and used by a content server, such as web servers 130 or 140 .
  • web server 130 may respond to the request by providing information such as a web page and one or more advertisements for display to the user 210 .
  • This query may be considered a primary event.
  • Web server 130 may also generate a key, for example here an event identifier (event ID).
  • event ID an event identifier
  • the query event may be considered a primary event
  • the event ID a primary event identifier (primary event ID).
  • the primary event ID may be a query identifier (query ID) for the query.
  • the web server 130 may also send the event information to the distributed event joiner system 107 .
  • the primary event information may include the query ID, a timestamp, an advertiser identifier, auction data for the advertisement, etc.
  • user 210 may click on one of the advertisements.
  • the click may be considered a secondary event.
  • the click event may be sent to web server 130 which may direct the client device to the advertiser's web site.
  • the click event may also be given a key or event ID.
  • the event ID would be a secondary event identifier (secondary event ID) and may be a click identifier (click ID).
  • the click ID may be associated with the corresponding query ID as well as other information used to bill the advertiser as secondary event information.
  • the secondary event information may also be sent to the distributed event joiner system 107 .
  • event information for example for user queries and user clicks
  • these different types of event information may be considered two continuous event streams.
  • click and query event streams such systems may be used to join many different types of event streams.
  • advertisement serving systems may provide advertisements and results as a user is typing a query, by making assumptions about what the user is searching for rather than waiting for a specific search request from the user. Thus, it may be necessary to join the user's actions, such as clicking on an advertisement with the corresponding query for which the system assumed was being searched.
  • FIG. 3 is an example of a configuration for the distributed joining system 107 .
  • primary event information 320 and secondary event information 360 may be received as input to the distributed event joiner system.
  • the event information may be received approximately in the timestamp order in continuous streams 320 and 360 .
  • the number of primary events may be much greater than the number of secondary events. For example, for every advertisement shown, only a portion may actually be associated with a click event.
  • a majority of joining requests from the secondary stream may be looking for recent events in the primary stream.
  • primary event information 320 may be directly streamed into the cache layer 310 .
  • the cache layer may store primary event information for up to an amount of time T based on the timestamp associated with each primary event. After T time has passed, primary event information may be moved (copied and overwritten) to the databases 70 and 80 on a first in, first out basis.
  • the value of T may be a relatively short amount of time, such as a few minutes, or significantly longer such as an hour or more.
  • the index map may keep track of a set of (key, offset) pairs.
  • the key may be a primary event ID.
  • Each entry can be thought of as a vertex in a linear, monotonically increasing function.
  • a given entry (K, d) may imply that all events before offset “d” (exclusive) associated with the primary key “K” have keys no greater than the value of K, as the record at offset “d” has a key slightly larger than the value of k.
  • the offset between adjacent keys may differ for different adjacent keys.
  • the index map may be sparse, such that the keys do not have to be continuous in the index.
  • Entries may be deleted if they are too close to existing vertices (i.e. their offsets differ by less than a threshold). As the index is written on the fly as events are read, it may contain redundant index entries. The threshold can be used to optimize the size of the index. This may both save space and improve the time for lookup of keys.
  • the secondary event information is inputted into the joiner tool 340 in order to identify corresponding primary event information.
  • the joiner tool may try identifying primary event information using a particular primary key of the secondary event information.
  • the joiner tool may first search the cache layer 310 in order to determine whether a particular primary key exists. For example, the joiner tool 340 may receive secondary event information identifying a primary event ID, “K.”
  • the index map may be searched to find the particular key “K.”
  • the max_skew value may then be subtracted from “K” to obtain an offset value.
  • the joiner tool then seeks to the offset value returned by getting lower bound of K minus max_skew in the index map, or the first entry that compares greater than K-max_skew.
  • the event information at the returned offset value may be read, and a new entry is added to the index map for the returned offset value.
  • the max_skew value may again be subtracted from “K” to obtain an offset value. However, because the new entry was added to the index map for the previously returned offset value, a different offset may be returned by getting lower bound of K minus the max_skew in the index map. The record at the offset value may be read and another new entry may be added to the index map.
  • a linear search may begin by ready keys sequentially until the key K may be found or a key greater than K plus max_skew is found. If a key greater than K plus max_skew may be found, this may indicate that the key K does not exist in the cache layer 107 .
  • the joiner tool 340 may use the lookup tool 350 to query the log data of databases 70 and 80 .
  • the logs of databases 70 and 80 may play the role of a catch-all.
  • older primary event information may still be available for pairing until it reaches an expiration date T2 past which a pairing with a secondary event would be unlikely, for example a few days.
  • the lookup tool may have to perform multiple disk reads of databases 70 or 80 to find an event as they system may seek and read at multiple disk offsets and the final event may need sequential reads. For example, if a key is not found, then the system may retry after some duration based on T2. However, this may be cheaper than cache-layer lookups, which can be costly in terms of RAM, but may have higher latency and processing loads.
  • FIGS. 4A and 4B are example flow diagrams for a distributed event joining system including some of the features described above.
  • FIG. 4A is an example flow diagram for the processes that may occur at cache layer 310 .
  • a continuous stream of primary events is received at block 402 .
  • Each primary event is associated with a primary event key.
  • the stream of primary events is stored in short-term memory at block 404 .
  • An index map for the primary events of the short-term memory is generated using the primary event keys at block 406 .
  • the stream of primary events is sent to long term memory.
  • the blocks of FIG. 4A may repeat continuously as new primary events are received from the continuous stream of primary events.
  • FIG. 4B is an example flow diagram for the processes that may be performed by the worker computers.
  • a continuous stream of secondary events, each associated with a primary event key, is received at block 410 .
  • a secondary event is selected at block 412 .
  • whether the primary event key associated with the selected secondary event is included in the short-term memory is determined using the index map (generated at block 406 of FIG. 4B ) at block 414 . This block may be repeated several times before progressing to the next block. If the primary event key is included in the short-term memory, the primary event is joined with the secondary event and sent to a joined event storage system at block 414 , and another secondary event is selected at block 412 .
  • the primary event key is not included in the short-term memory, whether the primary event key associated with the selected secondary event is included in the long-term memory is determined at block 416 . Again, this block may be repeated several times before progressing to the next block. If the primary event key is included in the long-term memory, the primary event is joined with the secondary event and sent to a joined event storage system at block 414 . If the primary event key is not included in the long-term memory, the pairing may fail, and another secondary event is selected at block 412 . Again, the blocks of FIG. 4B may repeat continuously as new primary events are received from the continuous stream of primary events.
  • One advantage of the cache layer 310 is relatively low latency and relatively low disk-load. As a result of this, the system 310 can even retry looking up a key in the cache layer multiple times before giving up and going to disk-based lookup system (for example, at databases 70 or 80 ). This multiple reply may be cheaper in terms of latency and processing loads than the cost of disk seeks on the databases. It may also provide some extra time for the cache layer 310 to catch up as new secondary event information is received.
  • the cache layer handles the majority of recent event lookups, this may add up to a tremendous savings in processing power, and thus, make the system scalable. For example, in a joining system for query and click events, if the cache layer is configured to store primary event information for up to an hour, this may lead to up to 90% of lookups being addressed at the cache layer.

Abstract

Aspects of the disclosure relate generally to a distributed event joining system for joining primary and secondary events based on a common key. In one example, a continuous stream of primary events may be stored at a cache layer. Each primary event may be associated with a primary event key which may be used to generate an index map for the cache layer. After a time T, the stream of primary events may be sent to long term memory. The system may also receive secondary events, each associated with a primary key. The primary key may be used to identify a primary event in the cache layer. If the primary event is not available in the cache layer, the long term memory may be searched for the primary key. Paired events may then be submitted to a distributed joined event storage system.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
The present application claims the benefit of the filing date of U.S. Provisional Patent Application No. 61/803,640 filed Mar. 20, 2013, the entire disclosure of which is hereby incorporated herein by reference.
BACKGROUND
Log joining systems may attempt to join one source of secondary events with another source of primary events. In one example, primary events may include search queries, while secondary events may include user clicks on advertisements. Every primary event is uniquely identified by a key, and every secondary event is associated with a key for a corresponding primary event. The purpose of log joining is to locate the corresponding primary event for every secondary event based on the primary key.
In a non-continuous system, the joining may be performed in sequential batches. This can easily be achieved by a series of massive map-reduces having a mapper component and a reducer component. Both secondary and primary events may be fed into the mapper component, and the mapper may emit secondary events keyed on the common primary event ID. The reducer, in turn, can take the joining decision and output the joined logs. However, such a configuration may not scale well in a larger system having a continuous stream of events.
SUMMARY
One aspect of the disclosure provides a method. The method includes receiving a continuous stream of primary events, each associated with a corresponding primary event key; storing the received primary events in a short term memory; generating, by a processor, an index map based on the received primary events currently stored in the short term memory; after a time T has passed, storing the received primary events in a long term memory; receiving a secondary event associated with a particular primary key; and using the index map to determine whether the particular primary event key is included in the short term memory.
In one example, the method also includes, when the particular primary event key is included in the short term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system. In another example, the method also includes, when the particular primary event key is not included in the short term memory, determining whether the particular primary event key is included in the long term memory. In this example, the method also includes when the particular primary event key is included in the long term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system.
In another example, the method also includes receiving a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events. In a further example, using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew value for the index map; determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory. In another example, using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew values for the index map; seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
Another aspect of the disclosure provides system. The system includes a cache layer for storing a continuously received stream of primary events for a time T. Each primary event of the continuously received stream of primary events having a corresponding primary event key. The system also includes a long term memory for storing the continuously received stream of primary events after a time T and a processor. The processor is configured to generate an index map based on the continuously received primary events currently stored in the short term memory; receiving a secondary event associated with a particular primary key; and using the index map to determine whether the particular primary event key is included in the short term memory.
In one example, the processor is also configured to, when the particular primary event key is included in the short term memory, join the secondary event with the primary event that is associated with the primary event key in the short term memory and to send the joined primary event and secondary event to a joined event storage system. In another example, the processor is also configured to, when the particular primary event key is not included in the short term memory, determine whether the particular primary event key is included in the long term memory. In this example, the processor is also configured to, when the particular primary event key is included in the long term memory, join the secondary event with the primary event that is associated with the primary event key in the long term memory and to send the joined primary event and secondary event to a joined event storage system.
In another example, the processor is also configured to receive a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events. In a further example, the processor is also configured to use the index map to determine whether the particular primary event key is included in the short term memory by determining a maximum skew value for the index map; determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory. In another example, the processor is also configured to use the index map to determine whether the particular primary event key is included in the short term memory by determining a maximum skew values for the index map; seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
A further aspect of the disclosure provides a non-transitory tangible computer-readable storage medium on which computer readable instructions of a program are stored. The instructions, when executed by a processor, cause the processor to perform a method. The method includes receiving a continuous stream of primary events, each associated with a corresponding primary event key; storing the received primary events in a short term memory; generating an index map based on the received primary events currently stored in the short term memory; after a time T has passed, storing the received primary events in a long term memory; receiving a secondary event associated with a particular primary key; and using the index map to determine whether the particular primary event key is included in the short term memory.
In one example, the method also includes, when the particular primary event key is included in the short term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system. In another example, the method also includes, when the particular primary event key is not included in the short term memory, determining whether the particular primary event key is included in the long term memory. In this example, the method also includes when the particular primary event key is included in the long term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory and sending the joined primary event and secondary event to a joined event storage system.
In another example, the method also includes receiving a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events. In a further example, using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew value for the index map; determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory. In another example, using the index map to determine whether the particular primary event key is included in the short term memory includes determining a maximum skew values for the index map; seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and using the offset value to determine whether the particular primary event key is included in the short term memory.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a functional diagram of a system in accordance with aspects of the disclosure.
FIG. 2 is a pictorial diagram of the system of FIG. 1.
FIG. 3 is an example diagram of an event joining system in accordance with aspects of the disclosure.
FIGS. 4A and 4B are example flow diagrams in accordance with aspects of the disclosure.
DETAILED DESCRIPTION
Aspects of the disclosure relate generally to a distributed event joining system for joining primary and secondary events based on a common key. As an example, a continuous stream of primary events may be received. Each primary event may be associated with a primary event key. The stream of primary events may be stored in short-term memory. An index map for the primary events of the short-term memory may be generated using the primary event keys. After a pre-determined period of time, the stream of primary events may be sent to a long term memory for storage. This process may repeat continuously as new primary events are received from the continuous stream of primary events.
A continuous stream of secondary events, each associated with a primary event key, may also be received. A secondary event may be selected. Whether the primary event key associated with the selected secondary event is included in the short-term memory may be determined using the index map generated as described above. This may be repeated several times. If the primary event key is included in the short-term memory, the primary event may be joined with the secondary event and sent to a joined event storage system. Another secondary event may be selected and used as described above.
If the primary event key is not included in the short-term memory, whether the primary event key associated with the selected secondary event is included in the long-term memory may be determined. Again, this may be repeated several times. If the primary event key is included in the long-term memory, the primary event may be joined with the secondary event and sent to a joined event storage system. If the primary event key is not included in the long-term memory, the pairing may fail, and another secondary event may be selected. Again, this process may repeat continuously as new primary events are received from the continuous stream of primary events.
FIGS. 1-2, depict a system 100, which is used herein as an example system in which the event joiner system described herein may be implemented. It should not be considered as limiting the scope of the disclosure or the usefulness of the features described herein. In this example, system 100 can include computers 110, 120, 130, 140, 150, 160, 170, and 180 and databases 10, 20, 70, and 80. Computers 110 and 120 can contain a processor 112, memory 114 and other components typically present in general purpose computers. Memory 114 of computer 110 can store information accessible by processor 112, including instructions 116 that can be executed by the processor 112.
Memory can also include data 118 that can be retrieved, manipulated or stored by the processor. The memory can be of any type capable of storing information accessible by the processor, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable, and read-only memories.
The instructions 116 can be any set of instructions to be executed directly, such as machine code, or indirectly, such as scripts, by the processor. In that regard, the terms “instructions,” “application,” “steps” and “programs” can be used interchangeably herein. The instructions can be stored in object code format for direct processing by the processor, or in any other computer language including scripts or collections of independent source code modules that are interpreted on demand or compiled in advance. Functions, methods and routines of the instructions are explained in more detail below.
Data 118 can be retrieved, stored or modified by processor 112 in accordance with the instructions 116. For instance, although the subject matter described herein is not limited by any particular data structure, the data can be stored in computer registers, in a relational database as a table having many different fields and records, or XML documents. The data can also be formatted in any computer-readable format such as, but not limited to, binary values, ASCII or Unicode. Moreover, the data can comprise any information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other memories such as at other network locations, or information that is used by a function to calculate the relevant data.
The processor 112 can be any conventional processor, such as commercially available CPUs. Alternatively, the processor can be a dedicated device such as an ASIC or other hardware-based processor. Although FIG. 1 functionally illustrates the processor, memory, and other elements of computer 110 as being within the same block, the processor, computer, or memory can actually comprise multiple processors, computers, or memories that can or cannot be stored within the same physical housing. For example, memory can be a hard drive or other storage media located in a housing different from that of computer 110. Accordingly, references to a processor, computer, or memory will be understood to include references to a collection of processors, computers, or memories that can or cannot operate in parallel.
The computer 110 can be at one node of a network 190 and capable of directly and indirectly communicating with other nodes, such as computers 130, 150, 160, 170 as well as databases 10 and 70, of the network. Similarly, computer 120 can be at another node of the network and capable of directly and indirectly communicating with other nodes, such as computers 140, 150, 160, and 180 as well as databases 20 and 80. The network 190 and intervening nodes described herein, can be interconnected using various protocols and systems, such that each can be part of the Internet, World Wide Web, specific intranets, wide area networks, or local networks. These can use standard communications protocols or those proprietary to one or more companies, Ethernet, WiFi and HTTP, and various combinations of the foregoing.
Each of computers 120, 130, 140, 150, 160, 170, 180 can be configured similarly to the computer 110, with a processor, memory, instructions, and data, similar to processor 112, memory 114, instructions 116, and data 118. As an example, computers 110 and 120 may be key registry servers, computers 170 and 180 may be worker computers, computers 130 and 140 may be web servers, and computers 150 and 160 may be client devices. As such, key registry server 110, worker computer 170, web server 130, and databases 10 and 70 may operate at a first data center DC1 (shown in FIG. 2) at a first geographic location, while key registry server 120, worker computer 180, web server 140, and databases 20 and 80 may operate at a second data center DC2 (shown in FIG. 2) at a second geographic location remote from the first geographic location of the first data center. In this regard, the first and second datacenters may be considered a geographically distributed computing system 105 (shown in FIG. 2). Although not shown, the computing system many more datacenters.
Although FIGS. 1 and 2 depict key registry servers 110 and 120 and worker computers 170 and 180 as singular devices, these devices may each represent many key registry servers or worker computers. Similarly, web servers 130 and 140 may also comprise many computers, e.g., a load balanced server farm, that exchange information with different nodes of network 190 for the purpose of receiving, processing and transmitting data to the client devices 150 and 160. In this instance, the client devices will typically still be at different nodes of the network than any of the computers of servers 110, 120, 130 or 140 or worker computers 170 or 180.
Each client device 150 and 160 can be a personal computer, intended for use by a user 210 or 220, having all the components normally found in a personal computer such as a central processing unit (CPU), display device, CD-ROM, hard drive, user inputs, speakers, modem and/or network interface device, and all of the components used for connecting these elements to one another. Moreover, client devices in accordance with the systems and methods described herein can comprise any device capable of processing instructions and transmitting data to and from humans and other computers including general purpose personal computers, PDAs, network computers lacking local storage capability, set-top boxes for televisions, wireless-enabled PDA, hand-held or in-car navigation device, tablet PC, netbook, a cellular phone capable of obtaining information using the Internet, and other networked devices.
As described in more detail below, databases 70 and 80 may store logs of event information reported by web servers 130 and 140. The logs may include input from continuous data streams including a primary data stream of primary keys or primary event identifiers, timestamps, and other associated information. This log data may be accessed by worker computers 170 and 180 arranged as a distributed event joining system 107 of FIG. 2.
An example of a configuration for the distributed joining system 107 is shown in more detail in FIG. 3. In this example, the joining system may further include a cache layer 310 for the primary event stream 320. The cache layer may be configured as one or more cache server computer, again configured similarly to computer 110, with a processor and memory storing instructions and data similar to processor 112, memory 114, instructions 116, and data 118. The cache layer 310 may store primary event information and generate an index map 330 as described in more detail below.
In this example, the instructions of worker computers 170 and 180 may include a joiner tool 340 and a lookup tool 350. As described in more detail below the joiner tool may be used to join primary and secondary events by common keys, here, event IDs. The lookup tool may be used to query the databases 70 and 80 for primary keys.
Databases 10 and 20 may include logs that store joined keys or event IDs. The logs may include primary keys or primary events IDs that have been paired with secondary keys or secondary event IDs. These logs may be managed by the key registry servers 110 and 120 as a distributed joined event storage system, such as system 109 of FIG. 2.
Although certain advantages are obtained when information is transmitted or received as noted above, other aspects of the subject matter described herein are not limited to any particular manner of transmission of information. For example, in some aspects, information can be sent using a medium such as a disk, tape or CD-ROM. Yet further, although some functions are indicated as taking place on a single computer having a single processor, various aspects of the subject matter described herein can be implemented by a multiple of computers, for example, communicating information over network 190.
In addition to the operations described below and illustrated in the figures, various operations will now be described. It should also be understood that the following operations do not have to be performed in the precise order described below. Rather, various steps can be handled in a different order or simultaneously. Steps can also be omitted unless otherwise stated.
In situations in which the systems discussed here collect personal information about users, or may make use of personal information, the users may be provided with an opportunity to control whether programs or features collect user information (e.g., information about a user's social network, social actions or activities, profession, a user's preferences, or a user's current location), or to control whether and/or how to receive content from the content server that may be more relevant to the user. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over how information is collected about the user and used by a content server, such as web servers 130 or 140.
As an example of the operation aspects of system 100, when a client device, such as client device 150, submits a search query to web server 130, web server 130 may respond to the request by providing information such as a web page and one or more advertisements for display to the user 210. This query may be considered a primary event. Web server 130 may also generate a key, for example here an event identifier (event ID). In this example, the query event may be considered a primary event, and the event ID a primary event identifier (primary event ID). The primary event ID may be a query identifier (query ID) for the query. The web server 130 may also send the event information to the distributed event joiner system 107. For each advertisement, the primary event information may include the query ID, a timestamp, an advertiser identifier, auction data for the advertisement, etc.
After receiving the web page and advertisements, user 210 may click on one of the advertisements. The click may be considered a secondary event. The click event may be sent to web server 130 which may direct the client device to the advertiser's web site. The click event may also be given a key or event ID. In this example, the event ID would be a secondary event identifier (secondary event ID) and may be a click identifier (click ID). The click ID may be associated with the corresponding query ID as well as other information used to bill the advertiser as secondary event information. The secondary event information may also be sent to the distributed event joiner system 107.
As the web servers 130 and 150 receive event information, for example for user queries and user clicks, over time, these different types of event information may be considered two continuous event streams. Although the present disclosure relates to click and query event streams, such systems may be used to join many different types of event streams. For example, some advertisement serving systems may provide advertisements and results as a user is typing a query, by making assumptions about what the user is searching for rather than waiting for a specific search request from the user. Thus, it may be necessary to join the user's actions, such as clicking on an advertisement with the corresponding query for which the system assumed was being searched.
Again, FIG. 3 is an example of a configuration for the distributed joining system 107. In this example, primary event information 320 and secondary event information 360 may be received as input to the distributed event joiner system. The event information may be received approximately in the timestamp order in continuous streams 320 and 360. The number of primary events may be much greater than the number of secondary events. For example, for every advertisement shown, only a portion may actually be associated with a click event. In addition, a majority of joining requests from the secondary stream may be looking for recent events in the primary stream.
As shown in FIG. 3, primary event information 320 may be directly streamed into the cache layer 310. As noted above, the cache layer may store primary event information for up to an amount of time T based on the timestamp associated with each primary event. After T time has passed, primary event information may be moved (copied and overwritten) to the databases 70 and 80 on a first in, first out basis. The value of T may be a relatively short amount of time, such as a few minutes, or significantly longer such as an hour or more.
As the primary event data stream is received by the cache layer 310, the cache layer builds an index map 320 in real time. The index map may keep track of a set of (key, offset) pairs. In the example above, the key may be a primary event ID. Each entry can be thought of as a vertex in a linear, monotonically increasing function. A given entry (K, d) may imply that all events before offset “d” (exclusive) associated with the primary key “K” have keys no greater than the value of K, as the record at offset “d” has a key slightly larger than the value of k. The offset between adjacent keys may differ for different adjacent keys. The index map may be sparse, such that the keys do not have to be continuous in the index. Entries may be deleted if they are too close to existing vertices (i.e. their offsets differ by less than a threshold). As the index is written on the fly as events are read, it may contain redundant index entries. The threshold can be used to optimize the size of the index. This may both save space and improve the time for lookup of keys.
The secondary event information is inputted into the joiner tool 340 in order to identify corresponding primary event information. In this regard, the joiner tool may try identifying primary event information using a particular primary key of the secondary event information. In this regard, the joiner tool may first search the cache layer 310 in order to determine whether a particular primary key exists. For example, the joiner tool 340 may receive secondary event information identifying a primary event ID, “K.”
Specifically, the index map may be searched to find the particular key “K.” The max_skew value may then be subtracted from “K” to obtain an offset value. The joiner tool then seeks to the offset value returned by getting lower bound of K minus max_skew in the index map, or the first entry that compares greater than K-max_skew. The event information at the returned offset value may be read, and a new entry is added to the index map for the returned offset value.
The max_skew value may again be subtracted from “K” to obtain an offset value. However, because the new entry was added to the index map for the previously returned offset value, a different offset may be returned by getting lower bound of K minus the max_skew in the index map. The record at the offset value may be read and another new entry may be added to the index map.
This may continue until the same offset value is returned twice. This may be an indication that the stream of primary events that have been seen so far is positioned as closely as possible before the start of the event containing key K (if any). Once this occurs, a linear search may begin by ready keys sequentially until the key K may be found or a key greater than K plus max_skew is found. If a key greater than K plus max_skew may be found, this may indicate that the key K does not exist in the cache layer 107.
When a key does not exist in the cache layer 107, the joiner tool 340 may use the lookup tool 350 to query the log data of databases 70 and 80. In this regard, the logs of databases 70 and 80 may play the role of a catch-all. Thus, older primary event information may still be available for pairing until it reaches an expiration date T2 past which a pairing with a secondary event would be unlikely, for example a few days. The lookup tool may have to perform multiple disk reads of databases 70 or 80 to find an event as they system may seek and read at multiple disk offsets and the final event may need sequential reads. For example, if a key is not found, then the system may retry after some duration based on T2. However, this may be cheaper than cache-layer lookups, which can be costly in terms of RAM, but may have higher latency and processing loads.
FIGS. 4A and 4B are example flow diagrams for a distributed event joining system including some of the features described above. For example, FIG. 4A is an example flow diagram for the processes that may occur at cache layer 310. First, a continuous stream of primary events is received at block 402. Each primary event is associated with a primary event key. The stream of primary events is stored in short-term memory at block 404. An index map for the primary events of the short-term memory is generated using the primary event keys at block 406. After a time T, the stream of primary events is sent to long term memory. The blocks of FIG. 4A may repeat continuously as new primary events are received from the continuous stream of primary events.
In the example of FIG. 4B, is an example flow diagram for the processes that may be performed by the worker computers. A continuous stream of secondary events, each associated with a primary event key, is received at block 410. A secondary event is selected at block 412. Next, whether the primary event key associated with the selected secondary event is included in the short-term memory is determined using the index map (generated at block 406 of FIG. 4B) at block 414. This block may be repeated several times before progressing to the next block. If the primary event key is included in the short-term memory, the primary event is joined with the secondary event and sent to a joined event storage system at block 414, and another secondary event is selected at block 412.
If the primary event key is not included in the short-term memory, whether the primary event key associated with the selected secondary event is included in the long-term memory is determined at block 416. Again, this block may be repeated several times before progressing to the next block. If the primary event key is included in the long-term memory, the primary event is joined with the secondary event and sent to a joined event storage system at block 414. If the primary event key is not included in the long-term memory, the pairing may fail, and another secondary event is selected at block 412. Again, the blocks of FIG. 4B may repeat continuously as new primary events are received from the continuous stream of primary events.
One advantage of the cache layer 310 is relatively low latency and relatively low disk-load. As a result of this, the system 310 can even retry looking up a key in the cache layer multiple times before giving up and going to disk-based lookup system (for example, at databases 70 or 80). This multiple reply may be cheaper in terms of latency and processing loads than the cost of disk seeks on the databases. It may also provide some extra time for the cache layer 310 to catch up as new secondary event information is received.
Because the cache layer handles the majority of recent event lookups, this may add up to a tremendous savings in processing power, and thus, make the system scalable. For example, in a joining system for query and click events, if the cache layer is configured to store primary event information for up to an hour, this may lead to up to 90% of lookups being addressed at the cache layer.
As these and other variations and combinations of the features discussed above can be utilized without departing from the subject matter defined by the claims, the foregoing description of the embodiments should be taken by way of illustration rather than by way of limitation of the subject matter defined by the claims. It will also be understood that the provision of the examples described herein, as well as clauses phrased as “such as,” “including” and the like, should not be interpreted as limiting the subject matter of the claims to the specific examples; rather, the examples are intended to illustrate only one of many possible embodiments. Further, the same reference numbers in different drawings can identify the same or similar elements.

Claims (21)

The invention claimed is:
1. A method comprising:
receiving a continuous stream of primary events corresponding to search queries submitted by one or more users, each received primary event being associated with a corresponding primary event key identifying a particular search query;
storing the received primary events in a short term memory;
generating, by a processor, an index map that tracks primary event keys of any received primary events currently stored in the short term memory;
after a time T has passed, storing the received primary events in a long term memory;
receiving a secondary event corresponding to an advertisement selected by one of the one or more users, the secondary event being associated with a particular primary key; and
using the index map to determine whether the particular primary event key is included in the short term memory.
2. The method of claim 1, further comprising:
when the particular primary event key is included in the short term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory; and
sending the joined primary event and secondary event to a joined event storage system.
3. The method of claim 1, further comprising when the particular primary event key is not included in the short term memory, determining whether the particular primary event key is included in the long term memory.
4. The method of claim 3, further comprising:
when the particular primary event key is included in the long term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory; and
sending the joined primary event and secondary event to a joined event storage system.
5. The method of claim 1, further comprising receiving a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events.
6. The method of claim 1, wherein using the index map to determine whether the particular primary event key is included in the short term memory includes:
determining a maximum skew value for the index map;
determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and
using the offset value to determine whether the particular primary event key is included in the short term memory.
7. The method of claim 1, using the index map to determine whether the particular primary event key is included in the short term memory includes:
determining a maximum skew value for the index map;
seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and
using the offset value to determine whether the particular primary event key is included in the short term memory.
8. A system comprising:
a cache layer for storing a continuously received stream of primary events for a time T, each primary event of the continuously received stream of primary events corresponding to a search queries submitted by one or more users, each primary event of the continuously received stream of primary events having a corresponding primary event key identifying a particular search query;
a long term memory for storing the continuously received stream of primary events after a time T;
a processor configured to:
generate an index map that tracks primary event keys of the continuously received primary events currently stored in the short term memory;
receiving a secondary event corresponding to an advertisement selected by one of the one or more users, the secondary event being associated with a particular primary key; and
using the index map to determine whether the particular primary event key is included in the short term memory.
9. The system of claim 8, wherein the processor is further configured to:
when the particular primary event key is included in the short term memory, join the secondary event with the primary event that is associated with the primary event key in the short term memory; and
send the joined primary event and secondary event to a joined event storage system.
10. The system of claim 8, wherein the processor is further configured to, when the particular primary event key is not included in the short term memory, determine whether the particular primary event key is included in the long term memory.
11. The system of claim 10, wherein the processor is further configured to:
when the particular primary event key is included in the long term memory, join the secondary event with the primary event that is associated with the primary event key in the long term memory; and
send the joined primary event and secondary event to a joined event storage system.
12. The system of claim 8, wherein the processor is further configured to receive a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events.
13. The system of claim 8, wherein the processor is further configured to use the index map to determine whether the particular primary event key is included in the short term memory by:
determining a maximum skew value for the index map;
determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and
using the offset value to determine whether the particular primary event key is included in the short term memory.
14. The system of claim 8, wherein the processor is further configured to use the index map to determine whether the particular primary event key is included in the short term memory by:
determining a maximum skew value for the index map;
seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value; and
using the offset value to determine whether the particular primary event key is included in the short term memory.
15. A non-transitory tangible computer-readable storage medium on which computer readable instructions of a program are stored, the instructions, when executed by a processor, cause the processor to perform a method, the method comprising method comprising:
receiving a continuous stream of primary events corresponding to search queries submitted by one or more users, each received primary event being associated with a corresponding primary event key identifying a particular search query;
storing the received primary events in a short term memory;
generating an index map that tracks primary event keys of any received primary events currently stored in the short term memory;
after a time T has passed, storing the received primary events in a long term memory;
receiving a secondary event corresponding to an advertisement selected by one of the one or more users, the secondary event being associated with a particular primary key; and
using the index map to determine whether the particular primary event key is included in the short term memory.
16. The medium of claim 15, wherein the method further comprises
when the particular primary event key is included in the short term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory; and
sending the joined primary event and secondary event to a joined event storage system.
17. The medium of claim 15, wherein the method further comprises when the particular primary event key is not included in the short term memory, determining whether the particular primary event key is included in the long term memory.
18. The medium of claim 17, wherein the method further comprises:
when the particular primary event key is included in the long term memory, joining the secondary event with the primary event that is associated with the primary event key in the short term memory; and
sending the joined primary event and secondary event to a joined event storage system.
19. The medium of claim 15, wherein the method further comprises receiving a stream of secondary events such that the secondary event associated with the particular primary key is received as part of the stream of secondary events.
20. The medium of claim 15, wherein the method further comprises using the index map to determine whether the particular primary event key is included in the short term memory by:
determining a maximum skew value for the index map;
determining an offset value for the particular primary event key based on a value of the primary event key and the maximum skew value; and
using the offset value to determine whether the particular primary event key is included in the short term memory.
21. The medium of claim 15, wherein the method further comprises using the index map to determine whether the particular primary event key is included in the short term memory by:
determining a maximum skew value for the index map;
seeking to an offset value returned by getting lower bound of a value of the primary event key minus the maximum skew value;
using the offset value to determine whether the particular primary event key is included in the short term memory.
US14/038,060 2013-03-20 2013-09-26 Real-time log joining on a continuous stream of events that are approximately ordered Active US9069681B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/038,060 US9069681B1 (en) 2013-03-20 2013-09-26 Real-time log joining on a continuous stream of events that are approximately ordered

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361803640P 2013-03-20 2013-03-20
US14/038,060 US9069681B1 (en) 2013-03-20 2013-09-26 Real-time log joining on a continuous stream of events that are approximately ordered

Publications (1)

Publication Number Publication Date
US9069681B1 true US9069681B1 (en) 2015-06-30

Family

ID=53441755

Family Applications (1)

Application Number Title Priority Date Filing Date
US14/038,060 Active US9069681B1 (en) 2013-03-20 2013-09-26 Real-time log joining on a continuous stream of events that are approximately ordered

Country Status (1)

Country Link
US (1) US9069681B1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107102918A (en) * 2017-05-26 2017-08-29 郑州云海信息技术有限公司 A kind of data processing method and device
US20190258733A1 (en) * 2018-02-19 2019-08-22 Red Hat, Inc. Methods and devices for joining multiple events in data streaming analytics systems
US11347748B2 (en) * 2020-05-22 2022-05-31 Yahoo Assets Llc Pluggable join framework for stream processing
US11558446B2 (en) * 2020-05-22 2023-01-17 Yahoo Assets Llc Joining and dimensional annotation in a streaming pipeline
US11640257B2 (en) 2016-07-28 2023-05-02 Huawei Technologies Co., Ltd. Data processing method and apparatus
EP4152174A4 (en) * 2021-06-23 2023-11-29 Beijing Baidu Netcom Science Technology Co., Ltd. Data processing method and apparatus, and computing device and medium

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167432A (en) * 1996-02-29 2000-12-26 Webex Communications, Inc., Method for creating peer-to-peer connections over an interconnected network to facilitate conferencing among users
US6477619B1 (en) * 2000-03-10 2002-11-05 Hitachi, Ltd. Disk array controller, its disk array control unit, and increase method of the unit
US20030204474A1 (en) * 2002-04-25 2003-10-30 International Business Machines Corporation Event scheduling with optimization
US20060242017A1 (en) * 2005-03-09 2006-10-26 Medio Systems, Inc. Method and system of bidding for advertisement placement on computing devices
US20110040887A1 (en) * 2009-08-14 2011-02-17 International Business Machines Corporation Processing of streaming data with a keyed join
US20110173235A1 (en) * 2008-09-15 2011-07-14 Aman James A Session automated recording together with rules based indexing, analysis and expression of content
US20110231241A1 (en) * 2010-03-18 2011-09-22 Yahoo! Inc. Real-time personalization of sponsored search based on predicted click propensity
US20110288928A1 (en) * 2010-05-21 2011-11-24 Microsoft Corporation Online platform for web advertisement competition
US20120010979A1 (en) * 2005-09-14 2012-01-12 Jorey Ramer System for targeting advertising content to a plurality of mobile communication facilities
US20120151253A1 (en) * 2010-12-14 2012-06-14 Western Digital Technologies, Inc. System and method for maintaining a data redundancy scheme in a solid state memory in the event of a power loss
US20120191982A1 (en) * 2007-12-06 2012-07-26 Levin Timothy Evert Non-volatile storage of encrypted data
US8370520B2 (en) 2008-11-24 2013-02-05 Juniper Networks, Inc. Adaptive network content delivery system

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6167432A (en) * 1996-02-29 2000-12-26 Webex Communications, Inc., Method for creating peer-to-peer connections over an interconnected network to facilitate conferencing among users
US6477619B1 (en) * 2000-03-10 2002-11-05 Hitachi, Ltd. Disk array controller, its disk array control unit, and increase method of the unit
US20030204474A1 (en) * 2002-04-25 2003-10-30 International Business Machines Corporation Event scheduling with optimization
US20060242017A1 (en) * 2005-03-09 2006-10-26 Medio Systems, Inc. Method and system of bidding for advertisement placement on computing devices
US20120010979A1 (en) * 2005-09-14 2012-01-12 Jorey Ramer System for targeting advertising content to a plurality of mobile communication facilities
US20120191982A1 (en) * 2007-12-06 2012-07-26 Levin Timothy Evert Non-volatile storage of encrypted data
US20110173235A1 (en) * 2008-09-15 2011-07-14 Aman James A Session automated recording together with rules based indexing, analysis and expression of content
US8370520B2 (en) 2008-11-24 2013-02-05 Juniper Networks, Inc. Adaptive network content delivery system
US20110040887A1 (en) * 2009-08-14 2011-02-17 International Business Machines Corporation Processing of streaming data with a keyed join
US20110231241A1 (en) * 2010-03-18 2011-09-22 Yahoo! Inc. Real-time personalization of sponsored search based on predicted click propensity
US20110288928A1 (en) * 2010-05-21 2011-11-24 Microsoft Corporation Online platform for web advertisement competition
US20120151253A1 (en) * 2010-12-14 2012-06-14 Western Digital Technologies, Inc. System and method for maintaining a data redundancy scheme in a solid state memory in the event of a power loss

Non-Patent Citations (31)

* Cited by examiner, † Cited by third party
Title
Abadi, Daniel J. et al., "The Design of the Borealis Stream Processing Engine," Proceedings of the 2005 CIDR Conference.
ATG Installation and Configuration Guide, [online], [Retrieved Mar. 7, 2013] Retrieved from the Internet: <http://docs.oracle.com/cd/E23095-01/Platform.93/ATGInstallGuide/html/s08> 1 page.
ATG Installation and Configuration Guide, [online], [Retrieved Mar. 7, 2013] Retrieved from the Internet: 1 page.
Baker Jason et al., "Megastore: Providing Scalable, Highly Available Storage for Interactive Services," 5th Biennial Conference on Innovative Data Systems Research (2011) Asilomar, California USA.
Chandrasekaran, Sirish et al., "Streaming Queries over Streaming Data," Proceedings of the 28th VLDB Conference, (2002) Hong Kong, China.
Chang, Fay et al., "Bigtable: A Distributed Storage System for Structured Data," ACM Transactions on Computer Systems (2008) 26:2 Article 4.
Codd, E.F. et al., "A Relational Model of Data for Large Shared Data Banks," Communications of the ACM, (1970) 13:6.
Corbett, James C. et al., "Spanner: Google's Globally-Distributed Database," 10th USENIX Symposium on Operating Systems Design and Implementation (2012).
Das, Abhinandan et al., "Approximate Join Processing Over Data Streams," SIGMOD (2003) ACM 1-58113-634.
Dean, Jeffrey et al., "MapReduce: Simplified Data Processing on Large Clusters," OSDI Technical Program (2004) pp. 1-13.
Fitzpatrick, Brad, "Distributed Caching with Memcached," Linux Journal (2004) www.linuxjournal.com/node/7451/print.
Gedik, Bugra, et al., "Executing Stream Joins on the Cell Processor," VLDB (2007) ACM 978-1-59593-649, Vienna Austria.
Ghemawat, Sanjay et al., "The Google File System," SOSP (2003) ACM 1-58113-757.
Hammad Moustafa A. et al., "Stream Window Join: Tracking Moving Objects in Sensor-Network Databases," SSDBM (2003).
Kang, Jaewoo et al., "Evaluating Window Joins Over Unbounded Streams", University of Wisconsin-Madison, Computer Sciences Department, 2003, 12 pages.
Kang, Jaewoo et al., "Evaluating Window Joins over Unbounded Streams," Proceedings of the 28th VLDB Conference, (2002) Hong Kong, China.
Karger, David et al., "Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web," Department of Mathematics, MIT, Cambridge (1997) http://theory.lcs.mit.edu.
Leslie Lamport, Paxos Made Simple, Nov. 1, 2001, 14 pages.
Mishra, Priti et al., "Join Processing in Relational Databases," ACM Computing Surveys, (1992) 24:1.
Neumeyer, Leonardo et al., "S4: Distributed Stream Computing Platform," IEEE International Conference on Data Mining Workshops, (2010) 978-0-7695-4257.
Rao, Jun et al., "Using Paxos to Build a Scalable, Consistent, and Highly Available Datastore," VLDB Endowment (2011) 4:4.
Schneider, Fred B., "Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial," ACM Computing Surveys, (1990) 22:4.
Shasa, Dennis et al., "Database Tuning: Principles, Experiments, and Troubleshooting Techniques," Morgan Kaufmann Publishers (2002) ISBN: 1558607536.
Spyros Blanas, Jignesh M. Patel, Vuk Ercegovac, Jun Rao, Eugene J. Shekita and Yuanyuan Tian, A Comparison of Join Algorithms for Log Processing in MapReduce, 12 pages, 2010.
Spyros Blanas, Jignesh M. Patel, Vuk Ercegovac, Jun Rao, Eugene J. Shekita and Yuanyuan Tian, A Comparison of Join Algorithms for Log Processing in MapReduce, Power Point Presentation, 17 pages, 2010.
Teubner, Jens et al., "How Soccer Players Would do Stream Joins," SIGMOD (2011) Athens, Greece.
Tushar Chandra, Robert Griesemer, and Joshua Redstone, Paxos Made Live-An Engineering Perspective, Jun. 26, 2007, 16 pages.
What is Amazon DynamoDB?-Amazon DynamoDB (2013) docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html.
Xie, Junyi et al., "A Survey of Join Processing in Data Streams," (2006).
Xie, Junyi et al., "A Survey of Join Processing in Data Streams," (2007).
Zaharia, Matei et al., "Discretized Streams: A Fault-Tolerant Model for Scalable Stream Processing," Electrical Engineering and Computer Sciences University of California at Berkeley (2012) http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-259.html.

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11640257B2 (en) 2016-07-28 2023-05-02 Huawei Technologies Co., Ltd. Data processing method and apparatus
CN107102918A (en) * 2017-05-26 2017-08-29 郑州云海信息技术有限公司 A kind of data processing method and device
US20190258733A1 (en) * 2018-02-19 2019-08-22 Red Hat, Inc. Methods and devices for joining multiple events in data streaming analytics systems
US10860586B2 (en) 2018-02-19 2020-12-08 Red Hat, Inc. Methods and devices for joining multiple events in data streaming analytics systems
US11669528B2 (en) 2018-02-19 2023-06-06 Red Hat, Inc. Joining multiple events in data streaming analytics systems
US11347748B2 (en) * 2020-05-22 2022-05-31 Yahoo Assets Llc Pluggable join framework for stream processing
US11558446B2 (en) * 2020-05-22 2023-01-17 Yahoo Assets Llc Joining and dimensional annotation in a streaming pipeline
US11645287B2 (en) 2020-05-22 2023-05-09 Yahoo Assets Llc Pluggable join framework for stream processing
US11899672B2 (en) 2020-05-22 2024-02-13 Yahoo Assets Llc Pluggable join framework for stream processing
US11956297B2 (en) 2020-05-22 2024-04-09 Yahoo Assets Llc Joining and dimensional annotation in a streaming pipeline
EP4152174A4 (en) * 2021-06-23 2023-11-29 Beijing Baidu Netcom Science Technology Co., Ltd. Data processing method and apparatus, and computing device and medium

Similar Documents

Publication Publication Date Title
US9069681B1 (en) Real-time log joining on a continuous stream of events that are approximately ordered
KR102102013B1 (en) Adjusting content delivery based on user submissions
US8438163B1 (en) Automatic learning of logos for visual recognition
US9448999B2 (en) Method and device to detect similar documents
US20200089666A1 (en) Secure data isolation in a multi-tenant historization system
US8825711B2 (en) Managing cross-correlated data
US10242051B2 (en) Efficient multi-tenant spatial and relational indexing
US11301425B2 (en) Systems and computer implemented methods for semantic data compression
US10990629B2 (en) Storing and identifying metadata through extended properties in a historization system
US9477720B1 (en) Social search endorsements
CN107451208B (en) Data searching method and device
Sehgal et al. Sentiment analysis of big data applications using Twitter Data with the help of HADOOP framework
US20130185429A1 (en) Processing Store Visiting Data
CN110019001B (en) Method, system and monitoring module for improving message tracing capability of message middleware
CN106951557B (en) Log association method and device and computer system applying log association method and device
CN106294695A (en) A kind of implementation method towards the biggest data search engine
US10476668B2 (en) Citation and attribution management methods and systems
US11789946B2 (en) Answer facts from structured content
CN104794190A (en) Method and device for effectively storing big data
US8082291B2 (en) Identifying relevant data from unstructured feeds
US20110258177A1 (en) Systems and methods for providing a microdocument framework for storage, retrieval, and aggregation
US20220391368A1 (en) Cryptography system for using associated values stored in different locations to encode and decode data
US9092338B1 (en) Multi-level caching event lookup
US8700628B1 (en) Personalized aggregation of annotations
CN109947759A (en) A kind of data directory method for building up, indexed search method and device

Legal Events

Date Code Title Description
AS Assignment

Owner name: GOOGLE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:QIU, TIANHAO;SINGH, MANPREET;JIANG, HAIFENG;AND OTHERS;SIGNING DATES FROM 20130419 TO 20130421;REEL/FRAME:031475/0637

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: GOOGLE LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044334/0466

Effective date: 20170929

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8