行为金融学 | 投资中的那些“错误”的行为 | UBS Asset Management - Global site 资产管理

 最近的市场，仍然延续着震荡而分化的格局，结构性机会与风险并存。如果你手中持有两只股票，一只浮盈10%，另一只浮亏10%，当你急需用钱的时候，会先卖出哪只呢？

相信大多数人更倾向于选择卖出赚钱的那只。

那么这是理性的操作吗？是什么导致了这样的操作呢？今天我们就从行为金融学角度，来聊聊投资中的那些“错误”的行为。

面对得失，风险偏好不同

诺贝尔经济学奖得主理查德·泰勒曾做了一个实验，他向被调查者问了两个问题：

问题1：在以下两个选项中做出选择：

（A）100%可以得到100美元；

（B）有50%的机会得到200美元，有50%的机会一分不得。

结果72%的被调查者选择了A选项。于是他接着问了第二个问题。

问题2：在以下两个选项中做出选择：

（A）100%会损失100美元；

（B）有50%的机会损失200美元，有50%的机会一分不失。

这一次，64%的被调查者选择了B选项。你是否也和大多数人的选择一样呢？

其实这两个问题，在经济学的逻辑上是一样的。选择A选项，都代表100%获得或者损失一个确定的、但是较小的金额。而选择第B选项，数学期望值都是获得或者损失100美元，但却有机会可以增加收益或者避免损失。

但是，大多数人面对这两个问题，却做出了截然不同的选择。

在面对收益时（问题1），我们会变得保守，更愿意追求确定性，不希望承担风险。而在面对损失时（问题2），只要有机会能让我们避免损失，就会变得更愿意承担风险。

损失造成的伤害大于获益带来的快乐

这种在获利时不愿冒险，而面临损失时倾向于冒险的行为，可以用价值函数曲线更好地解释：

在上图中，曲线的上半部分代表获益，下半部分代表损失。可以看到，损失曲线比获益曲线的走势更为陡峭。这代表着，同样是100美元，损失100美元时造成的伤害远远大于获益100美元时带来的快乐。这被称为“损失厌恶”，这也是为什么人们在面对损失时，更愿意冒风险去避免损失的发生。

这一现象在股市中体现得更为淋漓尽致。就如开头所讲到的案例，持有的两只股票，一只股票涨了10%，而另一只跌了10%，这时候很多人就会卖掉上涨了的那只，而留着下跌的那只，希望有一天能再涨回来，解套了再卖。

显然这并不是一个理性的决定，如果下跌的股票是因为基本面恶化，那么可能会带来更大的损失。但是“损失厌恶”的存在，让我们作出了“错误”的决策。

应对方法：

在作出投资决策时，应更多地考虑股票本身，如行业及公司基本面是否发生了变化，而不能单一地看持仓盈利与否。

心理账户与非理性决策

除了“损失厌恶”，还有一种现象时常影响着人们的决策，那就是“心理账户”。

心理账户，简单来说就是每个人心理上会把钱分成不同的账户，每个账户里的钱都是独立的，一个账户里的花销对另外的账户没有太大的影响。

一位美国的经济学家曾做了一项研究，关于汽油价格的变化对人们选择不同的汽油会有什么影响。结果发现，普通家庭如果制定了汽油预算后，这笔预算一般不会用来做别的，如果汽油便宜了，就会买更优质的汽油。在2008年金融危机期间，汽油价格大幅下降，大多数家庭在其他方面尽可能地节省开支，但却增加了高等级汽油的消费。

心理账户的现象在赌场上也很常见。当人们在赌场上赢了一笔钱之后，往往会把原来的本金放在一个心理账户，而把赢来的钱放在另外一个心理账户。用赢来的钱再去赌一把，就算输了也不会太心疼，反正也是赢来的。

但其实，不管是怎么赚来的，钱都是钱，并没有什么不同。由于人们对不同账户有不同的预期，因此才会出现很多经济学家看来非理性的行为。

心理账户同样影响着我们的投资决策。在投资中，对于每笔投资，人们常常会无形中构建一个心理账户，这就使得有些投资者更加关注单笔投资的得失，而缺乏大局观。对于亏损的股票，往往出于对亏损的厌恶，不想接受损失而选择继续持有。对于赚钱的股票，往往又想减少波动带来的纠结，更容易选择落袋为安。而当卖出之后，这一笔投资的心理账户才结束。

应对方法：

把整个投资看作一个组合，用长远的眼光看待整个投资组合，而不应过于看重单笔投资的得失。

传统经济学是建立在“理性人”假设之上的，但现实中人们的行为并非都是理性的。为了认清这些人类共有的行为习惯，行为经济学为我们开启了新的视野。

更多内容，一起来阅读理查德·泰勒的《“错误”的行为》，探索行为经济学的奥秘。

