Hi, 社区朋友们：

你是否觉得技术领域对你充满了无尽的挑战？

作为一名开发者, 相信大家时常在思考的问题就是如何让自己变得更优秀。如何利用自己有限的时间与精力去迭代自己的知识，学习新的东西，保持新鲜的技能。

因此，我们决定利用群众的智慧，来帮助社区的开发者们更有效地学习! 这个帖我们就用来简单聊聊大家最近都在学些什么技术、有哪些资源可以推荐给其他社区的小伙伴。 话题内容包含但不限于一本技术书籍、一篇论文、技术文章或是课程等 ，只要是干货都欢迎你分享！参与话题讨论并获得最多点赞数的前 5 位就有机会获得赠书！

活动时间： 05/26-05/31

回帖格式不限。这里提供两个模版让大家参考

回帖示例 1：

技术书籍： 《人月神话》作者：Jr. Frederick P. Brooks
适合人群： 所有人
分享原因：
这本书是作者 Brooks 在 IBM 公司任 System/360 计算机系列以及其庞大的软件系统 OS/360 项目经理时的实践经验。这本书最独特的观点是软件开发中最重要的问题在 “人” 而不是技术本身。一个大型软件少不了人与人的协作，因此怎么解决这些问题至关重要。以下经典语录截取于书中内容：

”因为软件开发本质上是一项系统工作错综复杂关系下的一种实践沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。”

“为什么要有正式的文档？首先，书面记录决策是很有必要的。只有记录下来，分歧才会明朗，矛盾才会突出。 第二，文档能够作为同其他人的沟通渠道。 最后，项目经理的文档还可以作为数据基础和检查列表。”

相关链接：https://book.douban.com/subject/4908230/

回帖示例 2：

技术文章： 手把手教你玩转 StarRocks 系列文章
分享原因： 这里有全网最全的 StarRocks 教程，多来这里翻翻，保证大家在学习和使用 StarRocks 上事半功倍！

手把手玩转1038×2775 379 KB

适合人群： 对 StarRocks 感兴趣的所有人
相关链接：https://blog.csdn.net/ult_me?spm=1000.2115.3001.5343

其他要求：

不能使用预设的用户名如 U_1652857xxxxx 参加此活动！如果你还没有修改你的用户名和头像，现在是一个很好的时机把它换掉，让社区小伙伴们可以更好地认识你！请看这里了解如何修改你的个人信息：

话题奖励：

参与话题讨论并获得最多点赞数的前 5 位就有机会获得赠书！

a0beaa2510d372a8c15b5f61bdad04511883×2562 329 KB

这本书不是要教大家如何造火箭，而是教你如何用造火箭的思维，来解决你所遇到的问题！ 3-2-1 …Lift off!

最后，如果大家发现其他人分享了不错的干货，也别吝啬帮他们点个赞！

技术书籍： 《 数据密集型应用系统设计》
作者： Martin Kleppmann
适合人群： 所有人
分享原因：
学习分布式的好书，包罗万象：数据库、缓存、消息队列、RPC；MAPREDUCE，一致性算法，流式设计等等，后面的参考文献也很有价值，关于分布式的好书太少，感觉还是要看paper啊。具体细分领域不熟悉导致部分内容理解不是很深刻，感觉以后有必要再读一遍。读完才发现现在的系统都是面向数据设计的。

全书分为三大部分：

1. 系统基石（Foundations of Data System）主要讨论有关增强数据密集型应用系统所需的若干基本原则。首先开篇第1章即瞄准目标：可靠性、可扩展性与可维护性，如何认识这些问题以及如何达成目标。第2章我们比较了多种不同的数据模型和查询语言，讨论各自的适用场景。接下来第3章主要针对存储引擎，即数据库是如何安排磁盘结构从而提高检索效率。第4章转向数据编码（序列化）方面，包括常见模式的演化历程。

2. 分散数据（Distributed Data）从单机的数据存储转向跨机器的分布式系统，这是扩展性的重要一步，但随之而来的是各种挑战。所以将依次讨论数据远程复制（第5章）、数据分区（第6章）以及事务（第7章）。接下来的第8章包括分布式系统的更多细节，以及分布式环境如何达成一致性与共识（第9章）。

