请将这 9 大类数据业务,牢记在心中

在大数据行业,经常把数据比作石油。长远来看,数据的战略价值不亚于石油,人工智能时代来临之后,相信每个人都能感受到这一点。

石油作为能源物资,尚有部分替代品;而数据,几乎意味着未来数字世界的生存规则。人类生老病死、衣食住行、工作消费、政治文化经济生活等活动都将被数据影响和控制,说统治也不为过。

把数据比作石油,还因为它们有相似的价值提炼过程。

石油从最初原油经过加工,提炼出汽油、柴油,进而合成塑料、橡胶等产品。

数据由原始的形态,经过加工,也会像石油一样有广泛的用途。

但并不是每个人都能说清楚数据能用来做什么,产生什么价值,大部分人可能只有一个模糊的印象。我想通过本文,使大家对大数据的典型应用有更进一步的了解。

1、主数据

狭义的主数据是指多个系统中高度复用的那类数据。当同一个数据在多个系统中存在的时候,主数据的问题就产生了。

举个例子,你收到了本月的工资,银行卡会有一条入账记录。同时,你又有记账的良好习惯,需要在记账软件中手动把工资收入的数字记录进去(除非你不怕隐私泄露,将银行卡交易信息授权给记账软件使用),完成两个数据的同步。如果记错了,很可能这个月的账对不上。这就是主数据的典型问题。银行卡交易数据,对个人来说就是主数据。

主数据是个人和组织价值较高的稳定数据。在多个系统中存在,也体现了它的重要性,所以它还被称为黄金数据。

最早的主数据问题,首先在企业中产生。一家公司,会有很多业务系统,比如 OA 办公系统、财务系统、CRM 客户管理系统、ERP 进销存系统等,如果是一家大型的集团公司,每个子公司同类业务的系统也可能不同。这就造成了同类数据如员工、供应商、客户等,在各个系统中不同步,这会造成业务延迟,甚至统计出错。

主数据本质是拥有数据的主体,保有一致性数据的问题。

个人、公司、政府都会受到这个问题的挑战。常说的数据孤岛,一方面是讲数据锁定在局部,不发生流通,另一方面,是讲同一份数据,不能保持一致性。

主数据的概念出现的非常早,大约 20 年前,IBM 就提出了概念、问题和方法。直到今天,这个问题也解决的不是十分完美。这里面的问题非常多,最重要的有几点:

  • 如何确定是同一个数据?
  • 数据以哪个系统为准(具体到字段级别)?
  • 如何及时同步给其它系统,遇到冲突怎么办?

政务数据共享交换开放,从广义上讲,也属于主数据的范畴,属于国家对政府各部门所拥有的高价值数据的定义、识别与分发。

在日常生活中,我们都已经享受到国家持续解决这个问题所带来的红利。比如异地检车、一网通办等各类便民业务。

在主数据应用领域中,更重要的是数据技术。如使用统一标识(One ID)技术去定位唯一数据,变化数据捕捉(CDC)技术及时发现变动的数据,数据同步技术完成数据的分发等。

2、搜索

这里主要是指全文检索

首先谈谈大家日常使用频率最高的大数据应用——搜索引擎。

百度的网络蜘蛛在全网抓取网页内容,将爬取的网页快照存储在自己的服务器上。毫无疑问,这是真正的大数据。

为了给用户返回精确的结果,接下来还有两件事情。首先是关键词和网页的匹配,其次是搜索结果的排序。

网页的内容,通过分词的手段,将内容打散,判断各词汇的密度,大体猜测出这篇内容讲得是哪方面的内容。这是传统搜索引擎主要做的工作,现代则应用了更多 NLP(自然语言处理)的技术,使程序“阅读”文本内容后“总结中心思想”更为精确。这里主要解决搜得准。

关键词和相关网页建立联系,就是索引,技术上也通过索引的优化,使得搜索结果能在毫秒级返回,这里很考验技术,既需要考虑相同关键词的索引数据尽可能分区集中,避免跨节点的读取延时,又需要考虑多并发(每天几十亿次查询)随机读的性能。这里主要解决搜得快。

搜索引擎另一大核心任务是对结果排序,按关键词密度给网页确定权重的方式,相对低级,内容生成者也容易作弊。排序本质是结果的精确度和内容价值的权重计算。如何靠机器判断内容的价值高低?Google 创建 PR 算法的假设是一个网页被其它网页引用的次数越多,该网页价值就越大,类似于评估论文的重要性的方法是统计它被引用的次数;另外也可以根据结果列表被点击的间隔时间来判断,如果第一个结果条目被点击后,很多人都又很快点击第二个条目,表明第一个结果质量不太高,并不是用户所需要的,系统就会逐步降低第一个条目的权重。类似的判断逻辑会有很多。

搜索引擎也在向个性化搜索结果的方向演进,判断用户的特征,呈现不一样的搜索结果。

明白了搜索引擎的原理,就很容易理解另一种大数据应用——舆情监控系统。可以理解为将有限数量的关键词的搜索结果自动汇总,再按情感聚类,最简单按正面的、负面的聚类,按负面的级别向用户告警。

除此之外,如法律文书的检索,或其它海量文本的检索,底层都是全文检索的技术引擎。著名的大数据组件 Elasticsearch 正是为此而生。

以提交关键词的方式,从海量文本中精确命中结果,是大数据的第二大类应用。

3、查询

这里主要指即席查询(Ad Hoc),又称为交互式查询。

提到交互式,程序员比较容易理解这个词,在命令行终端里,输入命令或程序语句,回车后系统马上能返回结果,这称为交互式环境。Node.js、Python 都提供了这样的交互式编程环境。

即席查询也是同样的道理,用户在界面上选择查询的条件、范围,或输入 SQL 语句,提交后立即可以获得查询结果。

和上面第二类全文检索核心不同之处在于查询所输入的内容不同,一种是灵活的文本关键词,另一种可以理解为 SQL 语句。理论上来讲,即席查询的数据比全文检索数据结构化程度更深,查询的命令也更为精确,相对更为容易。

但真的更容易吗?在数据量小的情况下,确实很容易,如果是单库单表查询,即使再复杂的SQL,加上比较耗性能的去重计数 count(distinct) 类的统计,也会在很短时间内获得正确的结果。

但是大数据量的情况就不同了。首先,数据量可能会大到用普通关系型数据库分表的方式都没办法存储,只能存在大数据库中,以前的文章中提到,NoSQL 的列式数据库适合存储大数据,如 HBase,这类数据库对 SQL 支持并不如关系型数据库那么良好。其次,复杂 SQL 语句或特定 SQL 语法在这类数据库里执行效率非常差,可能数十分钟,甚至小时级才能返回结果,或者干脆查不出来。

这就与即席查询的理念不符。用户所面临的问题是,查询所需的基础数据都已存储在物理数据库里,但查询耗时太长,不能满足查询时效的要求。

