- Dev - mailweb.openlookeng.io

IUD support on Carbondata partitioned table
by Aman Omer 15 Jul '20

15 Jul '20

Hello all, Openlookeng integration with Carbondata supports creation and reading data from partitioned table but doesn’t provide support for insert, update and delete. This becomes the limitation of openlookeng since other processing engine like spark provides the same. Insert, Update and Delete support on carbondata partitioned table is the high level goal of this proposal. Find initial design doc in attachments. Kindly let me know if there are any comments/suggestions. Thanks, Aman Omer

2 1

Welcome Xulifeng and Xutianli to the openLooKeng PMC
by Ken Zhang 15 Jul '20

15 Jul '20

Hi All, Our community is expanding! To ensure our roadmap and vision matches the big data trend. I am honored to announce Xulifeng and Xutianli has accepted our invitation to join openLooKeng PMC. Both of them have over 10 years of big data experience with in-depth knowledge about streaming, batch and ad-hoc data processing. They will not only bring insights on technical directions, but also provide valuable user scenarios which can help us shape the future of openLooKeng. Please join me in welcoming Xulifeng and Xutianli. Best regards, /** * Ken Zhang * openLooKeng PMC */

4 3

转发: Welcome to the "Dev" mailing list
by Jiangdayong 15 Jul '20

15 Jul '20

江大勇 -----邮件原件----- 发件人: dev-request(a)openlookeng.io [mailto:dev-request@openlookeng.io] 发送时间: 2020年7月15日 11:37 收件人: Jiangdayong <jiangdayong(a)huawei.com> 主题: Welcome to the "Dev" mailing list Welcome to the "Dev" mailing list! To post to this list, send your email to: dev(a)openlookeng.io You can unsubscribe or make adjustments to your options via email by sending a message to: dev-request(a)openlookeng.io with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You will need your password to change your options, but for security purposes, this password is not included here. If you have forgotten your password you will need to reset it via the web UI.

1 0

Carbondata Auto-Cleanup
by Sandeep K 15 Jul '20

15 Jul '20

Hello all, Openlookeng integration with Carbondata not supporting auto cleanup of vacuum/compaction tables. This becomes the limitation of openlookeng since other processing engine like spark provides the same. Find initial design doc in attachments. Kindly let me know if there are any comments/suggestions. Thanks, Sandeep.k

1 0

Compaction on Carbondata Connector [Carbondata]
by Siddharth Jaiswal 14 Jul '20

14 Jul '20

Hello All, We propose to include Compaction operation for Carbondata data source such that multiple segments of Carbondata files in memory are merged into smaller number of segments, either based on size or count constraints as supplied by the user. The Compaction operation is valid for both partitioned tables and simple non-partitioned tables. We call this operation as VACUUM and have as follows- 1. MINOR Vacuum Operation - based on count of segments to be merged 2. Major Vacuum Operation - based on size of segments to be merged This operation will be beneficial as it will compact the multiple segments that are maintained into a single segment in memory. Attached is the initial design document. Please let me know if there are any comments/suggestions. Thanks and Regards, Siddharth D Jaiswal

1 0

Table Scan Optimization Using Filter Pushdown [HIVE-ORC]
by Rajeev Rastogi 13 Jul '20

13 Jul '20

