 Hello everybody, I'm so happy to be here in the co-ordinator's edge day share with you about my thoughts for the edge computing. So my today's topic is streaming analytics on edge with Kuipe and Kuipe Edge. Before starting the session, I will introduce a little bit about myself. So my name is Rocky Jin and I'm the initiator of EMQX Kuipe project. And also I'm the Kuipe Edge IIoT worker group member. And also the LF Edge X Foundry project committer. And also the application and the China working group member. I'm also the former IBM China Software Development Lab as technology and the product leader and architect. Now let's look into what's the streaming analytics. So streaming analytics is our software or framework for state for computation of unbounded data streams so user can manage, monitor and analyze real time of live streaming data. So the typical such kind of software is Apache Frink or Apache Spark. But both of the software are typically running at the cloud data center that is not fit for the edge computing. Why Apache Frink and Spark are not fit for the edge streaming analytics? It has following three reasons. The first is that the latency. So it will take some time to send the data from the edge to cloud. And the secondary is the data security. So it is not fit for all of the data sending to the cloud for security reasons. And the last is the banner-wise costs. So for some user scenarios, the data collected frequency would be very, very high. So it will cost lots of banner-wise if we use the one to send all of the data from the edge to cloud. For example, in the Internet of a vehicle or IoT scenario, it will take lots of banner-wise if collected the data from the edge to the cloud. So there are three changes for edge streaming analytics. The first is that lightweight and high efficiency. So for most of scenarios, the device or computer or the server deployed as the edge is not very good. So it has restricted resources. The CPU and memory is not very good. But we will have such kind of software running at the resource-restricted devices. And the next is Azure and the flexible. So the IoT change is more frequency than before. We needed to have our application or software to support the Azure environment. And the next is deployment and management. So the device are deployed with distributed. They are not centralized as in the cloud. And also it is possibly with very weak network access. So the software needed to be deployed to the edge devices. It will take lots of effort to do this. To resolve the issues. So we proposed the Quipper project. The Quipper project is an open-source software for IoT Edge analytics. The project is initiated by EMQ. So I here introduce a little bit about EMQ. The EMQ is an open-source IoT infrastructure software provider. And now it has an MQTT message broke, which is the most popular open-source software project in the GitHub. Below I list some of the Quipper milestones. So in October 2019, the Quipper project was open-source and released the first version. And in the 2020, we have three major milestones. The first is that we integrated with Edge X Foundry. And the second we integrated with Google Edge. And also in October last year, the first stable version was released. And in the latest version was released at February this year. The Quipper project supported the binary data processing and the machine learning or AI function support. Here is the overview information of the Quip. So I just mentioned in the previous slides. So the project or the software deployed at the Edge must be lightweight. The Quipper project is finally installable and also provides dark images. Currently it has only about 8 MB install package and 10 MB initial memory overhead. So it is quite lightweight. And also it supports different kinds of CPU architect. For example, AMD and ARM and PPC. And also it supports different kinds of Linux systems and OpenWRT, Mac OS, and also provides dark images. Below I list some of the performance data that are running at Raspberry Pi 3B path. With a transaction per second, it's about $12,000. And the CPU consumption is about 70%. And the memory usage is about 20 MB. Of course, the benchmark data is up to the different kinds of user scenarios. So for detailed test scenarios, you can refer to the URL in the slides. So by using the Quip, you can achieve the goal of the data ETL. I mean data extraction, data transformation, and the data loading at the Edge. So if you look at the right side of the picture, we provide the source and they add the right side is the things in the middle of the architecture diagram is Quip run time. So for the data extraction, user can specify different kinds of data source. It could be the MQTT data source or MQ data source, or even the HTTP data source or database data source. With the data transformation, so we provide the SQL like language, user can achieve analytics and transformation with SQL. And the data loading, so user can save the result data to different kinds of target system. For example, the MQTT, the file, the HTTP, and also possible is all kinds of the database. So here are three steps to use the Quip. The first is to create a stream. So a stream is similar to a data source set to find where the data comes from. In the right, here's an example. So the data source is from the topic of an MQTT broke with the data center format is the JSON type. And the next step is to specify a rule. So rule specifies how to process the data and also where to send out the analysis result. So here we have a SQL property, which specifies the SQL logic and actually means that where the data or the result data sent to. So the first is that log, which means that the data will be printed to the log file. And the second is MQTT, so which means that the result will be sent to the broke.mqt.io with the topic device slash result. And the last step to submit and run the rule. So user can issue a command against the Quip address server with the rules specified in the previous step. So that is all of the three steps to use the Quip. Here, I will introduce a little more detail for the SQL analytics. So first of all, we provide the building functions, which include the mathematics, stream, aggregation, conversion, including and decoding, hashing, JSON processing and others, totally now about 80 functions. And also Quip provides a field, so user can filter the data by a well or case when SQL calls. Also it provides the join, so user can use different kinds of join, the left join, right join, full join and cross join. So one string can be joined to another string, so string is a dynamic flow in data, and also user can join to another tables. The tables is static data, so it is normally used for associating additional information. So for example, if the report data has an ID, but the target system or things need to get as a name, so it can be joined to the tables to get as a related name. And the next is the window, so it provides the tumbling, hopping, sliding, session and account. So the window is often used in the IoT user scenarios, user can use the window to calculate different kinds of analytical results, which is specified of a period of time. And the last provided by the SQL is group by and order by, so user can group by different kind of conditions and order by specified fields. Here introduced about advanced analytics provided by the Quip, so Quip currently also supports the binary, the binary data type spot. So first is the binary image processing, so user can resize or reduce the resolution of the image before sending to the cloud. So in the right side is an example, and also it provides the geohash functions for processing the logitude and latitude. So user can call the geohash in code, geohash decode, geohash neighbor, and geohash boundary box and so on. The last one is that the user also can use machine learning or AI streaming processing. So there are two approaches to achieve the goal. The first is that encapsulates the machine or machine learning or AI function with Quip. By this approach, user can get better performance but with higher development and maintenance effort. And the next approach is to use machine learning AI services by RPC or REST API. So in some of user scenarios, machine learning or AI is exposed with REST API or RPC service. So the Quipers can support invoke these interfaces with function call. With this approach, lower development and deployment effort but sacrifice some performance. So at the right side, here's an example. So input is the image data byte array, and we wanted to label the image, so user can just write as a SQL such as select label image function from the stream. So the output would be the image content of the image. Next is extension and plug-in. So Quip provides three extension points, source, sync, and function. After extension, users can use it in the Quip framework. So here are three steps to achieve the goal or develop a plug-in. The first is development and debug in your local environment. And then compile to the SO file with the sync environment as running in the production. And then deploy the plug-ins. So in the right side, I listed our source extension example. So user will have to implement three functions or interfaces that are required for the source plug-in. The configuration, the open, close, and the last is the initial nice instance for your plug-in. So this is the native plug-in environment development. So the advantage is that it can achieve the better performance because the plug-in is loaded with native. But the disadvantage is that it has very strict it has very strict limitations, which comes from the goal language. So Quip plug-in is based on the goal LAN plug-in. So user will have to have the same goal version between the Quip and your plug-in. And also the library dependence must be the same. And also should have the same goal path for the Quip and your plug-in. It is hard to maintain and develop. So user also will use Quip in another two scenarios. Here is one example. So first is the rule engine, rules engine. So EdgeX Foundry in the right side. So Quip project was the referenced rule engine implementation in the EdgeX Foundry project. So from April 2020, it has been included in the EdgeX Foundry project. So if you try to use EdgeX Foundry, the Quip is also included in the project. And then the next is the data format and the protocol conversion. So for some of the reasons, user wanted to accept the data from source and then after processing, send the data to another system. But the two systems has different protocols or data type. So user can use the Quip to do some transformation and conversion. So one of the examples is that user use the SAP NetWeaver RFC SDK to extract the data from the SAP system and then send it to another system after processing by the Quip rules. Now in this page, I will introduce a little bit more about Quip Edge and Quip integration. So the Quip Edge is an open source project extending native containerized application orchestration capabilities to host at Edge. With Quip and Quip Edge integration, it enhances the Edge analytics capabilities. So the benefits for the two open source project integrations is that it addresses IoT Edge computing challenges. So with Quip capabilities provided for Edge analytics, it provides lower latency and the bandwidth causes saving because all of the data can be processed at the Edge. And also it is easy for user to implement or refresh the business logic because user can just change the Quip rule at the cloud side. And the last benefit comes from the Quip Edge. User can manage and deploy the Quip applications or AI algorithm from the cloud and also manages the rule from the cloud. So it addresses the three challenges from the IoT Edge computing. Here is a customer case that leverages the Quip Edge and the Quip. So Quip accepts the data collecting from the device connected to the Quip Edge. And after processing one rule, we'll save the data to the EnflatDB, which is a time-celled DB deployed at Edge. And another rule was deployed for synchronizing the data or sending the data from the Edge to the remote MQTT broke, which is deployed at the cloud side. So next step for the Quip project. So we will contribute the Quip to the LF Edge. Now it's under the submission process. And also we will collaborate with more of open source projects from now on. So lastly, we will introduce more features at this year. For example, the third party language plugin development support. As I mentioned in the previous page, so the native approach of plugin development is not very convenient. So we will support the third party language plugin development, which will be more user friendly to the plugin development. And also we will add persistent support with third party frameworks, such as Redis. And for more detailed information, please refer to 2021 rule map. You can click as a link to get more detailed information. Okay, that's all for today's session. If you have any questions, let's discuss. Thank you.