为了解决这个问题,诞生了很多即席查询的引擎。如 Impala、Presto、Druid、Doris、ClickHouse 等。

它们的技术原理也很简单,比如增加热点数据的缓存、优化数据分区、预计算、内存计算、并行计算等,达到加快获得查询结果的目的。

4、分析

这里主要指多维分析,即 OLAP。数据分析可以说是最常见、最直接的数据业务,我们每个人或多或少地做过一些数据分析的工作。

基于统计学的数据分析,核心就是确定维度、指标、度量。多维分析,强调的是分析的灵活性。

从维度的角度来说,不同类型的维度值,有稳定不变的、缓慢增长的、急剧变化的;维度的层级和粒度,可以向上汇总、向下细分,即术语所说的上卷、下钻;从维度度量的组合、裁剪来说,借助数据立方体的模型,可以有切片、切块、旋转等操作。

度量,常见是那些聚合操作,求和、最小值、最大值、平均值、总数等。

指标,如人口数量、销量、及格率等,有的是数据库表中的一个已有的字段,称为原子指标,意思是不可再拆分,利用原子指标再计算得到的指标,称为派生指标。

数据分析,就是在玩维度、指标和度量,核心工作在于构建这三者组成的数据模型。

很多人分不清即席查询和多维分析的区别。多维分析始终围绕着数据建模,原始数据为了适应新模型,需要有数据融合、多表关联、指标定义加工等工作;即席查询,更多是通过查询获得一个值、一条数据或一批数据。在数据规模大的情况下,多维分析同样存在像即席查询的性能问题。

出于建模的需要,OLAP 常常和数据仓库紧密衔接。数据仓库的明细层、汇总层、公共维表层等,经常是为了 OLAP 的分析目标去构建模型。

现在常说的智能数据分析,是提取数据集里数据的特征,判断其连续性,偏离散的,自动识别为维度,偏连续的,识别为度量。自动生成事实表,再智能挑选合适的图表类型(折线图、柱状图、饼图等)表现出来。

5、可视化

数据可视化,也是较常见的数据业务。通过图表的方式,可更直观地表达数据的含义和数据之间的关系。分为 BI 可视化和大屏。

这里的 BI,是狭义的 BI,主要是指借助 BI 工具,去完成数据的可视化表达。更广义的 BI,是通过数据挖掘产生商业智能决策的依据,可进行规律探索、趋势发现和商业洞察。

一个好用的 BI 工具,支持快速选择和拖动维度和度量字段,生成恰当的数据透视表。可灵活地完成多维分析中提到的维度、度量、指标三者的定义和转换等。

现在某些厂商的 BI 产品,已经向着智能问答式的交互方向发展,对着系统说出分析的需求,如“某地区产品销量环比”,系统就能自动从相关数据集中获取维度与度量,智能生成透视表。

大屏,也是近年来较常见的数据需求,基于统计分析和监控告警的仪表盘(DashBoard)和领导驾驶舱,如天猫双十一销售统计大屏。

政府机构对大屏有比较广泛的需求,原因是数据大屏是展示数据建设工程成果比较好的方式。

为了快速生成大屏,也有相应的产品支撑,如阿里云的 DataV。这种产品可以自由地设定画布大小,灵活布局。可视化组件拖放到画布上,设置好所连接的数据源和更新频率,即可直接查询数据库或通过 API 请求所需数据。用户可以在很短时间内,配置出非常炫的大屏。

6、画像

我们常听到的用户画像,是从用户数据中提取用户特征,包含生理、社会属性,以及行为习惯的特征,以此精细刻画用户——甚至比他对自己的了解更深入。另外也可以根据相同的特征选取同一用户群体——这个操作称为用户圈层,接下来就可以针对性地对这类用户实施影响策略。

实际上,不只用户可以画像,一切实体均可画像。

画像背后的核心,是一套标签体系。标签可以是人工或程序产生。给数据打标签,有的简单,经过常规计算就能完成,有的则需要机器学习算法参与。

人工参与打部分标签,类似监督学习;无人干预,类似于无监督学习,算法自动找出数据规律,贴上正确的标签。

比如,出生地、80 后这种标签,根据字段值就能直接获得,有些则需要经过简单的计算。

另外一些就比较复杂。比如人的自然性别只有男女两种,购物性别则不然,男性在购买特定品类也会呈现出不同程度的女性心理,反之亦然,所以,淘宝的购物性别标签,据说有近 20 种。

这样一来,在导购设计、商品推荐和活动运营中,对不同品类和用户就可以有不同的策略设计。

7、广告

营销领域中,广告主最在意的就是效果和成本。为了服务好广告主,广告平台通过大数据不断优化广告内容、渠道和人群的匹配,实现效果营销和精准投放的目的。

这是三赢的局面,平台推送给用户的广告精准,一方面广告主高投入产出比达到了营销目的,也就更愿意选择这样优质的平台,另一方面,用户也不会受到太大的干扰。

精准投放和上面的画像应用密切相关,除此以外还包含更多的分析应用。

首先在投放层面需要有基础数据,包括用户画像、广告物料画像、渠道画像、三者的关联数据和生命周期数据等,算法不断调整它们的匹配度,给出投放建议。

在效果评估层面,有到达、转化的漏斗模型统计分析。这里有基于埋点日志的实时统计分析方法,去统计曝光率、事件交互等。

日志分析也是大数据的重要细分领域之一,有专门的大数据组件完成日志的采集,如 Flume、LogStash。配合实时计算引擎,如 Flink,完成一些实时分析统计。

至于我们搜索后在其它产品中出现相关广告,或者说过一句话,就在某产品中就出现了应答广告。原因是在技术上,系统确定了我们的唯一用户身份,并通过广告联盟平台进行了数据共享。

很多网站和应用上出现的广告,并不是它自身投放的。它作为一个流量主,注册成为了广告平台上的一个渠道。当广告平台获取到你的用户身份和行为,它就能把匹配到的广告投放到能触达你的每一个渠道。

如你在百度上完成了一次搜索,百度的广告平台就能获取到你的用户标识和搜索关键词,把匹配好的广告,自动投放到你使用的其它应用上,这样你就感觉在一段时间里,相同的广告包围了你。

APP 偷听也是同样的道理,某个 APP 获得手机麦克风的使用权限,如果它不尊重用户隐私,就会滥用权限,就可能把它匹配出来的广告通过广告联盟分发到其它 APP 上。

大部分 APP 还会读取剪贴板,获取我们复制的内容,用于广告或其它目的。目前大部分移动操作系统还都没有对剪贴板的权限进行管控。

8、风控

在工业和金融领域,对风控有很高的要求。需要基于规则模型处理大量数据,且实时性非常强。

工业方面,主要有设备故障监测告警、预警。在传感器产生的时序数据中,要能及时地发现异常波动,包含频率、周期的异常及其它离群值高的数据,结合上下游设备和环境的数据,定位风险,实时暴露。