Hello All, Many queries attribute good percentage of CPU time to table scan, so with making scan improvement, many queries will get performance improvement. Currently we focus on table scan optimization for tables stored in ORC format (but should be possible to extend to other data formats also). Overall approach for filter pushdown can be depicted as in the below picture. As can be seen, in the new approach (right side), filter evaluation has been pushed to the HIVE connector from the engine. [image: image.png] Below is a list of ideas to optimize table scan by reducing CPU time. 1. *Filter Pushdown* (Only deterministic filter e.g. id>10, id in (10,20) etc): This optimization is required to push the filter from engine to hive connector so that only filtered rows/columns get returned back to the engine layer. 2. *Efficient Row Skipping*: Currently if a filter on one column matches only for a small set of rows, then still we read all values in subsequent columns which are part of the query and immediately discard them. This waste CPU cycle unnecessarily. This can be optimized to read only rows for next columns which matched as part of the previous column. 3. *Avoid unwanted Columns*: Using this approach, the connector will return only columns required to project and not the column which was just used for the filter. 4. *Filter Re-ordering (Part-1)*: Considering the "Efficient Row Skipping", it is always beneficial to process columns with filter first which results in the least number of rows, so that further column processing needs to process only a relatively small number of rows. As part of this re-ordering will be done in such a way that the first column with filter will be processed first and then column without filter. But with-in the multiple column with filter ordering will be done later. In the first proposal, We would like to propose a design for the all the above optimization idea. Major changes required in HIVE connector to process filter along with some changes in optimizer to push filter down to connector. 1. HIVE Connector (ORC format) - Rajeev Rastogi 2. Optimizer - Nitin Kashyap. We will require a session configuration variable to enable/disable this feature. By default it will be disabled. We propose to have a configuration variable named as "*orc_predicate_pushdown_enabled*" for the same. But we can also discuss naming it as "*experimental_orc_predicate_pushdown_enabled*" till we see all TODO items finished and see everything working fine. Attached is the design document. Please let us know if any comments/suggestions. Once the first part is done, then it will open up opportunities for further optimization, some of them are as mentioned below: 5. *Not-deterministic Filter Pushdown (e.g. id1+id2 > 10 etc)*: As part of this non-deterministic filter will be pushed down to the connector layer and the same will be processed in the connector itself (like function processing). 6. *Filter Re-ordering (Part-2): *As part of this, re-ordering among multiple columns with a filter will be done. We may make use of stats (or type of filter) here to see which filter may return how many rows and then accordingly reorder it. 7. *Sub-field Pruning*: Hetu supports structural complex data-type e.g. Map, Array, List. In the current approach HIVE connector returns a whole map corresponding to a column and row, which may include many keys but the application might be interested in only one key. So here the optimization idea is to prune those unwanted keys and return whatever really wanted by the user. E.g. query "*SELECT ISDCODE('INDIA') FROM CITIZEN*", connector will no longer return ISDCODE corresponding to other countries stored in this row column. 8. *Multi-Column OR condition*: Handling of predicate OR condition on multiple columns. 9. In addition to these optimizations, there are some *TODO items in the design document*, which we can discuss to decide if it can be taken up after the first phase. -- *Thanks and Regards,Kumar Rajeev RastogiCell No - +91 8971367787*

1 0

[openEuler][Big Data][openLooKeng]Is it possible to introduce openLooKeng to openEuler
by Liyongle (Fred) 07 Jul '20

07 Jul '20

Hi openEuler AI-Bigdata SIG and openLooKeng development team, It happened that I am in both openEuler[0] and openLooKeng[2] communities. openLooKeng was opened just few days ago. I knew that AI & Big Data SIG in openEuler is working on many projects about Big Data. I hope there will be a chance to introduce openLooKeng into openEuler. This email was sent to bridge the 2 teams. Regards [0] https://openeuler.org [1] https://gitee.com/openeuler/community/tree/master/sig/sig-ai-bigdata [2] https://openlookeng.io Fred 李永乐

2 1

Glad to join dev mail list
by Fred Li 28 Jun '20

28 Jun '20

as titled -- Regards Fred Li (李永乐)

1 0

This is a test email
by Fred Li 28 Jun '20

28 Jun '20

I subscribed but failed thus I did the test. -- Regards Fred Li (李永乐)

2 1

Glad to meet you all here
by Fred Li 28 Jun '20

28 Jun '20

Hi openLooKeng developers, I am happy to *meet* you here and will try to contribute in this project. -- Regards Fred Li (李永乐)

1 1

2024

2023

2022

2021

2020

Dev