This commit moves the catboost model evaluation out of the server
process into the library-bridge binary. This serves two goals: On the
one hand, crashes / memory corruptions of the catboost library no longer
affect the server. On the other hand, we can forbid loading dynamic
libraries in the server (catboost was the last consumer of this
functionality), thus improving security.
SQL syntax:
SELECT
catboostEvaluate('/path/to/model.bin', FEAT_1, ..., FEAT_N) > 0 AS prediction,
ACTION AS target
FROM amazon_train
LIMIT 10
Required configuration:
<catboost_lib_path>/path/to/libcatboostmodel.so</catboost_lib_path>
*** Implementation Details ***
The internal protocol between the server and the library-bridge is
simple:
- HTTP GET on path "/extdict_ping":
A ping, used during the handshake to check if the library-bridge runs.
- HTTP POST on path "extdict_request"
(1) Send a "catboost_GetTreeCount" request from the server to the
bridge, containing a library path (e.g /home/user/libcatboost.so) and
a model path (e.g. /home/user/model.bin). Rirst, this unloads the
catboost library handler associated to the model path (if it was
loaded), then loads the catboost library handler associated to the
model path, then executes GetTreeCount() on the library handler and
finally sends the result back to the server. Step (1) is called once
by the server from FunctionCatBoostEvaluate::getReturnTypeImpl(). The
library path handler is unloaded in the beginning because it contains
state which may no longer be valid if the user runs
catboost("/path/to/model.bin", ...) more than once and if "model.bin"
was updated in between.
(2) Send "catboost_Evaluate" from the server to the bridge, containing
the model path and the features to run the interference on. Step (2)
is called multiple times (once per chunk) by the server from function
FunctionCatBoostEvaluate::executeImpl(). The library handler for the
given model path is expected to be already loaded by Step (1).
Fixes#27870
Fixes#39287
ClickHouse uses the same semantics for modulo on floats as Python, i.e.
4.2 % 2.0 = 0.2
and not as previously documented:
4.2 % 2.0 --> (drop decimal places) --> 4 % 2 = 0.
Fixed the documentation.
The documentation of functions
- parseDateTimeBestEffortUS(),
- parseDateTimeBestEffortUSOrNull() and
- parseDateTimeBestEffortUSOrZero()
previously repeated the text of functions
- parseDateTimeBestEffort(),
- parseDateTimeBestEffortOrNull() and
- parseDateTimeBestEffortOrZero().
In the docs of the first function, the duplication was removed and we
now emphasize the difference to the non-US version more clearly.
The docs of the second and third functions were just stripped of the
duplication. Chinese docs did not mention the US-date variants, hence
nothing was changed in them.