金融安全方面,有针对贷款业务的征信数据分析,也有对异常交易行为的快速处置。如发生一笔信用卡刷卡业务,产生了一条交易数据,会立即触发上百条规则去校验是否存在盗刷、套现等恶意行为。这些规则包含对商户、POS 机、持卡人、交易额度、时间、频率非常多交叉的判断。

除此以外,谋求黑产利益的羊毛党,对电商、O2O 业务也存在很大的挑战,商品限购、代金券优惠券发放的业务,都存在被刷的风险。除了在业务代码逻辑上防范这些风险,还要有基于数据实时分析的风控保障,疑似恶意的行为被及时感知并告警。误报、漏报之间的平衡,是技术细节的难点。

风控模型和规则引擎,是大数据风控业务的核心技术。

9、推荐

我们的生活已经被算法推荐包围了。拥有头条、抖音现象级产品的字节跳动公司的估值,也已超过了百度的市值。

推荐是大数据应用很重要的一个方向,目前已成效显著。可分为信息流推荐和商品推荐。

信息流推荐就是新闻、视频等内容推荐。根据我们点击、查看的记录,系统会不断学习识别我们的偏好,把相似内容不断地推送到眼前,让我们沉浸其中。

商品推荐一方面是根据我们的行为,如搜索、浏览、收藏、加购物车等进行推荐,另一方面是推荐同一类型画像用户购买的商品,这样会提高用户的下单率。

“千人千面”是这一业务的核心挑战,想想看,亿级用户个性化的推荐清单,都要随着用户行为变化而更新和排序,还要把已购商品从清单中去除,光是这项工作,就非常复杂了。

总结

立足于数据本身所能做的事情,我们总结出上述九大类业务。如果将数据和 AI 人工智能算法结合,数据作为燃料,算法作为引擎,还能展开更多的智能化业务,就不在本文的讨论范围内了。

可以说,这九大类的数据业务,足以涵盖目前及未来几年内的数据业务需求,数据产品经理可牢记心中。我们设想数据能发挥什么价值时,可以从这九类里寻找答案,获得启发。

这九大类数据业务,从上到下依次是从传统到现代、从离线到实时的变化特点,每个类别重点所需的大数据处理技术也不相同,有的重数据集成,有的重数据治理,有的重数据计算,越靠后的业务对大数据实时计算的要求越高。

在以后的文章中,我们逐步来了解每一项技术。

以上是「关耳爷」对大数据业务的一点小总结,请笑纳。

让合适的人有意愿去做正确的事

过去在大公司、小公司、自己创业的各个阶段中,我都总结过一些管理的感悟。

“让有能力的人有意愿去做他擅长的事”,是我过去对管理的一句话总结。

现在改为了:“让合适的人有意愿去做正确的事。”

理论层面,我认为这句话可能稍稍探触到管理的本质。

找到合适的人或培养出合适的人

识人、用人是管理的关键动作。过去我对识人的理解,是识别出有能力的人。

虽然可以勉强说某人有能力等同于他适合干这件事,但不如改为“合适的人”更为准确。

有能力,单方面强调了人的因素;合适,强调了人和事物之间的联系。

你认可某人的某种能力,未必和你要办的事相匹配,一方面是大材小用或小材大用,另一方面可能是牛唇不对马嘴,你以为他的能力可以跨界无缝迁移。

大小不等比,会造成资源浪费或心有不甘,任何一方心有不甘,迟早会分崩离析。

一个人某方面的能力不代表他全部的能力,我们常常笼统地看一个人,打上行或不行的标签,不能细分其能力维度。

识别和选用“合适的人”,首先得过一个心理关,需排除掉道德上的洁癖,把人选范围扩宽,包括那些“鸡鸣狗盗之徒”。

这与德才兼备、德优于才的传统管理观念相违背。

纵观历史,数不清的案例都显示了能成事的人,用人不拘一格,凡有价值皆可重用,管你是馋臣酷吏还是织席贩履、屠猪卖酒之辈。

很多人在这一关上过不去。

其次,对于合适与否,是个非常主观的判断。大部分时候,不合己意,我们就认为这个人不合适。

这种现象在企业面试招聘中很常见。能不能招到合适的人取决于面试官的认知能力,而一般公司很少进行系统的面试培训,所以面试官只能凭感觉来。

如果面对三观不合或其它阵营的人,还能清醒地知道他是担当某职最适合的人,那就有相当高的管理水平了,毕竟这很反人性。

拿今年高考作文中提到的齐桓公和管仲来说,齐桓公差点被对方阵营的管仲一箭射死,但即位后还是重用了管仲,终成一代霸业,成为了“春秋五霸”之首。

还有比“杀身之仇”更大的仇吗?能抛开这种仇恨而去用人,成就大业也就不奇怪了。

现实中往往是因为一点小事不合己意,就把最适合的人搞了下去。

合适的人,不容易找到,所以培养出合适的人,也是管理中非常重要的工作。诸葛亮在这方面做的比较差劲,没有做好梯队建设,导致在他死后蜀国几乎无人可用。

现在的社会节奏,大家对于培养没有太多耐心。大一些的公司重视管理,有管培生培养体系,形成了获得管理人才的制度。

从人际互动关系角度讲,现在培养一个人的动力实在是太过缺乏。陌生社会系统下建立长期互利互惠关系的必要性不大,只有传统社会流动性差,人与人之间有一定的依附效应,才会有师徒如父子的美德。

你看郭德纲师徒的一系列风波,就是这个道理。毕竟时代不同了。

如果能遇到一个培养自己的老大,那一定得珍惜这样的贵人,忽略他可能存在的培养形式上的粗暴,或者是其它不合己意的行为。强调这句话,是因为现在的人一般都受不了批评呀。

从几率上说,能遇到 100 个职场 PUA,也遇不到 1 个有培养意愿的上级。所以,遇到要珍惜。

能遇到一个愿意分享的人,也一定要和他做好朋友。

有意愿做事

驱动一个人发挥出主观能动性,比上面的要求更难。

一个人有强烈的意愿去做事时,就会穷尽的他的资源和能力,他可能不是最适合的人选,但结果也不会太差。

能不能找到合适的人,有时候得看运气;而能不能激发出一个人的意愿和动力,完全看本事,是对人性的把握,所以后者更重要,也更难。

管理学教材上,用的更频繁的词是“激励”,我更愿意用“驱动”。

激励更多是外部的引诱,外部的力量引导,而驱动是作用于内在的一种力量。

大的方面讲,人性的恐惧和贪婪,产生做事意愿和行动力。俗话说的胡萝卜加大棒。

细分来说,恐惧包含人对失业的不安全感、对外界负面评价和不被认同的恐惧、对受批评处罚的担心、对不能成功的忧虑等。每个个体所能承受的方面和程度是不同的。

现代企业中,想通过令人恐惧的方式达到管理的目的,很难。

