For beginners, the default configurations of the Kafka broker are good enough, but for production-level setup, one must understand each configuration. I am going to explain some of these configurations.
broker.id: The ID of the broker instance in a cluster.
zookeeper.connect: The ZooKeeper address (can list multiple addresses comma-separated for the ZooKeeper cluster). Example:
zookeeper.connection.timeout.ms: Time to wait before going down if, for some reason, the broker is not able to connect.
Read the whole thing.
Akhil Vijayan has a two-parter on serializing data in Scala. In the first post, he looks at uPickle:
uPickle serializer is a lightweight Json library for scala. uPickle is built on top of uJson which are used for easy manipulation of json without the need of converting it to a scala case class. We can even use uJson as standalone too. In this blog, I will focus only on uPickle library.
Note: uPickle does not support Scala 2.10; only 2.11 and 2.12 are supported
uPickle (pronounced micro-pickle) is a lightweight JSON serialization library which is fast than many other json serializers. I will talk more about the comparison of different serializers in my next blog. This blog will cover all the basic stuff about uPickle.
In my previous blog, I talked about how uPickle works. Now I will be comparing it will many other json serializers where I will be serializing and deserializing scala case class.
Before that let me discuss all the json serializers that I have used in my comparison. I will compare uPickle with PlayJson, Circe and Argonaut.
Check it out.
I recently read a very popular article entitled 5 Reasons “Logistic Regression” should be the first thing you learn when becoming a Data Scientist. Here I provide my opinion on why this should no be the case.
It is nice to have logistic regression on your resume, as many jobs request it, especially in some fields such as biostatistics. And if you learned the details during your college classes, good for you. However, for a beginner, this is not the first thing you should learn. In my career, being an isolated statistician (working with marketing guys, sales people, or engineers) in many of my roles, I had the flexibility to choose which tools and methodology to use. Many practitioners today are in a similar environment. If you are a beginner, chances are that you would use logistic regression as a black-box tool with little understanding about how it works: a recipe for disaster.
Read on for his reasons. I’m not totally convinced, but he does lay out his argument clearly.
One of the fundamental requirements of GDPR is the Right to Retrieve Personal Data.
With Lenses SQL the above requirement can be covered via a set of simple but thorough queries into the topics that contain PII data:SELECT * from topicA WHERE customer.id = "XXX"
Lenses will retrieve and deserialize the data from a binary format (i.e. Avro) into a human-readable format and provide full Control Execution.
Control Execution brings into context the fact that streaming SQL is operating on un-bounded streams of events: A query would normally be a never-ending query. In order to bring query termination schemantics into Apache Kafka we introduced 4 controls:
LIMIT 10000 – Force the query to terminate when 10,000 records are matched
max.bytes = 20000000 – Force the query to terminate once 20 MBytes have been retrieved
max.time = 60000 – Force the query to terminate after 60 seconds
max.zero.polls = 8 – Force the query to terminate after 8 consecutive polls are empty, indicating we have exhausted a topic
GDPR implementation is a lot trickier for a system like Kafka, but it’s still possible.
One of the many exciting announcements made at MSBuild recently was the release of the new Cosmos DB Bulk Executor library that offers massive performance improvements when loading large amounts of data to Cosmos DB (see https://docs.microsoft.com/en-us/azure/cosmos-db/bulk-executor-overview for details on how it works). A project I’ve worked on involved copying large amounts of data to Cosmos DB using ADF and we observed that the current Cosmos DB connector doesn’t always make full use of the provisioned RU/s so I am keen to see what the new library can offer and look to see if our clients can take advantage of these improvements.
In this post I will be doing a comparison between the performance of the Cosmos DB connector in ADF V1, ADF V2 and an app written in C# using the Bulk Executor library. As mentioned in the Microsoft announcement, the new library has already been integrated into a new version of the Cosmos DB connector for ADF V2 so the tests using ADF V2 are also using the Bulk Executor library.
There are some significant performance improvements from using this bulk loader, as Ben shows.
We have tidy data, both because that’s what I get when querying our databases and because it is useful for exploratory data analysis when preparing for a machine learning algorithm like PCA. To implement PCA, we need a matrix, and in this case a sparse matrix makes most sense. Most developers do not visit most technologies so there are lots of zeroes in our matrix. The tidytext package has a function
cast_sparse()that takes tidy data and casts it to a sparse matrix.
sparse_tag_matrix <- tag_percents %>% tidytext::cast_sparse(User, Tag, Value)
Several of the implementations for PCA in R are not sparse matrix aware, such as
prcomp(); the first thing it will do is coerce the BEAUTIFUL SPARSE MATRIX you just made into a regular matrix, and then you will be sitting there for one zillion years with no RAM left. (That is a precise and accurate estimate from my benchmarking, obviously.) One option that does take advantage of sparse matrices is the irlba package.
This is a great walkthrough of an important topic.
The SQL language offers the following types of JOIN:
- INNER JOIN
- OUTER JOIN
- CROSS JOIN
The result of a JOIN does not depends on the presence of a relationship in the data model. You can use any column of a table in a JOIN condition.
In DAX there are two ways you can obtain a JOIN behavior. First, you can leverage existing relationships in the data model in order to query data included in different tables, just as you wrote the corresponding JOIN conditions in the DAX query. Second, you can write DAX expressions producing a result equivalent to certain types of JOIN. In any case, not all the JOIN operations available in SQL are supported in DAX.
Read on for several examples.
To get the latest release you will need to run
1 Update-Module dbachecks
You should do this regularly as we release new improvements frequently.
We have also added better descriptions for the checks which was suggested by the same person who inspired the previous improvement I blogged about here
Click through for more details.