SQLite 不为人知的故事

《形形色色的数据库》里,向大家提到过 SQLite 小型嵌入式数据库。现在人们使用最多的数据库,可能就是 SQLite。在浏览器、手机、汽车、ATM机、飞机……各类设备上它都有广泛部署。

SQLite 数据库以一个独立的文件存在,不占用操作系统进程。其它关系型数据库,一般是客户端/服务端大型的技术架构,需要安装、启动服务,占用端口。

受益于整个数据库(包括结构定义、表、索引、数据本身)都在一个文件里,SQLite 很容易跨平台使用。麻雀虽小,五脏俱全,关系型数据库的关键特性(如事务),它都能良好支持。性能也很出色,同时它做到了 100% 的测试覆盖,稳定性和安全都有保障。

正是因为以上特点,它成为了移动设备中数据库的第一选择。

2022 年 7 月初,SQLite 的作者 Richard 参与了一期播客节目,讲述了 SQLite 是如何诞生和发展的。

这篇文章整理了博客节目的关键内容。看完后也许能理解,为什么我们没有这样的程序员,为什么我们做不出世界级的基础设施软件。

SQLite 如何诞生

Richard 早先是个外包程序员,所在团队承接了一个军工项目,开发军方战舰上使用的故障管理系统。

该系统使用了 IBM 的 Informix 数据库,可能是服务器方面的原因,数据库一直不是很稳定。只要数据库服务器挂掉,他们开发的系统就会无法正常运行,弹出提示:“无法连接到数据库”。

甲方大佬看到他们的系统产生了错误提示,也不关心具体背后是谁出了错,就把锅扣在了他们身上。

国内外的外包程序员都是伤不起啊,遇到这种情况,一般程序员都是选择换个环境,或者祈祷分到一个好侍侯的甲方项目中。

战舰故障管理系统的使用频率比较高,外包团队又没有数据库服务器的管控运维权限,怎么解决无法连接数据库的问题呢?

Richard 有了一个灵感:“为什么一定要从数据库引擎中取数据,而不能从硬盘中直接读?”

只要操作系统和硬盘没问题,程序能正常运行,就可以读取本地文件,而不必依赖数据库引擎的服务正常。

“功能越多,越不稳定。”我记得八十年代的时候,父母看一些工业产品时,就经常说这句话。奥卡姆剃刀原则“若无必要,勿增实体”在产品设计中是一条重要的指导原则:1、系统越简单,故障率越低;2、用户认知负担降低;3、带来了简洁的使用体验;4、成本降低。

他们在市面上找了许久,发现没有现成的 SQL 数据库引擎可以做到这一点。团队其它成员就鼓励 Richard 写一个出来。

查了一下资料,同类型数据库 Microsoft Access 1.1 在 1992 年就有了,但应该不能在 Linux 平台下使用。SQLite 是 2000 年才开始开发。

Richard 并没有立即开始,直到因为政策原因外包项目合同中断,Richard 失业了数月,才正式动手编写 SQLite。

可能也有拖延症。

当时是 2000 年,还没有维基百科,上网也是电话拨号,美国只有 1% 的家庭拥有 ADSL 宽带网络。

在 Google 上几乎搜不到构建一个本地文件型数据库的有用信息。

Richard 有开发编译器的经验,于是他把这项经验应用到了开发数据库上。

他把每条 SQL 语句(DDL 创建库表结构和 DML 读写操作数据,都是SQL语句)看作是一个程序,只要这个程序能执行成功,那就达到了最初的目的。

于是,问题变成了把程序编译成某种可执行代码,这就用到了他开发编译器的经验,他写了一个字节码引擎来运行一个查询。

SQLite 核心原理是通过一个编译器将 SQL 翻译成字节码,就这样,SQLite 诞生了。

面对生活中、工作中的痛苦时,我们习惯咬牙忍受,常常采取迁就、回避、的态度,长期下去就变得麻木,这是我们不擅长创新的重要原因之一。