遗憾的是有些管理者还在这个领域中做着不懈努力。

贪婪,唯名利二字。激发一个人意愿最粗暴有效的办法就是地位和金钱,有人误用成了画大饼。

其实很简单,提出目标,公开达成目标后的悬赏,最后兑现

悬赏可以是晋升涨薪,或发奖金。涨薪是长期的成本,只能让人开心一次,发奖金很多时候效果更明显,一直发奖一直爽,投入产出比更高。

关键有两点,一是公开目标和奖惩,很多公司都做不到这一点,员工不知道努力的方向和意义,长期下去就会懈怠;二是兑现,不兑现可不就是画大饼么。

像互联网各大厂,就有明文规定的岗位级别、头衔以及打包价,述职通过,升了一个级别,那一年多收入多少都心里有数;相反,连续获得了类似于阿里 3.25 的低绩效,那也意味着打包走人。

有的公司没有这样完善的制度,承诺每年涨薪一次,到期不兑现,请问员工有啥激情?

想让别人有动力,除了赤裸裸地拿钱说话,管理者还要有识别下属诉求的意识,并且准确给予反馈。这一点在没资源分配的情况下更为重要。

很多没经验的管理者都是从自己的角度出发去做管理。认为分解任务、监督过程、优化交付结果就是日常管理工作,充其量是主管级别吧。

真正管理的日常工作就是识别别人的诉求,考虑他所处的阶段,了解他的优缺点,发现他关注和回避哪一方面,让他无顾虑、有动力地做事,获得好的结果。

升职加薪每个人都高兴,但不可能频繁发生,就需要用别的方法。

有的人自尊心非常强,就要经常给予尊重;有的人非常敏感,就得时常安慰和鼓励,毛主席也为信心不足的林彪写过《星星之火可以燎原》。

有的人希望在工作中获得学习进步的空间;

有的人希望多做一些具体工作提升经验;

有人观念是家庭和工作并重,希望干好份内的事即可;

有人对干成一件事获得大的成就感尤为关注;

有的人关注协作氛围,希望做事开心;

有人希望自己的老大有大格局,能带自己上升一个新台阶……

每个人都有所图,管理要因人而异。

《素书》中有言:德者,人之所得,使万物各得其所欲。

意思是,“有德”的人,就是能让他人获得想要的东西的人,想升官发财的能让他们升官发财,想改变世界的能让他们改变世界……

知道“以德服人”有多难了吧?

管理之所以累,就表现在这些方面。你要指明方向,用愿景情怀感召别人,设计出激励制度,创造让人学习进步的空间,营造良性的氛围。从而,驱动出他人做事的意愿。

没有品牌和金钱招揽人才的时候,就需要用人格魅力和情怀来团结众人,经常性地激励士气。

让我印象深刻的是阿里之前放出的一个短视频,展示了阿里的发展历史,短短的视频里出现了很多形式的庆功场面,舞狮、开联欢会……领导和员工打成一片,从表情和神态上能看出每个人都释放了真我,一次可能是摆拍,不可能每次都是摆拍。由此可见,他们对于胜利的享受是实实在在的,在这样的集体中,你能不被焕发出热情吗?

即使没有这些行动,只要你能表达出你理解到他的诉求,管理也已经成功了一半。

反过来说,作为被管理的人来说,如何让管理者有意愿去了解你的诉求,也是值得思考的问题。

死活就是不愿意了解你的诉求,装聋作哑看不见听不见,听见了假装听不懂的,建议换地儿,世界那么大,竞争对手那么多。

韩信也是从项羽公司跳槽到了刘邦公司的。

做正确的事

这个是对领导力更高的要求。合适的人有了做事的动力,基本就能保证用正确的方式做事了。

而做正确的事,取决于战略选择能力。

如果智商够高(高到马斯克这种的),独断专行就够了,真理掌握在少数人手里。

如果没有超群的智商——有没有自己心里应该有数,但有着清醒判断的人好像不多,那需要做到下面两点:

一是信息要能支撑得起决策,收集的资料一定要全面、动态,至少要知己知彼。

二是广泛听取意见,尤其是不同的声音。三个臭皮匠顶个诸葛亮。

是发自内心地兼听,不是做做样子。

很难,大部分人都有刚愎自用,一意孤行的倾向,尤其是有人反对的时候。

关于做正确的事就说这么多。

还有半句话

“让合适的人有意愿去做正确的事。”并不是一句完整的话。

完整的是:“在自己的掌控范围内,让合适的人有意愿去做正确的事。”

这涉及到风险管理意识和权谋。

从权谋角度讲,如果没有这半句,前面说的都是在做公益。

朱元璋用朱文正,刘邦用韩信,曹操用司马懿,诸葛亮用魏延,都是一边重用,一边防控,全在自己的掌握之内。

政治家判断一个人无法掌控,或荐举收买人情、形成联盟,或在羽翼未丰之前干掉。

做管理难免不涉及权谋,因为地位之争是零和博弈,一个位置被占据了,其他人就无法占有同样的位置。

而地位又是权力的载体,权力是贯彻意志的必要条件。

但权谋不是目的,中层和基层更不应该把分权制衡、降低效率的权谋手段作为管理方法。

一般情况下职场上升不到像政治斗争那样零和博弈的境况,到不了你死我活的地步,可以找出第三种选择,达到共赢的局面。

这需要冷静、理智的头脑,冲动、不能隐忍的人是不行的。

所谓的风险管理意识,除了权谋对抗的风险以外,还要对一切可能导致失败的因素保有警惕心理。

比如单点故障问题,不管是有人主观上撂挑子,还是客观上的离职,都应该有相应的冗余备份机制。

比如各种系统性风险,需提前梳理出各种情况提早做预案,甚至需要演练。

管理是一门实践的学问,懂得和做到无法等同,就像开车一样,必须在实践中习得技能,在实践之前有机会系统地学习和思考,那定然是好的。

不经学习历练而去做专业的事,将是一场灾难。管理作为一门专业,公司应提供系统培训,不能靠经验尚浅的人自行领悟,很容易走偏。

持续评估和提高中层干部的管理水平,是公司最重要的事,此处应该没有之一。

以上是「关耳爷」关于管理的一点小输出,请笑纳。

人人不再是产品经理

这两天,被冒名老干妈欺骗了的腾讯公司,还干了另外一件事——在内部邮件中重新定义了产品经理。

邮件中规定,12 级(P4-1)以上才能称「产品经理」,否则为产品策划或产品运营。

这个消息在行业内一经传出,就引来了真正的产品经理的欢呼,研发工程师们也额手称庆,大有从此天下太平的气氛。

腾讯作为成熟的互联网头部企业,岗位级别和晋升体系也是相当完善的,我们来观摩一下:

