Abstract: Techniques for facilitating and accelerating log data processing are disclosed herein. The front-end clusters generate a large amount of log data in real time and transfer the log data to an aggregating cluster. When the aggregating cluster is not available, the front-clusters write the log data to local filers and send the data when the aggregating cluster recovers. The aggregating cluster is designed to aggregate incoming log data streams from different front-end servers and clusters. The aggregating cluster further sends the aggregated log data stream to centralized NFS filers or a data warehouse cluster. The local filers and the aggregating cluster stage the log data for access by applications, so that the applications do not wait until the data reach the centralized NFS filers or data warehouse cluster.

Abstract: Techniques for facilitating and accelerating log data processing by splitting data streams are disclosed herein. The front-end clusters generate large amount of log data in real time and transfer the log data to an aggregating cluster. The aggregating cluster is designed to aggregate incoming log data streams from different front-end servers and clusters. The aggregating cluster further splits the log data into a plurality of data streams so that the data streams are sent to a receiving application in parallel. In one embodiment, the log data are randomly split to ensure the log data are evenly distributed in the split data streams. In another embodiment, the application that receives the split data streams determines how to split the log data.

Abstract: Techniques for facilitating and accelerating log data processing are disclosed herein. The front-end clusters generate a large amount of log data in real time and transfer the log data to an aggregating cluster. When the aggregating cluster is not available, the front-clusters write the log data to local filers and send the data when the aggregating cluster recovers. The aggregating cluster is designed to aggregate incoming log data streams from different front-end servers and clusters. The aggregating cluster further sends the aggregated log data stream to centralized NFS filers or a data warehouse cluster. The local filers and the aggregating cluster stage the log data for access by applications, so that the applications do not wait until the data reach the centralized NFS filers or data warehouse cluster.

Abstract: Techniques for facilitating and accelerating log data processing are disclosed herein. The front-end clusters generate a large amount of log data in real time and transfer the log data to an aggregating cluster. When the aggregating cluster is not available, the front-clusters write the log data to local filers and send the data when the aggregating cluster recovers. The aggregating cluster is designed to aggregate incoming log data streams from different front-end servers and clusters. The aggregating cluster further sends the aggregated log data stream to centralized NFS filers or a data warehouse cluster. The local filers and the aggregating cluster stage the log data for access by applications, so that the applications do not wait until the data reach the centralized NFS filers or data warehouse cluster.

Abstract: A method and system on failure recovery in a storage system are disclosed. In the storage system, user data streams (e.g., log data) are collected by a scribeh system. The scribeh system may include a plurality of Calligraphus servers, HDFS and Zookeeper. The Calligraphus servers may shard the user data streams based on keys (e.g., category and bucket pairs) and stream the user data streams to Puma nodes. Sharded user data streams may be aggregated according to the keys in memory of a specific Puma node. Periodically, aggregated user data streams cached in memory of the specific Puma node, together with a Incremental checkpoint, are persisted to HBase. When a specific process on the specific Puma node fails, Ptail retrieves the Incremental checkpoint from HBase and then restores the specific process by requesting user data streams processed by the specific process from the scribeh system according to the Incremental checkpoint.

Abstract: Disclosed is an anticoagulant polypeptide and applications thereof. The anticoagulant polypeptide comprises a polypeptide formed by an amino acid sequence as represented in Seq. ID No. 1; or comprises a derived polypeptide that selectively inhibits coagulation factor XIa and is formed by an amino acid sequence, as represented in Seq. ID No. 1, that has undergone one or multiple amino acid residue substitutions, deletions, or insertions. The anticoagulant polypeptide is a selective inhibitor for coagulation factor XIa, has anticoagulant activity and small side-effect, and can be used in preparing medicines for the prevention and treatment of thrombotic diseases.

Abstract: Disclosed is an anticoagulant polypeptide and applications thereof. The anticoagulant polypeptide comprises a polypeptide formed by an amino acid sequence as represented in Seq. ID No. 1; or comprises a derived polypeptide that selectively inhibits coagulation factor XIa and is formed by an amino acid sequence, as represented in Seq. ID No. 1, that has undergone one or multiple amino acid residue substitutions, deletions, or insertions. The anticoagulant polypeptide is a selective inhibitor for coagulation factor XIa, has anticoagulant activity and small side-effect, and can be used in preparing medicines for the prevention and treatment of thrombotic diseases.

Abstract: A method and system on failure recovery in a storage system are disclosed. In the storage system, user data streams (e.g., log data) are collected by a scribeh system. The scribeh system may include a plurality of Calligraphus servers, HDFS and Zookeeper. The Calligraphus servers may shard the user data streams based on keys (e.g., category and bucket pairs) and stream the user data streams to Puma nodes. Sharded user data streams may be aggregated according to the keys in memory of a specific Puma node. Periodically, aggregated user data streams cached in memory of the specific Puma node, together with a Incremental checkpoint, are persisted to HBase. When a specific process on the specific Puma node fails, Ptail retrieves the Incremental checkpoint from HBase and then restores the specific process by requesting user data streams processed by the specific process from the scribeh system according to the Incremental checkpoint.

Abstract: Techniques for facilitating and accelerating log data processing by splitting data streams are disclosed herein. The front-end clusters generate large amount of log data in real time and transfer the log data to an aggregating cluster. The aggregating cluster is designed to aggregate incoming log data streams from different front-end servers and clusters. The aggregating cluster further splits the log data into a plurality of data streams so that the data streams are sent to a receiving application in parallel. In one embodiment, the log data are randomly split to ensure the log data are evenly distributed in the split data streams. In another embodiment, the application that receives the split data streams determines how to split the log data.

Abstract: Techniques for facilitating and accelerating log data processing are disclosed herein. The front-end clusters generate a large amount of log data in real time and transfer the log data to an aggregating cluster. When the aggregating cluster is not available, the front-clusters write the log data to local filers and send the data when the aggregating cluster recovers. The aggregating cluster is designed to aggregate incoming log data streams from different front-end servers and clusters. The aggregating cluster further sends the aggregated log data stream to centralized NFS filers or a data warehouse cluster. The local filers and the aggregating cluster stage the log data for access by applications, so that the applications do not wait until the data reach the centralized NFS filers or data warehouse cluster.

Abstract: A method, system and apparatus are provided to train a usefulness prediction model to generate a usefulness prediction in connection with a given universal resource locator (URL), the training of the usefulness prediction model being based on a training set of URLs and a count of negative URLs and a count of positive URLs identified by the training set, and for each feature extacted from the URLs in the training set, a count of the positive URLs in the training set that include the feature and a count of the negative URLs in the training set that include the feature. One or more features of the given URL are extracted, and the extracted features are used together with the usefulness prediction model to generate a usefulness prediction for the given URL.

Abstract: A method, system and apparatus are provided to train a usefulness prediction model to generate a usefulness prediction in connection with a given universal resource locator (URL), the training of the usefulness prediction model being based on a training set of URLs and a count of negative URLs and a count of positive URLs identified by the training set, and for each feature extacted from the URLs in the training set, a count of the positive URLs in the training set that include the feature and a count of the negative URLs in the training set that include the feature. One or more features of the given URL are extracted, and the extracted features are used together with the usefulness prediction model to generate a usefulness prediction for the given URL.