SQLite 如何发展壮大

SQLite 被发布到网上。

Richard 很激动地宣布,他在掌上电脑中跑起一个 SQL 数据库。就是下面这台 Palm Pilot 掌上电脑。

作为 80 后,我对掌上电脑印象深刻,曾梦寐以求想拥有一台,结果是拥有了电子词典。

SQLite 一发布就受到很多人关注,这让 Richard 大受鼓舞,不断迭代升级他的产品。

一两年后的某天,他接到了摩托罗拉公司的电话。摩托罗拉正在开发新版本的手机操作系统,有些功能适合用 SQLite,希望能把 SQLite 内嵌进去,并让 Richard 提供技术支持。

Richard 很激动,但对方问起价格时,他一时不知道该怎么答复。

放下电话,Richard 对产品定价仍没有头绪,他没有想过系统化地运作这个项目,也没有可参考的定价方式。

最后几乎是一拍脑袋,定了 8 万美金,当时折算人民币近 60 万。这就是 SQLite 的第一笔收入。Richard 又找了三个人,和他一起完成了这个项目。

2001、2002 年时,摩托罗拉公司的体量十分庞大,比今天国内的小米、华为等公司大很多。这样一个巨头,肯为一个小软件的作者致电并付费,这样的商业环境,对知识产权的重视,真是令人羡慕。可以想象,现在某些公司遇到这样的情况时,还是会给某部门的程序员下达一个任务:加班两周抄一个出来!

继摩托罗拉之后,又一笔生意找上门来,这次是 AOL(今天的美国在线,曾被 44 亿美元收购,又和雅虎打包一起 50 亿美元卖出)。

AOL 当时有邮寄 CD 的业务,他们想在CD中使用 SQLite 数据库的一些增强功能,为此 AOL 每月向 Richard 支付 10 美元。

不知道是不是每张CD 每月支付10 美元,原文没有说。如果是,这一下子就可以实现财富自由了。所以,完成从一个消费方到生产方的身份转换很重要,生产一个有价值的东西(无论是实体的,还是虚拟的),即使可能是小众的产品,也会产生回报。

紧接着,Symbian OS(塞班手机操作系统,后被诺基亚收购)和诺基亚分别和 Richard 签订了合同,这时 Richard 已经需要频繁飞往国外和这些公司谈合作了。

Symbian 在数据库选型期间,一共测试了 10 款产品,其中 2 款开源,7 款商业产品,还有 1 款就是 SQLite。考虑到商业公司相对更有保障,Symbian 给了商业产品多次优化调整的机会,但最终还是 SQLite 胜出。

成立 SQLite 联盟是里程碑事件,联盟目的是为项目提供更多的资金并让更多的协作者参与维护项目,以保证产品可以长期使用。

像一直等着生意上门一样,成立联盟这件事也不是 Richard 主动推动的,而是由管理 Mozilla 基金会的一位女士一手推动促成。Mozilla、Symbian 和 Adobe 三家大公司成为了联盟的创始成员,他们和其它联盟成员共同赞助 SQLite 发展,而产品的决策权仍在 Richard 手中。

有人说 Richard 做了个错误的决定,但事实证明,后面 SQLite 一直发展的很好。

再后来,2005年的时候,Google 联系了 Richard,向他展示了安卓的原型机。他们又在安卓系统上展开了 SQLite 的合作。这正是智能手机诞生的前夜。

Richard 回忆当时的一幕,他们正在使用 SQLite 调试适配手机上的一些应用,这时来了电话,电话被接通——Richard 意识到,这不再仅仅是手机。智能手机的时代要来临了,而摩托罗拉、Symbian 、诺基亚都没有意识到这点。

Richard 和 Google 签署了保密协议。他不能告诉摩托罗拉们,时代要变了。

SQLite 如何保持稳定

Richard 一度对 SQLite 很自信,他认为SQLite 绝对没有严重的错误,事实上好像也是如此。但安卓证明了这不是真的。当 SQLite 随着安卓系统在数百万台设备上部署时,出现了很多错误。