专业通道四大类别:

  • T 通道:技术通道,岗位包含研发、视觉设计、交互、运维等;
  • P 通道:产品/项目通道,岗位包括策划、产品、运营、项目管理等;
  • M 通道:市场通道,包括市场、编辑、商务拓展等子通道;
  • S 通道:职能通道,岗位包括行政、秘书、法务、财务、会计、人力资源、公关等

过去的体系中,每个通道分成 6 大级,每个大级又分 3 小级,所以产品经理就会有 P4-1 的级别。

新的体系中,不再分成 6 档,级别直接从 4——17,12 级对应的正好是 P4-1。

从级别 12 开始,是个分水岭,晋升成了专家,才能称为产品经理,叫「老师」没毛病了。

可见,腾讯公司是想让产品经理这个岗位真正的名实相副。

希望这套做法能在行业里通行起来。不过可以给产品策划改个名字,叫产品专员。

说起研发和产品,是天生的孽缘啊!

研发:产品完全不懂技术,提出的需求简直奇葩。

产品:研发水平太次,别人能实现的他做不出来。

研发:老板的传话筒,没有自己的思考。

产品:完全不领会产品意图,一直在那儿写 Bug。

研发:一句话需求,做产品经理太容易。

产品:这么简单的需求都不明白,这个程度的理解能力也能做研发。

研发:太不严谨,逻辑这么差怎么当上产品的。

产品:产品想不到的问题,技术不应该负责想到吗?

研发:这个功能需要两周

产品:难道 2 小时搞不定?

产品:这做出来的是个什么玩意儿?

研发:不是按你的设计实现的么?

围观的测试工程师:产品真垃圾、研发真垃圾……

把产品经理头衔里的水分挤出去后,产品经理应该可以对产品有决策权。

这一点也是很多产品经理的痛点,谁都可以对产品指点一二,做不好了只有产品经理背锅。

希望腾讯的举措在行业里尽快产生影响力,让产品经理这个岗位早日高大上起来。

理想中的精益创业

中型企业,有一个大的资源池,里面有产品、交互、UI、架构、前端、后端、测试等生产岗位,以及有增长(运营、市场、销售)人员。

当公司业务战略清晰分解后,有了若干个产品方向(此时还不是具体的),由产品经理(或其他人)自主选择感兴趣和擅长的方向,也可以是自行发现的商业机会(战略覆盖范围下)。进行商业规划和产品描述,具体表现形式可以是 BP、BRD。

准备好后,在公司内部路演,讲给高层和资源池的同事听。多人竞争同一个业务最好,如难分胜负,产品经理可进一步论述自己胜任该产品线的理由:展示成功经验、行业/产品理解的高度和深度、领导力、执行力。

商业规划中,对投入产出比、盈亏平衡点、盈利预期、利润分配机制要有详细的分析,在产品描述中,对实现商业目标有清晰的路径规划。

然后大家自由组队,双向选择,各岗位成员和产品负责人彼此看对眼,捏合成一个团队。

产品经理不单凭路演的感染力,他平常的表现也会被别人看在眼里,其人品和能力,能否提高大家收入,营造好的工作氛围,提升工作效率,满足大家工作的成就感……每一位职场员工也要考虑贡献度和合作度,关注自己的声誉和价值,否则没有一个产品经理要他,任何产品线都进不去。

公司可以不必过细地控制过程,只需看里程碑,目标是否达成。日常管理中,可以定期和不定期地验收成果。

在大的风险规避后,细节都交给团队,只要结果成功,方法、规则由团队自定。

公司信守承诺,按约定方式和产品线分享利润。产品负责人也信守承诺,和团队成员分享奖金。每个人都要衡量短期利益和长期利益,如确看好一个机会,有成功的信心和必胜的勇气,可以接受减少短期收入以增加远期收入,甚至于财务自由。

每个产品或项目,公司可以限定期限,以裁决成功和失败。每个自告奋勇,勇于挑起重任的员工,可以给他几次失败的机会,他不会失败多次,否则就无立足之地——无法召集团队被淘汰。

没有利润和竞争力的产品、项目,也会自然淘汰。

这就是「人之道,损不足以奉有余」,物竞天择,强者恒强。

对公司和个人都有好处。

帅将兵

再扁平的公司组织,也至少应该有「帅将兵」三层结构。即使名义上没有,在实际行动中也必然有这三类角色。

帅需要有制定战略和分解战略落地的能力,将需要执行战略,把战略转化为战术,进行计划、组织、监督的过程控制;兵需要执行具体任务,保证任务执行到位。

打工体制下,不能指望全员具有创业心态。这一点上,老板和部分拿了股份的帅迫切地希望下面的将兵能有强烈的主人翁意识和共患难的积极进取态度,但现实残酷,下面的将兵出于等值价值交换的衡量,往往不会像期望的那样行事。

这很正常。企业赚钱了,干活儿的员工并不能分享更多的利益,也就不能指望员工像打了鸡血那样充满激情,常言道,想让员工像狼,就得喂肉,不能喂草。

所以对于企业而言,激励制度永远是第一位的。老板要让员工清晰地看到目标在哪里,完成目标能获得什么相应的奖励。这才是企业能发展、壮大的核心所在。否则别畅想攻城略地、开创盛业。

在大的互联网公司,从 T6 升到 T7,每一年就会多拿几十万。摆在员工眼前的,有着清晰的打怪升级路线图,晋升和激励制度完善。某些创业公司,也会把股份、期权制度公开透明化,身边就有两位朋友加入了创业公司,公司上市后股票套现实现财务自由的案例。

从公司发展的角度讲,开创和守成是比较明显的两个阶段,但对于现如今的商业环境或某些行业来说,例如互联网,基本没有守成的概念,需要持续自我创新、颠覆,否则业务必然失守。也就是说,互联网行业需要开创性的人才要多一些。用保守派,就属于战略选择错误。

开创派相对激进,敢于用人,敢于让将、兵承担更大的责任,以便做出成绩进一步推高自己的地位;保守派,往往会担心局面失控,权力被削弱,尽可能地集权,防止下面做大,制衡各方,分权而不放权,让下层结构扁平,以便一竿子捅到底。

没有完善激励制度的打工环境,一般会加大上述弊端。将士上升无望,又要固守自己的位置,那对下属的压制将是必然的。

对于帅、将最重要的考核,就是团队中人才的贡献率。帮助老板发现人才,并把人才提拔起来,是对老板最大的帮助。问题是,帅和将这么做的动力在哪里?

不占股份,不会考虑全局最优的帅将这方面的意愿相当低。他们会表现另一种姿态,那就是让本人和士兵表现出「拼命」干活,大部分 996 就是这样诞生的。看吧,我们大家都在拼命干活儿,老板你能看在眼里吧?我们都已经干得这么拼命了,老板你对我的领导才能满意了吧?

对于老板而言,看见全员都在加班,能获得心理上的安慰。也仅仅是安慰剂的效应,对企业发展命脉有没有真正起到作用,不敢往下想。做出「勤奋」的姿态,足以掩盖更为困难和重要的使命。