3. 衍生数据（Derived Data）主要针对产生派生数据的系统，所谓派生数据主要指在异构系统中，如果无法用一个数据源来解决所有问题，那么一种自然的方式就是集成多个不同的数据库、缓存模块以及索引模块等。首先第10章以批处理开始来处理派生数据，紧接着第11章采用流式处理。第12章总结之前介绍的多种技术，并分析讨论未来构建可靠、可扩展和可维护应用系统可能的新方向或方法。
   系统基石 部分探讨了数据系统的一些通用侧面：

4. 可靠性、可扩展性、可维护性（Reliable, Scalable, and Maintainable Applications）

5. 数据模型和查询语言（Data Models and Query Languages）

6. 数据存储和检索（Storage and Retrieval）

7. 数据编码和演进（Encoding and Evolution）

分散数据 部分讨论了构建分散在多机上的数据系统和一些原则和面临的问题：

1. 冗余（replication）
2. 分片（Partition）
3. 事务（Transactions）
4. 分布式系统存在的问题（The Trouble With Distributed Systems）
5. 一致性和共识（Consistency and Consensus）

衍生数据 部分其实是在探讨分散在多机上的系统的处理问题。包括：

1. 批处理（Batch Processing）
2. 流式处理（Stream Processing）
3. 数据系统的未来（The Future of Data Systems）
   近年来流批系统趋于融合，从而让用户能够更加灵活、高效的对原始数据进行处理和变换。

这些章节拆分的都非常棒。熟读本书，让你在遇到一个新系统时，可以如庖丁解牛一般熟练拆解成为多个构件，并了每个构件背后的权衡取舍（trade off）。

以下经典语录截取于书中内容：

”For data warehouse queries that need to scan over millions of rows, a big bottleneck is the bandwidth for getting data from disk into memory. However, that is not the only bottleneck. Developers of analytical databases also worry about efficiently using the bandwidth from main memory into the CPU cache, avoiding branch mispredictions and bubbles in the CPU instruction processing pipeline, and making use of single-instruction-multi-data (SIMD) instructions in modern CPUs.
Besides reducing the volume of data that needs to be loaded from disk, columnoriented storage layouts are also good for making efficient use of CPU cycles. For example, the query engine can take a chunk of compressed column data that fits comfortably in the CPU’s L1 cache and iterate through it in a tight loop (that is, with no function calls). A CPU can execute such a loop much faster than code that requires a lot of function calls and conditions for each record that is processed. Column compression allows more rows from a column to fit in the same amount of L1 cache. Operators, such as the bitwise AND and OR described previously, can be designed to operate on such chunks of compressed column data directly. This technique is known as vectorized processing.” ——page 99

豆瓣链接：https://book.douban.com/subject/30329536/

感谢分享！ 还请你改一下系统设置的用户名和昵称，让社区小伙伴们认识你这位大佬哦～

朋友们，假日没事来写写分享吧～活动下周二就结束啦～

我书读的少，不要骗我，哈哈哈哈。

不过，最近在看一个专题博客，关于多线程和线程池的的。感觉不错，跟大家分享。

【博文推荐】

手写一款高性能的C++线程池（共5篇）：

http://www.chunel.cn/archives/cgraph-threadpool-1-introduce

【适合人群】

C++开发人员，多线程开发人员

【推荐原因】

该博客通过一个专栏（共5篇内容），介绍了设计和开发一款高性能的C++线程池的思路，优化方法，可行性分析和实际运行结果对比。并且在github上贴了源码，并附带了大量的使用demo。做到开箱即用。

第一篇：介绍了当前cpp语言对于多线程和线程池支持的缺失，并且设定了接下来的开发目标。

第二篇：介绍了通过multi-queue和work-steal技术，实现写入和消费级别加速。

第三篇：介绍了自动扩缩容，批量处理等机制，提升处理效率

第四篇：介绍了coding过程中，使用到的一些工程化技巧