Richard 学习了航空电子设备制造商的一些经验。在安全至关重要的航空产品的质量标准里,有一套 DO-178B 标准。其中一个关键是要求对产品 100% 的测试覆盖率。

Richard 把这个理念应用到了 SQLite 的开发中,他决定编写测试代码以使 SQLite 达到 100% 的质量。

在软件开发中,达到 90% 或 95% 的测试覆盖率是比较容易的。想达到最后 5% 非常非常困难,他们花了大概一年的时间才达到了100%的测试覆盖率,测试用例惊人地达到了10万个,在多种芯片、多种操作系统中完整测试一遍将会产生 10 亿次测试。这件事做完,就再也没有收到来自安卓的错误报告。

这一举措发挥了重要的作用,在接下来的八九年里,SQLite 真的没有发生任何错误。

第三方测试平台对各类数据库做了极限测试,除了 SQLite,只有 PostgresSQL 能达到同样的水平。

PostgresSQL 要做到这一点,比 SQLite 更不容易。因为PostgresSQL 正是文章一开始提到的客户端/服务器复杂架构,而且是原生分布式数据库,分布式会引入更多错误的机会。而 SQLite 只有一个文件。

其它数据库,包括 Oracle、DB2 等,都会在这项极限测试中奔溃。

伟大程序员的一些独特理念

毫无疑问,Richard 是一个伟大的程序员,他发明的 SQLite 嵌入式数据库是众多移动设备、移动应用能高效稳定运行的基础设施之一。难以想象,如果有一天 SQLite 不能用了,我们的生活将会受到多么大的影响。

他在播客中也提到了一些理念。

从第一性原理出发

Richard 准备开发 SQLite 时,和普通人一样,先去互联网上搜索了很多资料。遗憾的幸运的是,他什么都没有搜到。

很多计算机核心技术理论,都来自于麻省理工大学、哈佛大学或伯克利大学,他也没有办法从这些大学里得到帮助。

他只能动脑子用原创的方法来实现新的数据库。

奇怪的是,等回过头来再看 PostgreSQL 使用的火山模型和 SQLite 曾经的字节码模型,二者在顶层设计时有着不同的路线,但在同一技术领域中,两条独立的发展路线都给出了同样稳定的结果。

Richard 认为这是运用第一性原理后的结果。

“一点就透”

Richard 讲了一件很有意思的事情。有一次在德国召开一个 PHP 的会议,邀请 Richard 做演讲嘉宾(PHP 已经将 SQLite 集成了进去),另外还有一位演讲嘉宾是 MySQL 早期开发者。

这位开发者讲了 MySQL 一个关键性能实现方案。Richard 听了心想,“哇,这真是一个聪明的主意。” 于是就在回去的飞机上,打开电脑为 SQLite 实现了这一特性。

真正的领域专家,有时候只需要一点点启发,就能立即明白其中的关键,并把它实现出来。如果你怎么都没办法向别人说清楚一件事的时候,不要怀疑自己的能力,要怀疑对方的知识储备。

没有依赖的自由

庄子说御风而行的列子“此虽免乎行,犹有所待者也。”

Richard 可能没读过庄子,但他似乎更明白不依赖于他人的自由之可贵。

SQLite 除了依赖 C 编译器和 libc 中的一些东西,没有依赖任何“轮子”,需要到的“轮子”,全部都自己发明了一遍。

Richard 说,假如当时选择使用 Berkeley DB 作为 SQLite 第二版的存储引擎, 起初它是开源的,但后来就被卖给了Oracle,变成了双源模式,不付许可费就看不到源代码,那肯定会出问题。

SQLite 中的解析器也是作者多年前自己编写的,没有使用现成的 Yak 或 Bison 等产品。

当 SQLite 需要版本控制的时候,同样没有使用 CVS 或Linux之父开发的 Git ,而是自己开发了一套 Fossil 版本控制软件。

