You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@falcon.apache.org by ve...@apache.org on 2013/05/16 06:30:43 UTC
svn commit: r1483191 [5/5] - in /incubator/falcon: ./ src/ src/main/
src/main/webapp/ src/main/webapp/WEB-INF/ src/site/ src/site/resources/
src/site/resources/images/ src/site/resources/slides/
src/site/resources/slides/core/ src/site/resources/slides...
Added: incubator/falcon/src/site/twiki/docs/FalconArchitecture.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/docs/FalconArchitecture.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/docs/FalconArchitecture.twiki (added)
+++ incubator/falcon/src/site/twiki/docs/FalconArchitecture.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,611 @@
+---++ Contents
+ * <a href="#Architecture">Architecture</a>
+ * <a href="#Control_flow">Control flow</a>
+ * <a href="#Modes_Of_Deployment">Modes Of Deployment</a>
+ * <a href="#Entity_Management_actions">Entity Management actions</a>
+ * <a href="#Instance_Management_actions">Instance Management actions</a>
+ * <a href="#Retention">Retention</a>
+ * <a href="#Replication">Replication</a>
+ * <a href="#Cross_entity_validations">Cross entity validations</a>
+ * <a href="#Updating_process_and_feed_definition">Updating process and feed definition</a>
+ * <a href="#Handling_late_input_data">Handling late input data</a>
+ * <a href="#Idempotency">Idempotency</a>
+ * <a href="#Alerting_and_Monitoring">Alerting and Monitoring</a>
+ * <a href="#Falcon_EL_Expressions">Falcon EL Expressions</a>
+
+---++ Architecture
+---+++ Introduction
+Falcon is a feed and process management platform over hadoop. Falcon essentially transforms user's feed
+and process configurations into repeated actions through a standard workflow engine. Falcon by itself
+doesn't do any heavy lifting. All the functions and workflow state management requirements are delegated
+to the workflow scheduler. The only thing that Falcon maintains is the dependencies and relationship between
+these entities. This is adequate to provide integrated and seamless experience to the developers using
+the falcon platform.
+
+---+++ Falcon Architecture - Overview
+<img src="../images/Architecture.png" height="400" width="600" />
+
+---+++ Scheduler
+Falcon system has picked Oozie as the default scheduler. However the system is open for integration with
+other schedulers. Lot of the data processing in hadoop requires scheduling to be based on both data availability
+as well as time. Oozie currently supports these capabilities off the shelf and hence the choice.
+
+---+++ Control flow
+Though the actual responsibility of the workflow is with the scheduler (Oozie), Falcon remains in the
+execution path, by subscribing to messages that each of the workflow may generate. When Falcon generates a
+workflow in Oozie, it does so, after instrumenting the workflow with additional steps which includes messaging
+via JMS. Falcon system itself subscribes to these control messages and can perform actions such as retries,
+handling late input arrival etc.
+
+
+---++++ Feed Schedule flow
+<img src="../images/FeedSchedule.png" height="400" width="600" />
+
+---++++ Process Schedule flow
+<img src="../images/ProcessSchedule.png" height="400" width="600" />
+
+
+
+---++ Modes Of Deployment
+There are two basic components of Falcon set up. Falcon Prism and Falcon Server.
+As the name suggests Falcon Prism splits the request it gets to the Falcon Servers.More details below:
+
+---+++ Stand Alone Mode:
+Stand alone mode is useful when the hadoop jobs and revelant data processing invoves only one hadoop cluster. In this mode there is single Falcon server that contacts with oozie to schedule jobs on Hadoop. All the process / feed request like submit, schedule, suspend , kill are sent to this server only. For running in this mode oen should use the falcon whihc has been built for standalone mode , or build using standalone option if using source code.
+
+---+++ Distributed Mode:
+Distributed mode is the mode which you might me using most of the time. This is for orgs which have which have multiple instance of hadoop clusters, and multiple workflow schedulers to handle them. Here we have 2 components: Prism and Server. Both Prism and server have there own setup (runtime and startup properties) and there config localtions.
+In this mode Prism acts as a contact point for Falcon servers.Below is what all request can be sent tp prism and server in this mode:
+
+ Prism: submit, schedule, submitAndSchdeule, Suspend, Resume, Kill , instance management
+ Server: schedule, suspend, resume, instance management
+
+As observed above submit and kill are kept exclusively as Prism operations to keep all the config stores in sync and to support feture of idempotency.
+Request may also be sent from prism but directed to only one specific server, to use that once had to use option "-colo" from CLI or append the same in web request if using API.
+
+When a cluster is submitted it is bu default sent to all the servers configured in the prism.
+When is feed is SUBMIT / SCHEDULED request is only sent to he servers specified in the feed / process definitions. Servers are mentioned in the feed / process via CLUSTER tags in xml definition.
+
+---++++ Prism Setup
+<img src="../images/PrismSetup.png" height="400" width="600" />
+
+---+++ Configuration Store
+Configuration store is file system based store that the Falcon system maintains where the entity definitions
+are stored. File System used for the configuration store can either be a local file system or a hdfs file system.
+It is recommended that to maintain this store outside of the system where Falcon is deployed. This is needed
+for handling issues relating to disk failures or other permanent failures of the system where Falcon is deployed.
+Configuration store also maintains an archive location where prior versions of the configuration or deleted
+configurations are maintained. They are never accessed by the Falcon system and they merely serve to track
+historical changes to the entity definitions.
+
+---+++ Atomic Actions
+Often times when Falcon performs entity management actions, it may need to do several individual actions.
+If one of the action were to fail, then the system could be in an inconsistent state. To avoid this, all
+individual operations performed are recorded into a transaction journal. This journal is then used to undo
+the overall user action. In some cases, it is not possible to undo the action. In such cases, Falcon attempts
+to keep the system in an consistent state.
+
+---++ Entity Management actions
+
+---+++ Submit:
+Entity submit action allows a new cluster/feed/process to be setup within Falcon. Submitted entity is not
+scheduled, meaning it would simply be in the configuration store within Falcon. Besides validating against
+the schema for the corresponding entity being added, the Falcon system would also perform inter-field
+validations within the configuration file and validations across dependent entities.
+
+---+++ List:
+List all the entities within the falcon config store for the entity type being requested. This will include
+both scheduled and submitted entity configurations.
+
+---+++ Dependency:
+Returns the dependencies of the requested entity. Dependency list include both forward and backward
+dependencies (depends on & is dependent on). For ex, a feed would show process that are dependent on the
+feed and the clusters that it depends on.'
+
+---+++ Schedule:
+Feeds or Processes that are already submitted and present in the config store can be scheduled. Upon schedule,
+Falcon system wraps the required repeatable action as a bundle of oozie coordinators and executes them on the
+Oozie scheduler. (It is possible to extend Falcon to use an alternate workflow engine other than Oozie).
+Falcon overrides the workflow instance's external id in Oozie to reflect the process/feed and the nominal
+time. This external Id can then be used for instance management functions.
+
+---+++ Suspend:
+This action is applicable only on scheduled entity. This triggers suspend on the oozie bundle that was
+scheduled earlier through the schedule function. No further instances are executed on a suspended process/feed.
+
+---+++ Resume:
+Puts a suspended process/feed back to active, which in turn resumes applicable oozie bundle.
+
+---+++ Status:
+Gets the current status of the entity.
+
+---+++ Definition:
+Gets the current entity definition as stored in the configuration store. Please note that user documentations
+in the entity will not be retained.
+
+---+++ Delete:
+Delete operation on the entity removes any scheduled activity on the workflow engine, besides removing the
+entity from the falcon configuration store. Delete operation on an entity would only succeed if there are
+no dependent entities on the deleted entity.
+
+---+++ Update:
+Update operation allows an already submitted/scheduled entity to be updated. Cluster update is currently
+not allowed. Feed update can cause cascading update to all the processes already scheduled. The following
+set of actions are performed in Oozie to realize an update.
+
+ * Suspend the previously scheduled Oozie coordinator. This is prevent any new action from being triggered.
+ * Update the coordinator to set the end time to "now"
+ * Resume the suspended coordiantors
+ * Schedule as per the new process/feed definition with the start time as "now"
+
+---++ Instance Management actions
+
+
+Instance Manager gives user the option to control individual instances of the process based on their instance start time (start time of that instance). Start time needs to be given in standard TZ format. Example: 01 Jan 2012 01:00 => 2012-01-01T01:00Z
+
+All the instance management operations (except running) allow single instance or list of instance within a Date range to be acted on. Make sure the dates are valid. i.e are within the start and end time of process itself.
+
+For every query in instance management the process name is a compulsory parameter.
+
+Parameters -start and -end are used to mention the date range within which you want the instance to be operated upon.
+
+-start: using only "-start" without "-end" will conduct the desired operation only on single instance given by date along with start.
+
+-end: "-end" can only be used along with "-start" . It corresponds to the end date till which instance need to operated upon.
+
+ * 1. *status*: -status option via CLI can be used to get the status of a single or multiple instances. If the instance is not yet materialized but is within the process validity range, WAITING is returned as the state.Along with the status of the instance log location is also returned.
+
+
+ * 2. *running*: -running returns all the running instance of the process. It does not take any start or end dates but simply return all the instances in state RUNNING at that given time.
+
+ * 3. *rerun*: -rerun is the option that you will use most often from instance management. As the name suggest this option is used to rerun a particular instance or instances of the process. The rerun option reruns all parent workflow for the instance, which in turn rerun all the sub-workflows for it. This option is valid for any instance in terminal state, i.e. KILLED, SUCCEEDED, FAILED. User can also set properties in the request, which will give options what types of actions should be rerun like, only failed, run all etc. These properties are dependent on the workflow engine being used along with falcon.
+
+ * 4. *suspend*: -suspend is used to suspend a instance or instances for the given process. This option pauses the parent workflow at the state, which it was in at the time of execution of this command. This command is similar to SUSPEND process command in functionality only difference being, SUSPEND process suspends all the instance whereas suspend instance suspend only that instance or instances in the range.
+
+ * 5. *resume*: -resume option is used to resume any instance that is in suspended state. (Note: due to a bug in oozie �resume option in some cases may not actually resume the suspended instance/ instances)
+ * 6. *kill*: -kill option can be used to kill an instance or multiple instances
+
+
+In all the cases where your request is syntactically correct but logically not, the instance / instances are returned with the same status as earlier. Example: trying to resume a KILLED / SUCCEEDED instance will return the instance with KILLED / SUCCEEDED, without actually performing any operation. This is so because only an instance in SUSPENDED state can be resumed. Same thing is valid for rerun a SUSPENDED or RUNNING options etc.
+
+---++ Retention
+In coherence with it's feed lifecycle management philosophy, Falcon allows the user to retain data in the system
+for a specific period of time for a scheduled feed. The user can specify the retention period in the respective
+feed/data xml in the following manner for each cluster the feed can belong to :
+<verbatim>
+<clusters>
+ <cluster name="corp" type="source">
+ <validity start="2012-01-30T00:00Z" end="2013-03-31T23:59Z"
+ timezone="UTC" />
+ <retention limit="hours(10)" action="delete" />
+ </cluster>
+ </clusters>
+</verbatim>
+
+The 'limit' attribute can be specified in units of minutes/hours/days/months, and a corresponding numeric value can
+be attached to it. It essentially instructs the system to retain data spanning from the current moment to the time specified
+in the attribute spanning backwards in time. Any data beyond the limit (past/future) is erased from the system.
+
+---+++ Example:
+ If retention period is 10 hours, and the policy kicks in at time 't', the data retained by system is essentially the
+one falling in between [t-10h,t]. Any data in the boundaries [-�,t-10h) and (t,�] is removed from the system.
+
+The 'action' attribute can attain values of DELETE/ARCHIVE. Based upon the tag value, the data eligible for removal is either
+deleted/archived.
+
+---+++ NOTE: Falcon 0.1/0.2 releases support Delete operation only
+
+---+++ When does retention policy come into play, aka when is retention really performed?
+
+Retention policy in Falcon kicks off on the basis of the time value specified by the user. Here are the basic rules:
+
+ * If the retention policy specified is less than 24 hours: In this event, the retention policy automatically kicks off every 6 hours.
+ * If the retention policy specified is more than 24 hours: In this event, the retention policy automatically kicks off every 24 hours.
+ * As soon as a feed is successfully scheduled: the retention policy is triggered immediately regardless of the current timestamp/state of the system.
+
+Relation between feed path and retention policy: Retention policy for a particular scheduled feed applies only to the eligible feed path
+specified in the feed xml. Any other paths that do not conform to the specified feed path are left unaffected by the retention policy.
+
+---++ Replication
+Falcons feed lifecycle management also supports Feed replication across different clusters out-of-the-box.
+Multiple source clusters and target clusters can be defined in feed definition, Falcon replicates the data using
+hadoop's distcp version 2 across different clusters whenever a feed is scheduled.
+
+The frequency at which the data is replicated is governed by the frequency specified in the feed definition.
+Ideally, the feeds data path should have the same granularity as that for frequency of the feed, i.e. if the frequency of the feed is hours(3), then the data path should be to level /${YEAR}/${MONTH}/${DAY}/${HOUR}.
+<verbatim>
+ <clusters>
+ <cluster name="sourceCluster1" type="source" partition="${cluster.name}">
+ <validity start="2021-11-01T00:00Z" end="2021-12-31T00:00Z"/>
+ </cluster>
+ <cluster name="sourceCluster2" type="source" partition="COUNTRY/${cluster.name}">
+ <validity start="2021-11-01T00:00Z" end="2021-12-31T00:00Z"/>
+ </cluster>
+ <cluster name="backupCluster" type="target">
+ <validity start="2011-11-01T00:00Z" end="2011-12-31T00:00Z"/>
+ </cluster>
+ </clusters>
+</verbatim>
+
+If more than 1 source cluster is defined, then partition expression is compulsory, a partition can also have a constant.
+The expression is required to avoid copying data from different source location to the same target location, also only the data in the partition is considered for replication if it is present. The partitions defined in the cluster should be less than or equal to the number of partition declared in the feed definition.
+
+Falcon uses pull based replication mechanism, meaning in every target cluster, for a given source cluster a coordinator is scheduled which pulls the data using distcp from source cluster. So in the above example, 2 coordinators are scheduled in backupCluster, one which pulls the data from sourceCluster1 and another from sourceCluster2.
+Also, for every feed instance which is replicated Falcon sends a JMS message on success or failure of replication instance.
+
+Replication can be scheduled with the past date, the time frame considered for replication is the minimum overlapping window of start and end time of source and target cluster, ex: if s1 and e1 is the start and end time of source cluster respectively,
+and s2 and e2 of target cluster, then the coordinator is scheduled in target cluster with start time max(s1,s2) and min(e1,e2).
+---+++ Where is the feed path defined?
+
+It's defined in the feed xml within the location tag.
+
+*Example:*
+<verbatim>
+<locations>
+ <location type="data" path="/retention/testFolders/${YEAR}-${MONTH}-${DAY}" />
+</locations>
+</verbatim>
+
+Now, if the above path contains folders in the following fashion:
+
+/retention/testFolders/${YEAR}-${MONTH}-${DAY}
+/retention/testFolders/${YEAR}-${MONTH}/someFolder
+
+The feed retention policy would only act on the former and not the latter.
+
+Users may choose to override the feed path specific to a cluster, so every cluster
+may have a different feed path.
+*Example:*
+<verbatim>
+<clusters>
+ <cluster name="testCluster" type="source">
+ <validity start="2011-11-01T00:00Z" end="2011-12-31T00:00Z"/>
+ <locations>
+ <location type="data" path="/projects/falcon/clicks/${YEAR}-${MONTH}-${DAY}" />
+ <location type="stats" path="/projects/falcon/clicksStats/${YEAR}-${MONTH}-${DAY}" />
+ <location type="meta" path="/projects/falcon/clicksMetaData/${YEAR}-${MONTH}-${DAY}" />
+ </locations>
+ </cluster>
+ </clusters>
+</verbatim>
+
+
+---+++ Relation between feed's retention limit and feed's late arrival cut off period:
+
+For reasons that are obvious, Falcon has an external validation that ensures that the user
+always specifies the feed retention limit to be more than the feed's allowed late arrival period.
+If this rule is violated by the user, the feed submission call itself throws back an error.
+
+
+---++ Cross entity validations
+
+
+---+++ Entity Dependencies in a nutshell
+<img src="../images/EntityDependency.png" height="50" width="300" />
+
+
+The above schematic shows the dependencies between entities in Falcon. The arrow in above diagram
+points from a dependency to the dependent.
+
+
+Let's just get one simple rule stated here, which we will keep referring to time and again while
+talking about entities: A dependency in the system cannot be removed unless all it's dependents are
+removed first. This holds true for all transitive dependencies also.
+
+Now, let's follow it up with a simple illustration of an Falcon Job:
+
+Let's consider a process P that refers to feed F1 as an input feed, and generates feed F2 as an
+output feed. These feeds/processes are supposed to be associated with a cluster C1.
+
+The order of submission of this job would be in the following order:
+
+C1->F1/F2(in any order)->P
+
+The order of removal of this job from the system is in the exact opposite order, i.e.:
+
+P->F1/F2(in any order)->C1
+
+Please note that there might be multiple process referring to a particular feed, or a single feed belonging
+to multiple clusters. In that event, any of the dependencies cannot be removed unless ALL of their dependents
+are removed first. Attempting to do so will result in an error message and a 400 Bad Request operation.
+
+
+---+++ Other cross validations between entities in Falcon system
+
+*Cluster-Feed Cross validations:*
+
+ * The cluster(s) referenced by feed (inside the <clusters> tag) should be present in the system at the time
+of submission. Any exception to this results in a feed submission failure. Note that a feed might be referring
+to more than a single cluster. The identifier for the same is the 'name' attribute for the individual cluster.
+
+*Example:*
+
+*Feed XML:*
+
+<verbatim>
+ <clusters>
+ <cluster name="corp" type="source">
+ <validity start="2009-01-01T00:00Z" end="2012-12-31T23:59Z"
+ timezone="UTC" />
+ <retention limit="months(6)" action="delete" />
+ </cluster>
+ </clusters>
+</verbatim>
+
+*Cluster corp's XML:*
+
+<verbatim>
+<cluster colo="gs" description="" name="corp" xmlns="uri:falcon:cluster:0.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+</verbatim>
+
+*Cluster-Process Cross validations:*
+
+
+ * In a similar relationship to that of feed and a cluster, a process also refers to the relevant cluster by the
+'name' attribute. Any exception results in a process submission failure.
+
+
+---+++ Example:
+---+++ Process XML:
+<verbatim>
+<process name="agregator-coord16">
+ <cluster name="corp"/>....
+</verbatim>
+---+++ Cluster corp's XML:
+<verbatim>
+<cluster colo="gs" description="" name="corp" xmlns="uri:falcon:cluster:0.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+</verbatim>
+
+*Feed-Process Cross Validations:*
+
+
+1. The process <input> and feeds designated as input feeds for the job:
+
+ For every feed referenced in the <input> tag in a process definition, following rules are applied
+when the process is due for submission:
+
+ * The feed having a value associated with the 'feed' attribute in input tag should be present in
+the system. The corresponding attribute in the feed definition is the 'name' attribute in the <feed> tag.
+
+*Example:*
+
+*Process xml:*
+
+<verbatim>
+<input end-instance="now(0,20)" start-instance="now(0,-60)"
+feed="raaw-logs16" name="inputData"/>
+</verbatim>
+
+*Feed xml:*
+<verbatim>
+<feed description="clicks log" name="raaw-logs16"....
+</verbatim>
+
+
+ * The time interpretation for corresponding tags indicating the start and end instances for a
+particular input feed in the process xml should lie well within the timespan of the period specified in
+<validity> tag of the particular feed.
+
+*Example:*
+
+1. In the following scenario, process submission will result in an error:
+
+*Process XML:*
+<verbatim>
+<input end-instance="now(0,20)" start-instance="now(0,-60)"
+ feed="raaw-logs16" name="inputData"/>
+</verbatim>
+*Feed XML:*
+<verbatim>
+<validity start="2009-01-01T00:00Z" end="2009-12-31T23:59Z".....
+</verbatim>
+Explanation: The process timelines for the feed range between a 40 minute interval between [-60m,-20m] from
+the current timestamp (which lets assume is 'today' as per the 'now' directive). However, the feed validity
+is between a 1 year period in 2009, which makes it anachronistic.
+
+2. The following example would work just fine:
+
+*Process XML:*
+<verbatim>
+<input end-instance="now(0,20)" start-instance="now(0,-60)"
+ feed="raaw-logs16" name="inputData"/>
+</verbatim>
+*Feed XML:*
+<verbatim>
+validity start="2009-01-01T00:00Z" end="2012-12-31T23:59Z" .......
+</verbatim>
+since at the time of charting this document (03/03/2012), the feed validity is able to encapsulate the process
+input's start and end instances.
+
+
+Failure to follow any of the above rules would result in a process submission failure.
+
+*NOTE:* Even though the above check ensures that the timelines are not anachronistic, if the input data is not
+present in the system for the specified time period, the process can be submitted and scheduled, but all instances
+created would result in a WAITING state unless data is actually provided in the cluster.
+
+
+
+---++ Updating process and feed definition
+Any changes in feed/process can be done by updating its definition. After the update, any new workflows which are to be scheduled after the update call will pick up the new changes. Feed/process name and start time can't be updated. Updating a process triggers updates to the workflow that is triggered in the workflow engine. Updating feed updates feed workflows like retention, replication etc and also updates the processes that reference the feed.
+
+
+---++ Handling late input data
+Falcon system can handle late arrival of input data and appropriately re-trigger processing for the affected
+instance. From the perspective of late handling, there are two main configuration parameters late-arrival cut-off
+and late-inputs section in feed and process entity definition that are central. These configurations govern
+how and when the late processing happens. In the current implementation (oozie based) the late handling is very
+simple and basic. The falcon system looks at all dependent input feeds for a process and computes the max late
+cut-off period. Then it uses a scheduled messaging framework, like the one available in Apache ActiveMQ or Java's DelayQueue to schedule a message with a cut-off period, then after a cut-off period the message is dequeued and Falcon checks for changes in the feed data which is recorded in HDFS in latedata file by falcons "record-size" action, if it detects any changes then the workflow will be rerun with the new set of feed data.
+
+*Example:*
+The late rerun policy can be configured in the process definition.
+Falcon supports 3 policies, periodic, exp-backoff and final.
+Delay specifies, how often the feed data should be checked for changes, also one needs to
+explicitly set the feed names in late-input which needs to be checked for late data.
+<verbatim>
+ <late-process policy="exp-backoff" delay="hours(1)">
+ <late-input input="impression" workflow-path="hdfs://impression/late/workflow" />
+ <late-input input="clicks" workflow-path="hdfs://clicks/late/workflow" />
+ </late-process>
+</verbatim>
+
+---++ Idempotency
+All the operations in Falcon are Idempotent. That is if you make same request to the falcon server / prism again you will get a SUCCESSFUL return if it was SUCCESSFUL in the first attempt. For example, you submit a new process / feed and get SUCCESSFUL message return. Now if you run the same command / api request on same entity you will again get a SUCCESSFUL message. Same is true for other operatins like schedule, kill , suspend and resume.
+Idempotency also by takes care of the condition when request is sent through prism and fails on one or more servers. For example prism is configured to send request to 3 servers. First user sends a request to SUBMIT a process on all 3 of them, and receives a response SUCCESSFUL from all of them. Then due to some issue one of the servers goes down, and user send a request to schdeule the submitted process. This time he will receive a response with PARTIAL status and a FALIURE message from the server that has gone down. If the users check he will find the porcess would have been started and running on the 2 SUCCESSFUL servers. Now the issue with server is figured out and it is brought up. Sending the SCHEDULE request again through prism will result in a SUCCESSFUL response from pism as well as other three servers, but this time PORCESS will be SCHEDULED only on the server which had failed earlier and other two will keep running as before.
+
+
+---++ Alerting and Monitoring
+---+++ Alerting
+Falcon provides monitoring of various events by capturing metrics of those events.
+The metric numbers can then be used to monitor performance and health of the Falcon system and the entire processing pipelines.
+
+Users can view the logs of these events in the metric.log file, by default this file is created under /var/log/falcon/ directory.
+Users may also extend the Falcon monitoring framework to send events to systems like Mondemand/lwes.
+
+The following events are captured by Falcon for logging the metrics:
+ 1. New cluster definitions posted to Falcon (success & failures)
+ 1. New feed definition posted to Falcon (success & failures)
+ 1. New process definition posted to Falcon (success & failures)
+ 1. Process update events (success & failures)
+ 1. Feed update events (success & failures)
+ 1. Cluster update events (success & failures)
+ 1. Process suspend events (success & failures)
+ 1. Feed suspend events (success & failures)
+ 1. Process resume events (success & failures)
+ 1. Feed resume events (success & failures)
+ 1. Process remove events (success & failures)
+ 1. Feed remove events (success & failures)
+ 1. Cluster remove events (success & failures)
+ 1. Process instance kill events (success & failures)
+ 1. Process instance re-run events (success & failures)
+ 1. Process instance generation events
+ 1. Process instance failure events
+ 1. Process instance auto-retry events
+ 1. Process instance retry exhaust events
+ 1. Feed instance deletion event
+ 1. Feed instance deletion failure event (no retries)
+ 1. Feed instance replication event
+ 1. Feed instance replication failure event
+ 1. Feed instance replication auto-retry event
+ 1. Feed instance replication retry exhaust event
+ 1. Feed instance late arrival event
+ 1. Feed instance post cut-off arrival event
+ 1. Process re-run due to late feed event
+ 1. Transaction rollback failed event
+
+The metric logged for an event has the following properties:
+ 1. Action - Name of the event.
+ 2. Dimensions - A list of name/value pairs of various attributes for a given action.
+ 3. Status- Status of an action FAILED/SUCCEEDED.
+ 4. Time-taken - Time taken in nano seconds for a given action.
+
+An example for an event logged for a submit of a new process definition:
+
+ 2012-05-04 12:23:34,026 {Action:submit, Dimensions:{entityType=process}, Status: SUCCEEDED, Time-taken:97087000 ns}
+
+Users may parse the metric.log or capture these events from custom monitoring frameworks and can plot various graphs
+or send alerts according to their requirements.
+
+---+++ Notifications
+Falcon creates a JMS topic for every process/feed that is scheduled in Falcon.
+The implementation class and the broker url of the JMS engine are read from the dependent cluster's definition.
+Users may register consumers on the required topic to check the availability or status of feed instances.
+
+For a given process that is scheduled, the name of the topic is same as the process name.
+Falcon sends a Map message for every feed produced by the instance of a process to the JMS topic.
+The JMS MapMessage sent to a topic has the following properties:
+entityName, feedNames, feedInstancePath, workflowId, runId, nominalTime, timeStamp, brokerUrl, brokerImplClass, entityType, operation, logFile, topicName, status, brokerTTL;
+
+For a given feed that is scheduled, the name of the topic is same as the feed name.
+Falcon sends a map message for every feed instance that is deleted/archived/replicated depending upon the retention policy set in the feed definition.
+The JMS MapMessage sent to a topic has the following properties:
+entityName, feedNames, feedInstancePath, workflowId, runId, nominalTime, timeStamp, brokerUrl, brokerImplClass, entityType, operation, logFile, topicName, status, brokerTTL;
+
+The JMS messages are automatically purged after a certain period (default 3 days) by the Falcon JMS house-keeping service.TTL (Time-to-live) for JMS message
+can be configured in the Falcon's startup.properties file.
+
+---++ Falcon EL Expressions
+
+
+Falcon expression language can be used in process definition for giving the start and end instance for various feeds.
+
+Before going into how to use falcon EL expressions it is necessary to understand what does instance and instance start time refer to with respect to Falcon.
+
+Lets consider a part of process definition below:
+
+<verbatim>
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<process name="testProcess">
+ <clusters>
+ <cluster name="corp">
+ <validity start="2010-01-02T01:00Z" end="2011-01-03T03:00Z" />
+ </cluster>
+ </clusters>
+ <parallel>2</parallel>
+ <order>LIFO</order>
+ <timeout>hours(3)</timeout>
+ <frequency>minutes(30)</frequency>
+
+ <inputs>
+ <input end-instance="now(0,20)" start-instance="now(0,-60)"
+ feed="input-log" name="inputData"/>
+ </inputs>
+<outputs>
+ <output instance="now(0,0)" feed="output-log"
+ name="outputData" />
+</outputs>
+...
+...
+...
+...
+</process>
+</verbatim>
+
+
+The above definition says that the process will start at 2nd of Jan 2010 at 1 am and will end at 3rd of Jan 2011 at 3 am on cluster corp. Also process will start a user-defined workflow (which we will call instance) every 30 mins.
+
+This means starting 2010-01-02T01:00Z every 30 mins a instance will start will run user defined workflow. Now if this workflow needs some input data and produce some output, user needs to give that in <inputs> and <outputs> tags.
+Since the inputs that the process takes can be distributed over a wide range we use the limits by giving "start" and "end" instance for input. Output is only one location so only instance is given.
+The timeout specifies, the how long a given instance should wait for input data before being terminated by the workflow engine.
+
+Coming back to instance start time, since a instance will start every 30 mins starting 2010-01-02T01:00Z, the time it is scheduled to start is called its instance time. For example first few instance time for above example are:
+
+
+<pre>Instance Number instance start Time</pre>
+
+<pre>1 2010-01-02T01:00Z</pre>
+<pre>2 2010-01-02T01:30Z</pre>
+<pre>3 2010-01-02T02:00Z</pre>
+<pre>4 2010-01-02T02:30Z</pre>
+<pre>. .</pre>
+<pre>. .</pre>
+<pre>. .</pre>
+<pre>. .</pre>
+
+Now lets go to how to use expression language. Only thing to keep in mind is all EL evaluation are done based on the start time of that instance, and very instance will have different inputs / outputs based on the feed instance given in process definition.
+
+All the parameters in various El can be both positive, zero or negative values. Positive values indicate so many units in future, zero means the base time EL has been resolved to, and negative values indicate corresponding units in past.
+
+__Note: if no instance is created at the resolved time, then the instance immediately before it is considered.__
+
+Falcon currently support following ELs:
+
+
+ * 1. *now(hours,minutes)*: now refer to the instance start time.Hours and minutes given are in reference with the start time of instance. For example now(-2,40) corresponds to feed instance at -2 hr and +40 minutes i.e feed instance 80 mins before the instance start time. Id user would have given now(0,-80) it would have correspond to the same.
+ * 2. *today(hours,minutes)*: hours and minutes given in this EL corresponds to instance from the start day of instance start time. Ie. If instance start is at 2010-01-02T01:30Z then today(-3,-20) will mean instance created at 2010-01-01T20:40 and today(3,20) will correspond to 2010-01-02T3:20Z.
+
+ * 3. *yesterday(hours,minutes)*: As the name suggest EL yesterday picks up feed instances with respect to start of day yesterday. Hours and minutes are added to the 00 hours starting yesterday, Example: yesterday(24,30) will actually correspond to 00:30 am of today, for 2010-01-02T01:30Z this would mean 2010-01-02:00:30 feed.
+
+ * 4. *currentMonth(day,hour,minute)*: Current month takes the reference to start of the month with respect to instance start time. One thing to keep in mind is that day is added to the first day of the month. So the value of day is the number of days you want to add to the first day of the month.For example: for instance start time 2010-01-12T01:30Z and El as currentMonth(3,2,40) will correspond to feed created at 2010-01-04T02:40Z and currentMonth(0,0,0) will mean 2010-01-01T00:00Z.
+
+ * 5. *lastMonth(day,hour,minute)*: Parameters for lastMonth is same as currentMonth, only difference being the reference is shifted to one month back. For instance start 2010-01-12T01:30Z lastMonth(2,3,30) will correspond to feed instance at 2009-12-03:T03:30Z
+
+ * 6. *currentYear(month,day,hour,minute)*: The month,day,hour, minutes in the pareamter are added with reference to the start of year of instance start time. For our exmple start time 2010-01-02:00:30 reference will go back to 2010-01-01:T00:00Z. Also similar to days, months are added to the 1st month that Jan. So currentYear(0,2,2,20) will mean 2010-01-03T02:20Z while currentYear(11,2,2,20) will mean 2010-12-03T02:20Z
+
+
+ * 7. *lastYear(month,day,hour,minute)*: This is exactly similary to currentYear in usage> only difference being start reference is taken to start of previous year.For example: lastYear(4,2,2,20) will corrospond to feed insatnce created at 2009-05-03T02:20Z and lastYear(12,2,2,20) will corrospond to feed at 2010-01-03T02:20Z.
+
+ * 8. *latest(number of latest instance)*: This will simply make you input consider the number of latest avaliable instance of the feed given as parameter. For exmample: latest(0) will consider the last avaliable instance of feed, where as latest latest(-1) will consider second last avaliable feed and latest(-3) will consider 4th last avaliable feed.
+
+
Added: incubator/falcon/src/site/twiki/docs/FalconCLI.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/docs/FalconCLI.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/docs/FalconCLI.twiki (added)
+++ incubator/falcon/src/site/twiki/docs/FalconCLI.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,166 @@
+---+FalconCLI
+
+FalconCLI is a interface between user and Falcon. It is a command line utility provided by Falcon. FalconCLI supports Entity Management, Instance Management and Admin operations.There is a set of web services that are used by FalconCLI to interact with Falcon.
+
+---++Entity Management Operations
+
+---+++Submit
+
+Submit option is used to set up entity definition.
+
+Example:
+$FALCON_HOME/bin/falcon entity -submit -type cluster -file /cluster/definition.xml
+
+Note: The url option in the above and all subsequent commands is optional. If not mentioned it will be picked from client.properties file. If the option is not provided and also not set in client.properties, Falcon CLI will fail.
+
+---+++Schedule
+
+Once submitted, an entity can be scheduled using schedule option. Process and feed can only be scheduled.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [process|feed] -name <<name>> -schedule
+
+Example:
+$FALCON_HOME/bin/falcon entity -type process -name sampleProcess -schedule
+
+---+++Suspend
+
+Suspend on an entity results in suspension of the oozie bundle that was scheduled earlier through the schedule function. No further instances are executed on a suspended entity. Only schedulable entities(process/feed) can be suspended.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [feed|process] -name <<name>> -suspend
+
+---+++Resume
+
+Puts a suspended process/feed back to active, which in turn resumes applicable oozie bundle.
+
+Usage:
+ $FALCON_HOME/bin/falcon entity -type [feed|process] -name <<name>> -resume
+
+---+++Delete
+
+Delete removes the submitted entity definition for the specified entity and put it into the archive.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [cluster|feed|process] -name <<name>> -delete
+
+---+++List
+
+Entities of a particular type can be listed with list sub-command.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [cluster|feed|process] -list
+
+---+++Update
+
+Update operation allows an already submitted/scheduled entity to be updated. Cluster update is currently
+not allowed.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [feed|process] -name <<name>> -update
+
+---+++Status
+
+Status returns the current status of the entity.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [cluster|feed|process] -name <<name>> -status
+
+---+++Dependency
+
+With the use of dependency option, we can list all the entities on which the specified entity is dependent. For example for a feed, dependency return the cluster name and for process it returns all the input feeds, output feeds and cluster names.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [cluster|feed|process] -name <<name>> -dependency
+
+---+++Definition
+
+Definition option returns the entity definition submitted earlier during submit step.
+
+Usage:
+$FALCON_HOME/bin/falcon entity -type [cluster|feed|process] -name <<name>> -definition
+
+---++Instance Management Options
+
+---+++Kill
+
+Kill sub-command is used to kill all the instances of the specified process whose nominal time is between the given start time and end time.
+
+Note:
+1. For all the instance management sub-commands, if end time is not specified, Falcon will perform the actions on all the instances whose instance time falls after the start time.
+
+2. The start time and end time needs to be specified in TZ format.
+Example: 01 Jan 2012 01:00 => 2012-01-01T01:00Z
+
+3. Process name is compulsory parameter for each instance management command.
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -kill -start "yyyy-MM-dd'T'HH:mm'Z'" -end "yyyy-MM-dd'T'HH:mm'Z'"
+
+---+++Suspend
+
+Suspend is used to suspend a instance or instances for the given process. This option pauses the parent workflow at the state, which it was in at the time of execution of this command.
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -suspend -start "yyyy-MM-dd'T'HH:mm'Z'" -end "yyyy-MM-dd'T'HH:mm'Z'"
+
+---+++Continue
+
+Continue option is used to continue the failed workflow instance. This option is valid only for process instances in terminal state, i.e. SUCCEDDED, KILLED or FAILED.
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -re-run -start "yyyy-MM-dd'T'HH:mm'Z'" -end "yyyy-MM-dd'T'HH:mm'Z'"
+
+---+++Rerun
+
+Rerun option is used to rerun instances of a given process. This option is valid only for process instances in terminal state, i.e. SUCCEDDED, KILLED or FAILED. Optionally, you can specify the properties to override.
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -re-run -start "yyyy-MM-dd'T'HH:mm'Z'" -end "yyyy-MM-dd'T'HH:mm'Z'" [-file <<properties file>>]
+
+---+++Resume
+
+Resume option is used to resume any instance that is in suspended state.
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -resume -start "yyyy-MM-dd'T'HH:mm'Z'" -end "yyyy-MM-dd'T'HH:mm'Z'"
+
+---+++Status
+
+Status option via CLI can be used to get the status of a single or multiple instances. If the instance is not yet materialized but is within the process validity range, WAITING is returned as the state. Along with the status of the instance time is also returned. Log location gives the oozie workflow url
+If the instance is in WAITING state, missing dependencies are listed
+
+Example : Suppose a process has 3 instance, one has succeeded,one is in running state and other one is waiting, the expected output is:
+
+{"status":"SUCCEEDED","message":"getStatus is successful","instances":[{"instance":"2012-05-07T05:02Z","status":"SUCCEEDED","logFile":"http://oozie-dashboard-url"},{"instance":"2012-05-07T05:07Z","status":"RUNNING","logFile":"http://oozie-dashboard-url"}, {"instance":"2010-01-02T11:05Z","status":"WAITING"}]
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -status -start "yyyy-MM-dd'T'HH:mm'Z'" -end "yyyy-MM-dd'T'HH:mm'Z'"
+
+---+++Running
+
+Running option provides all the running instances of the mentioned process.
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -running
+
+---+++Logs
+
+Get logs for instance actions
+
+Usage:
+$FALCON_HOME/bin/falcon instance -type <<feed/process>> -name <<name>> -logs -start "yyyy-MM-dd'T'HH:mm'Z'" [-end "yyyy-MM-dd'T'HH:mm'Z'"] [-runid <<runid>>]
+
+
+---++Admin Options
+
+---+++Help
+
+Usage:
+$FALCON_HOME/bin/falcon admin -version
+
+---+++Version
+
+Version returns the current verion of Falcon installed.
+Usage:
+$FALCON_HOME/bin/falcon admin -help
Added: incubator/falcon/src/site/twiki/docs/GettingStarted.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/docs/GettingStarted.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/docs/GettingStarted.twiki (added)
+++ incubator/falcon/src/site/twiki/docs/GettingStarted.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,31 @@
+---+ Apache Falcon - Data management and processing platform
+
+Apache Falcon is a feed processing and feed management system aimed at making it
+easier for end consumers to onboard their feed processing and feed
+management on hadoop clusters.
+
+---++ Why?
+
+ * Establishes relationship between various data and processing elements on a Hadoop environment
+
+ * Feed management services such as feed retention, replications across clusters, archival etc
+
+ * Easy to onboard new workflows/pipelines, with support for late data handling, retry policies
+
+ * Integration with metastore/catalog
+
+ * Provide notification to end customer based on availability of feed groups
+ (logical group of related feeds, which are likely to be used together)
+
+ * Enables use cases for local processing in colo and global aggregations
+
+---+ Getting Started
+
+Start with these simple steps to install an falcon instance [[InstallationSteps][Simple setup]]. Also refer
+to Falcon architecture and documentation in [[FalconDocumentation][Documentation]].
+
+[[OnBoarding][On boarding]] describes steps to on-board a pipeline to Falcon. It also gives a sample pipeline
+for reference. [[EntitySpecification][Entity Specification]] gives complete details of all Falcon entities.
+
+[[FalconCLI][Falcon CLI]] describes the various options for the command line utility provided by Falcon.
+
Added: incubator/falcon/src/site/twiki/docs/InstallationSteps.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/docs/InstallationSteps.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/docs/InstallationSteps.twiki (added)
+++ incubator/falcon/src/site/twiki/docs/InstallationSteps.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,65 @@
+---++ Building & Packaging Falcon
+
+
+---+++ Installing Falcon
+
+*Pre-requisites:*
+ * hadoop-0.20.2 +
+ * oozie-3.1.5 +
+
+*Falcon Server*
+
+ * Download the source from https://git-wip-us.apache.org/repos/asf/incubator-falcon.git
+ * Navigate to base project folder,named 'Falcon'
+ * Build as "mvn clean package" at the base location. Please note that both maven 2/3 are supported.
+ * By default only embedded/standalone mode is build.
+ * To build Falcon with documentation build with MVN profile "all".
+ * To build the Falcon for distributed mode, i.e. multiple server and prism mode, build with MVN profile "distributed".
+ * Once the build operation is over,navigate to '<base-folder>/Falcon/webapps/target' and deploy the .war file generated
+ there in a web container (Eg: tomcat6).
+
+---+++ User Guide
+
+*Falcon Client*
+
+ * Follow the steps 1 to 3 from server instructions.
+ * Once the build operation is over, navigate to '<base-folder>/Falcon/client/target'. There is a client.jar that has
+ been generated along with multiple other jars. Fetch this jar and others to use the Falcon client application.
+ Please ensure that the other jars in the folder are always specified in the classpath of the client.jar.
+ * Please refer Falcon-CLI guide for various options on how to use the falcon client.
+
+---+++ Administration Guide
+
+*Setting up Falcon server properties:*
+Inside your web container, where the falcon war has exploded, you should be able to find 2 files, startup.properties and runtime.properties.
+The path would be:
+<container-base>/<war-location>/falcon-webapp-0.2-SNAPSHOT/WEB-INF/classes
+
+*startup.properties:* Specifies values/paths used by Falcon on startup. Common entries usually include config store location
+,broker url (for messaging), and other settings.Any changes to this requires Falcon to be restarted to take effect.
+
+*runtime.properties:* Specifies various properties that can be picked at runtime. Falcon server keeps polling this file after a certain interval;
+and incorporates changes, if any.
+
+*Domain based settings (only applicable for Falcon 0.2):*
+
+Falcon 0.2 and subsequent releases support domain based properties. The user can specify properties either for all domains
+(with prefixing the property with a '*' ) or for a particular domain (with prefixing the domain name to the property).
+Once the domain is set, the user can set an env variable,FALCON_DOMAIN as the domain that the Falcon is supposed to use.
+
+Please refer the example below:
+
+Example:
+Trying to set the config store property for all domains:
+
+*.config.store.uri=file:///var/lib/tomcat6/target/store
+
+Trying to set config store property for a 'specific' domain:
+
+qa.config.store.uri=file:///var/lib/tomcat6/target/store
+
+To ensure that Falcon installation on your system uses the qa domain settings, just set the FALCON_DOMAIN value to 'qa' in your environment.
+
+---++++ Security
+
+*TO-DO*
\ No newline at end of file
Added: incubator/falcon/src/site/twiki/docs/OnBoarding.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/docs/OnBoarding.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/docs/OnBoarding.twiki (added)
+++ incubator/falcon/src/site/twiki/docs/OnBoarding.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,264 @@
+---++ Contents
+ * <a href="#Onboarding Steps">Onboarding Steps</a>
+ * <a href="#Sample Pipeline">Sample Pipeline</a>
+
+---+++ Onboarding Steps
+ * Create cluster definition for the cluster, specifying name node, job tracker, workflow engine endpoint, messaging endpoint. Refer to [[EntitySpecification][cluster definition]] for details.
+ * Create Feed definitions for each of the input and output specifying frequency, data path, ownership. Refer to [[EntitySpecification][feed definition]] for details.
+ * Create Process definition for your job. Process defines configuration for the workflow job. Important attributes are frequency, inputs/outputs and workflow path. Refer to [[EntitySpecification][process definition]] for process details.
+ * Define workflow for your job using the workflow engine(only oozie is supported as of now). Refer [[http://incubator.apache.org/oozie/docs/3.1.3/docs/WorkflowFunctionalSpec.html][Oozie Workflow Specification]]. The libraries required for the workflow should be available in lib folder in workflow path.
+ * Set-up workflow definition, libraries and referenced scripts on hadoop.
+ * Submit cluster definition
+ * Submit and schedule feed and process definitions
+
+
+---+++ Sample Pipeline
+---++++ Cluster
+Cluster definition that contains end points for name node, job tracker, oozie and jms server:
+<verbatim>
+<?xml version="1.0"?>
+<!--
+ Cluster configuration
+ -->
+<cluster colo="ua2" description="" name="corp" xmlns="uri:falcon:cluster:0.1"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <interfaces>
+ <interface type="readonly" endpoint="hftp://name-node.com:50070" version="0.20.2-cdh3u0" />
+
+ <interface type="write" endpoint="hdfs://name-node.com:54310" version="0.20.2-cdh3u0" />
+
+ <interface type="execute" endpoint="job-tracker:54311" version="0.20.2-cdh3u0" />
+
+ <interface type="workflow" endpoint="http://oozie.com:11000/oozie/" version="3.1.4" />
+
+ <interface type="messaging" endpoint="tcp://jms-server.com:61616?daemon=true" version="5.1.6" />
+ </interfaces>
+
+ <locations>
+ <location name="staging" path="/projects/falcon/staging" />
+ <location name="temp" path="/tmp" />
+ <location name="working" path="/projects/falcon/working" />
+ </locations>
+</cluster>
+</verbatim>
+
+---++++ Input Feed
+Hourly feed that defines feed path, frequency, ownership and validity:
+<verbatim>
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+ Hourly sample input data
+ -->
+
+<feed description="sample input data" name="SampleInput" xmlns="uri:falcon:feed:0.1"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <groups>group</groups>
+
+ <frequency>hours(1)</frequency>
+
+ <late-arrival cut-off="hours(6)" />
+
+ <clusters>
+ <cluster name="corp" type="source">
+ <validity start="2009-01-01T00:00Z" end="2099-12-31T00:00Z" timezone="UTC" />
+ <retention limit="months(24)" action="delete" />
+ </cluster>
+ </clusters>
+
+ <locations>
+ <location type="data" path="/projects/bootcamp/data/${YEAR}-${MONTH}-${DAY}-${HOUR}/SampleInput" />
+ <location type="stats" path="/projects/bootcamp/stats/SampleInput" />
+ <location type="meta" path="/projects/bootcamp/meta/SampleInput" />
+ </locations>
+
+ <ACL owner="suser" group="users" permission="0755" />
+
+ <schema location="/none" provider="none" />
+</feed>
+</verbatim>
+
+---++++ Output Feed
+Daily feed that defines feed path, frequency, ownership and validity:
+<verbatim>
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+ Daily sample output data
+ -->
+
+<feed description="sample output data" name="SampleOutput" xmlns="uri:falcon:feed:0.1"
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <groups>group</groups>
+
+ <frequency>days(1)</frequency>
+
+ <late-arrival cut-off="hours(6)" />
+
+ <clusters>
+ <cluster name="corp" type="source">
+ <validity start="2009-01-01T00:00Z" end="2099-12-31T00:00Z" timezone="UTC" />
+ <retention limit="months(24)" action="delete" />
+ </cluster>
+ </clusters>
+
+ <locations>
+ <location type="data" path="/projects/bootcamp/output/${YEAR}-${MONTH}-${DAY}/SampleOutput" />
+ <location type="stats" path="/projects/bootcamp/stats/SampleOutput" />
+ <location type="meta" path="/projects/bootcamp/meta/SampleOutput" />
+ </locations>
+
+ <ACL owner="suser" group="users" permission="0755" />
+
+ <schema location="/none" provider="none" />
+</feed>
+</verbatim>
+
+---++++ Process
+Sample process which runs daily at 6th hour on corp cluster. It takes one input - SampleInput for the previous day(24 instances). It generates one output - SampleOutput for previous day. The workflow is defined at /projects/bootcamp/workflow/workflow.xml. Any libraries available for the workflow should be at /projects/bootcamp/workflow/lib. The process also defines properties queueName, ssh.host, and fileTimestamp which are passed to the workflow. In addition, Falcon exposes the following properties to the workflow: nameNode, jobTracker(hadoop properties), input and output(Input/Output properties).
+
+<verbatim>
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+ Daily sample process. Runs at 6th hour every day. Input - last day's hourly data. Generates output for yesterday
+ -->
+<process name="SampleProcess">
+ <cluster name="corp" />
+
+ <frequency>days(1)</frequency>
+
+ <validity start="2012-04-03T06:00Z" end="2022-12-30T00:00Z" timezone="UTC" />
+
+ <inputs>
+ <input name="input" feed="SampleInput" start="yesterday(0,0)" end="today(-1,0)" />
+ </inputs>
+
+ <outputs>
+ <output name="output" feed="SampleOutput" instance="yesterday(0,0)" />
+ </outputs>
+
+ <properties>
+ <property name="queueName" value="reports" />
+ <property name="ssh.host" value="host.com" />
+ <property name="fileTimestamp" value="${coord:formatTime(coord:nominalTime(), 'yyyy-MM-dd')}" />
+ </properties>
+
+ <workflow engine="oozie" path="/projects/bootcamp/workflow" />
+
+ <retry policy="backoff" delay="minutes(5)" attempts="3" />
+
+ <late-process policy="exp-backoff" delay="hours(1)">
+ <late-input input="input" workflow-path="/projects/bootcamp/workflow/lateinput" />
+ </late-process>
+</process>
+</verbatim>
+
+---++++ Oozie Workflow
+The sample user workflow contains 3 actions:
+ * Pig action - Executes pig script /projects/bootcamp/workflow/script.pig
+ * concatenator - Java action that concatenates part files and generates a single file
+ * file upload - ssh action that gets the concatenated file from hadoop and sends the file to a remote host
+
+<verbatim>
+<workflow-app xmlns="uri:oozie:workflow:0.2" name="sample-wf">
+ <start to="pig" />
+
+ <action name="pig">
+ <pig>
+ <job-tracker>${jobTracker}</job-tracker>
+ <name-node>${nameNode}</name-node>
+ <prepare>
+ <delete path="${output}"/>
+ </prepare>
+ <configuration>
+ <property>
+ <name>mapred.job.queue.name</name>
+ <value>${queueName}</value>
+ </property>
+ <property>
+ <name>mapreduce.fileoutputcommitter.marksuccessfuljobs</name>
+ <value>true</value>
+ </property>
+ </configuration>
+ <script>${nameNode}/projects/bootcamp/workflow/script.pig</script>
+ <param>input=${input}</param>
+ <param>output=${output}</param>
+ <file>lib/dependent.jar</file>
+ </pig>
+ <ok to="concatenator" />
+ <error to="fail" />
+ </action>
+
+ <action name="concatenator">
+ <java>
+ <job-tracker>${jobTracker}</job-tracker>
+ <name-node>${nameNode}</name-node>
+ <prepare>
+ <delete path="${nameNode}/projects/bootcamp/concat/data-${fileTimestamp}.csv"/>
+ </prepare>
+ <configuration>
+ <property>
+ <name>mapred.job.queue.name</name>
+ <value>${queueName}</value>
+ </property>
+ </configuration>
+ <main-class>com.wf.Concatenator</main-class>
+ <arg>${output}</arg>
+ <arg>${nameNode}/projects/bootcamp/concat/data-${fileTimestamp}.csv</arg>
+ </java>
+ <ok to="fileupload" />
+ <error to="fail"/>
+ </action>
+
+ <action name="fileupload">
+ <ssh>
+ <host>localhost</host>
+ <command>/tmp/fileupload.sh</command>
+ <args>${nameNode}/projects/bootcamp/concat/data-${fileTimestamp}.csv</args>
+ <args>${wf:conf("ssh.host")}</args>
+ <capture-output/>
+ </ssh>
+ <ok to="fileUploadDecision" />
+ <error to="fail"/>
+ </action>
+
+ <decision name="fileUploadDecision">
+ <switch>
+ <case to="end">
+ ${wf:actionData('fileupload')['output'] == '0'}
+ </case>
+ <default to="fail"/>
+ </switch>
+ </decision>
+
+ <kill name="fail">
+ <message>Workflow failed, error message[${wf:errorMessage(wf:lastErrorNode())}]</message>
+ </kill>
+
+ <end name="end" />
+</workflow-app>
+</verbatim>
+
+---++++ File Upload Script
+The script gets the file from hadoop, rsyncs the file to /tmp on remote host and deletes the file from hadoop
+<verbatim>
+#!/bin/bash
+
+trap 'echo "output=$?"; exit $?' ERR INT TERM
+
+echo "Arguments: $@"
+SRCFILE=$1
+DESTHOST=$3
+
+FILENAME=`basename $SRCFILE`
+rm -f /tmp/$FILENAME
+hadoop fs -copyToLocal $SRCFILE /tmp/
+echo "Copied $SRCFILE to /tmp"
+
+rsync -ztv --rsh=ssh --stats /tmp/$FILENAME $DESTHOST:/tmp
+echo "rsynced $FILENAME to $DESTUSER@$DESTHOST:$DESTFILE"
+
+hadoop fs -rmr $SRCFILE
+echo "Deleted $SRCFILE"
+
+rm -f /tmp/$FILENAME
+echo "output=0"
+</verbatim>
Added: incubator/falcon/src/site/twiki/index-new.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/index-new.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/index-new.twiki (added)
+++ incubator/falcon/src/site/twiki/index-new.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,69 @@
+
+<div class="hero-unit">
+ <h3>Welcome to Apache Falcon!</h3>
+<p>
+ <span style="font-weight: bold">Apache Falcon</span>
+ is a data processing and management solution for Hadoop designed for data motion,
+ coordination of data pipelines, lifecycle management, and data discovery. Falcon enables end consumers
+ to quickly onboard their data and its associated processing and management tasks on Hadoop clusters.
+</p>
+</div>
+
+<div id="components" class="carousel slide">
+<!-- Carousel items -->
+<div class="carousel-inner">
+ <div class="active item">
+ <div class="hero-unit">
+ <h1>Data Motion</h1>
+ <p>Data Import & Export from DBs, Filers into HDFS.</p>
+ <p>
+ <a class="btn btn-primary pull-right" href="././docs/GettingStarted.html">Learn more</a>
+ </p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h1>Process orchestration</h1>
+ <p>Late Data Handling, Retries, etc.</p>
+ <p>Multi-cluster management to support Local/Global Aggregations, Rollups, etc.</p>
+ <!--
+ <p>
+ <a href="http://oozie.apache.org/">Scheduler</a> integration.
+ </p>
+ -->
+ <p>
+ <a class="btn btn-primary pull-right" href="././docs/GettingStarted.html">Learn more</a>
+ </p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h1>Data Lifecycle Management</h1>
+ <p>Retention, Replication/BCP/DR, Anonymization of PII Data, Archival, etc.</p>
+ <p>
+ <a class="btn btn-primary pull-right" href="././docs/GettingStarted.html">Learn more</a>
+ </p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h1>Data Discovery</h1>
+ <p>Data Classification, Audit, Lineage.</p>
+ <p>
+ <a class="btn btn-primary pull-right" href="././docs/GettingStarted.html">Learn more</a>
+ </p>
+ </div>
+ </div>
+</div>
+</div>
+
+<div class="hero-unit">
+ <h3>Getting Involved</h3>
+<p>
+ Developers interested in getting involved with Falcon may join the [[./mail-lists.html][mailing lists]],
+ [[https://issues.apache.org/jira/browse/FALCON][report bugs]], retrieve code from the
+ [[./source-repository.html][version control system]], and make
+ [[https://cwiki.apache.org/confluence/display/FALCON/How+To+Contribute][contributions]].
+</p>
+</div>
+
Added: incubator/falcon/src/site/twiki/index.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/index.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/index.twiki (added)
+++ incubator/falcon/src/site/twiki/index.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,101 @@
+---+ Apache Falcon - Data management and processing platform
+
+Apache Falcon is a data processing and management solution for Hadoop designed for data motion,
+coordination of data pipelines, lifecycle management, and data discovery. Falcon enables end consumers
+to quickly onboard their data and its associated processing and management tasks on Hadoop clusters.
+
+Data Management on Hadoop encompasses data motion, process orchestration, lifecycle management,
+data discovery, etc. among other concerns. Falcon is a new data processing and management platform
+for Hadoop that solves this problem and creates additional opportunities by building on existing
+components within the Hadoop ecosystem without reinventing the wheel.
+
+Falcon will enable easy data management via declarative mechanism for Hadoop. Users of Falcon platform
+simply define infrastructure endpoints, data sets and processing rules declaratively. These declarative
+configurations are expressed in such a way that the dependencies between these configured entities are
+explicitly described. This information about inter-dependencies between various entities allows Falcon
+to orchestrate and manage various data management functions.
+
+Falcon was successfully accepted as an incubation project in April 2013 and is now in apache incubation.
+
+
+<div id="components" class="carousel slide">
+<!-- Carousel items -->
+<div class="carousel-inner">
+ <div class="active item">
+ <div class="hero-unit">
+ <h3>Provides key services for data processing apps</h3>
+ <p>Complex data processing logic handled by Falcon instead of hard-coded in apps</p>
+ <!--
+ <p>
+ <a class="btn btn-primary pull-right" href="././docs/GettingStarted.html">Learn more</a>
+ </p>
+ -->
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Introduces higher layer of abstractions</h3>
+ <p>Data Set, Infrastructure (Cluster, Database, Filer, etc.), Process</p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Declarative language for expressing data management functions</h3>
+ <p>Data management expressed as simple directives, instead of verbosely defining it repeatedly</p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Promotes Separation of Concerns</h3>
+ <p>
+ Allow process owners to keep application/user workflow specific to their application logic
+ than muddy them with the common management functions.
+ </p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Promotes Polyglot programming</h3>
+ <p>
+ Does not do any heavy lifting but delegates to tools with in the Hadoop ecosystem,
+ Enhances productivity
+ </p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Data Motion</h3>
+ <p>Data Import & Export from DBs, Filers into HDFS</p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Process orchestration</h3>
+ <p>
+ Late Data Handling, Retries, etc.
+ Multi-cluster management to support Local/Global Aggregations, Rollups, etc.
+ <a href="http://oozie.apache.org/">Scheduler</a> integration
+ </p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Data Lifecycle Management</h3>
+ <p>Retention, Replication/BCP/DR, Anonymization of PII Data, Archival, etc.</p>
+ </div>
+ </div>
+ <div class="item">
+ <div class="hero-unit">
+ <h3>Data Discovery</h3>
+ <p>Data Classification, Audit, Lineage.</p>
+ </div>
+ </div>
+</div>
+</div>
+
+---++ Getting Involved
+
+Developers interested in getting involved with Falcon may join the [[./mail-lists][mailing lists]],
+[[https://issues.apache.org/jira/browse/FALCON][report bugs]], retrieve code from the
+[[./source-repository][version control system]], and make
+[[./wiki/HowToContribute][contributions]].
Added: incubator/falcon/src/site/twiki/wiki/Acknowledgements.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/Acknowledgements.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/Acknowledgements.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/Acknowledgements.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,17 @@
+---+ Acknowledgements
+
+---+++ Code
+
+ * Initial code for Apache Falcon has been kindly donated by [[http://www.inmobi.com][InMobi]]
+ * The Apache Falcon logo has been kindly donated by [[http://www.inmobi.com][InMobi]]
+
+
+---+++ Mentors
+
+We would like to thank our mentors:
+
+ * Chris Douglas
+ * Devaraj Das
+ * Arun Murthy
+ * Alan Gates
+ * Owen O'Malley
Added: incubator/falcon/src/site/twiki/wiki/FALCON.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/FALCON.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/FALCON.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/FALCON.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,3 @@
+---+ Placeholder for Falcon Confluence twiki
+
+This is being tracked at: https://issues.apache.org/jira/browse/INFRA-6273
\ No newline at end of file
Added: incubator/falcon/src/site/twiki/wiki/HowToContribute.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/HowToContribute.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/HowToContribute.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/HowToContribute.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,11 @@
+---+ How To Contribute
+
+Welcome contributors! We strive to include everyone's contributions.
+This page provides necessary guidelines on how to contribute effectively towards
+furthering the development and evolution of Apache Falcon. You should also read the
+guide on setting up Development Environment where you will find details on how to
+checkout, build and test Apache Falcon.
+
+Note: This guide applies to general contributors. If you are a committer, please read the How to Commit as well.
+
+---++ TBD
\ No newline at end of file
Added: incubator/falcon/src/site/twiki/wiki/IRCChannel.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/IRCChannel.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/IRCChannel.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/IRCChannel.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1 @@
+---+ Placeholder for Falcon Confluence twiki
Added: incubator/falcon/src/site/twiki/wiki/News.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/News.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/News.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/News.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,24 @@
+---+ Apache Falcon - News
+
+---+++ Falcon was in the news
+
+ * http://hortonworks.com/blog/project-falcon-tackling-hadoop-data-lifecycle-management-via-community-driven-open-source/
+ * http://www.inmobi.com/inmobiblog/2013/04/02/inmobi-works-with-hortonworks-to-incubate-falcon-with-apache-software-foundation-to-provide-huge-benefits-to-the-big-data-community
+
+
+---+++ Falcon talk was accepted at Hadoop Summit 2013, SJC
+Srikanth and Venkatesh had submitted a talk to present Falcon at the Summit and the talk was accepted in the
+Enterprise Data Architecture track. Program details at: http://hadoopsummit.org/san-jose/program/.
+
+
+---+++ Incubation Proposal Accepted
+Falcon was successfully accepted as an incubation project in April 2013 and is now in apache incubation.
+
+
+---+++ Falcon was proposed for Apache Incubation
+Falcon was proposed as an APache incubator by Srikanth in March 2013.
+
+
+---+++ Falcon Talk at Bangalore HUG
+Srikanth presented Falcon and its use at InMobi at Bangalore HUG.
+
Added: incubator/falcon/src/site/twiki/wiki/PoweredBy.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/PoweredBy.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/PoweredBy.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/PoweredBy.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,7 @@
+---+ Powered By
+
+
+This page documents a list of institutions that are using Falcon for educational or production uses.
+
+ * [[http://www.inmobi.com][InMobi]]
+ * Deployed in production for about a year
Added: incubator/falcon/src/site/twiki/wiki/Roadmap.twiki
URL: http://svn.apache.org/viewvc/incubator/falcon/src/site/twiki/wiki/Roadmap.twiki?rev=1483191&view=auto
==============================================================================
--- incubator/falcon/src/site/twiki/wiki/Roadmap.twiki (added)
+++ incubator/falcon/src/site/twiki/wiki/Roadmap.twiki Thu May 16 04:30:42 2013
@@ -0,0 +1,82 @@
+---+ Apache Falcon Roadmap
+
+---++ Initial Release at Apache (June 2013 - By Summit)
+
+ * Fix unit tests profiles
+ * Checkstyle and Findbugs plugin and fix warnings
+ * Falcon should work with secure Hadoop
+ * Remove dependency on custom DistCp and Oozie
+ * Documentation for User & Developer
+
+
+---++ Data Motion
+
+---+++ Database
+
+ * Import
+ * Export
+ * Credential management
+
+---+++ Filer (File movement)
+
+ * Import using ssh+scp
+ * Export using ssh+scp
+ * Credential management
+
+
+---++ Data Lifecycle
+
+---+++ Anonymization of PII Data
+
+ * One-way hash MR job (Pluggable)
+
+---+++ Archival
+
+ * Archive data prior to retention or as its generated/copied into an archival end point (S3, Filer, etc.)
+
+
+---++ HCatalog Integration
+
+ * Register/Deregister Partitions
+ * Schema to be derived from HCatalog
+ (HCatalog is the single source of truth, tables need to be created prior to scheduling a feed)
+
+
+---++ Resource Management
+
+ * # of connections/streams as a resource
+ * Bandwidth as a resource constraint
+ * Copy jobs will honor the constraints
+
+
+---++ Data Processing
+
+ * Ability to execute Pig/HiveQL scripts directly with out requiring user to embed a oozie workflow
+ * Spring Batch integration (Wish & stretch goal)
+
+
+---++ User Experience
+
+ * UI to define Entities and flow
+
+
+---++ Data Discovery
+
+---+++ Data classification
+
+ * Support feed and process classification based on tags
+
+---+++ Lineage and Audit
+
+ * Record audit for all processing triggered
+ * Record Lineage for process
+ * Will need enhancements to HCatalog
+
+
+---++ Release Schedule (Tentative)
+
+We'll strive to have quarterly releases for Falcon.
+
+ * 0.3 - June 2013
+ * 0.4 - Sep 2013
+ * 0.5 - Dec 2013