从资源最大化利用角度来讲,帅、将、兵应该各安其位,干他该干的事。比如一个人具备将才,那应该为他派兵,配给资源让他完成某个战略目标,这算是物尽其用。而有些管理思维是,花大价钱请了一员大将,那就是要一个人顶一个排来用,把士兵干的活儿也派给他,把他的时间全都占满,似乎这样才算对得起花的那份钱。

这还是一种记量、记件的考核思维。有些工作的价值产出,无法按量计算。如果看中的是大将的思维和经验,要发挥他谋划布局的能力,那就应该控制他把时间用在这些工作方面,而不是让他去搬砖挖战壕。在后者领域,他的产出有可能比不过一个普通工兵。

请将军做将军兼士兵的工作,老板赚了吗?不赚反赔。

如果一个将军自愿抢士兵的工作,而不是指导和监督士兵把工作做好,那他在带兵的这项能力上也是不称职的。西方的管理学上,也有「别让猴子跳回背上」的管理理念。

微信扫一扫
关注该「关耳爷」

产品经理成长系列(7):功能&交互

1

通过前面几篇文章,我们已经弄清了做一款商业产品所需的前期准备工作,对要做的产品做出了价值和机会判断,接下来就要确定产品真正做成什么样子。

产品通过功能、界面、内容传递应用价值,用户也是通过这三点来触达和体验产品。所以狭义的产品经理日常执行工作,也是重点围绕这三点来展开。

分两篇来说,这一篇说功能与交互,下一篇说界面和内容。

之所以要把功能和交互放在一起,是因为这两者密不可分,用户要使用一项功能,就离不开人机交互。

我们从下面这张图看起。期望转型或已经成为产品经理的同学都应该见过这张图。

战略层,通过对外部环境(政策、经济、技术、市场)、内部资源优势及用户需求深入分析之后,确定了产品的目标和资源计划、运营计划。

范围层和结构层,即是本文讲述的重点。

框架层和表现层,放在下一篇文章中阐述。

2

我们设计一个产品,确定包含哪些功能(功能范围),这需要系统化思维、结构化思维的过程。

一个系统,包含了参与方、互动关系(生产、消费)和反馈链,反应到产品中,就是产品谁来用(用户角色),他们目标是什么,产生和消费了什么,资源如何流动?

比如电商平台,必要的参与方有平台、商家、顾客。

平台方要建设和运营平台,服务好商家和顾客,让他们在线上完成交易,把制定的交易规则落地到流程中,需招募商家,举办活动,充分满足商家的商品曝光和销售需求,还需要分析数据,观察商家、顾客的行为,追踪平台运营的各项指标。

商家需入驻平台,编辑商品和上架、接受咨询、处理订单、发货、进行售后服务、收款提现、对账等,还要做推广,维护客情。

顾客要搜索挑选商品、比价、下单、付款、收货、评价……

这里以电商的业务举例,一是假设大家对剁手熟悉,容易理解。换作其它产品也是用同样的系统化思维切入,按参与方分解子系统,梳理相互关系、资源流动与反馈链条,从而确定整个系统的功能范围。

在本系列第一篇,回顾了互联网产品历史和分类,每种类型的产品都可以用系统化思维来分解参与方角色,用功能来框定角色的责权利。

二是因为电商是一种典型的交易模型,从更高的维度来看,很多人类活动和产品模型都是广义交易模型,有生产方和消费方,过程中发生着信息、资金、物质的交换。

一个系统的实体要素,可以总结为五大项:人、财、物、活动、管理。活动是人、事物的核心事件和行为,比如发生在公司里的生产、研发、销售、市场、财务等经营活动,在学校里,主要活动有教、学、科研。

C 端用户也类似,用户面对自身、家庭、工作所进行的学习提升、娱乐休闲等,就是主要活动。管理,就是对前四者的计划、配置、监控、统计。一个产品的功能范围,就要覆盖这几个方面。

当某项活动足够复杂,或者信息密度低、流通不畅的时候,必然要诞生新的角色提供相应的服务,这就是中间商、中介。对于我们的启发有两点。

一是能不能发现成为一个中介的机会。比如新浪微博早期没有自建广告平台,「微博易」之类的中介公司乘势崛起,建设了中间平台,撮合广告主和大 V 的交易,盈利状况非常好。微信公众平台就比微博更聪明,在功能规划里包含了广告平台,没有把肥肉丢给外人。

二是能不能发现干掉中介的机会。这方面就不多说了。

回到一个功能的设计,即是围绕这五项展开。也是另一项重要的思维——结构化思维的用武之地。比如确定了参与方后,再细分参与方的角色、使用场景、行为流程……方法是确定每一层的分类方法不断细分下去,直到落实到可以在页面上所能进行操作的功能上。

如上图是对 B 类电商典型买家角色的细分。产品经理就是在不断界定产品的服务对象和服务环节,结合机会和自身优势,将某类对象的主要痛点充分地解决。

确定功能范围这项工作,最终的交付成果,可以是 Feature List、用户故事地图、用例图。贴几张图看一下。

3

最难同时也是最重要的是从全面、广泛的功能中确定核心功能。一个产品功能十分全面,不代表是一个好产品,也许是中庸的代名词。产品的功能复杂,也只能说明产品经理具备复杂化的能力,更有价值的是复杂化后回归简单的能力,当然,很多时候产品经理可能都不具备精确复杂化的能力……

产品的功能范围,可以体现一个产品经理对判断力的信心,没信心的时候,往往就追求大而全,指望能面面俱到,通过广撒网的方式不丢失用户。真正有信心的产品,核心的功能一定是较为单一明确的。

从最终产品交付来讲,一开始就试图设计一个完善的系统是不可能实现的。虽然能一定程度避免返工,但无法确保最终市场的胜利。尤其是从无到有这个阶段,速度很重要。

这方面可以和产品需求 KANO 模型进行关联。

4

结构层,简单谈信息架构。信息架构确定如何组织和展示内容、功能,用户通过功能的入口、操作的路径和可见的内容功能集合来感知信息架构是否合理。

这里面最重要的是同理心的运用。在我的经验中,最容易出问题的是菜单、导航、快捷方式、功能层级等按照非常严谨的方式组织起来,逻辑上完全正确、标准,但用户使用起来变扭,感觉不方便。

反观有些产品貌似杂乱,但用起来却很顺手,相信不少人都有过类似的体验。大数据里常举一个伪例是啤酒和尿布放一起,在这里倒可以作为以上道理的例子。

在需要的地方出现,这是信息架构和交互原则里最重要的一项。

5

再来说交互。交互就是人和机器的互动。

  • 人用眼睛看屏幕,屏幕有大有小;
  • 人用手指触摸屏幕,分左右手、拇指食指,可拖动、点按、长按、捏合;
  • 人操作鼠标,有单击、右击、双击、拖动、滚动。有移入、移出、按下、抬起。
  • 人可以操作键盘、发出语音指令……