Richard 甚至计划自己开发一个邮件服务去替换 Gmail,他不希望邮件内容被厂商记录和控制。

自己做,不依赖第三方,就能掌握自己的命运,就会拥有更多的自由。

SQLite 作者的一点建议

“构建一个没有服务器的数据库引擎,直接与硬盘文件交互,忽略数据类型,这在当时绝对是一个疯狂的想法。”

“如果去问专家,他们都会说:‘那是不可能的,永远也行不通。这个想法太愚蠢了。’”

“幸运的是,我不认识任何专家,我就去做了,事情就做成了。我认为,不要过多地听专家的话,做自己认为有意义的事,就有希望能做成。”

从今天起,坚持每天写作 45 分钟

打两把王者荣耀要 40 分钟,刷一会儿抖音很快半小时过去,清理当天未读的公众号也得一顿饭的功夫。

争取拿出一节课的时间来写作。

为什么是一节课的时间?太长的时间也没有,日常活动的关键词有:陪伴与教育、锻炼、运营网站、阅读、编程、学习、工作任务,各项只用一个小时,也几乎占满了白天的全部时间。

一节课的时间,够简单地写写当天的感悟和思考,但系统性肯定不够,这也是公众号断更的原因,总觉得需要较为完美和系统地输出一个主题,否则对不起订阅的朋友,或者说很担心被订阅的朋友看不起,取关。

对于自己来说,写总比不写强。也许要先满足自己,再「取悦」别人。这样持续下去,说不定才能两者兼得。

今天得到的启发是对「资源」的理解。我们每个人都有很多资源,但因为它很常见,或者你获得它较为容易,所以觉得它很平凡,但这个世界上还有很多人想各种办法求而不得。比如一些电子书,比如某软件的序列号,或者是一些模板、素材,也或者是你习以为常的一项技能,这些不起眼的资源,都能变现。

变现比以前更容易,是因为:

  • 移动支付不像支付现金那样让人心疼,看起来减少的只是数字。
  • 人们已经有了为节省时间小额付费的习惯。
  • 人们有了为别人的劳动买单的意识。尽管这种劳动可能只是简单地搬运、打包,但人们已不再纯粹地享受「免费」,存心只做伸手党。我理解这更类似于「小费」意识。

但把资源变现,还需要方法、平台和渠道。今天的时间不够说。

思考是逻辑和步骤是:

  • 自己有什么资源?资源够不够多,能不能持续输出,输出的成本高不高。
  • 再看寻找这些资源的人群活跃在哪儿,如果没有细分的平台,笼统地说有几亿人都活跃在那五六个 App 上。
  • 如何获得大曝光率?
  • 如何把变现闭环打通?

请将这 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/

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

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

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

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

形形色色的数据库

形形色色的数据库

——一文读懂 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,也是分析型数据库核心要面对的问题。

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

数据存储那点事:数据湖和数据仓库

数据湖是个筐,什么都能往里装……物联网设备传感数据、网站、APP、社交媒体和业务系统的非结构化数据和结构化数据统统往里装。

数据仓库就不同了,既然是仓库,就需要事先规划,按品类分区,原料、半成品以及成品分开存储,以提高出入库、调拨的效率。

事实上确实如此,数据仓库(DW, Data Warehousing),通常分为:

  • 操作数据层(ODS, Operational Data Store)
  • 明细数据层( DWD, Data Warehouse Detail)
  • 汇总数据层(DWS , Data Warehouse Summary)
  • 应用数据层(ADS, Application Data Store)

另外还有一个公共维表层(DIM) 。

先不要被这些概念吓住,以后讲数据仓库建模的时候会详细说,先初步有个印象。

