{"id":13486446,"url":"https://github.com/apache/kudu","last_synced_at":"2025-05-14T01:03:37.515Z","repository":{"id":37550414,"uuid":"50647838","full_name":"apache/kudu","owner":"apache","description":"Mirror of Apache Kudu","archived":false,"fork":false,"pushed_at":"2025-05-06T07:47:19.000Z","size":88676,"stargazers_count":1870,"open_issues_count":10,"forks_count":652,"subscribers_count":107,"default_branch":"master","last_synced_at":"2025-05-10T17:16:38.640Z","etag":null,"topics":["big-data","cplusplus","kudu"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/apache.png","metadata":{"files":{"readme":"README.adoc","changelog":null,"contributing":"CONTRIBUTING.adoc","funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"docs/security.adoc","support":"docs/support/doxygen/client_api.doxy.in","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-01-29T08:00:06.000Z","updated_at":"2025-05-09T09:34:43.000Z","dependencies_parsed_at":"2024-01-23T17:31:44.824Z","dependency_job_id":"7166646c-ebda-422f-a134-e940331c6551","html_url":"https://github.com/apache/kudu","commit_stats":{"total_commits":10309,"total_committers":205,"mean_commits":50.28780487804878,"dds":0.8420797361528761,"last_synced_commit":"1c69ec6081a88dc531ebaa60b19abd4c0e54ae47"},"previous_names":[],"tags_count":84,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fkudu","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fkudu/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fkudu/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/apache%2Fkudu/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/apache","download_url":"https://codeload.github.com/apache/kudu/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253851992,"owners_count":21973835,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["big-data","cplusplus","kudu"],"created_at":"2024-07-31T18:00:46.100Z","updated_at":"2025-05-14T01:03:37.478Z","avatar_url":"https://github.com/apache.png","language":"C++","readme":"// Licensed to the Apache Software Foundation (ASF) under one\n// or more contributor license agreements.  See the NOTICE file\n// distributed with this work for additional information\n// regarding copyright ownership.  The ASF licenses this file\n// to you under the Apache License, Version 2.0 (the\n// \"License\"); you may not use this file except in compliance\n// with the License.  You may obtain a copy of the License at\n//\n//   http://www.apache.org/licenses/LICENSE-2.0\n//\n// Unless required by applicable law or agreed to in writing,\n// software distributed under the License is distributed on an\n// \"AS IS\" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY\n// KIND, either express or implied.  See the License for the\n// specific language governing permissions and limitations\n// under the License.\n= Kudu Developer Documentation\n\n== Building and installing Kudu\n\nFollow the steps in the\nhttps://kudu.apache.org/docs/installation.html#build_from_source[documentation]\nto build and install Kudu from source\n\n=== Building Kudu out of tree\n\nA single Kudu source tree may be used for multiple builds, each with its\nown build directory. Build directories may be placed anywhere in the\nfilesystem with the exception of the root directory of the source tree. The\nKudu build is invoked with a working directory of the build directory\nitself, so you must ensure it exists (i.e. create it with _mkdir -p_). It's\nrecommended to place all build directories within the _build_ subdirectory;\n_build/latest_ will be symlinked to most recently created one.\n\nThe rest of this document assumes the build directory\n_\u003croot directory of kudu source tree\u003e/build/debug_.\n\n=== Automatic rebuilding of dependencies\n\nThe script `thirdparty/build-if-necessary.sh` is invoked by cmake, so\nnew thirdparty dependencies added by other developers will be downloaded\nand built automatically in subsequent builds if necessary.\n\nTo disable the automatic invocation of `build-if-necessary.sh`, set the\n`NO_REBUILD_THIRDPARTY` environment variable:\n\n[source,bash]\n----\n$ cd build/debug\n$ NO_REBUILD_THIRDPARTY=1 cmake ../..\n----\n\nThis can be particularly useful when trying to run tools like `git bisect`\nbetween two commits which may have different dependencies.\n\n\n=== Building Kudu itself\n\n[source,bash]\n----\n# Add \u003croot of kudu tree\u003e/thirdparty/installed/common/bin to your $PATH\n# before other parts of $PATH that may contain cmake, such as /usr/bin\n# For example: \"export PATH=$HOME/git/kudu/thirdparty/installed/common/bin:$PATH\"\n# if using bash.\n$ mkdir -p build/debug\n$ cd build/debug\n$ cmake ../..\n$ make -j8  # or whatever level of parallelism your machine can handle\n----\n\nThe build artifacts, including the test binaries, will be stored in\n_build/debug/bin/_.\n\nTo omit the Kudu unit tests during the build, add -DNO_TESTS=1 to the\ninvocation of cmake. For example:\n\n[source,bash]\n----\n$ cd build/debug\n$ cmake -DNO_TESTS=1 ../..\n----\n\n== Running unit/functional tests\n\nTo run the Kudu unit tests, you can use the `ctest` command from within the\n_build/debug_ directory:\n\n[source,bash]\n----\n$ cd build/debug\n$ ctest -j8\n----\n\nThis command will report any tests that failed, and the test logs will be\nwritten to _build/debug/test-logs_.\n\nIndividual tests can be run by directly invoking the test binaries in\n_build/debug/bin_. Since Kudu uses the Google C++ Test Framework (gtest),\nspecific test cases can be run with gtest flags:\n\n[source,bash]\n----\n# List all the tests within a test binary, then run a single test\n$ build/debug/bin/tablet-test --gtest_list_tests\n$ build/debug/bin/tablet-test --gtest_filter=TestTablet/9.TestFlush\n----\n\ngtest also allows more complex filtering patterns. See the upstream\ndocumentation for more details.\n\n=== Running tests with the clang AddressSanitizer enabled\n\n\nAddressSanitizer is a nice clang feature which can detect many types of memory\nerrors. The Jenkins setup for kudu runs these tests automatically on a regular\nbasis, but if you make large changes it can be a good idea to run it locally\nbefore pushing. To do so, you'll need to build using `clang`:\n\n[source,bash]\n----\n$ mkdir -p build/asan\n$ cd build/asan\n$ CC=../../thirdparty/clang-toolchain/bin/clang \\\n  CXX=../../thirdparty/clang-toolchain/bin/clang++ \\\n  ../../thirdparty/installed/common/bin/cmake \\\n  -DKUDU_USE_ASAN=1 ../..\n$ make -j8\n$ ctest -j8\n----\n\nThe tests will run significantly slower than without ASAN enabled, and if any\nmemory error occurs, the test that triggered it will fail. You can then use a\ncommand like:\n\n\n[source,bash]\n----\n$ cd build/asan\n$ ctest -R failing-test\n----\n\nto run just the failed test.\n\nNOTE: For more information on AddressSanitizer, please see the\nhttps://clang.llvm.org/docs/AddressSanitizer.html[ASAN web page].\n\n=== Running tests with the clang Undefined Behavior Sanitizer (UBSAN) enabled\n\n\nSimilar to the above, you can use a special set of clang flags to enable the Undefined\nBehavior Sanitizer. This will generate errors on certain pieces of code which may\nnot themselves crash but rely on behavior which isn't defined by the C++ standard\n(and thus are likely bugs). To enable UBSAN, follow the same directions as for\nASAN above, but pass the `-DKUDU_USE_UBSAN=1` flag to the `cmake` invocation.\n\nIn order to get a stack trace from UBSan, you can use gdb on the failing test, and\nset a breakpoint as follows:\n\n----\n(gdb) b __ubsan::Diag::~Diag\n----\n\nThen, when the breakpoint fires, gather a backtrace as usual using the `bt` command.\n\n=== Running tests with ThreadSanitizer enabled\n\nThreadSanitizer (TSAN) is a feature of recent Clang and GCC compilers which can\ndetect improperly synchronized access to data along with many other threading\nbugs. To enable TSAN, pass `-DKUDU_USE_TSAN=1` to the `cmake` invocation,\nrecompile, and run tests. For example:\n\n[source,bash]\n----\n$ mkdir -p build/tsan\n$ cd build/tsan\n$ CC=../../thirdparty/clang-toolchain/bin/clang \\\n    CXX=../../thirdparty/clang-toolchain/bin/clang++ \\\n    ../../thirdparty/installed/common/bin/cmake \\\n    -DKUDU_USE_TSAN=1 ../..\n$ make -j8\n$ ctest -j8\n----\n\nTSAN may truncate a few lines of the stack trace when reporting where the error\nis. This can be bewildering. It's documented for TSANv1 here:\nhttps://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithm\nIt is not mentioned in the documentation for TSANv2, but has been observed.\nIn order to find out what is _really_ happening, set a breakpoint on the TSAN\nreport in GDB using the following incantation:\n\n[source,bash]\n----\n$ gdb -ex 'set disable-randomization off' -ex 'b __tsan::PrintReport' ./some-test\n----\n\n\n=== Generating code coverage reports\n\n\nIn order to generate a code coverage report, you must use the following flags:\n\n[source,bash]\n----\n$ mkdir -p build/coverage\n$ cd build/coverage\n$ CC=../../thirdparty/clang-toolchain/bin/clang \\\n  CXX=../../thirdparty/clang-toolchain/bin/clang++ \\\n  cmake -DKUDU_GENERATE_COVERAGE=1 ../..\n$ make -j4\n$ ctest -j4\n----\n\nThis will generate the code coverage files with extensions .gcno and .gcda. You can then\nuse a tool like `gcovr` or `llvm-cov gcov` to visualize the results. For example, using\ngcovr:\n\n[source,bash]\n----\n$ cd build/coverage\n$ mkdir cov_html\n$ ../../thirdparty/installed/common/bin/gcovr \\\n      --gcov-executable=$(pwd)/../../build-support/llvm-gcov-wrapper \\\n      --html --html-details -o cov_html/coverage.html\n----\n\nThen open `cov_html/coverage.html` in your web browser.\n\n=== Running lint checks\n\nKudu uses cpplint.py from Google to enforce coding style guidelines. You can run the\nlint checks via cmake using the `ilint` target:\n\n[source,bash]\n----\n$ make ilint\n----\n\nThis will scan any file which is dirty in your working tree, or changed since the last\ngerrit-integrated upstream change in your git log. If you really want to do a full\nscan of the source tree, you may use the `lint` target instead.\n\n=== Running clang-tidy checks\n\nKudu also uses the clang-tidy tool from LLVM to enforce coding style\nguidelines. You can run the tidy checks via cmake using the `tidy` target:\n\n[source,bash]\n----\n$ make tidy\n----\n\nThis will scan any changes in the latest commit in the local tree. At the time\nof writing, it will not scan any changes that are not locally committed.\n\n=== Running include-what-you-use (IWYU) checks\n\nKudu uses the https://github.com/include-what-you-use/include-what-you-use[IWYU]\ntool to keep the set of headers in the C++ source files consistent. For more\ninformation on what _consistent_ means, see\nhttps://github.com/include-what-you-use/include-what-you-use/blob/master/docs/WhyIWYU.md[_Why IWYU_].\n\nYou can run the IWYU checks via cmake using the `iwyu` target:\n\n[source,bash]\n----\n$ make iwyu\n----\n\nThis will scan any file which is dirty in your working tree, or changed since the last\ngerrit-integrated upstream change in your git log.\n\nIf you want to run against a specific file, or against all files, you can use the\n`iwyu.py` script:\n\n[source,bash]\n----\n$ ./build-support/iwyu.py\n----\n\nSee the output of `iwyu.py --help` for details on various modes of operation.\n\n[[building-docs]]\n=== Building Kudu documentation\n\nKudu's documentation is written in asciidoc and lives in the _docs_ subdirectory.\n\nTo build the documentation (this is primarily useful if you would like to\ninspect your changes before submitting them to Gerrit), use the `docs` target:\n\n[source,bash]\n----\n$ make docs\n----\n\nThis will invoke `docs/support/scripts/make_docs.sh`, which requires\n`asciidoctor` to process the doc sources and produce the HTML documentation,\nemitted to _build/docs_. This script requires `ruby` and `gem` to be installed\non the system path, and will attempt to install `asciidoctor` and other related\ndependencies into `$HOME/.gems` using https://bundler.io/[bundler].\n\nSome of the dependencies require a recent version of Ruby. To build the\ndocumentation on a system that comes with an older Ruby version (such as Ruby\n2.0 on CentOS 7), it is easiest to use https://github.com/rbenv/rbenv[rbenv] to\ninstall Ruby 2.7.\n\nWARNING: As the default values for some configuration options differ between Mac\nand Linux (e.g. file vs log block manager) and the configuration reference is\ngenerated by running the binaries with `-help`, the documentation *MUST NOT* be\ngenerated on Mac for publishing purposes, only for verification.\n\nNOTE: Java API docs can only be built on Java 8 due to Javadoc compatibility\nissues.\n\n[[updating-the-site]]\n=== Updating the Kudu web site documentation\n\nTo update the documentation that is integrated into the Kudu web site,\nincluding Java and C++ client API documentation, you may run the following\ncommand:\n\n[source,bash]\n----\n$ ./docs/support/scripts/make_site.sh\n----\n\nThis script will use your local Git repository to check out a shallow clone of\nthe 'gh-pages' branch and use `make_docs.sh` to generate the HTML documentation\nfor the web site. It will also build the Javadoc and Doxygen documentation.\nThese will be placed inside the checked-out web site, along with a tarball\ncontaining only the generated documentation (the _docs/_ and _apidocs/_ paths\non the web site). Everything can be found in the _build/site_ subdirectory.\n\nTo build the C++ Client API you need to have Doxygen 1.8.19 or later which is\nfairly new so you might need to\nhttps://www.doxygen.nl/manual/install.html#install_src_unix[build it from\nsource]. To build it on RHEL/CentOS you'll also need\nhttps://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/[devtoolset] as\nDoxygen uses {cpp}14 since 1.8.17.\n\nYou can proceed to commit the changes in the pages repository and send a code\nreview for your changes. In the future, this step may be automated whenever\nchanges are checked into the main Kudu repository.\n\nAfter making changes to the `gh-pages` branch, follow the instructions below\nwhen you want to deploy those changes to the live web site.\n\nWARNING: The site *MUST NOT* be built on Mac for publishing purposes, only for\nverification. See the warning in \u003c\u003cbuilding-docs\u003e\u003e for details.\n\n=== Deploying changes to the Apache Kudu web site\n\nWhen the documentation is updated on the `gh-pages` branch, or when other web\nsite files on that branch are updated, the following procedure can be used to\ndeploy the changes to the official Apache Kudu web site. Committers have\npermissions to publish changes to the live site.\n\n[source,bash]\n----\ngit checkout gh-pages\ngit fetch origin\ngit merge --ff-only origin/gh-pages\n./site_tool proof        # Check for broken links (takes a long time to run)\n./site_tool publish      # Generate the static HTML for the site.\ncd _publish \u0026\u0026 git push  # Update the live web site.\n----\n\nNOTE: sometimes, due to glitches with the ASF gitpubsub system, a large commit,\nsuch as a change to the docs, will not get mirrored to the live site. Adding an\nempty commit and doing another git push tends to fix the problem. See the git\nlog for examples of people doing this in the past.\n\n== Improving build times\n\n=== Caching build output\n\nThe kudu build is compatible with ccache. Simply install your distro's _ccache_ package,\nprepend _/usr/lib/ccache_ to your `PATH`, and watch your object files get cached. Link\ntimes won't be affected, but you will see a noticeable improvement in compilation\ntimes. You may also want to increase the size of your cache using \"ccache -M new_size\".\n\n=== Improving linker speed\n\nOne of the major time sinks in the Kudu build is linking. GNU ld is historically\nquite slow at linking large C++ applications. The alternative linker `gold` is much\nbetter at it. It's part of the `binutils` package in modern distros (try `binutils-gold`\nin older ones). To enable it, simply repoint the _/usr/bin/ld_ symlink from `ld.bfd` to\n`ld.gold`.\n\nNote that gold doesn't handle weak symbol overrides properly (see\nhttps://sourceware.org/bugzilla/show_bug.cgi?id=16979[this bug report] for details).\nAs such, it cannot be used with shared objects (see below) because it'll cause\ntcmalloc's alternative malloc implementation to be ignored.\n\n=== Building Kudu with dynamic linking\n\nKudu can be built into shared objects, which, when used with ccache, can result in a\ndramatic build time improvement in the steady state. Even after a `make clean` in the build\ntree, all object files can be served from ccache. By default, `debug` and `fastdebug` will\nuse dynamic linking, while other build types will use static linking. To enable\ndynamic linking explicitly, run:\n\n[source,bash]\n----\n$ cmake -DKUDU_LINK=dynamic ../..\n----\n\nSubsequent builds will create shared objects instead of archives and use them when\nlinking the kudu binaries and unit tests. The full range of options for `KUDU_LINK` are\n`static`, `dynamic`, and `auto`. The default is `auto` and only the first letter\nmatters for the purpose of matching.\n\nNOTE: Static linking is incompatible with TSAN.\n\n\n== Developing Kudu in Eclipse\n\nEclipse can be used as an IDE for Kudu. To generate Eclipse project files, run:\n\n[source,bash]\n----\n$ mkdir -p \u003csibling directory to source tree\u003e\n$ cd \u003csibling directory to source tree\u003e\n$ rm -rf CMakeCache.txt CMakeFiles/\n$ cmake -G \"Eclipse CDT4 - Unix Makefiles\" -DCMAKE_CXX_COMPILER_ARG1=-std=c++17 \u003csource tree\u003e\n----\n\nWhen the Eclipse generator is run in a subdirectory of the source tree, the\nresulting project is incomplete. That's why it's recommended to use a directory\nthat's a sibling to the source tree. See [1] for more details.\n\nIt's critical that _CMakeCache.txt_ be removed prior to running the generator,\notherwise the extra Eclipse generator logic (the CMakeFindEclipseCDT4.make module)\nwon't run and standard system includes will be missing from the generated project.\n\nThanks to [2], the Eclipse generator ignores the `-std=c++17` definition and we must\nadd it manually on the command line via `CMAKE_CXX_COMPILER_ARG1`.\n\nBy default, the Eclipse CDT indexer will index everything under the _kudu/_\nsource tree. It tends to choke on certain complicated source files within\n_thirdparty_. In CDT 8.7.0, the indexer will generate so many errors that it'll\nexit early, causing many spurious syntax errors to be highlighted. In older\nversions of CDT, it'll spin forever.\n\nEither way, these complicated source files must be excluded from indexing. To do\nthis, right click on the project in the Project Explorer and select Properties. In\nthe dialog box, select \"C/C++ Project Paths\", select the Source tab, highlight\n\"Exclusion filter: (None)\", and click \"Edit...\". In the new dialog box, click\n\"Add Multiple...\". Select every subdirectory inside _thirdparty_ except _installed_.\nClick OK all the way out and rebuild the project index by right clicking the project\nin the Project Explorer and selecting Index -\u003e Rebuild.\n\nWith this exclusion, the only false positives (shown as \"red squigglies\") that\nCDT presents appear to be in atomicops functions (`NoBarrier_CompareAndSwap` for\nexample).\n\nAnother way to approach enormous source code indexing in Ecplise is to get rid of\nunnecessary source code in \"thirdparty/src\" directory right after building code\nand before opening project in Eclipse. You can remove all source code except\nhadoop, hive and sentry directories.\nAdditionally, if you encounter red squigglies in code editor due to\nEclipse's poor macro discovery, you may need to provide Eclipse with preprocessor\nmacros values, which it could not extract during auto-discovery.\nGo to \"Project Explorer\" -\u003e \"Properties\" -\u003e \"C/C++ General\" -\u003e\n\"Preprocessor Include Paths, Macros, etc\" -\u003e \"Entries\" tab -\u003e Language \"GNU C++\" -\u003e\nSetting Entries \"CDT User Setting Entries\" -\u003e button \"Add\"\n-\u003e choose \"Preprocessor Macro\" [3]\n\nAnother Eclipse annoyance stems from the \"[Targets]\" linked resource that Eclipse\ngenerates for each unit test. These are probably used for building within Eclipse,\nbut one side effect is that nearly every source file appears in the indexer twice:\nonce via a target and once via the raw source file. To fix this, simply delete the\n[Targets] linked resource via the Project Explorer. Doing this should have no effect\non writing code, though it may affect your ability to build from within Eclipse.\n\n1. https://cmake.org/pipermail/cmake-developers/2011-November/014153.html\n2. https://public.kitware.com/Bug/view.php?id=15102\n3. https://www.eclipse.org/community/eclipse_newsletter/2013/october/article4.php\n\n== Export Control Notice\n\nThis distribution uses cryptographic software and may be subject to export controls.\nPlease refer to docs/export_control.adoc for more information.\n","funding_links":[],"categories":["C++"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fapache%2Fkudu","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fapache%2Fkudu","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fapache%2Fkudu/lists"}