第五篇：给出了简单的使用demo，并且跟github上其他cpp线程池做了性能对比，并给出数据。在文末做的一些展望工作，github上的源码，也一一实现。

通过阅读博客，可以了解到多线程编程的优化思路，和一些实践经验。作者在文末还留了联系方式，有意见和问题，可以随时交流 [手动狗头]

哇～发现一个野生 C++ 大佬，你的博客风格好有趣呀！ 感谢分享！

技术文章：42 things I learned from building a production database | mahesh’s blog

适合人群：软件开发人员/数据库开发人员

链接：https://maheshba.bitbucket.io/blog/2021/10/19/42Things.html

作者应该是Facebook Delos(Chubby/Zookeeper)的Tech Leader，分享了构建生产级别数据库的经验：如何定位产品，如何进行项目管理，如何做CodeReview以及创建良好的工程师环境。其中有这么几点对我来说特别有启发：

客户优先，多和客户沟通交流

[1] Keep your customers happy; else the rest of this document doesn’t matter.
[3] Interface directly with customer ICs. A lot of intra-team conflict can be resolved by saying “I talked to the customer just now and they said…”. In infra we often don’t need to speculate about what customers want; we can just ask them.

re-org这种事情在大公司里面非常常见，re-org下来manager会发生变化，确保项目下面的IC成果不会因为manager churn(变动?)而被埋没，这样对于IC来说不公平，更进一步地会损害到项目本身。

[10] Make your project robust to re-orgs. A company management hierarchy is inherently fragile (a tree is a 1-connected graph, after all); socialize the project continuously with managers who might take over in the future. Do whatever it takes to make sure that manager churn does not result in unfair career outcomes for ICs.

API设计要为多种实现做准备。但是这里有个悖论，Hyrum’s Law：用户最终一定会依赖某种实现。

[12] Be conservative on APIs and liberal with implementations.
[13] But insist on careful process around rolling out new implementations (shadowing, staged roll-out).
[14] When designing APIs, write code for one implementation; plan actively for the second implementation; and hope/pray that things will work for a third implementation.

抽象层次和数量要适当：抽象不够的话那么实现不够灵活；抽象太多认知负担太重。

[21] Have the right number of abstractions (this is hard). Too few and you end up with a messy monolith; too many and the team will be overwhelmed by the cognitive overhead of understanding each abstraction’s semantics.

对于关键组件，不要将发布时间看做是first priority metric, 而应该质量优先。 这些关键组件，一旦发布出去如果存在缺陷的话：a. 产品稳定性存在问题 b. 如果客户依赖这个实现，那么就需要一直维护它。

[29] For critical components, time to landing a diff is not a metric of importance: push back against impulses to measure this metric and optimize it. Create a culture where ICs are okay with diffs not landing quickly (creative endeavors – books, papers, etc. – typically involve long review cycles due to the cost of high-quality reviewing; why should code be different?).

不要和其他teams在性能或者是效率上做比赛，容易搞成类似军备竞赛的东西，花费大量时间和精力在证明比其他teams更好上，而忘记了自己项目的独特价值。

[33] Do not compete on raw performance or efficiency with other teams; this will escalate into an arms race where both teams waste time optimizing their systems for point workloads, generating apples-to-oranges comparisons, etc. Compete on fundamental design characteristics.

尝试新东西而不只是一味地复制，一味复制过来的东西通常也只是一知半解的。

[41] Try new things. Bias towards novelty within the space of feasible solutions. Fight the impulse to copy designs verbatim. Every major system was just a half-baked idea in someone’s head at some point.

感谢分享，真是太太实用，爱了爱了！

活动到今天结束～快来

技术文章： 数仓黄金价值圈: 为什么、是什么、怎么做
作者： Eric_Zhang
适合人群： 数据相关人

今天给大家一起分享下有着悠久历史的数据仓库的一些思考由三部分组成

为什么，搭建数据仓库

是什么，数据仓库定义

怎么做，如何搭建数仓

一：为什么，搭建数据仓库

最终目标： 数据驱动资源优化配置，即科学、高效和精准的决策

第一个视角是从业务视角出发，我们可以提炼为三个字为 管 ， 产 ， 运

