在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:gpdb开源软件地址:https://gitee.com/mirrors/gpdb开源软件介绍:Concourse Pipeline |Travis Build |Zuul Regression Test On Arm Greenplum Database (GPDB) is an advanced, fully featured, opensource data warehouse, based on PostgreSQL. It provides powerful and rapid analytics onpetabyte scale data volumes. Uniquely geared toward big dataanalytics, Greenplum Database is powered by the world’s most advancedcost-based query optimizer delivering high analytical queryperformance on large data volumes. The Greenplum project is released under the Apache 2license. We want to thankall our past and present community contributors and are really interested inall new potential contributions. For the Greenplum Database communityno contribution is too small, we encourage all types of contributions. OverviewA Greenplum cluster consists of a coordinator server, and multiplesegment servers. All user data resides in the segments, the coordinatorcontains only metadata. The coordinator server, and all the segments, sharethe same schema. Users always connect to the coordinator server, which divides up the queryinto fragments that are executed in the segments, and collects the results. More information can be found on the project website. Building Greenplum Database with GPORCAGPORCA is a cost-based optimizer which is used by Greenplum Database inconjunction with the PostgreSQL planner. It is also known as just ORCA, andPivotal Optimizer. The code for GPORCA resides src/backend/gporca. It is builtautomatically by default. Installing dependencies (for macOS developers)Follow these macOS steps for getting your system ready for GPDB Installing dependencies (for Linux developers)Follow appropriate linux steps for getting your system ready for GPDB Build the database# Configure build environment to install at /usr/local/gpdb./configure --with-perl --with-python --with-libxml --with-gssapi --prefix=/usr/local/gpdb# Compile and installmake -j8make -j8 install# Bring in greenplum environment into your running shellsource /usr/local/gpdb/greenplum_path.sh# Start demo clustermake create-demo-cluster# (gpdemo-env.sh contains __PGPORT__ and __MASTER_DATA_DIRECTORY__ values)source gpAux/gpdemo/gpdemo-env.sh The directory and the TCP ports for the demo cluster can be changed on the fly.Instead of DATADIRS=/tmp/gpdb-cluster PORT_BASE=5555 make cluster The TCP port for the regression test can be changed on the fly: PGPORT=5555 make installcheck-world To turn GPORCA off and use Postgres planner for query optimization: set optimizer=off; If you want to clean all generated files make distclean Running tests
make installcheck-world
Alternative ConfigurationsBuilding GPDB without GPORCACurrently, GPDB is built with GPORCA by default. If you want to build GPDBwithout GPORCA, configure requires # Clean environmentmake distclean# Configure build environment to install at /usr/local/gpdb./configure --disable-orca --with-perl --with-python --with-libxml --prefix=/usr/local/gpdb Building GPDB with PXFPXF is an extension framework for GPDB to enable fast access to external hadoop datasets.Refer to PXF extension for more information. Currently, GPDB is built with PXF by default (--enable-pxf is on).In order to build GPDB without pxf, simply invoke Building GPDB with Python3 enabledGPDB supports Python3 with plpython3u UDF See how to enable Python3 for details. Building GPDB client tools on WindowsSee Building GPDB client tools on Windows for details. Development with VagrantThere is a Vagrant-based quickstart guide for developers. Code layoutThe directory layout of the repository follows the same general layoutas upstream PostgreSQL. There are changes compared to PostgreSQLthroughout the codebase, but a few larger additions worth noting:
ContributingGreenplum is maintained by a core team of developers with commit rights to themain gpdb repository on GitHub. At thesame time, we are very eager to receive contributions from anybody in the widerGreenplum community. This section covers all you need to know if you want to seeyour code or documentation changes be added to Greenplum and appear in thefuture releases. Getting startedGreenplum is developed on GitHub, and anybody wishing to contribute to it willhave to have a GitHub account and be familiarwith Git tools and workflow.It is also recommend that you follow the developer's mailing listsince some of the contributions may generate more detailed discussions there. Once you have your GitHub account, forkthis repository so that you can have your private copy to start hacking on and touse as source of pull requests. Anybody contributing to Greenplum has to be covered by either the Corporate orthe Individual Contributor License Agreement. If you have not previously doneso, please fill out and submit the Contributor License Agreement.Note that we do allow for really trivial changes to be contributed without aCLA if they fall under the rubric of obvious fixes.However, since our GitHub workflow checks for CLA by default you may find iteasier to submit one instead of claiming an "obvious fix" exception. Licensing of Greenplum contributionsIf the contribution you're submitting is original work, you can assume that Pivotalwill release it as part of an overall Greenplum release available to the downstreamconsumers under the Apache License, Version 2.0. However, in addition to that, Pivotalmay also decide to release it under a different license (such as PostgreSQL License to the upstream consumers that require it. A typical example here would be Pivotalupstreaming your contribution back to PostgreSQL community (which can be done eitherverbatim or your contribution being upstreamed as part of the larger changeset). If the contribution you're submitting is NOT original work you have to indicate the nameof the license and also make sure that it is similar in terms to the Apache License 2.0.Apache Software Foundation maintains a list of these licenses under Category A. In addition to that, you may be required to make proper attribution in theNOTICE file similar to these examples. Finally, keep in mind that it is NEVER a good idea to remove licensing headers fromthe work that is not your original one. Even if you are using parts of the file thatoriginally had a licensing header at the top you should err on the side of preserving it.As always, if you are not quite sure about the licensing implications of your contributions,feel free to reach out to us on the developer mailing list. Coding guidelinesYour chances of getting feedback and seeing your code merged into the projectgreatly depend on how granular your changes are. If you happen to have a biggerchange in mind, we highly recommend engaging on the developer's mailing listfirst and sharing your proposal with us before you spend a lot of time writingcode. Even when your proposal gets validated by the community, we still recommenddoing the actual work as a series of small, self-contained commits. This makesthe reviewer's job much easier and increases the timeliness of feedback. When it comes to C and C++ parts of Greenplum, we try to followPostgreSQL Coding Conventions.In addition to that we require that: We recommend using All new functionality that is contributed to Greenplum should be covered by regressiontests that are contributed alongside it. If you are uncertain on how to test or documentyour work, please raise the question on the gpdb-dev mailing list and the developercommunity will do its best to help you. At the very minimum you should always be running Changes applicable to upstream PostgreSQLIf the change you're working on touches functionality that is common between PostgreSQLand Greenplum, you may be asked to forward-port it to PostgreSQL. This is not only sothat we keep reducing the delta between the two projects, but also so that any changethat is relevant to PostgreSQL can benefit from a much broader review of the upstreamPostgreSQL community. In general, it is a good idea to keep both code bases handy soyou can be sure whether your changes may need to be forward-ported. Submission timingTo improve the odds of the right discussion of your patch or idea happening, pay attentionto what the community work cycle is. For example, if you send in a brand new idea in thebeta phase of a release, we may defer review or target its inclusion for a later version.Feel free to ask on the mailing list to learn more about the Greenplum release policy and timing. Patch submissionOnce you are ready to share your work with the Greenplum core team and the rest ofthe Greenplum community, you should push all the commits to a branch in your ownrepository forked from the official Greenplum andsend us a pull request. We welcome submissions which are work in-progress in order to get feedback earlyin the development process. When opening the pull request, select "Draft" inthe dropdown menu when creating the PR to clearly mark the intent of the pullrequest. Prefixing the title with "WIP:" is also good practice. All new features should be submitted against the main master branch. Bugfixesshould too be submitted against master unless they only exist in a supportedback-branch. If the bug exists in both master and back-branches, explain thisin the PR description. Validation checks and CIOnce you submit your pull request, you will immediately see a number of validationchecks performed by our automated CI pipelines. There also will be a CLA checktelling you whether your CLA was recognized. If any of these checks fails, youwill need to update your pull request to take care of the issue. Pull requestswith failed validation checks are very unlikely to receive any further peerreview from the community members. Keep in mind that the most common reason for a failed CLA check is a mismatchbetween an email on file and an email recorded in the commits submitted aspart of the pull request. If you cannot figure out why a certain validation check failed, feel free toask on the developer's mailing list, but make sure to include a direct linkto a pull request in your email. Patch reviewA submitted pull request with passing validation checks is assumed to be availablefor peer review. Peer review is the process that ensures that contributions to Greenplumare of high quality and align well with the road map and community expectations. Everymember of the Greenplum community is encouraged to review pull requests and providefeedback. Since you don't have to be a core team member to be able to do that, werecommend following a stream of pull reviews to anybody who's interested in becominga long-term contributor to Greenplum. As Linus would say"given enough eyeballs, all bugs are shallow". One outcome of the peer review could be a consensus that you need to modify yourpull request in certain ways. GitHub allows you to push additional commits intoa branch from which a pull request was sent. Those additional commits will be thenvisible to all of the reviewers. A peer review converges when it receives at least one +1 and no -1s votes fromthe participants. At that point you should expect one of the core teammembers to pull your changes into the project. Greenplum prides itself on being a collaborative, consensus-driven environment.We do not believe in vetoes and any -1 vote casted as part of the peer reviewhas to have a detailed technical explanation of what's wrong with the change.Should a strong disagreement arise it may be advisable to take the matter ontothe mailing list since it allows for a more natural flow of the conversation. At any time during the patch review, you may experience delays based on theavailability of reviewers and core team members. Please be patient. That beingsaid, don't get discouraged either. If you're not getting expected feedback fora few days add a comment asking for updates on the pull request itself or sendan email to the mailing list. Direct commits to the repositoryOn occasion you will see core team members committing directly to the repositorywithout going through the pull request workflow. This is reserved for small changesonly and the rule of thumb we use is this: if the change touches any functionalitythat may result in a test failure, then it has to go through a pull request workflow.If, on the other hand, the change is in the non-functional part of the code base(such as fixing a typo inside of a comment block) core team members can decide tojust commit to the repository directly. DocumentationFor Greenplum Database documentation, please check theonline documentation. For further information beyond the scope of this README, please seeour wiki |
请发表评论