Emotion-based Social Computing Platform for Streaming Big-data ...

Emotion-based Social Computing Platform for Streaming Big-data: Architecture and Application * Leihan Zhang [, Jichang Zhao2 , Ke Xu [

[State Key Lab of Software Development Environment, Beihang University, Beijing, China 2School of Economics and Management, Beihang University, Beijing, China * Corresponding author: [email protected] Abstract-Exploration of user generated content in the epoch of Web 2.0 brings unprecedented challenge to the social comput­ ing, which has to provide real-time solution in the circumstance of massive data volumes and evolving application scenarios. This paper presents an emotion-based social computing platform namely ESC for streaming big-data. The main aim of ESC is to provide sentiment analysis as the foundation of social computing and enable both real-time computation on streaming big-data and batch computation on off-line big-data with high performance and low risk. Different from conventional data processing technologies, ESC is designed as a scalable and

to unstructured texts and images. Except for the previous mentioned technology, there exists another solution for data processing framework. Specifically, by loading the data into one or a few centered powerful computers, the computation can be separated and then delivered on these centers. The short comings of this approach is that even for a powerful computer, its storage space is too limited to deposit large-scale continuously produced data and meanwhile, it is infeasible to transfer so much data to one node at the cost of expensive network bandwidth and high-risk.

QoS-optimized adaptive platform for developers to only focus on business models instead of being distracted by details of the computing infrastructure. In addition, continuous streaming computing is emphasized in ESC to keep tracking on long term dynamic evolution in social media, which can provide a valuable proxy for in-depth social analytics. The architecture of ESC is implemented by distributed storage, sentiment analysis, data parallelism and routing, real-time streaming computation, batch computation and distributed machine learning. And the evaluation results from real-time and batch computations testify the high performance and scalability of ESC. Moreover, a few applications based on it further demonstrates its usability in enacting on different streaming big-data and variety of social computations.

I.

INTRODUCTION

During recent years there has been a great progress in smart cellphones and wearable technology, which produce infinite information around people and the technology and in­ formation play more and more important roles in transforming people's lives and reorganizing the society. Confronted with constantly produced streaming big data, business organizations and governments have critical demands for streaming big-data analytics in market, engineering, social computing and many other directions. However, due to algorithmic or infrastructural reasons, the streaming data always have complex data access patterns and various structures [1]. On the other hand, because of the heterogeneous and highly dynamic volume, handling these large amounts of streaming and historical data, ranging from structured to unstructured and numerical to micro-blog tweets, is extremely challenging [2]. Data processing has been in the spotlight for many decades, especially accompanied with the development of computer science and the emergence of Internet. And the conventional data processing technology can be represented by the classical frameworks of relational databases (such as MySQL and Oracle) and data analyzing tool (such as MatLab and Microsoft Excel). However, these technologies are primarily designed for exact query and unit transaction, which can not be applied

In contrast to above approaches, many computers can be connected together through network to collaborate on on specific task, which is named distributed computing and it has actually evolved into one of the most widely employed technologies [3] in recent years. Particularly, the latest ad­ vancements in resource virtualization has also help numerous businesses exploit the power of large-scale distributed com­ puting without any investment on expensive operational infras­ tructure. In the meantime, with the ongoing commercialization of the distributed computing cluster, the computing paradigm has changed from the traditional one-shot data processing to scalable and virtualized distributed computing, which can greatly facilitates the process of continuous, various and high­ volume big data. In spite of distributed computing enable the processing of large scale and various kinds of data, the deep analysis on so­ cial streaming data is still a challenging task. Explosion in user generated and software generated data demand effective and deep analysis combining with expert knowledge. Traditional analytics such as Business Intelligence, Operation Research and Data Mining are no longer sufficient enough [4] to harvest value or knowledge from big data. In this paper, we introduce a emotion-based social computing platform (ESC) for streaming big data, which integrates sentiment analysis and distributed computing to realize real time streaming computation and batch processing. Evaluations in realistic scenario testify its competence in high scalability and several interesting appli­ cations from different business models further demonstrate its usability and robustness. The rest of this paper is organized as follows. Section II reviews the related works in recent years and further points out our motivations. Section III introduces the architecture of the social computing platform and Section IV evaluates the performance of the established platform. A few applications based on ESC are demonstrated in Section V. Finally we briefly conclude the paper in Section VI.

978-1-5090-2842-9/16/$31.00 ©Q016 IE

VOLUME •

Terabytes

•

Records

•

Transactions

•

Tables, files

indexing real-time streams of big datasets.

•

Batch

•

Strllcnlred

•

NearTime

•

Unstructured

•

Real Time

•

Semistructured

•

Streams

•

All the above

VELOCITY

VARIETY

It can be easily learnt from the above review that many basic solutions for big-data computation, from storage to real­ time processing, have already been comprehensively devel­ oped in recent decades. However, corresponding to the social computation in the circumstance of massive user generated content, how to establish an easy-use and scalable platform that might greatly facilitate the development of diverse applications in realistic scenarios still remains unclear, while it definitely deserves more explorations.

Fig. 1: Three Vs of big data. II.

ARCHITECTURE

RELATED WORKS

As can be seen in Fig. 1, a recent case study [5] investi­ gated the nature of big data in different real-world businesses and stated that big data can be depicted by three aspects: volume, variety and velocity. These three dimensions have some relationship with each other and directly influence the methods used to store and process the data. In fact, the volume dimension does not only define the size of the data, but also determines the storage method of the data and the associated meta data. Data could be stored as big files, records of file blocks or tables. W hen the volume grows, the processing and 10 load on the cluster increases and dramatically decreases the performance. The variety factor regards to the structure of the data, which could be structured, unstructured or semistruc­ tured data. That's to say, the data generally is highly multi­ dimensional and sparsely distributed. It is known that the more structured the data is, the easier to perform analytics. Moreover, the velocity factor is usually two-pronged, i.e., the rate at which data is generated or input to the system and how often it needs to be processed in order to update the previous results. In big data processing, majority of the input is large­ scale history data, which means that there is no need to finish computation in seconds and it is more import to em­ phasize speed of computation with specific algorithm. As a cheap but fast distributed computing framework, Hadoop [6] has become the most widely used distributed computation infrastructure. Moreover, Hadoop Mahout and Spark MLib provide decent distributed implementations for many popular machine learning algorithms. For time-sensitive applications that require real-time response, real streaming computation technology with low latency becomes necessary. A real time streaming computation software Apache Storm was established and applied on twitter streaming data [7] and there is another near-time computation framework named Spark streaming [8]. Except for computation, distributed message queuing frameworks and NoSQL databases for unstructured data are equally important. Amazon Kinesis and Apache Kafka [9] can provide a reliable, high-throughput, low-latency solutions. The frameworks can also process low level distributed system management, such as task scheduling, fault management, and result collection. For NoSQL database frameworks, such as MongoDB [10], Cassandra, and HBase, allow data access based on predefined access primitives such as key-value pairs. Given the exact key, the value will be returned. This well­ defined data access pattern results in better scalability and performance predictability that is suitable for storing and

MongoDB MySQL

--

-----

\\ eb Cra\\Ier (Welbo, l\ews, Blog etc)

---

----

Log Collector

Fig. 2: Illustration of the architecture. Targeting at enable both real-time computation and batch processing of emotion-based social streaming data, we can separate the problem into six layers: data collection, distributed storage, sentiment analysis, data parallelism, real-tim or batch computation and visualization. As shown in Fig. 2, a few of key technologies, such as Hadoop, Spark, Storm, Kafka, MoodLens [11] are used to build our distributed computation platform. With web crawler or log collection agents, Streaming data can be obtained as input for the architecture. Later, by employing MoodLens, these streaming data will be tagged with an emotion. Then there will be two paths for streaming data labeled by different emotions, the one path is being transfered to HBase or HDFS, and the other path is being distributed to real-time streaming computation module-Storm by messaging system Kafka. And based on the distributed database, streaming data can be assessed for further batch computation and analysis with machine learning algorithms and other business models. For simplifying the elucidation, we will not introduce the layer of data collection and visualization, which are not our focus in the present work.

A. Distributed storage Because of the huge amount of the big-data, it is necessary to guarantee the redundancy and reading velocity for the data. We employ HBase as the underlying database to handle this. HBase is a Hadoop-based database and usually described as a sparse, distributed, persistent and multidimensional sorted map, which is indexed by rowkey, columnkey, and times­ tamp [12]. Fundamentally, it is a platform for storing and retrieving data with random access, which means that HBase can provide random data writing and reading. It is should be noted that HBase can store both structured and semistructured data naturally, such as tweets from Weibo, parsed log files and customer reviews from Taobao, which are just the regular type of big-data in Web 2.0 epoch. Moreover, HBase can also store unstructured data. It does not care about types and allows for

a dynamic and flexible data model that does not constrain the data categories. HBase is designed to run on a cluster of computers instead of a single computer and the cluster can be built in terms of commodity hardware. HBase scales horizontally as adding more machines to the cluster. Each node in the cluster provides a bit of storage, cache, and computation as well. This characteristic makes HBase incredibly flexible and scalable. The replication number is usually set as an integer bigger than two, so if one of those machines breaks down, it is feasible to replace it with another and the data is safe for redundancy. The file system for HBase is HDFS, which stands for "Hadoop Distributed Filesystem", is designed for storing very large files with streaming data access patterns, running on clusters of c Olmnodity hardware [13]. HDFS is built around the idea that the most efficient data processing pattern is a write­ once, read-many-times pattern. A dataset is typically generated or copied from source, and then various analyses are performed on that dataset over time. B.

Sentiment Analysis

The sentiment analysis is based on our previous work MoodLens [11], which is the first system for sentiment analysis of Chinese tweets in Weibo. In MoodLens, 95 emoticons are mapped into four categories of sentiments, i.e. angry, disgusting, joyful, and sad, which serve as the class labels of tweets. MoodLens collects over 3.5 million labeled tweets as the corpus to train a fast Naive Bayes classifier. MoodLens also implements an incremental learning method to tackle the problem of the sentiment shift and the generation of new terms. In this study, the category of human emotion is further extended by adding the sentiment of scare and the similar accuracy with the original MoodLens is kept. C.

Data parallelism

Fig. 3: Aggregation and analysis scenario based on Kafka messaging system. Although HBase and HDFS can provide distributed reading and writing, the latency is still not acceptable for real-time computation. In fact, applications that require low-latency access to data, in the tens of milliseconds range, will not work well with HDFS. However, real-time information is continuously being generated by applications (business, social, or any other types), and this information needs easy ways to be reliably and quickly routed to multiple types of receivers. At most of the time, applications that produce information and applications that are consuming the corresponding information are well apart and inaccessible to each other. These heteroge­ neous applications leads to redevelopment for providing an integration point between them. Therefore, a mechanism is

required for the seamless integration of information from pro­ ducers and consumers to avoid any kind of application rewrit­ ing at either end. And Apache Kafka can afford these needs decently. As a distributed, partitioned, and replicated commit­ log-based publish-subscribe messaging system, Apache Kafka mainly designed with the following characteristics: Persistent messaging, High throughput, Distributed, Multiple clients and Real time guarantee [9]. Kafka provides a real-time publish­ subscribe solution that overcomes the challenges of consuming the real-time and batch data volumes that may grow in order of magnitude to be larger than the real data. Kafka also supports parallel data loading in HDFS, indicating that it can be suitable embedded into the storage framework.

D. Real-time and batch computation

Stream tranformation Stream data source Tuple (ream

Fig. 4: Conceptual architecture of a Storm topology. Storm is a distributed, reliable, fault-tolerant system for processing streams of data. Apache Storm executes topologies which consume and process streams of data [7]. A Storm topology will typically run until killed and it processes data items as and when they are produced. The system handles load balancing and recovers from failure of worker nodes by restarting them as required and workers can be directly added even at runtime. As shown in Fig. 4, the sinks and entities that provide transformations are called bolts. Bolts implement a single transformation on a stream and all processing within a Storm topology. Bolts can implement traditional things like MapRe­ duce functionality or more complex actions like filtering, aggregations, or communication with external entities such as a database. The input stream of a Storm cluster is handled by a component called a spout. A typical Storm topology implements multiple transformations and therefore requires multiple bolts with independent tuple streams. Both spouts and bolts are implemented as one or more tasks within a System. A Storm cluster can be imagined as a chain of bolt components that each make some kind of transformation on the data exposed by the spout. And unlike other stream processing systems, with Storm there is no need for intermediate queues. Continuous computation sends data to clients continuously so they can update and show results in real time. Except real-time computation, there exists much necessary for batch processing. We use Spark to fulfill batch compu­ tation. Comparing with Hadoop, Spark not only maintains MapReduces linear scalability and fault tolerance, but also extends it in three important ways. Firstly, rather than relying on a rigid map and reduce sequence, Spark can execute a more general directed acyclic graph of operators, which means that, in situations where MapReduce must write out intermediate re­ sults to the HDFS, Spark can pass them directly to the next step

in the pipeline. Secondly, Spark complements this capability with a rich set of transformations that enable progr armners to express computation more naturally. It has a strong streamlined APIs that can represent complex pipelines with very simple code. Thirdly, Spark extends its predecessors with in-memory processing. Its Resilient Distributed Dataset (RDD) abstraction enables developers to materialize any point in a processing pipeline into memory across the cluster, and it means that future steps that want to deal with the same data set need not recompute it or reload it from disk. This capability opens up use cases that distributed processing engines could not previously approach. Spark is well suited for highly iterative algorithms that require multiple passes over a data set, as well as reactive applications that quickly respond to user queries by scanning large in-memory data sets [8]. What's more, the distributed machine learning framework is also an important module for streaming computation. Built on Apache Spark, MLib is a fast and general engine for large-scale data processing and provides machine learning primitives, such as algorithms of classification, regression, collaborative filtering, clustering and decomposition. Its speed of performing machine learning algorithms is up to dozens of times faster than Hadoop Mahout. So Mlib is also selected into our architecture. IV.

EVALUATION

The key measuring factors of QoS for large-scale data pro­ cessing platform include throughput and latency in distributed messaging system, response time in the batch processing, and precision recall in the scalable data mining [2]. To verify the performance of our computation platform, we deliver the evaluation from three aspects on our developing cluster: computation speed of Spark and Spark streaming, throughput and latency of Storm reading data from HDFS and Kafka, and speed of Spark MLib and Hadoop Mahout. It should be noted that our platform have 11 nodes with total 264 CPU cores (Intel X5650 @ 2.67GHz), 330G memory and 80TB disk. Firstly, we select two nodes from our cluster to test the performance of Spark on three tasks of aggregation by key, sort by key and count by key, respectively. And as shown in Table I, Spark can count about 60 millions records per second, sort 60 millions records per second and aggregate 40 millions records per second. Then on the same two nodes, we also test the performance of Spark Streaming on three basic tasks of state by key, group by key and reduce by key respectively. As listed in Table II, it needs about one second for Spark Streaming to complete a task on the records during a window period, which means that the latency of Spark Streaming is about several seconds. Secondly, with the same two nodes, we perform evaluation on the computation speed of Storm ingesting data from HDFS and Kafka, respectively. As can be seen from Table III, when obtaining data from HDFS, the throughput of Storm can reach at about 21 MB/s and the average latency is about 7 ms, which is far less than the latency of Spark Streaming. Comparatively, when ingesting data from distributed message system Kafka, the latency decreases to about 0.5 ms, which is ten times faster than reading data from HDFS. The results suggest that Kafka and Storm can realize real-time steaming computation excellently.

40

....... Hadoop Mahout -e- Spark Mlib

� 25 '5 c:

I

20 E f= 15 "

10

°2

8

4

16

Nodes

Fig. 5: Comparison of Hadoop Mahout and Spark MLib on K-Means Clustering. The last evaluation is to compare the performance of distributed machine learning frameworks, i.e., Spark MLib with Hadoop Mahout on 2, 4, 8, and 16 workers, respectively. As shown in Fig. 5, MLib is tens times faster than Mahout and when the using workers numbers is increasing, the speed is getting close to MLib, while the speed of MLib almost remains unchanged. The reason is probably that the computation data of Spark MLib is kept in memory, while the data of Hadoop Mahout need to be read from disk first. To sum up, Spark MLib is obviously faster than Mahout and it can be better choice for our architecture. V.

ApPLICATION

The emotion-based social computing platform has been collecting social streaming data, such as Weibo and forums for more than two years. By using MoodLens, we can get the sentiment of the streaming data and the further analysis is performed on about 20 millions tweets and other kinds of data in every day. From the computation result, we have got a lot of interesting findings. In the following text, we will introduce three applications based on our sentiment-based streaming computation platform.

A.

PM2.5

and public emotion 4

00,----����-----., 00 4 Beijing hanghai 300

w

200

.

100 o

1\0

120

130

::� rl 100 o

Time

110

120

130

Fig. 6: Correlation between people's emotion on air pollution and the real index of PM2.5 in Beijing, Shanghai, Guangzhou and Chengdu. As the economic development, air pollution imposes a severe threaten to people's health. As a symbol of air pollution, PM2.5 rises and declines periodically. Consequently, people become angry with the terrible air quality and complained in

TABLE I: Spark Performance Task

Records Number

Unique Key

Length of Key

Unique values

Length of Key

Median(s)

Std(s)

Min(s)

Aggregation by key

200 000 000

20 000

10

1000 000

10

50.2925

2.998

49.137

Sort by key

20 000 000

2 000

10

100 000

10

6.001

0.482

5.597

Counl by key

200 000 000

20 000

10

1000 000

10

32.158

6.024

28.234

TABLE II: Spark Streaming Performance Task

BatchIWindow Duration

Unique Key

Records Per Sec

Unique Values

Min(s)

Ave(s)

Std(s)

Max(s)

State by key

2 000

100 000

10 000

1000 000

0.388

0.585

0.340

1.926

Group by key and window

10 000

10 000

10 000

1000 000

0.339

0.346

0.043

0.452

Reduce by key and window

10 000

10 000

10 000

1000 000

0.292

0.346

0.043

0.458

TABLE III: Storm Performance Time

Transfered

Throughput

Throughput

Spout Throughput

Spout Transfered

Spout Throughput

Ave Latency

Max Latency

(s)

(messagests)

messages

(MBts)

(MBts)

messages

(messagesls)

(ms)

(ms)

60

7893800

131547

13

6

3945320

65747

7.6

7.8

120

12771280

212408

21

10

6385180

106196

7.1

7.3

180

13104120

218125

21

10

6551600

109055

7.0

7.2

240

13030780

216745

21

10

6511600

108392

6.9

7.1

300

12660240

210761

21

10

6332580

105421

7.0

7.1

TABLE IV: Performance of Storm ingesting data from Kafka Time

Transfered

Throughput

Spout Transfered

Spout Throughput

Ave Latency

Max Latency

(s)

(messagesls)

messages

messages

(messagests)

(ms)

(ms)

60

1561580

26023

780920

13013

0.8

3.1

120

12771280

212408

550020

9153

0.5

2.2

180

13104120

218125

547300

9112

0.4

1.8

240

13030780

216745

550900

9171

0.4

1.5

300

12660240

210761

554980

9241

0.3

1.4

Weibo. Oppositely, when the pollution gone, people tweeted their happiness with the beautiful scenery under clear sky. Assuming that people's happiness is negatively correlated with PM2.5 and people's anger is consistent with the changing of PM2.5. In order to verify the assumption, we obtain the emo­ tion of Weibo users towards PM2.5 (when a tweet contains the keyword "PM2.5", the emotion of the tweet can be taken as the user's emotion on PM2.5.) in Beijing, Shanghai, Guangzhou and Chengdu. On the other hand, we collect the realistic value of PM2.5. Then, we compare the daily history dynamic of "anger", "happiness", and "PM2.5" during the period range from Jan 2, 2016 to Jan 31, 2016. As shown in Fig. 6, the anger dynamic generally follow the trends of PM2.5, while the happiness dynamic is mostly opposite with PM2.5. B.

Information diffusion in online social media

Through the history streaming computation, in the previ­ ous study we also inspect the diffusion of trending Internet slangs [14]. It is interesting that we find that slang words demonstrate the phenomenon of spatial propagation, tending to spread from several cities to the other cities across the country [14]. As shown in Fig. 7, "rich redneck", as a rep­ resentation of numerous Internet slangs, which firstly mainly appeared in few places like Guangzhou and Nanjing on Apr 29,2013. And five days later, the slang diffused widely to Wuhan and Chengdu. And between the period range from Nov 27,2013 to Dec 5, 2013, similar phenomenon happened again. The above finding suggests that the information might spread in both social network and space and unraveling the patterns of spatial diffusion indeed helps the prediction of the information diffusion from the perspective of geography. And we argue that through our platform many interesting experiments can be conducted to reveal promising directions from big social

data in the future work. C.

Hot event detection

As an application of near-time streaming computation, we access streaming data from HBase and perform hot event detection algorithm on the passing five hours' streaming data, as total more than 100 thousands tweets. As seen in Fig. 8, in Frankfurt Airport, a passenger tweeted that he was taxed 278€ on his iphone, which has been used for more than one year. The event stirs up feelings of dissatisfaction among the Weibo users. Many users retweet the message and expressed their anger on the event. The sentiment on this event of users are mainly angry and with a little disgusted and disappointed Fig. 9. It suggests event-detection like applications can be perfectly supported by our platform, including the requirement of real-time processing and mUlti-perspective analysis. VI.

CONCLUS ION

An emotion-based social computing platform for streaming big-data, named ESC, is established and evaluated in this study. The platform enables both real-time streaming computation and batch computation on huge data. Besides, it provides scal­ able and applicable computation resources for many different realistic applications. Thorough evaluation on real-world data set demonstrates its high performance in both storage, routing and data mining. Several interesting applications further testify its usability in diverse scenarios. ESC will shed lights on investigation of many promising directions in the future work. ACKNOWLEDGMENT

This work was supported by the National Natural Science Foundation of China (Grant Nos. 71501005 and 71531001)

rich rednecks Apr 29, 2013

May 4, 2013

e 1.00

38.00

�

•

1

""l""

�

0.00

•

0.00

Nov 27, 2013

42.00

79.00

0.00

0.00

Fig. 7: Temporal-spatial diffusion of Internet slang in Weibo.

Real-time top events ...� An&1'Y ...� Happy ..... DI

REFERENCES

,t

Fig. 8: Hot events evolves in Weibo.

EU_Consulate General_Frankfurt

[1]

R. Filguiera, I. Klampanos, A. Krause, M. David, A. Moreno, and M. Atkinson, "DispeI4py: A python framework for data-intensive sci­ entific computing," in Proceedings of the 2014 International Workshop on Data Intensive Scalable Computing Systems, Piscataway, NJ, USA, 2014, pp. 9-16.

[2]

R. Ranjan, "Streaming big data processing in datacenter clouds," IEEE Cloud Computing, no. 1, pp. 78-83, 2014.

[3]

A. Osman, M. El-Refaey, and A. Elnaggar, "Towards real-time ana­ lytics in the cloud," in Services (SERVICES), 2013 IEEE Ninth World Congress on. IEEE, 2013, pp. 428-435.

[4]

D. D. Roure and C. Goble, "Software design for empowering scientists," IEEE Software, vol. 26, no. 1, pp. 88-95, 2009.

[5]

P. Russom et al., "Big data analytics," TDW I Best Practices Report, Fourth Quarter, 2011.

[6]

K. Shvachko, H. Kuang, S. Radia, and R. Chansler, "The hadoop distributed file system," in Mass Storage Systems and Technologies (MSST), 2010 IEEE 26th Symposium on. IEEE, 2010, pp. 1-10.

[7]

M. T. Jones, "Process real·time big data with twitter storm;' IBM Technical Library, 2013.

[8]

M. Zaharia, M. Chowdhury, M. 1. Franklin, S. S henker, and l. Stoica, "Spark: Cluster computing with working sets." HotCloud, vol. 10, pp. 10-10, 2010.

[9]

N. Garg, Learning Apache Kafka.

Airport

Sad 1.9% Disgusted 0.95%

Angry 97.15%

P. Membrey, E. Plugge, and D. Hawkins, T he definitive guide to MongoDB: the noSQL database for cloud and desktop computing. Apress, 2011.

[11]

J. Zhao, L. Dong, J. Wu, and K. Xu, "Moodlens: an emoticon-based sentiment analysis system for chinese tweets," in Proceedings of the 18th ACM SIGKDD international conference on Knowledge discovery and data mining. ACM, 2012, pp. 1528-1531.

[12]

N. Dimiduk, A. Khurana, M. H. Ryan, and M. Stack, HBase in action. Manning Shelter Island, 2013.

[13]

K. S hvachko, H. Kuang, S. Radia, and R. Chansler, "The hadoop dis­ tributed file system," in Proceedings of the 2010 IEEE 26th Symposium on Mass Storage Systems and Technologies (MSST), Washington, DC, USA, 2010, pp. 1-10.

[14]

L. Zhang, J. Zhao, and K. Xu, "Who creates trends in online social media: The crowd or opinion leaders?" Journal of Computer-Mediated Communication, vol. 21, no. \, pp. 1-16, 2016.

Fig. 9: Sentiment of hot event in Weibo (red reflects anger). and the fund of the State Key Lab of Software Development Environment (Grant Nos. SKLSDE-201SZX-OS and SKLSDE201SZX-28).

Packt Publishing Ltd, 2015.

[10]