1、管是管理，即让管理层进行科学决策【不再是屁股决定脑袋的决策】

2、产是产品，即让产品流程优化，快速迭代【不再自嗨式的闭门造车】

3、运是运营，即数据驱动业务运营策略【不再是盲人摸象式的策略】

第二个视角从技术角度出发，我们可以提炼为八个字为 降本增效 ， 清晰明了

1、降本是技术的使命，即让数据高效复用，减少重复开发

2、增效是技术的价值，即降低数据使用门槛，让数据服务无处不在

3、清晰明了是数据GPS，即清晰的管理、追踪、定位数据

把为什么想清楚了，接下来就是探讨数据仓库是什么，是否能满足以上的诉求

二、是什么，数据仓库定义

数据仓库广泛定义：数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。

随着数字化浪潮到来仅仅支撑管理决策暴露出了局限性， 应在管理决策基础上扩展到产品决策、运营决策、服务决策等等

1、面向主题【微服务、业务过程、数据域】

操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。

2、集成的【大一统、全链路】

数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

3、相对稳定的【核心业务数据】

数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

4、反映历史变化【洞察秋毫】

数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

以上是数据仓库的广泛定义，随着企业数字化转型的大浪潮中，我们需要把数据上升一个维度来看，适合当下这个万物互联的时代，我们可以总结成一句话

数据是物理世界的 镜像 ，而数据仓库是 有序 还原物理世界的一种 载体

有序 是核心，也是数据仓库的 价值所在 ，

那如何判断有序是关键，我们可以反过来想，有序的反面是无序，那我们判断无序程度，来反向证明有序度。那如何判断无序程序，不能绕过去的一个概念“熵”，它代表一个系统的混乱程度，熵增越大，代表无序程度越高。

如何对抗熵增，是数据仓库的一个重要命题， 耗散结构 是最好的方式

首先来看下耗散结构的定义

所谓耗散结构就是包含多基元 多组 分多层次 的开放系统处于远 离平衡态时在涨落的触发下从无序突变为有序而形成的一种时间，空间或时间——时空结构

再看下耗散结构的特点

1、产生耗散结构的系统都包含有大量的系统基元甚至多层次的组分

2、产生耗散结构的系统必须是开放系统，必定同外界进行着物质与能量的交换

3、产生耗散结构的系统必须处于远离平衡的状态

以上特点也是数据仓库的特点，所以好的数据仓库一定是耗散结构的

多层次，开放，一直被构建ing

三、怎么做，如何搭建数仓

建设思路

如何搭建数仓，在业界一直存在着两种思路

从顶到下

从顶到下，即从点到面，到面面俱到

从低到上

从低到上，即面面俱到，到各个击破

数仓分层

不管是哪一种，都逃脱不了以下的常用分层架构

• ODS:操作型数据(Operational Data Store)，指结构与源系统基本保持一致的增量或者全量数据。作为DW数据的一个数据准备区，同时又承担基础数据记录历史变化，之所以保留原始数据和线上原始数据保持一致，方便后期数据核对需要。
• CDM：通用数据模型，又称为数据中间层(Common Data Model)，包含DWD、DWS、DIM层。
• DWD：数据仓库明细层数据(Data Warehouse Detail)。对ODS层数据进行清洗转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，基于维度建模思想，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理，构建明细宽表。
• DWS：数据仓库汇总层数据(Data Warehouse Summary)，基于指标需求，构建初步汇总事实表，一般是宽表。基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标。
• DIM：建立一致数据分析维表，可以降低数据计算口径不统一的风险，同时可以方便进行交叉探查。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。
• DM/ADS：面向应用的数据服务层(Application Data Service)。整合汇总成分析某一个主题域的服务数据，面向应用逻辑的数据加工。该层主要存放数据产品个性化的统计指标数据，这一层的数据直接对接数据的消费者，是产品、运营等角色可以直接感知理解的一层，大多数这一层的表都可以直接在BI上通过图表的形式直接透出。

建设过程

在建设过程中，我们总结出了三段论， 分别为

还原论

整体论

系统论

我们来依次来解释下，三论的定义

还原论

