Social Commerce is caused by the evolution of commercial market and the widespread use of social network-based data. In a various of systems and smart platform provide to commercial services with product data and customer historical record by online commerce market such as e-commerce, m-commerce or u-commerce [1]. Their commerce market is based on Amazon, eBay, Facebook, or Coupang and so on, these system is supported on recommendation obtained using the web community and social data. Nevertheless they were fast growth and increasing with social commerce what they want service, they did not satisfy about their commercial policy how to effectively manage to users for social service [2]. In other words, despite they made up design with online market place, they have a question what components need in a social commerce framework, what they want communications for personalized service, how they connect social channel with system to system, system to user or system to platform [3]. These are based on the integration of previous system to newly system and also, the existing knowledge of big data environment. Accordingly, our main idea propose a new framework and a set of fundamental principle for social commerce [4]. Moreover, we provide Big Data Platform architecture analysis for social commerce including four key elements [5-9].

In order to main contributions of our work, this paper are that we propose a users and service provider using BDP Architecture.

This paper is organized as follows. In Section 2 details the Big Data. Then Big Data Platform architecture is presented and discussed in Section 3. Finally, Section 4 concludes the paper by briefly summarizing the main points and proposing future work.

There is no single formulation of what Big Data actually is. Generally, it is described as the data that enhances the processing capacity of traditional systems and cannot be processed or analyzed using conventional tools or processes. More and more organizations are receiving and collecting large amounts of data, but they often do not have the means of how to store and analyze the information. This spark of information overflow comes from multiple facts. Sensors are becoming a natural part of every device, and many sensors are capturing information on a constant frequency [10]. It is a trend nowadays to perform most of the activities on the Internet using different services for different needs, and people tend to generate massive volumes of data on social networks. However, the amount of information is only one of the aspects of Big Data. The data, especially from sensors, usually come in a raw, semistructured, or unstructured format. It is necessary to prepare the received data before it can be stored and analyzed. The analysis became more complex as well, requiring statistical, data mining, and machine learning to manage the Big Data.

Big Data Platform architecture is a regular software architecture that concentrates on the Big Data domain. Since the Big Data is such a complex environment, it is more than necessary to specify an architecture before actually building the system. As mentioned before, the architecture should be evaluated as soon as possible, to prevent future issues. Currently, there are many different Big Data architectures specified, but no general solution is agreed as a standard. The lack of the standard in Big Data may be caused by the fact that it is a relatively new concept and there was simply no time to establish it, or by the complexity of the domain. Thus, it is complex to compare them in order to design a new architecture or to enhance existing ones. The enhancement can be done by comparing the existing architecture against some unified format and then evaluating the parts that were not found in the scope of the current architecture. During the evaluation, it has to be decided whether the part of the system that is currently not implemented can bring some additional value from the business or technical perspective. If yes, a guideline on how this component should work and cooperate with the rest of the system is needed. Moreover, technology has to be selected for the new part of the system that can be easily integrated with the existing solution.

The conceptual measurement model was conceived in several steps. Firstly, the grounds of comparison had to be specified. Only the data manipulation part of the whole Big Data systems was selected as the their scope. The security aspect, quality assurance, and other non-functional requirements do not fall under the their scope. The same applies to the end-user decision making regarding the received final data and type specification of the data that enter the architecture. As to the actual model creation process, the initial requirement of all Big Data architectures was defined in the highest level as possible. Specifically, the general requirement for each architecture, which can be later extended or used only partially, is similar to the basic retrieve, transform, and consume process. The process starts with data retrieval from various sources, then the data are processed and transformed, and finally, the result of the manipulation is returned. This simple principle was then extended in every aspect within selected grounds for comparison, and a process of data modification and preservation was applied to each step. Afterward, this measurement model was validated against available architectures both from the scientific domain and architectures used in industrial applications. A few changes were applied to extend the model to cover more business and theoretical scenarios of Big Data capabilities. <Figure 1> is a result of the analysis process and should cover most of the scenarios required for big data architectures in the set their scope.

Social commerce architecture was built by analyzing the existing architectures from the industry domain, namely Naver, Instagram, Twitter, and so on, Network traffic measurement. All these existing applications were then mapped to the their architecture to prove the universality of the proposed architecture. The high-level design of the resulting architecture can be seen in <Figure 2> Data sources, Data extraction, Data loading and pre-processing, Data processing, Data analysis, Data loading and transformation, Interfacing and visualization, Data Storage, and Job and model specification. Data sources can be categorized into two dimensions: mobility and structure of data. Data sources refer only to the actual data and do not describe the data retrieval, that is the purpose of the Data extraction component. These two components of the architecture correspond with the Data acquisition component of the conceptual measurement model.

Consecutively, the raw data can be transformed, loaded, or compressed in the Data-loading and preprocessing component. This raw data transformation matches the Pre-processing component of the measurement model. The next component of the architecture can also transform data in terms of combining, cleaning, or replication. Furthermore, the stream processing or information extraction can be defined in the scope of Data processing component, which has the same name in the measurement model and can be mapped directly. Similarly, the Data analysis maps to the Data analysis component, where deep analytics or stream analytics take place. The following step can be an additional transformation of the results of data analysis, which takes place in the Data loading and transformation component. The counterpart of this component in the measurement model is Transformation and modeling. It also includes the model specification of the architecture, which is defined separately in

the Job and model specification as a standalone process. Visualization of the analyzed and transformed data is part of the Interfacing and visualization component, which is a correlative component to the Interpretation part of the measurement model. Data storage component is spanned across all the components described above and resembles the previous architecture, where the data storage solution was very similar. The same way as in the previous example, this is represented in the conceptual measurement model in two parts as primary and secondary Data storage.

In this paper, we have proposed a description of the theoretical background on the Big Data. The main definition and characteristics of Big Data are described together with Hadoop and its specifications in terms of the main parts which are HDFS, MapReduce, and Common. contains the definition of the measurement model provided for the evaluation of Big Data architectures. The model is structured as multiple interacting components, where almost all the components can be treated as optional. Each component is described with expected functionality and the scope of responsibilities. The our scope for this conceptual measurement model was set with the emphasis on the data flow process and its orchestration, not on the data itself nor the attributes of the system. Then selected BDP architecture from both conceptual and industry origin were evaluated and mapped to the measurement model for a unified point of comparison. Each evaluated architecture contains a description of the process used in the architecture. Our BDP architecture was randomly selected with the emphasis on the relevance to the Big Data architecture domain, and we shown <Figure 3>.

It was possible to map all architectures to the conceptual measurement model allowing further evaluation in terms of technologies. This measurement model is not meant as the architecture proposal, but a unified structure on which was later possible to conduct group analysis for all different architectures with different approaches to the Big Data problematics. The architectures were similar in many ways, but some of them used various and unique approaches. Also, the purpose of each architecture differed based on the domain to which it was proposed.