多元资产投资方案

投资最痛苦的三件事

 

投资最痛苦的三件事，我不想再遇到

第一件事痛苦的事情，自然是亏钱。亏钱当然会让我们痛苦，这是人性。

人们对于亏钱的感受往往比获利的感受更加强烈，这是因为人的心理存在所谓的“损失厌恶”倾向。这种心理倾向使人们在面对同样数额的损失和获利时，更倾向于避免损失，而对获利的期望和欲望不那么强烈。这是我们远古祖先进化的基因，在资源匮乏的时代，那些更重视避免损失的祖先更有存活下来的机会。

亏钱会让我们现实中的经济压力加大，亏钱让我们的生活捉襟见肘，改善生活的希望变得渺茫，这些都是痛苦的事情。

亏钱还意味着，人们不仅仅面临着金钱上的损失，更会感受到内心深处的痛苦和焦虑。此外，投资亏损与自身投资决策的不确定性和迷茫也有一定的关系。人们容易陷入自我质疑和自责之中，从而增加了心理上的负担，进一步加深了痛苦的感觉。

尤其是这一年，股市上各种黑天鹅不断，经常见证历史，真的很会让人怀疑，自己所积累的对于投资的认知体系，是不是就是错的？一旦陷入到自我否定，或者自己的认知经常被市场打脸，这种痛苦就更加强烈。

所以，这是第一件痛苦的事情，亏钱本身所带来的痛苦。

投资第二件痛苦的事情是，你知道一个股票价格跌的很便宜了，你知道现在就是底部，但是你没有钱买了。

股价从2021年2月的高位199.74见顶，之后因为行业大环境的变化，股价开始暴跌，最低跌到了8.4元，跌幅达到95%。

如果一个人非常看好新东方这个品牌，非常认可俞敏洪这个企业家，从新东方跌到100时，高位下来了跌了50%了，大胆抄底，然后会发现，没用多久，继续腰斩，到了50了，股价只有高位的四分之一了，这时候继续ALL IN进去，满仓抄底，心想再也跌不到哪里去了吧。

结果最低跌到8.4了。这时候这个人很可能还是很看好新东方，坚信一定会起来，尤其是在新东方开始做直播电商以后，但是，这时候发现了非常痛苦的事情：你已经太早进行了补仓，你已经没钱补仓了。

这样，即使新东方之后从低位反弹，借着直播电商涨了好几倍，但是你看着可能只有看着急，因为没钱补了，最后也没解套，因为之前补的太高位了。

这就是为什么说看对了也不一定能赚钱，因为可能买的着急了，买高了，最后没钱补了。这就是第二种痛苦，这种痛苦比光亏钱更痛苦。

第三种痛苦，是最终证明你是对的，但是跟你没关系了。

还是举上面新东方的例子。在新东方下跌的过程中，如果一个人觉得跌的太多了够便宜了，然后融资用了杠杆去抄底，那么他很可能在这样反复腰斩的惨烈行情中爆仓了。如果爆仓的话，自己的本钱很可能就亏光了。

这样的话，即使新东方回到了200美元的最高价，跟他也没什么关系了，因为他的钱已经爆仓亏光了。新东方再好，跟他也没关系了。

看对了，但是因为过程没把握好，最好看的再对，涨的再好，跟你也没关系了，这就是投资中最痛苦的事。

所以，在投资中，心态第一，仓位第二，策略只是第三。如果一个人心态不对，很着急赚钱特别是暴富赚大钱，那么他之后的动作很可能太过激进，也没多少耐心，这样在投资上不容易赚钱。

很多人比较忽略的一个问题是仓位管理。仓位管理不好的话，影响太大了。我们可以对比一下古代行军打仗，很讲究阵法，还有左军右军中军还有预备队等等，这些其实也是仓位管理。做企业做生意也是如此，你得学着流动资金管理，让自己有充分的抗风险抵抗力，否则，现金流一断，你的产品再好，公司也会崩盘。

这些道理都是通的。如何让自己避免这些痛苦的事情：我想关键是一定要牢记三个原则：

1、投资大方向上尽量顺势而为，不要想买在最低，卖在最高，让趋势出来，顺着趋势走。逆势的话，风险太大了，因为谁都不知道底在哪里。

2、仓位管理上尽量能做一个组合，配置到几个标的，同时尽量不要一把满仓，让自己能有一些多一点的容错空间。

3、不是艺高人胆大的专业投资者，不要借钱不要用杠杆去投资。这个不是非常专业的话，很容易亏大钱

GeeksforGeeks | Database Sharding – System Design Interview Concept

Here is the article. 