人通过器官、设备向机器输入,机器输出过程和结果信息,这就是交互。交互设计就是对输入输出对象的格式、大小、操作方式、反馈方式的设计。

产品经理很重要的一项工作就是交互原型设计,有的公司会把这项工作细分出来,交给交互设计师。

产品经理如何快速入门交互原型设计?有一个极简单、直接的方法,它就是(画重点):

Google、Apple、Bootstrap 三篇关于交互和设计的文档,用三周时间,每篇看三遍以上。

  • 《Material Design 》:https://www.material.io/
  • 《Apple 人机界面指南》:https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/
  • 《Bootstrap 中文文档》:https://v3.bootcss.com/css/

因为交互设计里有太多的知识,比如布局的栅格系统、比如几十种典型的表单组件规范……

授人以鱼不如授人以渔,熟悉了上面三篇文档,不管是做交互原型,还是做界面设计,从思维、原理、方法上都有系统的把控。

(* 文中图片来源于互联网,版权归原作者所有)

来源于:微信公众号「关耳爷」

性格和职业

端午期间,和老婆刷了一部剧,名字叫《隐秘的角落》,是最近很火的一部网剧。

已经很久没有看过连续剧了,因为很耗时间,现在几乎连看完一部电影的完整时间和耐心都没有。

这部剧只有 12 集,所以很快就看完了。结局真是细思极恐。当得知作者紫金陈原来是一名产品经理时,我就对作者更感兴趣了。找了他的小说来看。

据一篇文章写到,紫金陈是这样的经历:

紫金陈原名陈徐,紫金陈是他的笔名,86 年生人,08 年毕业于浙江大学水利系。因为对炒股感兴趣,毕业后他加入了一家互联网公司,就是做炒股软件的同花顺,并在这里干了三年。刚入职时,他的工资只有 3500,后来涨到了 4000。很多人觉得 3500 的工资太低了,跟现在的应届生都没法比。但要知道,那是 2008 年,12 年前。

2008 年的时候,我也转型为了产品经理。工资应该是比紫金陈多 1000,但我是在北京。

紫金陈的性格:

他说自己其实挺适合做产品的,觉得做产品和写小说很像,想象力和逻辑思维能力二者缺一不可。但他觉得自己性格内向、情商低、合作能力差,认为自己不适合在公司生存。上班时觉得领导智商低,领导也认为他沟通能力不行,一来二去互相看不顺眼,后来就被公司劝退了。没了工作的他想过做其它事,计划考公务员,但又不想过那种一眼看到头的生活。计划学习编程,想做一些网站接广告联盟赚钱,后来觉得极消耗精力又赚不到什么钱。后来,经过对自己的分析,他找到了一条或许可行的路,写小说。

我觉得内向、情商低、合作能力差这三点,和我真是极像。「不需要太多与其他人打交道,专注干自己的事就行」也和我对自己的认知是相符的,类似的话我也说过很多次。

还有很相像的是,我现在都在学习编程,运营网站,想通过网站赚点钱,也往往是因为太消耗精力、时间,不能持续地进行。

我也想过写小说,甚至想到了以这次的新冠疫情为背景。武汉第一次正式报道疫情的时候,我在武汉,大规模爆发的前两天,领导又让出差去武汉,我不愿意去,他还问:「你们就这么害怕吗?」直到除夕的那天,才刚过 14 天潜伏期。提心吊胆好几天。

那几天就和老婆闲聊,可以以这个内容作为开头,接下来写,主角感染到了病毒,这一切都是瘟神的阴谋,但主角意外获得了超能力,一路过关升级获得了蝙蝠的全部能力,但并非吸血鬼编制……为保护人类,和瘟神 BOSS 来一场决战,最后发现吸血鬼和瘟神,都是保护地球生态的重要成员,而自己获得这些能力,也是地球长治久安的命运安排……

但是没有写的信心,一直没有开头。是不是也该试着写写?

形形色色的数据库

形形色色的数据库

——一文读懂 OLTP 和 OLAP

1

为什么会有这么多类型的数据库?

因为满足不了用户使用数据的全部需求。

数据使用说起来很简单,概括起来就是「读、写」二字,但实际操作中,无比复杂。

数据业务在大的方向上有两类,分别是交易型业务和分析型业务。

你可能见过这两个词:OLTP 和 OLAP,基本上就是对应这两种情况。

数据库为满足业务需求,也分为两大类:交易型数据库和分析型数据库。

交易型数据库是什么?

交易型数据库用于业务系统数据的增、删、改、查。又称为操作型数据库、事务型数据库。

业务系统就是我们平常所能接触到的各种功能系统,如企业经营过程中使用的各种管理系统,包括设计、研发、制造、销售、人力、财务的各种系统;个人生活娱乐、工作中用到的各种应用,如电商、微博、微信等。都可以看成业务系统。

这些系统,需要把我们提交的信息实时保存下来,也需要把保存好的数据展示出来,按用户各种查询条件过滤数据,还可接受用户的修改、删除。

通常,完整的一段信息会被分开存储,如一篇文章,分成标题、正文、作者等部分,按固定的结构存储,这就叫「结构化存储」。这种存储方式,有很多优点,因为粒度细、结构规整,想局部、全部地读写数据都很方便,效率非常高。

交易型业务,有两个字非常重要,即「实时」。数据要实时地成功写入,快速地读取。想想看,发生了一笔充值或消费的操作,数据却没有被实时地记录,后果非常严重。

哪种数据库用来支持交易型业务?

适用于以上场景的数据库,主要是大家所熟知的关系型数据库,如 MySQL、Oracle、SQL Server、PostgreSQL 等。

它们共同特点是一个库里会有多张表,相当于一个 Excel 文件中有多个 Sheet 页。每张表会存储相同业务和结构的数据,如商品表,只存储和商品有关的信息,有商品名称、商品规格、商品描述……订单表,只存储和订单相关的信息,订单号、订单金额、下单时间……每张表有多个列(字段)存储这些数据,同 Excel 文件的列一样。

这些数据库,有的是商业公司开发的,有的是开源的。一般来说,商业数据库,会支持更多的特性,性能、稳定性也更高,有好的服务保障。关键行业应用的数据库,如银行,用的都是商业数据库。

开源数据库应对一般的使用场景也没有问题,还可以按需调优和改造。很多国产关系型数据库就是基于开源关系型数据库改造而来。

关系型数据库除了上述几种,还有一类轻量的产品,以 SQLite 为代表,非常适合手机等移动设备应用本地存储。

只有关系型数据库就够了吗?

关系型数据库太「规范」了,事先需要有大量的结构设计(即建模)工作,到用的时候需要知道结构才能取出所需要的数据。读写的速度也不行,因为它最终要存储在硬盘上,如果数据从内存中读取,速度可以保障,但丢失风险高。