还原论的定义:是一种哲学思想，认为复杂的系统、事务、现象可以通过将其化解为各部分之组合的方法，加以理解和描述。

把还原论映射到数据仓库，ODS层操作型数据(Operational Data Store)与DWD明细层数据(Data Warehouse Detail)，是还原论的的载体

通过数据还原物理世界的过程中，包含 数据还原与数据重组

ODS的建设思路是:

与线上数据源保持一致，还原业务，长期存储

DWD的建设思路是:

数据规范统一 【表名、字段名、枚举值等等】

还原业务过程 【提炼核心业务环节，确定实体】

屏蔽业务变更 【屏蔽业务复杂过程，类似于Java的封装】

重组数据明细 【明细级宽表，同数据域不同业务过程】

明细级的数据模式一般有以下数据组成

谁 ，在 哪 ，什么 时间 ，用什么 方式 ，在 做什么 事情

在DWD这一层主要提炼出业务核心业务过程，识别每一业务过程的实体及实体与实体这件的关系，基于每个具体的业务过程特点，构建最细粒度的明细事实表。

随着软件行业 微服务架构 成为一种常用架构，微服务有 松耦合 与 去中心化 的特点，这样的架构模式更加符合大规模复杂系统协作，提高整体研发效能，但如果站在数据视角去看，数据是 分散的 ， 割裂的 ， 不一致的 ，这就对数据建设提出了更好的要求，可以结合公司的数据使用特点，基于维度建模思想，将明细事实表进行 数据重组 ，把微服务架构引起的数据特点，进行同一业务过程不同事实表进行 融合 ，把同一业务过程的关键属性字段做适当冗余，即宽表化处理，构建 明细宽表 。

在还原业务过程过程中，需要对具体表进行如下数据剖析，对数据内容要了然于胸

1、业务场景【产品随时间串行的流程，例如授信、支用、还款、催收等等】

2、数据表粒度【实体主键、如何判断唯一一条记录】

3、数据生产方式【场景下增删改查】

4、关键字段状态【status，type】

5、注意事项

整体论

整体论:这种哲学认为，将系统打碎成为它的组成部分的做法是受限制的，对于高度复杂的系统，这种做法就行不通，因此我们应该以整体的系统论观点来考察事物

把整体论映射到数据仓库，包含 数据汇聚与全局数据 DWS：数据仓库汇总层数据(Data Warehouse Summary) DIM：数据仓库为表层（Dimension）

DWS的建设思路是:

确定分析实体 【用户、用户&产品、用户&渠道等等】

圈定实体维度 【时间、地点等等】

串联业务过程 【授信、支用、还款等等】

封装指标口径 【授信次数，支用金额，还款金额、贷余】

在DWS这一层主要汇聚串联业务核心业务过程，站在业务 全链路 的视角构建不同粒度的汇总事实表，以满足不同场景下的主题分析场景，用少量的汇总表支撑常见的分析场景，理想情况是用20%的表，支撑80%的分析场景。

DIM的建设思路：

全局唯一

纵横扩展

自动更新

在DIM这一层主要保证数据仓库 一致性维度 ，保证数据一致性。

系统论

系统论的定义:主要任务就是以系统为对象，从整体出发来研究系统整体和组成系统整体各要素的相互关系，从本质上说明其结构、功能、行为和动态，以把握系统整体，达到最优的目标

把系统论映射到数据仓库，包含 决策数据与系统最优

DM/ADS：面向应用的数据服务层(Application Data Service)

系统最优: 耗散结构式数仓 ，即数据治理

ADS建设思路

报表体系 【全链路指标体系】

自助服务 【自助式数据服务，例如托拉拽式OLAP】

回流业务 【数据回流业务生产系统】

数据治理建设思路：

数仓热度【下冷、中温、上热】

成本治理【有进有出，数据流动】

质量保障【端到端的稽核】

没想到 start with why 的思维也可以套用到大数据技术上。今天又学到了宝贵的一课！感谢你的分享～

亲，我私信你啦～请你回复我一下！ 3Q

恭喜获得书籍一本，请你私信与我联系～ 3Q