System design is one of the most important rounds of interviews for software engineers in big tech companies. There are a lot of concepts an engineer should be aware of and database sharding is one of them. Whenever any application starts receiving a huge amount of concurrent requests and it sees significant growth of the users on the website it eventually needs to scale to handle the increasing amount of data or traffic on the website. It’s difficult to predict the growth of the website in the future, and we can’t predict how long a website will maintain its popularity and growth. So we need to scale our database dynamically and database sharding is the technique that can fulfill this job. Let’s understand this concept in detail. 

Database sharding is a technique for horizontal scaling of databases, where the data is split across multiple database instances, or shards, to improve performance and reduce the impact of large amounts of data on a single database.

1. Sharding can be used in system design interviews to help demonstrate a candidate’s understanding of scalability and database design. When designing a sharded database, the following key considerations should be taken into account:
2. Data distribution: How the data will be split across the shards, either based on a specific key such as the user ID or by using a hash function.
3. Shard rebalancing: How the data will be balanced across the shards as the amount of data changes over time.
4. Query routing: How queries will be directed to the correct shard, either by using a dedicated routing layer or by including the shard information in the query.
5. Data consistency: How data consistency will be maintained across the shards, for example by using transaction logs or by employing a distributed database system.
6. Failure handling: How the system will handle the failure of one or more shards, including data recovery and data redistribution.
7. Performance: How the sharded database will perform in terms of read and write speed, as well as overall system performance and scalability.

In summary, database sharding is a complex but important concept in system design that can help to improve the scalability and performance of a database-driven system. A strong understanding of database sharding is often viewed as a key requirement for successful system design.

What is Sharding or Data Partitioning?

Take the example of Pizza (yes!!! your favorite food). You get the pizza in different slices and you share these slices with your friends. Sharding which is also known as data partitioning works on the same concept of sharing the Pizza slices. It is basically a database architecture pattern in which we split a large dataset into smaller chunks (logical shards) and we store/distribute these chunks in different machines/database nodes (physical shards). Each chunk/partition is known as a “shard” and each shard has the same database schema as the original database. We distribute the data in such a way that each row appears in exactly one shard. It’s a good mechanism to improve the scalability of an application. 

Advantages of Sharding

• Solve Scalability Issue: With a single database server architecture any application experience performance degradation when users start growing on that application.  Reads and write queries become slower and the network bandwidth starts to saturate.  At some point, you will be running out of disk space. Database sharding fixes all these issues by partitioning the data across multiple machines.
• High Availability: A problem with single server architecture is that if an outage happens then the entire application will be unavailable which is not good for a website with more number of users. This is not the case with a sharded database. If an outage happens in sharded architecture, then only some specific shards will be down. All the other shards will continue the operation and the entire application won’t be unavailable for the users.
• Speed Up Query Response Time: When you submit a query in an application with a large monolithic database and have no sharded architecture, it takes more time to find the result. It has to search every row in the table and that slows down the response time for the query you have given. This doesn’t happen in sharded architecture. In a sharded database a query has to go through fewer rows and you receive the response in less time.
• More Write Bandwidth: For many applications writing is a major bottleneck. With no master database serializing writes sharded architecture allows you to write in parallel and increase your write throughput.
• Scaling Out: Sharding a database facilitates horizontal scaling, known as scaling out. In horizontal scaling, you add more machines in the network and distribute the load on these machines for faster processing and response. This has many advantages. You can do more work simultaneously and you can handle high requests from the users, especially when writing data because there are parallel paths through your system. You can also load balance web servers that access shards over different network paths, which are processed by different CPUs, and use separate caches of RAM or disk IO paths to process work.

Disadvantages of Sharding

• Adds Complexity in the System: You need to be careful while implementing a proper sharded database architecture in an application. It’s a complicated task and if it’s not implemented properly then you may lose the data or get corrupted tables in your database. You also need to manage the data from multiple shard locations instead of managing and accessing it from a single entry point. This may affect the workflow of your team which can be potentially disruptive to some teams.
• Rebalancing Data: In a sharded database architecture, sometimes shards become unbalanced (when a shard outgrows other shards). Consider an example that you have two shards of a database. One shard store the name of the customers begins with letter A through M. Another shard store the name of the customer begins with the letters N through Z. If there are so many users with the letter L then shard one will have more data than shard two. This will affect the performance (slow down) of the application and it will stall out for a significant portion of your users. The A-M shard will become unbalance and it will be known as database hotspot. To overcome this problem and to rebalance the data you need to do re-sharding for even data distribution. Moving data from one shard to another shard is not a good idea because it requires a lot of downtimes.
• Joining Data From Multiple Shards is Expensive: In a single database, joins can be performed easily to implement any functionalities. But in sharded architecture, you need to pull the data from different shards and you need to perform joins across multiple networked servers You can’t submit a single query to get the data from various shards. You need to submit multiple queries for each one of the shards, pull out the data, and join the data across the network. This is going to be a very expensive and time-consuming process. It adds latency to your system.
• No Native Support: Sharding is not natively supported by every database engine. For example, PostgreSQL doesn’t include automatic sharding features, so there you have to do manual sharding. You need to follow the “roll-your-own” approach. It will be difficult for you to find the tips or documentation for sharding and troubleshoot the problem during the implementation of sharding.