我们的目的是用数据,可不想耗费精力在它的结构上,通过结构化对数据进行使用,只是一种方法和手段而已,并不是一定得把数据结构化后才能用。况且,有时候结构本身是数据的一部分,拆成行、列的存储形式用起来反而不方便。

有些数据,非常适合用 JSON 的结构存储,如下图。再把这种 JSON 文档存储在不同的「单元格」中,这种存储方式和上面关系型数据库的原理有本质的差别。实际上这种方式就是 NoSQL 数据库的一种类型,叫做文档数据库。代表产品是 MongoDB。用户可以事先不关注数据库结构,只需关注文档内部的结构,每个文档的内部结构都可以不同,这样一来更贴合人类「自然」的使用。

NoSQL 除了文档型数据库,还有键值型数据库、列式数据库、图数据库、时序数据库等。各自典型的代表有 Redis、HBase、Neo4j、InfluxDB 等。

NoSQL 数据库为什么也有这么多种类型?

简单来说,有两个原因,一是数据本身的特点;二是出于使用场景的需要。

一种新技术或新产品的出现,一定是为解决某个具体的痛点。

比如 Redis 是基于内存的键值数据库,键值这种存储结构,类似于查字典,查询速度非常快,数据又是在内存读取,比硬盘快很多倍。它的应用场景在于较稳定不变的数据的高频读取,不必每次都从关系型数据库中查询,所有一般应用在数据缓存的场景中。

时序数据,即按照固定频率不断生成的周期性数据,一般物联网设备、日志数据等都会呈现时序特征,这类数据有非常显著的特点,比如说插入频率较为稳定,不会像天猫双十一活动非常高的并发写入,写入的数据几乎不被更新,不会像订单数据那样进行状态更新,也很少会删除单条数据,一般是对过期数据批量化删除。时序数据偶尔丢失几条,不会对整体业务造成太大的影响。它们的某些维度,可以合并存入,降低存储成本,如某台设备的 ID、IP 地址、甚至是地区,可以是类似「合并单元格」的存储方式,这实际上就是时序数据的压缩技术,可以有效节省存储空间。针对以上特点进行优化设计,就产生了专门的时序数据库。

图数据库,和图片、图像完全没有关系。它擅长实体关系的存储和表达,如社交关系、投资关系等,关系型数据库也能做到,多个实体可以通过主外键来建立关联,多对多的关系需要产生一张中间表来关联,如果存在大量的这种数据,关系型数据库就会耗费大量的存储资源,关联查询和递归查询效率也会比较低。即使是同一实体,如果关系穿透路径较长时,有时也会低到不可用的地步。图数据库利用节点和边的结构,比较完美地解决了上述问题。

从 NoSQL 这里,就有了向分析型数据库过渡的倾向,这一点在列式数据库上有明显的体现。列式数据库典型的代表是 HBase,顾名思义,在物理存储上,列式数据库按列存储数据,最大的优势是获取「局部数据」更快,在数据统计分析的场景下,我们通常是按列进行操作,比如对价格一列进行求总和、平均值、最大值、最小值等(术语上称为「聚合查询」,是分析的基础),这一列数据物理上存储在一个区域,一次就可以读取,而如果是按行存储,需要读取每一行,才能从每一行数据中找到「价格」那个单元格,这就是它最大的优势,所以数据分析业务,即 OLAP,列式数据库有很高的性能。

这种列式存储的结构,也非常有利于分布式存储。天然适合大数据。2

分析型数据库有什么特点?

简单地说,分析型数据库,是面向分析的,而不是面向记录数据和更新数据(这是交易型数据库做的事情)。

分析就是通过对数据进行有逻辑的计算,得出新的数据,新的数据可以印证一定的假设。想要做好数据分析,要求分析型数据库有以下特点:

首先,它需要存储大量静态的数据,基于尽可能多的数据,才最有可能还原真实情况。其次,需要能很快地取出计算所需的数据,这对于快速得到计算结果至关重要。最后,取出的数据可以很快地得到聚合的结果。

上面已经说到,列式数据库在前两点上已经支持的不错了。

换个角度来说,分析就是尽可能多角度地看待某项定量数据。多角度,就是「维度」,定量数据,就是「度量」,分析的核心内容,围绕的就是这两个关键词。

而这两个关键词的背后,就是离散数据和连续数据,两者之间相互转化的主要手段,就是聚合查询。所以最后一点,能快速得到聚合的结果,也是分析型数据库的着力点之一。由此诞生了很多 OLAP 的引擎。我们耳熟能详的有:Hive、Presto、Impala、Clickhouse、Greenplum、Doris、Druid、TiDB。

这些大数据开源工具,很难严格地界定它们是数据库,还是 OLAP 引擎,还是交互式查询(即席查询)引擎,正是由于上面提到的最后一个要求。它们通过各种技术原理和方法,实现能够快速地进行维度构建、关联、转换和度量的计算,最终达到快速获得分析结果。

另一方面,分析型数据库还得考虑易用性,对于我们来说,目前最好用的分析方法还是属 SQL 语句(尽管对普通人还是很难)。对于存得多和取数快,偏偏是 NoSQL 的长项,如何让分析型数据库良好兼容 SQL,也是分析型数据库核心要面对的问题。

以上是「关耳爷」微信公众号的小输出,请笑纳。

记日记是一种生活方式

昨天整理微信的收藏列表,找到一些儿子小时候的视频,发给老婆看。我们对一些细节已经记不起来了,视频还原了当时的场景。

在一个视频里,餐桌上摆了一碗韩国杂酱面,这和老婆的印象不一致。在她的记忆里,那些年应该不会吃这种饭,也没有地方可以买。

所以有必要每天都写日记,记录当天的所见所闻。若干年后,当记忆已经模糊,再翻看这些细节,可以了解当时的状态和情绪。

下班回家吃过饭,基本已经到了 8 点。在电脑前坐一天,又在地铁上站一小时,饭后只想葛优躺,刷刷各种信息流放松一下。疫情期间,老婆辅导儿子一整天的学习和其它课外练习,也非常辛苦,她希望我回家后可以多陪陪儿子。

我每天也规划了一个小时用来陪伴儿子,但不够自律,没有做到。希望从今天开始,尽可能做到。

每隔较长时间后,一个月或两个月,我都会集中几天玩王者荣耀或刷抖音。

连续刷几个小时抖音,我就有种莫名的感动,接着就是归隐田园生活的冲动。

短视频里,拥有不同才艺的人展示着他们的活力与激情,或抚弄乐器,或吟唱舞蹈,姣好的面容、帅气的脸庞、完美的身材,还有那么美丽的风景与世界……

衬托之下,我如此平凡,生活平淡乏味。

特别想回到小时候生活的地方,置身在湛蓝的天空之下,呼吸纯粹的空气,感受晨露湿土。

过一段,自给自足、无忧无虑的生活。