类比来看,这就是一个数据原材料——原材料半加工——半成品全加工——按需食用的过程。

  • 结构化的数据先原样存入 ODS 层。要用到数据采集、同步的技术,上篇文章有写到。这一步相当于把原材料拉进仓库里。操作数据层和数据湖有点像,但不包含半结构化、非结构化数据。
  • 明细层和汇总层,存的都是事实表,事实表又是个啥?就是反应了一项事实,比如谁什么时间花了多少钱购买了哪个商家的某个产品。这正好是一张数据表的各项字段。明细层存的是详细的事实数据,而汇总层,是按业务需求,做了一定的汇总后存放的数据,比如最近 7 天北京地区活跃的男性和女性用户数量,这是一行汇总数据,是根据明细数据汇总而成的数据。
  • 明细层的数据,是从 ODS 加工而来的,如何加工?最简单常见的就是 JOIN、UNION,写一些复杂的 SQL。这一步是半加工。
  • 我们建数据仓库,最终还是为数据分析(OLAP)、可视化等业务应用提供支撑。为了更好地调用、分析数据,数据是按主题分类的,就是后文要说的「面向主题」。
  • 公共维表层,存放用于分析时的那些维度,维度是衡量和观察业务的角度。比如省市区、年月日、用户等级等。

说清楚了数据仓库,再来回顾下数据湖和数据仓库最大的不同。

数据湖是一个庞大的混合存储库,一般是集中式的,可以存储所有结构化和非结构化数据。

而数据仓库,是一个「面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。」这是数据仓库之父Bill Inmon在 1991 年出版的《Building the Data Warehouse》一书对数据仓库所做的定义。

  • 面向主题,简单来说,就是按目的(比如分析的指标大类)把数据分类,比如电商的数据运营,会对商品、会员、销售、物流等各项指标分析,可以按以上分类把数据分表存放。
  • 集成的,意思是多个供应商(业务系统)的货(数据),我们都有序地存放在一个中央仓库(数据仓库)里,康师傅和统一的方便面,我们都放在方便面的货架里。
  • 相对稳定,这是区别于 OLTP 数据的特点,比如一条订单数据,状态会不断变化,有下单(待付款)、付款(待发货)、发货(待确认收货)……等一系列更新(UPDATE)过程,这就是不稳定,而存入数仓的数据,一般不会再更新。
  • 反应历史变化,是指要把反映过程的数据尽可能地存储下来,以便支撑更为精细的分析。这样一来存入的数据会很多,以上面的订单数据为例,在 OLTP 中只有一条记录,可能只有状态字段和时间字段更新,其它商品、用户字段不发生变化,而在数仓中,会把每次更新都存下来,这样会有多条数据。而「拉链表」就是优化这种存储场景的一种方法(以后详述),可以有效降低存储成本。

数据仓库这种「数据集合」,需要根据业务的需要,事先规划定义数据结构,因此它可以用传统的关系型数据库来搭建,因为要存储很多历史数据,所以要对单表的存储容量和性能有所要求,传统数据仓库很多都是用 Oracle 搭建的。

那么说数据仓库和大数据又有什么关系吗?数据仓库是种方法论,大数据能提供技术手段。比如 Hive,就是大数据里用来搭建数据仓库的好组件。

数据湖是不是就是一个简单的混合存储库?也不是。数据湖并不是存储方案,它的目的也是用于分析和指导决策。

  • 数据湖本身要支持运行不同类型的分析(如 SQL 查询、大数据分析、全文搜索、实时分析和机器学习),不需要将数据移至另外的分析系统。
  • 数据湖要能够对数据进行爬网、编目和建立索引来让用户了解和使用湖中的数据。这项功能的难度很高,因为数据湖中的数据更为复杂。

数据仓库可以充当用户可信任的「单一信息源。」数据湖则是以更丰富的数据格式和类型,以及更全面的分析工具,提供更广泛价值挖掘的可能性。

对于当前大部分公司的数据应用水平来说,应先建立规范的数据仓库,这是对理念和方法的考验,而不是技术和手段(用关系型数据库就能建立)。数据湖,在更先进的技术屏蔽了复杂的存储、编目和底层分析工具后,将会是趋势,可逐步关注。

关耳爷

微信号wei-talk