Sharding Architectures

1. Key Based Sharding

This technique is also known as hash-based sharding. Here, we take the value of an entity such as customer ID, customer email, IP address of a client, zip code, etc and we use this value as an input of the hash function. This process generates a hash value which is used to determine which shard we need to use to store the data. We need to keep in mind that the values entered into the hash function should all come from the same column (shard key) just to ensure that data is placed in the correct order and in a consistent manner. Basically, shard keys act like a primary key or a unique identifier for individual rows.  

Consider an example that you have 3 database servers and each request has an application id which is incremented by 1 every time a new application is registered. To determine which server data should be placed on, we perform a modulo operation on these applications id with the number 3. Then the remainder is used to identify the server to store our data.

The downside of this method is elastic load balancing which means if you will try to add or remove the database servers dynamically it will be a difficult and expensive process. For example, in the above one if you will add 5 more servers then you need to add more corresponding hash values for the additional entries. Also, the majority of the existing keys need to be remapped to their new, correct hash value and then migrated to a new server. The hash function needs to be changed from modulo 3 to modulo 8. While the migration of data is in effect both the new and old hash functions won’t be valid. During the migration, your application won’t be able to service a large number of requests and you’ll experience downtime for your application till the migration completes.

Note: A shard shouldn’t contain values that might change over time. It should be always static otherwise it will slow down the performance. 

2. Horizontal or Range Based Sharding 

In this method, we split the data based on the ranges of a given value inherent in each entity. Let’s say you have a database of your online customers’ names and email information. You can split this information into two shards. In one shard you can keep the info of customers whose first name starts with A-P and in another shard, keep the information of the rest of the customers. 

Range-based sharding is the simplest sharding method to implement. Every shard holds a different set of data but they all have the same schema as the original database. In this method, you just need to identify in which range your data falls, and then you can store the entry to the corresponding shard. This method is best suitable for storing non-static data (example: storing the contact info for students in a college.)

Learn more

The drawback of this method is that the data may not be evenly distributed on shards. In the above example, you might have a lot of customers whose names fall into the category of A-P. In such cases, the first shard will have to take more load than the second one and it can become a system bottleneck.

3. Vertical Sharding

In this method, we split the entire column from the table and we put those columns into new distinct tables. Data is totally independent of one partition to the other ones. Also, each partition holds both distinct rows and columns. Take the example of Twitter features. We can split different features of an entity in different shards on different machines. On Twitter users might have a profile, number of followers, and some tweets posted by his/her own. We can place the user profiles on one shard, followers in the second shard, and tweets on a third shard.

In this method, you can separate and handle the critical part (for example user profiles) non-critical part of your data (for example, blog posts) individually and build different replication and consistency models around it. This is one of the main advantages of this method.

The main drawback of this scheme is that to answer some queries you may have to combine the data from different shards which unnecessarily increases the development and operational complexity of the system. Also, if your application will grow later and you add some more features in it then you will have to further shard a feature-specific database across multiple servers.

4. Directory-Based Sharding

In this method, we create and maintain a lookup service or lookup table for the original database. Basically we use a shard key for lookup table and we do mapping for each entity that exists in the database. This way we keep track of which database shards hold which data. 

The lookup table holds a static set of information about where specific data can be found. In the above image, you can see that we have used the delivery zone as a shard key. Firstly the client application queries the lookup service to find out the shard (database partition) on which the data is placed. When the lookup service returns the shard it queries/updates that shard.  

Directory-based sharding is much more flexible than range based and key-based sharding. In range-based sharding, you’re bound to specify the ranges of values. In key-based, you are bound to use a fixed hash function which is difficult to change later. In this approach, you’re free to use any algorithm you want to assign to data entries to shards. Also, it’s easy to add shards dynamically in this approach. 

The major drawback of this approach is the single point of failure of the lookup table. If it will be corrupted or failed then it will impact writing new data or accessing existing data from the table. 

Conclusion

Sharding is a great solution when the single database of your application is not capable to handle/store a huge amount of growing data. Sharding helps to scale the database and improve the performance of the application. However, it also adds some complexity to your system. The above methods and architectures have clearly shown the benefits and drawbacks of each sharding technique. So before you decide to choose any sharding method make sure you compare each one of them and depending on the type of information stored in the database, choose sharding or any one of the sharding techniques.